Обсуждается архитектура клиент-сервер применительно к распределённым измерительным системам. Показана роль спецификации VXI-11 при создании встроенного программного обеспечения контрольно-измерительных приборов. Содержится практическое руководство по созданию программного обеспечения, позволяющего управлять приборами по сети Ethernet в соответствии с требованиями специализированного стандарта.
Программно-управляемые измерительные приборы находят всё более широкое применение в контрольно-измерительных комплексах, испытательных стендах и различных автоматизированных системах. Уже многие годы действуют международные стандарты на аппаратное и программное обеспечение интерфейсов связи программно-управляемой аппаратуры с управляющими компьютерами: 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().
Одним из способов оснащения прибора интерфейсом 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).
Первое, что необходимо сделать на пути к реализации сервера 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. То есть каркас приборного сервера готов и функционирует в соответствии со спецификацией, теперь необходимо наполнить каркас функциональностью.
Основная функциональность сервера 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 нет, то есть вся специфика прибора целиком и полностью определяется разработчиком.
В предыдущем разделе обсуждался вопрос создания сервера 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. Актуальность изучения данного протокола, создание и внедрение программного обеспечения на его основе не вызывает сомнений. ●
VMEbus Extensions for Instrumentation TCP/IP Instrument Protocol Specification, VXI-11, Revision 1.0. — VXIbus Consortium, Inc., 1995.
У. Стивенс. UNIX: взаимодействие процессов. — СПб. : Питер, 2002.
VMEbus Extensions for Instrumentation TCP/IP-VXIbus Interface Specification, VXI-11.1, Revision 1.0. — VXIbus Consortium, Inc., 1995.
VMEbus Extensions for Instrumentation TCP/IP-IEEE 488.1 Interface Specification, VXI-11.2, Draft 0.3. — VXIbus Consortium, Inc., 1995.
VMEbus Extensions for Instrumentation TCP/IP-IEEE 488.2 Instrument Interface Specification, VXI-11.3, Draft 0.3. — VXIbus Consortium, Inc., 1995.
Д. Алексеев, Е. Ведревич, А. Волков и др. Практика работы с QNX. — М. : Издательский дом «КомБук», 2004.
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.
А. Баженов. Стандарты GPIB, 488.2 и SCPI и их влияние на развитие автоматизации измерений // Мир компьютерной автоматизации. 2000. № 1.
А. Баженов. Стандарт VXIplug&play для создания интероперабельных измерительных систем и переносимых приложений. Часть 2. Библиотека VISA: управление инструментами и доступ к памяти // Мир компьютерной автоматизации. 2001. № 2.
LXI Standard, Revision 1.0. — LXI Consortium, Inc., September 23, 2005.
Авторы — сотрудники Нижегородского государственного университета им. Н.И. Лобачевского и Нижегородского исследовательского физико-технического института при НГУ им. Н.И. Лобачевского
Телефон: (8312) 37-0742
Факс: (8312) 65-6615
Модули ввода/вывода EKF PRO-Logic для автоматизированных систем управления
Модули ввода/вывода обеспечивают связь между контроллером и периферийными устройствами, такими как датчики, исполнительные механизмы, реле и другое оборудование. Такие устройства крайне важны в распределённых системах автоматизации или на производствах с большими площадями помещений. С развитием технологий автоматизации промышленности модули ввода/вывода (I/O) стали неотъемлемой частью систем управления производственными процессами. 17.10.2024 175 0 0Разбор параметрирования нескольких преобразователей частоты с помощью WI-FI модуля на примере ПЧ Sinvel SID300
09.10.2024 264 0 0Контроллер, программируемый с помощью условий
Возможно ли создать алгоритм для задач автоматизации технологического процесса, не используя язык программирования? Предлагается описание системы создания алгоритма работы ПЛК для устройств малой автоматизации без использования специальных языков программирования. 01.09.2024 СТА №3/2024 651 0 0Как биометрия и искусственный интеллект помогают быстро и безопасно обслужить пассажиров в аэропортах
В условиях современных аэропортов идентификация пассажиров является одной из самых важных функций быстрого и безопасного обслуживания. Передовая биометрия помогает в этом, надёжно контролируя все этапы и существенно повышая пропускную способность транспортных узлов. 28.07.2024 СТА №3/2024 724 0 0