Иногда мы вынуждены включаться в процесс разработки не только в своей текущей области ( у меня электроника, к примеру), но и вспоминать когда-то приобретенные навыки программиста после 20 летнего перерыва.

Постановка задачи

А задача была такая: создать программную систему для производства, поверки и тестирования интеллектуальных датчиков с протоколом HART на тестовых станциях с программируемым оборудованием. Кто не знает что такое HART - это протокол "точка-точка" частотной модуляции тока , который накладывается на токовую петлю 4-20 мА датчика и используется для калибровки,настройки и поверки интеллектуальных датчиков с токовой петлей 4-20 mA/HART. Тестирование таких изделий включает в себя линеаризацию передаточной характеристики датчика, поверку, множество тестов на этапах отработки и периодических испытаний с использованием циклов по давлению, температурам, напряжению питания и HART обмену. Желательно иметь возможность редактировать функционал Тестов, то есть изменять программу тестирования. Естественно, нужно сохранять "сырые" данные тестирования и формировать протоколы тестирования.

Одна тестовая станция должна поддерживать до 32 датчиков и включать такое оборудование как компьютер, задатчик-калибратор воздействий (давление) на датчики, климатическую камеру, вольтметр,источник питания, коммутатор датчиков на 32 канала, эталонная мера сопротивления, HART модем. Все приборы имеют различные интерфейсы управления, такие как USB, GPIB, TCP/IP, RS232. Для коммутации датчиков ( не забываем что у нас протокол "точка- точка") используем плату коммутации в слоте расширения вольтметра.Тестовых станций в перспективе может быть от 5 до 10. Отсюда вытекает необходимость в некой системе мониторинга этих станций, которая бы показывала что происходит на каждой станции тестирования, режимы работы оборудования, логи и т п.

Задача поначалу казалась очень непростой. Но какая бы ни была сложная система, стандартный подход к решению сложных задач состоит в их декомпозиции, разбивке сложной задачи на несколько более простых. Следуя этому принципу, можно выделить в данной системе несколько подсистем. Первая - это управление и работа с оборудованием и датчиками. Вторая - это программирование тестов и работа с базой данных. Третья- это обработка данных и расчеты, формирование протоколов. Четвертая - мониторинг тестирования. Такое структурирование уже проясняет архитектуру требующейся программной системы и можно рассматривать различные варианты создания подсистем.

Работа с оборудованием и датчиками

