Сервисный элемент CMS (CAN based Message Specification) представляет собой язык описания и манипуляции с объектами распределенного приложения. Доступ узлов приложения к CMS-объектам осуществляется в модели клиент-сервер (Client-Server). При этом сервером является узел, управляющий исполнительным механизмом, а клиент – узел, дающий сигнал на его включение или выключение.
CMS предоставляет возможность задаче моделировать свое поведение через объекты и удаленный сервис для этих объектов. Для этого CMS предлагает 3 типа объектов: переменная (Variable), событие (Event) и домен (Domain).
Объекты типа Переменная (Variable) обеспечивает передачу данных, инициируемую клиентом. Переменные обеспечивают обмен данными размером не более 8 байт, то есть обмен данными осуществляется с помощью передачи всего одного COB’а.
Примером применения такого объекта может служить тревожная сирена. Сервер объекта – узел, непосредственно управляющий сиреной. Клиент – узел, вырабатывающий управляющий сигнал на включение или выключение. Управление сиреной осуществляется передачей (записью) требуемого булевского значения клиентом серверу (рисунок 2.4)
Рисунок 2.4 – Пример CMS-модели для управления сиреной
Для описания каждого объекта стандарт предусматривает сервис Define, определяющий атрибуты объекта (таблица 2.1).
Таблица 2.1 – Атрибуты CMS-объектов
Атрибут
Описание
Name
Каждый CMS объект в рамках одного распределенного приложения имеет уникальное символическое имя, которое должно быть одно и то же на клиентах и серверах объекта. Используется для динамического распределения СОВ-ID. При статическом распределении СОВ-ID имя может не использоваться.
User Type
При определении объекта на узле распределенного приложения необходимо указать, кем по отношению к объекту является узел – клиентом или сервером.
Priority
Приоритет СОВ’а(ов), используемых объектом. Используется при динамическом распределении COB-ID. При статическом распределении СОВ-ID не используется, т.к. СОВ-ID’ы задаются при определении объекта.
Inhibit Time
Время запрещения – минимальное время между двумя передачами СОВ'а. Каждый узел может указать собственное значение. При динамическом распределении СОВ’ов DBT укажет единое значение для всех узлов, использующих этот объект.
Data Type (Variables и Events)
Передаваемые данные могут иметь различный тип. Тип служит для определения размера передаваемых данных и гарантирует одинаковое представление данных на разнотипных узлах.
Error Type (Variables и Events)
Подтверждаемые сервисы могут возвращать ошибки. Атрибут определяет тип данных, соответствующих возвращаемому коду ошибки.
Class:
Variables
Events
Domains
Переменная может относиться к одному из двух классов: базовая (Basic) или мультиплексная (Multiplexed). Для мультиплексной переменной дополнительно должны быть заданы Variable Set Name и Multiplexor. Несколько мультиплексных переменных на одном множестве используют одинаковые СОВ’ы.
Событие может относиться к одному из трех классов: неуправляемое (Uncontrolled); управляемое (Controlled), клиент может запретить или разрешить серверу оповещение о событии; событие с памятью (Stored), сервер осуществляет оповещение о событии, кроме того, клиент может прочесть данные события, как для ReadOnly переменной.
Домен может относиться к одному из двух классов: базовый (Basic) или мультиплексный (Multiplexed). Domains Мультиплексный домен благодаря различным значениям мультиплексора обеспечивает передачу различных данных некоторого узла, используя один и тот же СОВ.
Access Type (Variables)
Тип доступа клиента к переменной. Допустимые значения:
– только для записи (WriteOnly), для такой переменной клиент может записать новое значение переменной, сервис чтения значения переменной отсутствует;
– только для чтения (ReadOnly), для такой переменной клиент может прочесть значение переменной, сервис записи значения переменной отсутствует;
– для чтения и записи (ReadWrite), клиент может как читать, так и писать значение переменной.
Variable Set Name (Multiplexed Variables)
Имя множества, объединяющего несколько мультиплексных переменных. Мультиплексные переменные, принадлежащие одному и тому же множеству, имеют один и тот (те) же СОВ-ID. Используется при динамическом распределении COB-ID.
Multiplexor
Мультиплексор (индекс), позволяющий различить мультиплексные переменные на одном множестве.
Multiplexor Data Type (Multiplexed Domains)
Для правильной интерпретации мультиплексора на клиенте и сервере следует обеспечить их одинаковое представление, что обеспечивается указанием типа данных мультиплексора.
В зависимости от значений атрибутов Class и Access Type переменная может требовать одного COB’а для передачи данных от сервера клиенту – неподтверждаемый сервис (рисунок 2.3), либо двух, в том случае, если протокол требует запроса и подтверждения (результата) – подтверждаемый сервис. Назначение COB’ов выполняется сервисным элементом DBT.
Для манипуляции с переменными стандарт предусматривает сервисы чтения (Read), записи (Write) и обновления (Update) данных.
Объекты типа Событие (Event) обеспечивают передачу данных, инициируемую сервером. События обеспечивают обмен данными размером не более 8 байт.
Примером применения такого объекта может служить датчик считывания смарт-карты, используемой в качестве пропуска (рисунок 2.5). Сервер объекта – узел, содержащий считыватель и оповещающий заинтересованные узлы о прикладывании пропуска. Клиент – узел, принимающий событие. Данные события – код пропуска.
Рисунок 2.5 – Пример CMS-модели считывания смарт-карты
При определении события с помощью сервиса Define необходимо указать его атрибуты (таблица 2.1).
Для манипуляции с событиями стандарт предусматривает сервисы оповещения (Notify), чтения (Read), обновления (Store) данных и изменения статуса (Set Control State).
Объекты типа Домен (Domain) обеспечивают передачу данных, инициируемую клиентом. Размер массива не ограничен.
В качестве примера сервера мультиплексного домена можно рассмотреть узел, выполняющий считывание различных данных с некоторого лабораторного оборудования. При этом мультиплексор будет определять то, какие данные требуется получить клиенту (рисунок 2.6).
Рисунок 2.6 – Пример CMS-модели для считывания блока данных
При определении события с помощью сервиса Define необходимо указать его атрибуты (таблица 2.1).
Передача больших блоков данных с помощью домена обеспечивается за счет разбиения блока данных на сегменты, помещающиеся в один СОВ. Таким образом, для сегментированного приема и передачи стандарт предусматривает сервисы инициализации передачи (Initiate Domain Download, Initiate Domain Upload), собственно передачи сегмента (Download Domain Segment, Upload Domain Segment) и прерывания обмена( Abort Domain Transfer). Причем если инициатором обмена может выступать только клиент, то прервать обмен может как клиент, так и сервер.
При использовании сегментированного обмена ответственность за правильность разбиения домена на сегменты и определения завершения передачи лежит на прикладной программе. Если же применять несегментированный сервис (Domain Download, Domain Upload), то все управление обменом выполняет CAL.
