В этой части серии публикаций, посвящённых протоколу DLMS/COSEM, дается определение интерфейсным классам и их экземплярам, рассматриваются способы обращения к объектам COSEM, приводится структура описания интерфейсных классов и диаграмма классов COSEM. Описывается модель прибора учета, рассказывается о роли логического устройства управления, а также приводится краткое описания системы идентификации объектов (OBIS).
Ссылки на опубликованные части серии публикаций
- DLMS/COSEM – открытый протокол для обмена данными с приборами учета. Часть 1: краткий обзор
- DLMS/COSEM – открытый протокол для обмена данными с приборами учета. Часть 2: интерфейсные классы, модель прибора учета
Интерфейсные классы
Интерфейсные классы являются одним из ключевых элементов протокола DLMS/COSEM, обеспечивающие взаимодействия между системами сбора данных и приборами учета различных производителей. Другими словами, та самая интероперабельность систем сбора данных и приборов учета, т.е. способность взаимодействия друг с другом, достигается, в частности, за счет применения интерфейсных классов. Поскольку и система сбора данных и прибор учета имеют единое представление информации.
Прежде чем дать определение интерфейсному классу рассмотрим сначала его экземпляры, т.е. объекты COSEM. Объекты COSEM представляют собой набор атрибутов и методов. Атрибуты отражают характеристики объекта, а значения атрибутов могут влиять на поведение объекта. Первый атрибут (logical_name) любого объекта содержит в качестве значения логическое имя, которое идентифицирует объект. Методы объекта позволяют или просматривать, или изменять значения атрибутов.
Объекты имеющие общие характеристики (атрибуты и методы) составляют интерфейсный класс, т.е. интерфейсный класс дает описание характеристик, присущих всем объектам этого интерфейсного класса.
Выше сказанное иллюстрирует рисунок 1.
Рисунок 1 – Интерфейсный класс и его экземпляры
На рисунке 1 прибор учета содержит два регистра, т.е. два экземпляра интерфейсного класса «Register». Причем оба экземпляра представляют различную информацию, так объект COSEM с логическим именем
Обратиться к объекту COSEM и считать/записать определенный атрибут или выполнить определенный метод, можно двумя способами, либо через его логическое имя (LN referencing), либо через короткое имя (SN referencing).
В случае обращения к объекту COSEM через логическое имя, ссылка на атрибут состоит из идентификатора класса (class_id), значения атрибута logical_name и параметра attribute_index, а ссылка на метод – из идентификатора класса (class_id), значения атрибута logical_name, и параметра method_index, где:
- attribute_index – индекс (порядковый номер) атрибута. Индексы атрибутов определяются в описании интерфейсного класса, и нумеруются, начиная с 1.
- method_index – индекс (порядковый номер) метода. Индексы методов определяются в описании интерфейсного класса, и нумеруются, начиная с 1.
Описание интерфейсных классов придерживается структуры, представленной на рисунке 2.
Рисунок 2 – Структура описания интерфейсного класса
Назначение определений, используемых в структуре описания интерфейсного класса следующее:
Class name
Название интерфейсного класса (например «Register», «Data», «Clock» и т.д.).Cardinality
Число экземпляров интерфейсного класса в логическом устройстве.Class_id
Идентификатор интерфейсного класса.Version
Версия интерфейсного класса.Attributes
Атрибуты присущие данному интерфейсному классу. Атрибуты могут быть как динамическими (dyn.), их значения обновляет сам прибор учета, так и статическими (static), в этом случае прибор учета не может обновлять их значения сам (например, конфигурационные данные).Logical name
Значение этого атрибута представляется в виде строки байтов (octet string), attribute_index этого атрибута всегда равен 1. По значению этого атрибута идентифицируются экземпляры интерфейсного класса, т.е. объекты COSEM.Data type
Типы данных для атрибута.Min.
Минимальное значение атрибута.Max.
Максимальное значение атрибута.Def.
Значение атрибута по умолчанию.Short name
Короткое имя атрибута или метода если используется SN referencing.Specific method
Методы присущие данному интерфейсному классу.m/o
Тип метода: обязательный (m) или опциональный (o).Пример интерфейсного класса «Register» приведен на рисунке 3, а его описание на рисунке 4.
Рисунок 3 – интерфейсный класс «Register»
Рисунок 4 — Описание интерфейсного класса «Register»
Все интерфейсные классы можно условно разделить на 12 групп, наименование этих групп, а также наименования классов, которые в них входят, приведены на диаграмме классов (рисунок 5 [кликабельный]).
Рисунок 5 — Диаграмма интерфейсных классов (кликабельный)
С кратким описанием интерфейсных классов можно ознакомиться в сокращенной версии голубой книге.
Модель прибора учета
В основе протокола DLMS/COSEM лежит клиент-серверная архитектура. Прибор учета выполняет роль сервера, а система сбора данных – роль клиента. Инициатором обмена информацией является система сбора данных, прибор учета лишь предоставляет требуемую информацию в ответ на запрос системы сбора данных. Однако, в определённых ситуациях сам прибор учета может инициировать обмен данными с системой сбора данных.
На рисунке 6 приведена модель прибора учета. Прибор учета представляет собой физическое устройство (COSEM physical device), в рамках которого есть, как минимум, одно логическое устройство (Management logical device). Использование нескольких логических устройств позволяет реализовать комбинированные приборы учета. Например, теплосчетчик с импульсным входом для измерения расхода воды.
Рисунок 6 – Модель прибора учета DLMS/COSEM
За адресацию как физических, так и логических устройств отвечают нижние уровни используемого стека протокола. Например, при использовании на канальном уровне протокола HDLC, адрес прибора учета представляется в виде последовательности байт, причем возможны три схемы адресации: однобайтовая (только адрес логического устройства), двухбайтовая (адрес логического и физического устройства, значение которых не превышает 127) и четырехбайтовая (адрес логического и физического устройства, значения которых превышает 127). Более подробная информация об адресации при использовании протокола HDLC находится в главе 8 зеленой книге.
Каждое логическое устройство имеет уникальное имя LDN, оно доступно или через объект интерфейсного класса «SAP Assignment», или через COSEM объект «COSEM logical device name» (как правило, это экземпляр интерфейсного класса «Data»).
LDN представляет собой строку байтов размером до 16 байт. Первые три байта – это идентификатор производителя. Производитель гарантирует, что LDN, начинающийся с трех байтов и следующие за ними 13 байтов являются уникальными.
Объект, содержащий LDN, обязательно присутствует в логическом устройстве, как, впрочем, и объекты ассоциации (Association objects).
Для того, чтобы клиент получил доступ к объектам COSEM расположенным на сервере (прибор учета), он должен быть с ним ассоциирован. В процессе ассоциации определяются партнеры (клиент и сервер) и контекст в котором они свяжутся. Основными элементами контекста являются:
- Контекст приложения. Определяется способ обращения к объектам COSEM (LN или SN referencing) и возможность шифрования передаваемой информации.
- Механизм аутентификации. Определяется способ доступа к логическому устройству: открытый доступ (lowest level security), доступ по паролю (low level security), доступ с аутентификацией (high level security using AES128/MD5/SHA-1/GMAC/SHA-256/ECDSA).
- Контекст xDLMS. Определяются параметры прикладного уровня.
- Объекты интерфейсного класса «Association SN» — в случае SN referencing;
- Объекты интерфейсного класса «Association LN» — в случае LN referencing.
Список видимых объектов COSEM находится в атрибуте object_list соответствующего объекта ассоциации.
Как было сказано ранее, в каждом физическом устройстве всегда есть хотя бы одно логическое устройство, которое называется логическое устройство управления (Management logical device). Оно имеет зарезервированный адрес (0x01) и поддерживает ассоциацию публичного клиента с самым низким уровнем секретности. Таким образом, логическое устройство управления всегда находится в открытом доступе.
Основная роль логического устройства управления — представление внутренней структуры физического устройства и поддержка уведомлений о событиях в приборе учета.
Внутренняя структура физического устройства представляется объектом интерфейсного класса «SAP assignment» и содержит SAP и LDN каждого логического устройства. По сути, SAP это и есть адрес логического устройства. Таким образом, для того чтобы узнать сколько логических устройств есть в приборе учета, а также получить их SAP и LDN необходимо считать атрибуты объекта интерфейсного класса «SAP assignment». Этот объект также находится в открытом доступе.
Система идентификации объектов (OBIS код)
Система идентификации объектов определяет идентификационные коды для широко используемых элементов данных в измерительных устройствах. OBIS предоставляет уникальные идентификаторы для всех данных внутри измерительного устройства, включая идентификаторы не только измеряемых значений, но и также идентификаторы абстрактных значений, используемые для конфигурации или получения информация о поведении измерительного оборудования.
Применительно к экземплярам интерфейсных классов COSEM, OBIS код используется в качестве логического имени объекта COSEM и однозначно идентифицирует информацию, которую данный объект представляет.
OBIS код, являющийся значением первого атрибута любого объекта COSEM, представляет собой числовую комбинацию из шести групп цифр. Каждая группа содержит число из диапазона от 0 до 255. Структура OBIS кода и назначение каждой группы чисел следующее:
Группа A
Значение этой группы определяет тип энергоресурса, с которым связано измерение (электричество, тепло, газ и т.п.) или абстрактные данные. Под абстрактными данными понимается та информация, которая присуща прибору учета, а не измеряемой величине. Например, к абстрактным объектам относятся объект, представляющий имя логического устройства, объекты ассоциации, объект, представляющий версию прошивки прибора учета и др.Группа B
Значение этой группы, как правило, определяет номер измерительного канала, но также может определять и номер коммуникационного канала, а в некоторых случаях, и другие элементы. Интерпретация значений этой группы не зависит от значения группы A.Группа С
Значение этой группы определяет наименование измеряемой величины (ток, напряжение, мощность, объем, температура) или абстрактные данные. Интерпретация значения этой группы зависит от значения группы A. Методы обработки, классификации и хранения определяются значениями групп D, E и F. Для абстрактных данных значения групп D, E и F обеспечивают дальнейшую классификацию данных определенных значениями групп A, B и C.Группа D
Значение этой группы определяет типы, или результат обработки физических величин, определенных значениями групп А и С, в соответствии с различными конкретными алгоритмами.Группа E
Значение этой группы определяет дальнейшую обработку или классификацию величин определенных значениями групп A – D.Группа F
Значение этой группы определяет накопленные данные, идентифицируемые через значения групп A – E, в соответствии с различными расчетными периодами.Значения стандартных OBIS кодов доступно для скачивания в виде excel-документа с официального сайта DLMS UA, более подробная информацию об OBIS находится в главе 7 голубой книге.
Комментарии (27)
Jef239
20.06.2016 03:42Было бы полезно прямо в тексте дать ссылку на предыдущую часть.
AlexFTF
20.06.2016 03:52Сделал.
Jef239
20.06.2016 04:28+1Почитал. Не нужен никому этот протокол. НЕ ТУ задачу он решает.
Типовая задач — есть предприятие (завод, кампус, институт), надо купить умные счетчики и организовать учет. Тут лучше проприетарный протокол — он позволяет использовать возможности счетчика на 100%
А DLMS/COSEM исходит из ИНОЙ предпосылки — есть ЗООПАРК разных счетчиков, но 95% поддерживают этот протокол. Причем выгоднее заменить эти 5%, а чем все 100%. То есть счетчиков много.
Что это за задача? Это управление ГОРОДОМ или районом. На худой конец — микрорайоном, домом. Местом, где много разных владельцев и централизованную закупку не сделать.
Встает вопрос — а ЗАЧЕМ владельцам счетчики с возможностью передачи информации? Что с этого получает владелец? При нашей модели, когда электричество оплачивает владелец счетчика — НИЧЕГО. При модели ДОХОДНОГО дома, где за электричество платит владелец дома, а не арендаторы — да, экономический смысл виден.
Так что УВЫ. Какое-то применение в РФ этот протокол найдет лишь лет через 20, и то — ЕСЛИ нормативными документами потребуют, чтобы все новые счетчики имели эту функцию.
В результате получается, что ваш материал интересен лишь разработчикам счетчиков. И то — для продажи их моделей заграницу.AlexFTF
20.06.2016 05:55Почитал. Не нужен никому этот протокол
Проводили опросы?
Типовая задач — есть предприятие (завод, кампус, институт), надо купить умные счетчики и организовать учет. Тут лучше проприетарный протокол — он позволяет использовать возможности счетчика на 100%
Какие возможности прибора учета принципиально невозможно реализовать используя протокол DLMS/COSEM, но которые можно реализовать используя проприетарный протокол?
А DLMS/COSEM исходит из ИНОЙ предпосылки — есть ЗООПАРК разных счетчиков, но 95% поддерживают этот протокол. Причем выгоднее заменить эти 5%, а чем все 100%. То есть счетчиков много.
Зоопарк это место где много животных разного вида за которыми ухаживают и на которых можно посмотреть, как зоопарк соотносится с приборами учета? Здесь вы приводите какие то проценты, откуда они?
Встает вопрос — а ЗАЧЕМ владельцам счетчики с возможностью передачи информации? Что с этого получает владелец? При нашей модели, когда электричество оплачивает владелец счетчика — НИЧЕГО. При модели ДОХОДНОГО дома, где за электричество платит владелец дома, а не арендаторы — да, экономический смысл виден.
Вы тут опять всё в кучу намешали, и физических лиц и юридических… Скажу одно, применение протокола DLMS/COSEM позволяет избавиться, как вы говорите от того самого «ЗООПАРКА», поскольку становится возможным интеграция и взаимодействие оборудования разных производителей, ибо оборудование «одного вида». Вы же не думаете что приборы учета производит только одна компания?
Так что УВЫ. Какое-то применение в РФ этот протокол найдет лишь лет через 20, и то — ЕСЛИ нормативными документами потребуют, чтобы все новые счетчики имели эту функцию.
Россети уже об этом позаботились и сдается мне что этот протокол найдет применение в России не через 20 лет, а гораздо раньше.
Jef239
20.06.2016 08:42Проприетарный протокол может многое… как пример — инкрементальная передача данных, за счет чего можно работать на очень низкой битовой скорости. Например, радиопередатчики LoRa обеспечивают дальность 50-100 км при милливаттах мощности. Но на скорости 20-100 бит в секунду. см. http://www.lora-alliance.org/
Проценты идут из экономической эффективности.
В КАКОЙ ситуации вы видите экономический смысл закупать приборы разных производителей? Придумайте хоть одну такую ситуацию.
Не-а, 20 лет — минимум… КАКАЯ экономическая выгода потребителям, что энергосеть сможет мониторить их счетчики? Выгода идет энергосетям, а не потребителям. Поэтому такие счетчики будут бойкотировать.AlexFTF
20.06.2016 09:39В КАКОЙ ситуации вы видите экономический смысл закупать приборы разных производителей? Придумайте хоть одну такую ситуацию.
Например, в ситуации когда предприятию необходимо модернизировать АСКУЭ, в связи с расширением производства например. В этом случае если на рынке буду представлены более дешевые приборы учета, но другого производителя, есть экономический смысл закупать более дешевые приборы?
Проприетарный протокол может многое… как пример — инкрементальная передача данных, за счет чего можно работать на очень низкой битовой скорости. Например, радиопередатчики LoRa обеспечивают дальность 50-100 км при милливаттах мощности. Но на скорости 20-100 бит в секунду. см. http://www.lora-alliance.org
Протоколов для передачи информации великое множество, DLMS/COSEM — это стек протоколов, он определят несколько уровней модели OSI, например прикладной, канальный и др. Стек протоколов DLMS/COSEM ориентирован в первую очередь на достижение взаимодействия между устройствами различных производителей в области учета энергоресурсов. Любой проприетарный протокол это вещь в себе, я не говорю что они хуже или лучше, нет. Но если все производители будут использовать один протокол обмена данных в своих устройствах, тогда не будет проблем с интеграцией такого оборудования.aquamakc
20.06.2016 11:43Стек протоколов DLMS/COSEM ориентирован в первую очередь на достижение взаимодействия между устройствами различных производителей в области учета энергоресурсов.
Для таких случаев давно придумано решение — OPC. Есть верхний уровень системы, есть OPC прослойка. Если руководство компании настолько некомпетентно, что решает превратить номенклатуру приборов учёта в зоопарк — добавляется драйвер (интерпретатор, переводчик, неважно, как называется) нового прибора для OPC сервера. Верхний уровень уже работает с универсальными данными.
По факту у вас всёго-лишь ещё один «универсальный» протокол приборов учёта.AlexFTF
20.06.2016 11:53Еще раз, DLMS/COSEM это стек протоколов который определят и способ представления данных и способ их передачи, конкретно для систем учета энергоресурсов. OPC технология регламентирует только интерфейс между OPC-клиентами и OPC-серверами. И она абсолютно не регламентирует способ получения этих данных от оборудования.
По факту у вас всёго-лишь ещё один «универсальный» протокол приборов учёта
Приведите, пожалуйста, альтернативу протоколу DLMS/COSEM или те самые «ещё одни универсальные протоколы».aquamakc
20.06.2016 12:53OPC технология регламентирует только интерфейс между OPC-клиентами и OPC-серверами. И она абсолютно не регламентирует способ получения этих данных от оборудования.
В том то и прелесть, что OPC технологии совершенно неважно откуда и как пришли данные. Задача только в том, чтобы преобразовать полученную последовательность байт по стандарту OPC в соответствии со спецификацией протокола и наоборот. Преобразование происходит на промежуточном уровне между железом и SCADA системой, ни верх, ни низ, при этом занимаются своими делами совершенно не заботясь о взаимной совместимости.
Это нам даёт возможность объединения в одной системе разнотипного оборудования разных годов выпуска, работающего по различным каналам связи с применением любого протокола обмена.AlexFTF
20.06.2016 18:11Вы все правильно говорите, и так сейчас в принципе делается. Однако в такой системе слабым местом, как раз является та самая прослойка между «железом» и SCADA. Поскольку при изменении протоколов обмена в оборудовании придется ее менять, а производители вряд-ли будут гарантировать неизменность своих проприетарных протоколов. Ведь рынок это динамичная структура, сегодня одни производители, завтра другие, вот и получается что потребитель, в лице дочерних компаний Россетей, покупает не только прибор учета но и еще в довесок к нему «переводчика». А зачем тратить деньги на дополнительное оборудование, когда от него можно отказаться? В частности, эту возможность предоставлет стек протоколов DLMS/COSEM. Поскольку он напрямую ориентирован на организацию обмена данными между приборами учета и системами сбора данных, менуя аппаратную прослойку между уровнем представления данных и транспортным уровнем.
Jef239
21.06.2016 03:52Вы не понимаете роли OPC. Сейчас все SCADA его используют. Одни — как единственный протокол, другие — как основной (при вспомогательном старом проприетарном).
В итоге все приборы, предназначенные для автоматизации, имеют OPC-сервера. то есть при замене мы просто покупаем пару — прибор + OPC-сервер к нему.
Относительно отказа от OPC — планируется написание собственных SCADA? Или просто OPC-сервер, переводящий ваш протокол в OPC?
А что с OPCHD, то есть с ведением архивов? у вас есть свой собственный аналог?
Jef239
21.06.2016 03:32На равновесном рынке отличия в стоимости — 5-10 процентов, не больше. ПОЧЕМ производитель Б продает в 2 раза ешевле, чем А? Он что, не хочет денег? Значит по каким-то параметрам у Б прибор хуже. А зоопарк вендоров — это увеличение стоимости обслуживания и увеличение цены отказа. Так что экономический смысл менять вендора бывает редко.
Вы не сравнивайте счетчики с компами — у компов технология все время развивается, поэтому рынок изначально неравновесный. Хотя на рынке мониторов — четко видно, что при одинаковых характеристиках отличие цен довольно мало и определяется логистикой дилера.
Проблемы с интеграцией ваш протокол решает лишь для тривиальных случаев. ПРИМЕР. Учет газа. Важная характеристика — влажность. В чем она? В процентах? В граммах на тонну? В миллилитрах на кубометр? В вашем протоколе специфицированы такие тонкости?
AlexFTF
21.06.2016 08:26Уважаемый Jef239, DLMS/COSEM это не мой протокол, это международный стандарт. Вижу, что об этом стандарте вы знаете только из моих двух публикаций. Поэтому предлагаю закончить безпредметную дискуссию и дождаться либо других моих публикаций, посвещенных данному стеку протоколов, либо можете сами ознакомиться более подробно с этим набором протоколов, прочитав голубую и зеленую книгу. Тогда у вас как минимум невозникет вопросов про «учет газа», про «отказ от ОРС», про «ведение архивов».
Отвечая на ваш вопрос про учет газа, скажу, что в протоколе DLMS/COSEM такие тонкости специфицированы.Jef239
21.06.2016 09:36Спецификация таких тонкостей — это ужасно. Известный факт — язык, который нельзя модифицировать, умирает. см. например, историю BASIC engish. Чем тогда будут отличаться приборы учета? К какую сторону пойет развитие? Или развитие приведет к тому, что новые поля будут у всех разные. Или — развитие остановится и стандарт умрет, не распространившись.
Действительно, спор беспредметен. Мы говорим о протоколах, которые использовали в СВОИХ системах. У вас, как я понимаю, ни одной реализованной ВАМИ системы нет. Потому и получается спор практиков с теоретиками.
Jef239
23.06.2016 06:14Еще одна вещь, которой нету в DLMS/COSEM — это функциональность, не относящаяся к учету. Ваш протокол — он же стандартный и не изменяемый. В отличие от всех остальных, развить его невозможно.
Киллер-фича — квартирный счет с пожарной и охранной сигнализацией. Ценой небольшого усложнения прошивки счетчика — экономим на отдельных пожарных и охранных сигнализациях. Застройщики в восторге будут.
Но… передача алармов не ложиться в клиент-серверную модель. Тут нужна передача по иницативе счетчика.aquamakc
23.06.2016 09:19Справедливости ради охрана и пожарка — не счётчика дело. И не надо навешивать на устройство нетипичных для его типа задач.
Другое дело, если мы хотим организовать условное единое информационное пространство. «Умный дом» + «Умное ЖКХ». Но опять-же данный «Универсальный протокол» в этом деле нам не поможет.Jef239
23.06.2016 16:59Сигнализации должны быть всегда подключены. Служба охраны не знает — то ли пробки перегорели, то ли воры обрезали провода к датчику охраны. Выезд ОМОНа на перегоревшую из-за КЗ пробку — ещё так веселуха.
Так что логично размещать сигнализацию в счетчике, то есть ДО пробок.
Действительно, это шаг в сторону «умного здания». Сейчас и так в новых домах монтируется видеонаблюдение в подъездах + контролирующая его служба охраны (или консьержей). Ценой небольшого удорожания счетчиков получаются приличные маркетинговые преимущества.
Автоматизация выписки счетов за электричество — не так важна для жильцов, как дешевая и надежная система охраны.aquamakc
23.06.2016 17:02Все системы охранных и пожарных сигналок, которые я видел имеют возможность подключения резервного источника питания, как правило это АКБ 1207.
Jef239
23.06.2016 17:19Ну 1207 это такой гроб… Боюсь, что в реальной жизни — это всего лишь возможность…
В любом случае — плюсы от такого решения есть.
Ещё один плюс — счетчик знает энергопотребление в квартире. То же снятие с охраны можно сделать как 2 раза включить и выключить лампочку определенного номинала. Например — включаем в коридоре и в туалете.
Ну и контроль, что всё выключили, уходя из квартиры.
progchip666
Интересно, много ли приборов поддерживают подобный протокол в России. Почему то кажется что если и существуют такие то только совсем свежие разработки. Сомнительно как то что подобный протокол реализовывали каких нибудь 51 совместимых микроконтроллерах или пиках.
AlexFTF
Возможно есть решения на базе DLMS/COSEM и других отечественных производителей, но я таковых пока не встречал. Может плохо смотрел, не знаю, но если у кого-нибудь есть информация о решениях на базе DLMS/COSEM Российских производителей, будут рад если эту информацию предоставят в комментариях.
Для 51 не знаю, но для «пиков» есть готовый стек DLMS/COSEM, в журнале КиТ можно прочитать короткую заметку о нем, для msp430 есть готовый стек, пост на habrahabr о нем здесь
progchip666
Спасибо. Тема интересная но судя по всему будет внедряться поначалу всё таки в топовых продуктах, хотя для разработчиков именно это возможно и представляет повышенный интерес.
Как любое универсальное решение выглядит несколько громоздко, но при условии наличия бесплатного стека может найти своё применение в системах сбора данных. Встаёт правда ещё тема регистрации компании производителя для получения идентификатора — процедура может быть сложной и недорогой.
Вообще немного странно выглядит что существуют стеки для пиков и MPS, а не для ARM в которых с ресурсами всё много проще или там этот стек стандартными методами реализуется без кастомизации какой либо?
AlexFTF
Наверняка и для ARM контроллеров есть готовые стеки, просто я эту тему не зондировал. Встречал зарубежные конторы у которых можно стек купить, а раз можно купить значить они могут и адаптировать его под конкретный контроллер. Думаю что это лишь вопрос цены.