Первый вариант, который пришел в голову - использовать какой либо язык с ООП, описать на нем структуру команд всех интерфейсов приборов и т п. Вариант был сразу отметен ввиду сложности и длительности процесса такой разработки, да и найти такого специалиста соответствующей квалификации (допустим для C#) очень проблематично. Я знал такие подходы в компании где работал до этого и в общем, это работало, но тенденции в мире измерений и тестирования электоники такие, что ведущие компании по производству интеллектуальных приборов переходят (или уже перешли) в таких задачах на оборудование и программную систему LabView компании National Instruments. Все необходимые интерфейсы к приборам и оборудованию в LabView есть и использовать их относительно просто (тому кто знаком с языком управления приборами SCPI, к примеру). Оставалось найти программиста LabView. Их не очень много, так как графическая среда разработки в которой вообще нет кода, довольно специфична. Но тот кто ищет, тот всегда найдет. Такой человек в команду нашелся и довольно высокой квалификации в этой области программирования. SQL я взял на себя, памятуя о довольно приличном опыте в нем двадцать лет назад.

Сразу было понятно, что если в качестве клиентской части применять LabView на тестовой станции, то использовать ООП не получится, так как эта система его не поддерживает. Поэтому архитектурные варианты с бизнес-логикой на клиенте сразу были исключены из рассмотрения. Тот кто видел программы на Labview, тот сразу поймет , что усложнять и без того сложные диаграммы LabView можно, но не нужно, мы бы погрязли в болоте взимозависимостей бизнес-логики очень надолго, достаточно интерфейсных зависимостей. Вся логика тестирования должна быть вынесена наружу, в программу или в скрипт теста. Сам скрипт может храниться в файле или таблице базы данных. После некоторых раздумий было принято решение хранить скрипт в базе данных, так как вся обработка данных (или почти вся) в этой архитектуре тоже должна быть в базе данных.

Программирование тестов и работа с базой данных

Идея с редактируемым скриптом теста сразу натолкнула на мысль, что клиент LabView тестовой станции должен быть по сути интерпретатором, в основном выполняющим команды из скрипта теста. Отсюда следовало, что скрипт должен содержать команды управления оборудованием с параметром типа "Установить давление X", "Установить температуру Y", "Измерить и Записать данные токовой петли","Подключить канал коммутатора Z" и т. п. Фактически это означало, что надо разработать некую систему команд в виде табличного скрипта, которая будет включать работу с оборудованием, базой данных, климатической камерой, датчиками и Тест в данном случае будет состоять из таблицы строк команд с параметрами в виде линейного алгоритма, соответствующий определенному функционалу Теста, который будет выполнятся на тестовой станции клиентом LabView , работающего в режиме интерпретатора. Функционал Теста тогда можно строить из "кирпичиков" - операций Теста. Оставалась одна сложность - как разбивать тесты на операции ( команды) по функционалу Тестов. Видов тестов требовалось довольно много. Если разбить мелко - будет слишком длинные тесты в табличном виде и редактировать их будет неудобно. Если разбить крупно - снижается гибкость программирования теста. Золотая середина была найдена так - первый вариант основного теста температурной калибровки датчика делался с жесткой логикой на клиенте Labview. Это помогло понять подходы к разбиению теста на операции . Но одно дело понять, другое сделать и протестировать. В общем все было сделано, таблица с операциями Теста температурной калибровки получилась длинная, так как алгоритм был линейный и включал циклы по давлению, температуре и пулу тестируемых датчиков в виде последовательных наборов операций. Напрашивалось добавление операторов (команд) цикла типа WHILE, где бы внутри цикла последовательность операций выполнялась столько раз , сколько указано в начале цикла. Исходя их этого в систему команд скрипта были добавлены две команды инициализации цикла и проверки окончания цикла. Кроме того, проход по пулу тестируемых датчиков (не стоит забывать, что у нас HART, то есть тип соединения "точка- точка") был включен в сами операции работы (измерение, обнуление, калибровка и т. п.) с датчиками с указанием (через параметр) работы с пулом или с конкретным каналом. Это помогло уменьшить длину Теста и повысить функциональность программ тестирования по управлению каналами коммутатора датчиков.

Реализация общего цикла WHILE была сделана в базе данных в отдельной таблице, в которую записывались параметры цикла ( начальное значение цикла, конечное значение цикла, текущее значение, активный тестируемый пул датчиков, станция тестирования) при выполнении операции инициализации цикла. Введение операторов цикла позволило резко сократить ( в два раза ) количество строк Теста. Такой цикл требует перед его выполнением выполнения операции загрузки из таблиц БД статических моделей воздействий внутри цикла ( списка температур и давлений, к примеру). Для инициализации циклов по температурам, давлениям и каналам и получения величин воздействий из самого скрипта теста использовался тот же вид цикла что уже был, но для операций инициализации цикла ( начального давления, к примеру) потребовалась дополнительная таблица циклов по воздействию давления с указанием начальных и конечных значений воздействий, шага воздействия и способа модификации переменной цикла до или после начала цикла( ++i и i++ по аналогии с циклами в С++).

Встал вопрос - сколько нужно параметров для операций (команд), которые будут использоваться в скрипте теста? Ответ - 2 параметра оказалось достаточно для всех созданных операций в скриптах ( всего было запрограммировано 104 операции). Так как операций и вариантов параметров много и запомнить их сложно, таблица, в которой редактировался Тест связывалась по номеру операции с таблицей описания использования параметров операций и в редакторе Теста при выборе строки Теста показывалось описание параметров. Редактор Теста позволял копировать Тесты , редактировать и "компилировать" их ( стирать старый тест и заменять его новым). Получилось довольно не затратно - программист Теста заботится только о порядке операций, добавлении или удалении операций и значениях 2-х параметров. Все остальное ( расстановка нумерации строк, ссылок на следующю команду теста, комментарии к операциям с учетом циклов и т п) взяла на себя система ( используется встроенная процедура корректировки указанного Теста, которая автоматически формирует тест и все ссылки)

Работа с базой данных и формирование протокола тестирования

Клиент Labview работает с базой данных через вызовы хранимых процедур. Это не простые SELECT * FROM .... а порой сложные запросы и обработка данных в зависимости от операции ( команды). К примеру, первая операция теста с номером 0 создает в базе данных новый номер пула и при поиске датчиков по протоколу HART они автоматически привязываются к этому пулу ( записываются в таблицу пулов). Далее Labview через скрипт обращается к базе данных по этому пулу и номеру датчика в процессе тестирования. Как пример обработки в хранимой процедуре -операция 58. Формирование протокола тестирования пула датчиков, которая при вызове соответствующей хранимой процедуры формирования отчета с параметром пула рассчитывает метрологические параметры датчиков и определяет класс точности с учетом формул расчета референсных погрешностей в зависимости от диапазона и настройки датчиков из таблицы описания типа. Или операция 43 - формирование, транспонирование (все в SQL) и передача матриц данных на клиент LabView для расчета коэффициентов полиномов линеаризации передаточных характеристик датчика по давлению,току петли и температуре среды.

Считывание строки скрипта и выполнение операции происходит построчно из таблицы скрипта. Такой режим выбран для того чтобы был доступен режим корректировки теста в процессе его выполнения. Для того чтобы знать на какую строку переходить после выполнения текущей, в выполняемой строке скрипта есть ссылка на следующую строку программы теста. То есть этот скрипт теста связывает строки по ссылке, но она скрыта от пользователя и формируется автоматически при "компиляции" теста. Ссылка в конце цикла указывает на следующую строку после инициализации цикла, а когда переменная цикла достигает максимума, программа переходит на следующую строку когда достигли конца цикла. Все эти "хитрости" cо скриптами и циклами , реализованными в базе данных позволили получить неограниченную вложенность циклов, режим пошагового выполнения скрипта ( программы Теста) для отладки операций, остановку выполнения операций , ручной переход на любую строку скрипта. Практика показала что это очень важно и очень удобно при различных нестандартных ситуациях в процессе тестирования, когда нужно повторить ранее выполненные операции , пропустить следующие, добавить операцию в выполняемый Тест и т д. При внезапных отключениях питания тестовых станций ( климатическую камеру к примеру на UPS не подключить) есть режим перезапуска теста. Так как основная информация хранится в SQL базе данных и она не падает, так как защищена от пропадания питания, то режим перезапуска позволяет не запускать тест заново, а вернуться при перезапуске в ту же точку где был останов.

Для программирования теста и изменения его нужно менять только два параметра в колонках PROCESS_TEST и AUTO_OR_HAND.

Мониторинг тестовых станций

Часть сбора параметров оборудования для мониторинга тестовых станций была отдана клиенту Labview, который сохранял их в БД c интервалом 1 сек. Также сохранялся в базе данных лог всех выполненных операций. Под систему мониторинга было сделано отдельное приложение, которое обращаясь к параметрам оборудования и логам операций (через вызовы хранимых процедур) формировало и показывало следующие указанные ниже представления в режиме on-line c интервалом 1 сек.:

• список и статус режима работы станций  и длительность активного текущего теста на них,

• тесты и операции, выполненные и выполняемые  в реальном времени  на каждой станции тестирования,

• статусы и текущие параметры оборудования  выбранной тестовой станции:
  

  • метрология датчика (ток в токовой петле),

  • текущая температура в климатической камере,

  • текущее давление на выходе калибратора давления,

  • статус работы вакуумного насоса,

  • номер текущего активного канала коммутатора,

  • номер текущей\последней HART команды,

  • размер рабочей базы данных и лога транзакций, а также ее состояние (on или off),

  • загрузка сервера БД (%) и объем (%) используемой оперативной памяти на сервере,

  • текущее напряжение питания датчиков,

  • состав пула датчиков (серийный номер, диапазон, наименование и номер теста и т п.)

  • текущая операция с пулом и метрология датчика (основная и температурная погрешность и т п в момент подачи воздействия и измерения,

  • программа выполняемого теста (завершенные операции, выполняемая операция и ожидающие выполнения операции и их параметры),

  • статус HART каждого датчика в процессе выполнения Теста,

  • операционный лог и HART‑лог по станциям, пулам и датчикам в активных тестах.

  • получение отчетов по выполненным тестам CV и верификации,

  • поиск данных по поверке датчиков, протоколам, датам и т. п. и выгрузка отчетов (протоколов) по проведенным поверкам датчиков и калибровкам (CV) датчиков

Система отличается высокой стабильностью и предсказуемостью. Нестандартные ситуации с получением данных обрабатываются в базе данных и в случае ошибок программа уходит в режим паузы для выбора дальнейших действий оператором . Нестандартные ситуации с приборами обрабатываются на клиенте LabView.  Все такие ситуации отображаются в операционном логе и в программе мониторинга станций тестирования.  Сложно в небольшой статье описать все что удалось реализовать в связке SQL + LabView. Эта связка показала что при переносе основной логики в БД можно относительно быстро и просто реализовать сложные приборные интерфейсы и приложения на их основе.

Эта связка была положена в следующую разработанную нами  систему - настройка, мониторинг и конфигурирование приборов  с интерфейсом Modbus.. Но об этом в следующей статье.