Сервер VXI-11 на платформе QNX Neutrino

Введение

Программно-управляемые измерительные приборы находят всё более широкое применение в контрольно-измерительных комплексах, испытательных стендах и различных автоматизированных системах. Уже многие годы действуют международные стандарты на аппаратное и программное обеспечение интерфейсов связи программно-управляемой аппаратуры с управляющими компьютерами: IEEE 488.1, IEEE 488.2, VXIplug&play 4.X, VXI-11.X и др. На сегодняшний день наиболее распространённым приборным интерфейсом является IEEE 488. Им оснащается подавляющее большинство аппаратуры таких фирм, как Agilent Technologies, Tektronix, Rohde&Shwartz, ННИПИ «Кварц» и др. С помощью специальных интерфейсных плат и таких программных продуктов, как NI VISA (National Instruments) или AG VISA (Agilent Technologies), достаточно просто организовать обмен данными между управляющим компьютером и приборами, подключёнными к шине IEEE 488, что уже давно оценено российскими и зарубежными разработчиками контрольно-измерительных систем.

На рубеже XX и XXI веков невысокая пропускная способность шины IEEE 488 и другие принципиальные ограничения заставили производителей измерительной аппаратуры оснащать свои изделия дополнительными высокоскоростными интерфейсами Ethernet 10/100/1000 Гбит/с, USB, IEEE 1394. Вновь выпускаемое оборудование всё чаще совсем не поддерживает интерфейс IEEE 488, но благодаря реализации производителями требований таких стандартов, как VXIplug&play 4.X и VXI-11.X, сохраняется преемственность способов взаимодействия программ пользователей с измерительной аппаратурой.

К сожалению, отечественные фирмы-производители, в своё время хорошо освоившие шину IEEE 488, не торопятся оснащать свои приборы современными скоростными последовательными интерфейсами. Причина такой неторопливости не связана со сложностью интеграции в приборы аппаратной части интерфейсов, а кроется в проблемах логической совместимости со спецификациями VXI-11.X и VXIplug&play 4.X. То есть техническая возможность оснастить прибор интерфейсом, например Ethernet 100Base-T, есть, но для того чтобы иметь возможность управлять данным прибором так же, как и приборами других производителей, необходимо реализовать и разместить в приборе программное обеспечение, соответствующее опубликованным спецификациям консорциумов VXI и VXIplug&play.

Существенно сократить затраты, связанные с внедрением в приборостроительной отрасли новых связных интерфейсов, можно с помощью встраиваемой микропроцессорной техники. Предпосылками этого являются снижение стоимости компактных, быстродействующих микропроцессорных плат, уже оснащённых необходимыми интерфейсами, и появление мультиплатформенных встраиваемых операционных систем. Как в таком окружении организовать обмен данными между измерительным прибором и управляющим компьютером в соответствии со стандартным протоколом? Ответу на этот вопрос и посвящена данная статья.

Архитектура клиент-сервер для распределённых измерительных систем

По мере совершенствования вычислительной техники и средств коммуникации всё чаще контрольно-измерительные комплексы рассматриваются как распределённые многопроцессорные системы (рис. 1). 

Измерительные средства, входящие в состав таких комплексов, управляются встроенными микропроцессорами, а обмен данными с управляющими узлами осуществляется посредством каналов Ethernet или USB. За счёт открытости и распространённости применяемых связных интерфейсов упрощаются разработка, сопровождение, расширение таких комплексов, а ограничения на пространственное размещение аппаратных средств практически отсутствуют.

Спецификация VXI-11 [1] консорциума VXI определяет механизмы и логику взаимодействия приборов, оснащённых интерфейсом Ethernet, c управляющим компьютером. Хотя данная спецификация и выпущена под эгидой консорциума VXI, но к шине VXIbus никакого отношения не имеет и может применяться (и применяется) к любым приборам, управление которыми сводится к выдаче команд и операциям чтения/записи символьных буферов (аналогично IEEE 488.1 и/или IEEE 488.2).

Определим прибор (вернее, логический блок прибора, «обращённый» наружу через Ethernet) как приборный сервер (Network Instrument Server), а программу, выполняющуюся на управляющем компьютере, как клиент прибора (Network Instrument Client).

Стек протоколов, задействованных при обмене информацией между приборным сервером и приборным клиентом, описывается в таблице 1. Два самых нижних уровня стека протоколов должны быть реализованы драйвером сетевого ввода/вывода и никакой специфики, связанной с рассматриваемой задачей, не имеют. Сеансовый уровень определён как ONC/RPC (Open Network Computing / Remote Procedure Call), а внешнего представления данных – XDR (External Data Representation). Наиболее известная реализация данных спецификаций – пакет Sun RPC фирмы Sun Microsystems [2], который входит в состав дистрибутивов большинства операционных систем семейства Unix. Для семейства Windows доступны коммерческие реализации ONC/RPC + XDR.

Прикладной уровень подробно описан в спецификации VXI-11 [1], где определены интерфейсы вызываемых посредством RPC функций и правила реализации внутренней логики приборного сервера и его клиента. Всего определены три канала (Channels) для информационного взаимодействия: основной (Core), прекращения (Abort) и прерываний (Interrupt). Распределение процедур по каналам показано в таблице 2.

Вызов всех процедур через RPC осуществляется по инициативе приборного клиента (каналы Core и Abort). Исключением является device_intr_srq() – эта процедура вызывается по инициативе сервера, в этом случае происходит обмен ролями между сервером и клиентом.

Для успешной работы RPC на стороне сервера должен быть запущен демон (скрытая от пользователя служебная программа) portmap или rpcbind [2]. Для успешной работы клиента наличие процессов portmap или rpcbind необязательно.

Взаимодействие приборного сервера и клиента начинается с вызова клиентом процедуры create_link(). При первом вызове данной процедуры сервер должен открыть свободный порт, запустить процесс, где данный порт будет прослушиваться. Номер прослушиваемого порта должен быть возвращён клиенту в качестве порта канала Abort. Кроме номера порта, функцией create_link() должны быть возвращены код ошибки (0 – успех), идентификатор соединения (произвольное число) и максимально допустимое число байтов для сообщений устройству. При последующих вызовах create_link() значения возвращаемых параметров должны быть тождественны значениям при первом вызове.

После того как соединение установлено, клиент может вызывать любые другие процедуры каналов Core и Abort. Обязательными для реализации на стороне приборного сервера являются процедуры device_write(), device_read(), device_lock(), device_unlock(). Остальные процедуры могут быть не реализованы, то есть при вызове возвращать код ошибки 8 (operation not supported). Примечательно, что в спецификациях [3, 4, 5] определены рекомендуемые шаблоны поведения приборов. Шаблоны представляют собой комплекты правил (ограничений) для реализации процедур таким образом, чтобы поведение приборов соответствовало спецификациям VXIbus [3], IEEE 488.1 [4] и IEEE 488.2 [5].

По завершении работы с прибором клиент должен ликвидировать соединение посредством вызова процедуры destroy_link(). После того как успешно отработала данная процедура, работа с прибором возможна только после вызова create_link().

Создание сервера VXI-11 на платформе QNX

Одним из способов оснащения прибора интерфейсом Ethernet является применение готовой микропроцессорной платы, поддерживающей данный интерфейс. Компактные и функциональные устройства данного типа выпускаются фирмами Octagon Systems, Fastwel, Advantech и др. Абстрагироваться от аппаратной реализации микропроцессорных плат можно, выбрав в качестве операционной системы RTOS QNX Neutrino. Основные предпосылки такого выбора: близость QNX Neutrino к операционным системам Unix и, как следствие, наличие реализации ONC/RPC, а также широкая номенклатура поддерживаемых аппаратных платформ.

Итак, имеем процессорную плату с интерфейсом Ethernet и развёрнутым пакетом QNX Momentics 6.3 (среда разработки). Кроме серверной части, понадобится клиент – пусть его роль будет выполнять ПЭВМ под управлением операционной системы Windows XP. На клиентском вычислительном узле должны быть развёрнуты программы AG VISA (библиотека ввода/вывода для взаимодействия с приборами доступна по адресу http://adn.tm.agilent.com/index.cgi?CONTENT_ID=1035&LAST_CONTENT_ID=747) и NTRpcInfo (аналог Unix-утилиты rpcinfo, доступна по адресу http://www.securitylab.ru/software/232914.php).

Попробуем посмотреть на реальный прибор и наш сервер со стороны клиента. В качестве прибора, уже поддерживающего спецификацию VXI-11, возьмём генератор сигналов Agilent Technologies 33220А. Пусть IP-адрес прибора будет 192.168.10.94, а создаваемого сервера — 192.168.10.81. Воспользуемся утилитой NTRpcInfo для получения информации о механизме и процедурах RPC на данных сетевых узлах (листинг 1). 

Из этого эксперимента видно, что в генераторе сигналов зарегистрированы две программы, процедуры которых можно вызвать посредством ONC/RPC по протоколу TCP. Согласно спецификации [1] номер 395183 имеет канал Core, то есть все процедуры, определённые для данного канала, могут быть вызваны удалённо. Программа под номером 395180 в спецификациях VXI-11 не определена. Для разрабатываемого же сервера каналы Core и Abort не определены (что совершенно естественно), а эксперимент показывает наличие полноценной службы распределения портов ONC/RPC (зарезервированные для такой службы идентификатор 100000 и порт 111), поддерживающей одновременно 3 версии спецификации ONC/RPC на базе протоколов ТСР и UDP. Тот факт, что программ с идентификатором 100000 нет в генераторе, означает, что полноценного распределителя портов там тоже нет, а развернута только урезанная реализация, рассчитанная на работу только с двумя программами (395183 и 395180).

Генерация ONC/RPC-заглушки

Первое, что необходимо сделать на пути к реализации сервера VXI-11, — это создать файлы-заглушки серверной части. Роль заглушки – ожидание запросов со стороны клиента на запуск процедур с известной сигнатурой и по приходу таких запросов вызов этих процедур с передачей им полученных от клиента параметров. Так как интерфейсы RPC-процедур различны, то и заглушка для каждого нового интерфейса должна быть сгенерирована заново.

Интерфейсы процедур каналов Core, Abort и Interrupt определены в спецификации VXI-11 с использованием нотации RPCL (RPC Language). Необходимо скопировать спецификацию каналов Core и Abort в файл с расширением «.x» (спецификацию канала Interrupt копировать не надо, так как данная программа должна поддерживаться клиентом, а не сервером). В состав операционных систем семейства Unix обычно входит утилита rpcgen, которая предназначена для генерации кода заглушек RPC; есть такая утилита и в QNX Momentics. Пусть спецификации каналов Core и Abort помещены в файл Device.x. Попробуем сгенерировать заглушку средствами QNX Momentics:

$rpcgen –C /tmp/Device/Device.x

cannot find any C preprocessor (cpp)

Весьма неожиданный результат: утилита rpcgen есть, а сгенерировать заглушку с её помощью нельзя. К сожалению, в составе QNX Momentics 6.3 отсутствует препроцессор glibc, и утилита rpcgen неработоспособна. Поэтому для генерации придётся воспользоваться какой-либо другой Unix-системой (так как сгенерировать код заглушки нужно только один раз, то это не должно вызвать особых затруднений), например FreeBSD или Linux. Итак, копируем Device.x на компьютер с FreeBSD и снова запускаем rpcgen:

$rpcgen –C /tmp/Device/Device.x

Никаких сообщений нет, а в директории /tmp/Device появились файлы Device.h, Device_clnt.c, Device_svc.c, Device_xdr.c. Назначение этих файлов:

• Device.h – прототипы функций, которые будет вызывать заглушка при получении запросов от клиента (их необходимо будет реализовать);

• Device_clnt.c – заглушка клиента (для реализации сервера не понадобится);

• Device_xdr.c – содержит функции, необходимые для преобразования заглушкой данных в соответствии со стандартом XDR;

• Device_svc.c – собственно код заглушки, уже содержащий функцию main().

Дальнейшая задача построения каркаса сервера сводится к созданию проекта приложения QNX Neutrino на базе сгенерированных rpcgen-файлов и добавления файла с реализацией объявленных в Device.h функций. Создание проекта приложения (организация иерархии директорий и генерация make-файла) – достаточно тривиальная процедура, она подробно описана в документации по QNX Momentics и в [6]. А в исходный код нужно внести некоторые изменения.

1. Добавим файл, содержащий реализацию функций каналов Core и Abort, назовём его Device_server.c (функции объявлены в Device.h).

2. Для того чтобы каркас сервера удалось скомпилировать и запустить, необходимо в реализации каждой функции, объявленной в Device.h, создать статический экземпляр структуры, возвращаемой этой функцией, присвоить полю error данной структуры значение 0 и вернуть адрес этой структуры. Например:

...

Device_Error *

device_abort_1_svc(Device_Link *argp, struct svc_req *rqstp){

static Device_Error result;

result.error = 0;

return &result;

}

Create_LinkResp *

create_link_1_svc(Create_LinkParms *argp, struct svc_req *rqstp){

static Create_LinkResp result;

result.error = 0;

static &result;

}

...

3.            В файле Device_svc.c функцию main() необходимо привести к виду:

...

int main (int argc, char **argv){

//Сетевой транспорт

register SVCXPRT *transp;

//Сброс кан. Abort

pmap_unset (DEVICE_ASYNC,

DEVICE_ASYNC_VERSION);

//Сброс кан. Core

pmap_unset (DEVICE_CORE,

DEVICE_CORE_VERSION);

//Сетевой транспорт

transp=svctcp_create(RPC_ANYSOCK,0,0);

if (transp == NULL) {

fprintf (stderr, "%s",

    "cannot create tcp service.");

exit(1);

}

//Регистрация канала Abort

if (!svc_register(transp, DEVICE_ASYNC, DEVICE_ASYNC_VERSION,

device_async_1, IPPROTO_TCP)) {

fprintf (stderr, "%s", "Portmap: unable to register (DEVICE_ASYNC).");

exit(1);

}

//Регистрация канала Core

if (!svc_register(transp, DEVICE_CORE, DEVICE_CORE_VERSION,

device_core_1, IPPROTO_TCP)) {

fprintf (stderr, "%s", "Portmap: unable to register (DEVICE_CORE).");

exit(1);

}

//Запуск сервера в режим ожидания запросов

svc_run ();

fprintf (stderr, "%s\n", "svc_run returned");

exit (1);

}

Надо отметить, что по неизвестной причине идентификатор канала Abort именуется в спецификации RPCL [1] и, соответственно, в Device.h как DEVICE_ASYNC, а не DEVICE_ABORT, как следовало бы ожидать.

Изменения, которые необходимо внести в main() из Device_svc.c (после отработки rpcgen), заключаются в удалении кода, отвечающего за создание транспортной службы UDP и регистрацию каналов Core и Abort, доступных через эту службу (согласно VXI-11 транспорт UDP не поддерживается).

После того как написана некоторая реализация функции каналов Core и Abort и скорректирована функция main(), можно скомпилировать полученный каркас в исполняемый модуль. На данном этапе будет полезно протестировать корректность реализации каркаса. Для этого запускаем на стороне прибора (QNX) portmap и модуль каркаса сервера. Воспользуемся снова утилитой NTRpcInfo на стороне клиента (Windows):

С:\tmp>ntrpcinfo 192.168.10.81

Getting RPC information for: 192.168.10.81

...

=================================

Program: **DONE**

Program ID : 395184

Version: 1

Port: 1022

Protocol: TCP

=================================

Program: **DONE**

Program ID : 395183

Version: 1

Port: 1022

Protocol: TCP

Эксперимент показывает, что на стороне сервера дополнительно к программе службы распределения портов появились программы с идентификаторами 395183 и 395184, которые и представляют собой каналы VXI-11. То есть каркас приборного сервера готов и функционирует в соответствии со спецификацией, теперь необходимо наполнить каркас функциональностью.

Реализация Core-интерфейса сервера

Основная функциональность сервера VXI-11 сосредоточена в канале Core. Всего в данном интерфейсе определено 15 функций (процедур). Начинается любое взаимодействие клиента с приборным сервером с установления соединения (connection), то есть с вызова процедуры create_link(). Рассмотрим реализацию данной функции более подробно.

Входные параметры поступают в процедуру create_link() посредством структуры Create_LinkParms, а выходные возвращаются через Create_LinkResp:

struct Create_LinkParms {

//Идентификатор клиента

long clientId;

//Признак блокировки устройства

//(0 – блокировать, 1 – нет)

bool_t lockDevice;

//Интервал ожидания (мс) возможности

//заблокировать устройство

u_long lock_timeout;

//Наименование типа устройства

char *device;

};

struct Create_LinkResp {

//Код ошибки

Device_ErrorCode error;

//Уникальный идентификатор соединения

Device_Link lid;

//Номер порта канала Abort

u_short abortPort;

//Максимальный размер ожидаемого

//устройством сообщения

u_long maxRecvSize;

};

Значение идентификатора клиента никак не влияет на алгоритм установления соединения. В спецификации [1] рекомендуется сохранять данное значение в протоколе работы сервера, что может быть полезным при анализе сбоев в его работе.

При первом вызове процедуры create_link() сервер должен сгенерировать уникальный идентификатор соединения lid и вернуть его. При последующих вызовах всегда возвращается lid, сгенерированный при первом обращении, и изменяется значение счётчика вызовов create_link() (счётчика соединений). Следует отметить, что соединение может быть аннулировано с помощью функции destroy_link(), при вызове которой счётчик соединений уменьшается на единицу, а при достижении значения 0 соединение с данным lid прекращает своё существование, и при последующем вызове create_link() должен быть сгенерирован новый идентификатор соединения.

Признак блокировки устройства lockDevice позволяет одному соединению заблокировать другие соединения, то есть пока для конкретного lid не будет вызвана процедура device_unlock(), запросы на вызов большинства процедур будут возвращать код ошибки 11 (устройство заблокировано другим соединением). Такое поведение имеет смысл, если через текущий сервер доступно не одно, а несколько различных устройств. Например, в приборе имеются независимые блоки А и Б. Соединения устанавливаются независимо для каждого из блоков. Тип блока, для которого устанавливается соединение в данном вызове create_link(), определяется через входной строковый параметр device. В одном случае этот параметр будет иметь значение “Block A\n” и lid, равный 3742, а в другом – “Block B\n” и lid, равный 8452. При блокировке сервера соединением 3742 (блок А) взаимодействия клиентов с соединением 8452 (блок Б) будут запрещены (процедуры будут возвращать код ошибки).

Попытка установить соединение с заблокированным сервером будет завершена с ошибкой не сразу, а по истечении интервала времени, указанного в параметре lock_timeout (мс). То есть в течение заданного интервала необходимо ожидать снятия блокировки сервера.

Выходной параметр abortPort представляет собой не что иное, как коммуникационный порт протокола IP, через который клиент может вызвать функцию device_abort() для прерывания исполняемой устройством команды, то есть это порт канала Abort. В спецификации [1] говорится, что реализация канала Abort не является обязательной для устройств VXI-11, но не указывается, какой номер порта необходимо возвращать в этом случае. Эксперименты с клиентами VXI-11, выполненные фирмами Agilent Technologies и National Instruments (см. далее), показали, что существующие клиенты отказываются устанавливать соединение, если состояние порта канала Abort, возвращаемое процедурой create_link(), не является корректным и порт не прослушивается со стороны приборного сервера. То есть даже самая примитивная реализация процедуры create_link() должна возвращать состояние открытого на прослушивание порта.

Максимальный размер ожидаемого сообщения (выходной параметр) определяется из специфики принимаемых устройством строковых команд (процедуры device_write()) и может как быть константой, так и изменяться в процессе работы сервера.

В листинге 2 представлен пример реализации create_link() в файле Device_server.c .

В приведённом примере используются функции getsocket() и threadAbort(), применяемые для обнаружения/открытия свободного порта и прослушивания канала Abort. Так как информация о текущем соединении должна сохраняться в течение работы сервера, то объявлены несколько глобальных переменных: pThreadAbort, clntIntr, handleIntr, addr, current_lid, connect_counter, содержащих сеансовую информацию (см. комментарии к переменным).

Теперь можно переходить к реализации процедур, отражающих специфику работы конкретного сервера. Основными процедурами, вызываемыми в рабочих режимах, являются device_write(), device_read(). Процедура записи позволяет передать серверу строковую команду (с параметрами или без), а с помощью процедуры чтения клиент получает результат выполнения команды (тоже в виде строки). Примером команды может служить запрос идентификационных данных “*IDN?” согласно спецификации [7], в ответ на который устройство должно выставить свои идентификационные данные: фирму-изготовитель, тип модели, серийный номер, версию программного обеспечения. Примеры реализации процедур чтения и записи приведены в листинге 3: на консоль выводится полученная от клиента команда, а на любой запрос в ответ выдаётся строка идентификации “NIFTI NNSU lab.14, Server VXI-11 for OS QNX, L14K533, 1.00”.

Для наполнения полезной функциональностью каркаса сервера необходимо определить для прибора свою систему команд или позаимствовать её у существующего прибора. В качестве базиса для такой системы можно рекомендовать спецификацию языка SCPI [8]. Затем необходимо будет реализовать механизм разбора строковых команд (parser), обеспечивающий обращение к управляющей функциональности прибора (взаимодействие с регистрами и/или с последовательными интерфейсами). Никаких требований и ограничений на такую функциональность в спецификациях VXI-11 нет, то есть вся специфика прибора целиком и полностью определяется разработчиком.

Библиотека VISA как клиент сервера VXI-11

В предыдущем разделе обсуждался вопрос создания сервера VXI-11, а как быть с клиентом? В общем случае по известной спецификации RPCL (в нашем случае файл Device.x) можно легко получить код клиентской заглушки [2] и реализовать удалённый клиент приборного сервера. Но, к счастью, это не является обязательным, так как существуют готовые клиенты, созданные в полном соответствии со спецификацией VXI-11. К таким клиентам относятся программные комплексы NI VISA и AG VISA. Ядром этих комплексов является реализация библиотеки функций VISA (Virtual Instrument Software Architecture) visa32.dll [9]. С помощью программного интерфейса из данной библиотеки можно получить доступ к удалённым серверам VXI-11. Кроме программного интерфейса, комплексы обеих фирм поддерживают операторские панели для работы с библиотекой VISA: VISA Assistant (Agilent Technologies) и MAX (National Instruments). Эти панели являются полноценными клиентами серверов VXI-11.

Функциональность обеих реализаций одинаковая, поэтому рассмотрим, как взаимодействует AG VISA c реализованным каркасом сервера и для сравнения с сервером генератора сигналов 33220А.

Для экспериментов понадобится версия 2.0.0 (или более поздняя) комплекса AG VISA (поставляется с приборами Agilent Technologies, доступна по адресу http://adn.tm.agilent.com/ index.cgi?CONTENT_ID=1035&LAST_CONTENT_ID=747). На стороне сервера запустим программу-демон portmap и созданный приборный сервер. На стороне клиента запустим панель конфигурации “Agilent IO Libraries Configuration - IO Config”. Из доступных типов интерфейсов выберем “TCPIP”, сконфигурируем его на работу с двумя VISA-ресурсами: “TCPIP::192.168.10.81::INSTR” (приборный сервер) и “TCPIP::192.168.10.94::INSTR” (генератор 33220А). При конфигурировании обязательно необходимо указать на панели “LAN Client” протокол по умолчанию – “VXI-11 (TCP/IP Instrument Protocol)”. Теперь AG VISA «знает» о двух приборных серверах VXI-11 и при последующих запусках панели “VISA Assistant” будет пытаться установить с ними соединение. Успешно распознанный сервер будет отображен панелью в списке обнаруженных устройств, и для него будут доступны функции форматированного ввода/вывода VISA (рис. 2, вкладка “Formatted I/O”).

Попробуем с помощью панели выдать обнаруженным устройствам команду “*IDN?” и прочитать ответ устройств. Нажатие на кнопку “*IDN?” панели соответствует вызову функции VISA viQueryf(…), внутри которой последовательно вызываются процедуры device_write() и device_read() приборного сервера. Как и ожидалось, вновь созданный сервер всегда отвечает строкой “NIFTI NNSU lab.14, Server VXI-11 for OS QNX, L14K533, 1.00”, а генератор 33220А — своей строкой идентификации “Agilent Technologies,33220A, MY44006595,2.00-2.00-22.2” (рис. 3). То есть разработанный приборный сервер обнаруживается и управляется наравне с «фирменным» и может служить прототипом встроенного программного обеспечения настоящих приборных серверов.

Особенностью клиента фирмы Agilent Technologies является то, что сразу после первого вызова create_link() со стороны клиента немотивированно вызывается несколько раз процедура device_docmd(). Вероятно, менеджер ресурсов AG VISA пытается получить дополнительную информацию об удалённом сервере. Такое поведение клиента не описано в спецификациях VXI-11, и реакция с кодом ошибки 8 (operation not supported) на вызовы device_docmd() не мешает обнаружению и последующей работе с сервером.

Заключение

Рассмотренная в статье технология создания приборных серверов VXI-11 позволяет создавать встроенное программное обеспечение для широкого класса аппаратных платформ и может найти применение как в области приборостроения, так и при создании распределённых контрольно-измерительных комплексов открытого типа.

Как протокол сетевого взаимодействия контрольно-измерительных средств с управляющими вычислительными узлами VXI-11 не уникален, но наиболее распространён. Один из перспективных протоколов – LXI [10], продвигаемый такими фирмами, как Advantech, Agilent Technologies, Racal Instruments, Rohde&Schwarz и др., в части идентификации удалённых приборов базируется на VXI-11. Актуальность изучения данного протокола, создание и внедрение программного обеспечения на его основе не вызывает сомнений. ●

Литература

1. VMEbus Extensions for Instrumentation TCP/IP Instrument Protocol Specification, VXI-11, Revision 1.0. — VXIbus Consortium, Inc., 1995.

2. У. Стивенс. UNIX: взаимодействие процессов. — СПб. : Питер, 2002.

3. VMEbus Extensions for Instrumentation TCP/IP-VXIbus Interface Specification, VXI-11.1, Revision 1.0. — VXIbus Consortium, Inc., 1995.

4. VMEbus Extensions for Instrumentation TCP/IP-IEEE 488.1 Interface Specification, VXI-11.2, Draft 0.3. — VXIbus Consortium, Inc., 1995.

5. VMEbus Extensions for Instrumentation TCP/IP-IEEE 488.2 Instrument Interface Specification, VXI-11.3, Draft 0.3. — VXIbus Consortium, Inc., 1995.

6. Д. Алексеев, Е. Ведревич, А. Волков и др. Практика работы с QNX. — М. : Издательский дом «КомБук», 2004.

7. IEEE Std 488.2-1992, IEEE Standard Codes, Formats, Protocols, and Common Commands For Use With IEEE Std 488.1-1987, IEEE Standard Digital Interface for Programmable Instrumentation.

8. А. Баженов. Стандарты GPIB, 488.2 и SCPI и их влияние на развитие автоматизации измерений // Мир компьютерной автоматизации. 2000. № 1.

9. А. Баженов. Стандарт VXIplug&play для создания интероперабельных измерительных систем и переносимых приложений. Часть 2. Библиотека VISA: управление инструментами и доступ к памяти // Мир компьютерной автоматизации. 2001. № 2.

10. LXI Standard, Revision 1.0. — LXI Consortium, Inc., September 23, 2005. 

Авторы — сотрудники Нижегородского государственного университета им. Н.И. Лобачевского и Нижегородского исследовательского физико-технического института при НГУ им. Н.И. Лобачевского
Телефон: (8312) 37-0742
Факс: (8312) 65-6615