В этой статье я делаю обзор одного из возможных подходов к созданию гибких и стабильных MES систем классической клиент-серверной архитектуры с использованием "чистого" SQL с бизнес - логикой на сервере SQL. Современные тренды с использованием web клиента для подобных систем считаю не очень подходящими для такого типа задач. Ну и стоит учитывать что команда разработки этой системы включала всего два человека и один из команды еще паралельно занимался разработкой электроники этих датчиков. Старый добрый проверенный способ разработки в двухзвенной архитектуре здесь стал палочкой-выручалочкой, позволив сравнительно просто разработать сложную систему.
Постановка задачи
А задача была такая: создать программную систему для производства, поверки и тестирования интеллектуальных датчиков с протоколом HART на тестовых станциях с программируемым оборудованием. Кто не знает что такое HART - это протокол "точка-точка" частотной модуляции тока , который накладывается на токовую петлю 4-20 мА датчика и используется для калибровки,настройки и поверки интеллектуальных датчиков с токовой петлей 4-20 mA/HART. Тестирование таких изделий включает в себя линеаризацию передаточной характеристики датчика, поверку, множество тестов на этапах отработки и периодических испытаний с использованием циклов по давлению, температурам, напряжению питания и HART обмену. Желательно иметь возможность редактировать функционал Тестов, то есть изменять программу тестирования. Естественно, нужно сохранять "сырые" данные тестирования и формировать протоколы тестирования.
Одна тестовая станция должна поддерживать несколько десятков датчиков и включать такое оборудование как компьютер, задатчик воздействий на датчики, климатическую камеру, измерительное оборудование и коммутатор, эталон сопротивления, HART модем. Все приборы имеют различные интерфейсы управления, такие как USB, GPIB, TCP/IP, RS232. Тестовых станций может быть тоже не одна и не две, а в перспективе десяток и больше. Отсюда вытекает необходимость в некой системе мониторинга этих станций, которая бы показывала что происходит на каждой станции тестирования, режимы работы оборудования, логи и т п.
Задача поначалу казалась очень непростой. Но какая бы ни была сложная система, стандартный подход к решению сложных задач состоит в их декомпозиции, разбивке сложной задачи на несколько более простых. Следуя этому принципу, можно выделить в данной системе несколько подсистем. Первая - это управление и работа с оборудованием и датчиками. Вторая - это программирование тестов и работа с базой данных. Третья- это обработка данных и расчеты, формирование протоколов. Четвертая - мониторинг тестирования. Такое структурирование уже проясняет архитектуру требующейся программной системы и можно рассматривать различные варианты создания подсистем.
Работа с оборудованием и датчиками
Первый вариант, который пришел в голову - использовать какой либо язык с ООП, описать на нем структуру команд всех интерфейсов приборов и т п. Вариант был сразу отметен ввиду сложности и длительности процесса такой разработки, да и найти такого специалиста соответствующей квалификации (допустим для C#) очень проблематично. Я знал такие подходы в компании где работал до этого и в общем, это работало, но тенденции в мире измерений и тестирования электроники такие, что ведущие компании по производству интеллектуальных приборов переходят (или уже перешли) в таких задачах на оборудование и программную систему LabView компании National Instruments. Все необходимые интерфейсы к приборам и оборудованию в LabView есть и использовать их относительно просто (тому кто знаком с языком управления приборами SCPI, к примеру). Оставалось найти программиста LabView. Их не очень много, так как графическая среда разработки в которой вообще нет кода, довольно специфична. Но тот кто ищет, тот всегда найдет. Такой человек в команду нашелся и довольно высокой квалификации в этой области программирования. SQL я взял на себя, памятуя о довольно приличном опыте разработки в двухзвенной архитектуре и владения SQL c логикой в БД.
Сразу было понятно, что если в качестве клиентской части применять LabView на тестовой станции, то использовать ООП не получится, так как эта система его не поддерживает. Поэтому архитектурные варианты с бизнес-логикой на клиенте сразу были исключены из рассмотрения. Тот кто видел программы на Labview, тот сразу поймет , что усложнять и без того сложные диаграммы LabView можно, но не нужно, мы бы погрязли в болоте взимозависимостей бизнес-логики очень надолго, достаточно интерфейсных зависимостей. Вся логика тестирования должна быть вынесена наружу, в программу или в скрипт теста. Сам скрипт может храниться в файле или таблице базы данных. После некоторых раздумий было принято решение хранить скрипт теста в таблице базы данных, так как вся обработка данных (или почти вся) в этой архитектуре тоже должна быть в базе данных.
Программирование тестов и работа с базой данных
Идея с редактируемым скриптом теста сразу натолкнула на мысль, что клиент LabView тестовой станции должен быть по сути интерпретатором, в основном выполняющим команды из скрипта теста. Отсюда следовало, что скрипт должен содержать команды управления оборудованием с параметром типа "Установить давление 100 кПа", "Установить температуру -40 С", "Измерить и Записать данные токовой петли","Подключить канал коммутатора 4" и т. п. Фактически это означало, что надо разработать некую систему команд в виде табличного скрипта, которая будет включать работу с оборудованием, базой данных, климатической камерой, датчиками и Тест в данном случае будет состоять из таблицы строк команд с параметрами в виде линейного алгоритма, соответствующий определенному функционалу Теста, который будет выполнятся на тестовой станции клиентом LabView , работающего в режиме интерпретатора. Функционал Теста тогда можно строить из "кирпичиков" - операций Теста. Оставалась одна сложность - как разбивать тесты на операции ( команды) по функционалу Тестов. Видов тестов требовалось довольно много. Если разбить мелко - будет слишком длинные тесты в табличном виде и редактировать их будет неудобно. Если разбить крупно - снижается гибкость программирования теста. Золотая середина была найдена так - первый вариант основного теста температурной калибровки датчика делался с жесткой логикой на клиенте Labview. Это помогло понять подходы к разбиению теста на операции . Но одно дело понять, другое сделать и протестировать. В общем все было сделано, таблица с операциями Теста температурной калибровки получилась длинная, так как алгоритм был линейный и включал циклы по давлению, температуре и пулу тестируемых датчиков в виде последовательных наборов операций. Напрашивалось добавление операторов (команд) цикла типа WHILE, где бы внутри цикла последовательность операций выполнялась столько раз , сколько указано в начале цикла. Исходя их этого в систему команд табличных скриптов тестов были добавлены две команды инициализации цикла и проверки окончания цикла. Кроме того, проход по пулу тестируемых датчиков (не стоит забывать, что у нас HART, то есть тип соединения "точка- точка") был включен в сами операции работы (измерение, обнуление, калибровка и т. п.) с датчиками с указанием (через параметр) работы с пулом или с конкретным каналом. Это помогло уменьшить длину Теста и повысить функциональность программ тестирования по управлению каналами коммутатора датчиков.
Реализация общего цикла WHILE была сделана в базе данных в отдельной таблице, в которую записывались параметры цикла ( начальное значение цикла, конечное значение цикла, текущее значение, активный тестируемый пул датчиков, станция тестирования) при выполнении операции инициализации цикла. Введение операторов цикла позволило резко сократить ( в два раза ) количество строк Теста. Такой подход потребовал перед выполнением цикла операции загрузки из таблиц БД статических моделей воздействий внутри цикла ( списка температур и давлений, к примеру). Для инициализации циклов по температурам, давлениям и каналам и получения величин воздействий из самого скрипта теста использовался тот же вид цикла что уже был, но для операций инициализации цикла ( в зависмости от вида воздействия) потребовалась дополнительная таблица циклов по по типам воздействий с указанием начальных и конечных значений параметров воздействий, шага воздействия и способа модификации переменной цикла до или после начала цикла ( ++i и i++ по аналогии с циклами в С++). В общем все довольно просто было сделать, но сложно было придумать как это сделать просто.
Встал вопрос - сколько нужно параметров для операций (команд), которые будут использоваться в скрипте теста? Ответ - 2 параметра оказалось достаточно для всех созданных операций в скриптах ( всего было разработано больше 100 операций, из которых можно строить программы тестирования датчиков). Так как операций и вариантов параметров много и запомнить их сложно, таблица, в которой редактировался Тест связывалась по номеру операции с таблицей описания использования параметров операций и в редакторе Теста при выборе строки Теста показывалось описание параметров. Редактор Теста позволял копировать Тесты , редактировать и "компилировать" их ( стирать старый тест и заменять его новым). Получилось довольно не затратно - программист Теста заботится только о порядке операций, добавлении или удалении операций и значениях 2-х параметров. Все остальное ( расстановка нумерации строк, ссылок на следующю команду теста, комментарии к операциям с учетом циклов и т п) взяла на себя система ( используется встроенная процедура корректировки указанного Теста, которая автоматически формирует тест и все ссылки)
Работа с базой данных и формирование протокола тестирования
Клиент Labview работает с базой данных через вызовы хранимых процедур. Это не простые SELECT * FROM ..., а порой сложные запросы и обработка данных в зависимости от операции ( команды ) вплоть до транспонирования матриц в SQL для расчета коэффициентов полиномов, применяемых для линеаризации передаточной характеристики и компенсации температурной погрешности метрологических параметров датчиков. Как пример сложной обработки в хранимой процедуре - формирование протокола тестирования пула датчиков, которая при вызове соответствующей хранимой процедуры формирования отчета с рассчитывает метрологические параметры датчиков пула и определяет класс точности по формулам из описания типа в зависимости от диапазона перестройки датчиков. Используются две хранимые процедуры, одна главная для перебора датчиков в БД и сохранения результатов и вторая, которая рассчитывает все метрологические параметры датчиков по основной и температурной погрешности на основании полученных данных в процессе тестирования с учётом формул расчета и референсных значений в таблице описания типа.
Работа клиентской части в качестве интерпретатора происходит следующим образом.Считывание строки скрипта из базы данных и выполнение операции происходит построчно из таблицы скрипта вместо загрузки его полностью. Табличный скрипт представляет собой односвязный список, где каждая строка связывается со следующей ссылкой.
Такой режим выбран для того, чтобы был доступен режим корректировки Теста в процессе его выполнения, подобно тому, как запускается любая программа в режиме отладки. Для того чтобы знать на какую строку переходить после выполнения текущей, в выполняемой строке скрипта есть ссылка на следующую строку программы теста. То есть скрипт теста связывает строки по ссылке, но она скрыта от пользователя и формируется автоматически при "компиляции" табличного теста после его создания. Ссылка на следующую операцию в в операции проверки конца цикла указывает на следующую строку после инициализации цикла, но когда переменная цикла достигает максимума, программа переходит на следующую строку после операции проверки конца цикла. Все эти "хитрости" cо скриптами и циклами, были реализовананы в хранимой процедуре базы данных и в итоге позволили получить неограниченную вложенность циклов, режим пошагового выполнения скрипта ( программы Теста) для отладки операций, остановку выполнения операций , ручной переход на любую строку скрипта. Практика показала что это очень удобно и важно при отладке теста и очень удобно при различных нестандартных ситуациях в процессе тестирования, когда нужно повторить ранее выполненные операции , пропустить операции и даже добавить операцию в выполняемый Тест и т д. При внезапных отключениях питания тестовых станций ( климатическую камеру к примеру на UPS не подключить) есть режим перезапуска теста. Так как основная информация хранится в SQL базе данных и соединение с ней не обрывается, так как БД защищена от пропадания питания, то режим перезапуска позволяет не запускать тест заново, а вернуться при перезапуске в ту же точку где программа теста была оборвана.
для программирования теста и его изменения программисту теста нужно менять только два параметра в колонках PROCESS_TEST и AUTO_OR_HAND. Комментарии к строкам, все скрытые ссылки связности операций и циклов формируются автоматически при "компиляции" теста, что делает соответствующая хранимая процедура в БД. Режим итерактивной помощи позволяет при написании и просмотре программы сразу показывать аргументы и их описание. После того как программа Теста составлена из операций, достаточно ее "скомпилировать" ( запустить операцию, которая автоматичеки ее упакует в таблицу и напишет комментарии), чтобы использовать для работы или отладки. Как и в любом языке, при составлении программмы Теста надо учитывать порядок выполнения операций исходя из логики Теста. Пошаговый режим работы интерпретатора позволяет отладить работу программы даже в режиме активного тестирования.
Мониторинг тестовых станций
Часть сбора параметров оборудования для мониторинга тестовых станций отдана клиенту Labview, который сохраняет их в БД c интервалом 1 сек. Также сохраняется в базе данных лог всех выполненных операций. Лог разделен на оперативный и рабочий. Такое разделение сделано для системы онлайн мониторинга выполняемых тестов. Под систему мониторинга было сделано отдельное приложение, которое обращаясь к параметрам оборудования и логам операций (через вызовы хранимых процедур) формировало и показывало следующие указанные ниже представления в режиме on-line c интервалом 1,6 сек. Это была сложная работа, сделать так чтобы без дополнительных утилит и систем, на чистом SQL мониторинг не требовал много процессорного времени и отсутствовали взаимоблокировки ресурсов сервера SQL.
Это удалось сделать благодаря специально спроектированной архитектуре в БД с разделением логов и оптимизации хранимых SQL процедур. Загрузка процессора и памяти сервера для клиента мониторинга пренебрежимо малы и взаимоблокировки ресурсов сервера отсутствуют. Ниже провожу для примера краткий перечень основных возможностей показа и контроля системы мониторинга. Что показывается и какие отчеты можно получить в режиме онлайн:
список станций тестирования, показ статуса режима работы станций и длительности активного текущего теста на них,
тесты и операции, выполненные и выполняемые в реальном времени на каждой станции тестирования,
статусы и текущие параметры оборудования выбранной тестовой станции:
метрология датчика ( приведенная к диапазону погрешность токовой петли, приведенная к диапазону цифровая погрешность)
текущая температура в климатической камере,
текущее давление на выходе калибратора давления,
статус работы вакуумного насоса,
номер текущего активного канала коммутатора,
номер текущей\последней HART команды,
размер рабочей базы данных и лога транзакций, а также ее состояние (on или off),
загрузка сервера БД (%) и объем (%) используемой оперативной памяти на сервере,
текущее напряжение питания датчиков,
состав пула датчиков (серийный номер, диапазон, наименование и номер теста и т п.)
текущая операция с пулом и метрология датчика (основная и температурная погрешность и т п в момент подачи воздействия и измерения,
программа выполняемого теста (завершенные операции, выполняемая операция и ожидающие выполнения операции и их параметры),
статус HART каждого датчика в процессе выполнения Теста,
операционный лог и HART‑лог по станциям, пулам и датчикам в активных тестах.
получение отчетов по выполненным тестам CV и верификации,
поиск данных по поверке датчиков, протоколам, датам и т. п. и выгрузка отчетов (протоколов) в EXcell по проведенным поверкам датчиков и калибровкам (CV) датчиков.
выгрузка данных и протоколов в Excel
Система отличается высокой стабильностью и предсказуемостью. Нестандартные ситуации с получением данных обрабатываются в базе данных и в случае ошибок программа уходит в режим паузы для выбора дальнейших действий оператором Теста. Нестандартные ситуации с приборами и задатчиками давлени обрабатываются на клиенте LabView. Все такие ситуации отображаются в операционном логе и в программе мониторинга станций тестирования. Сложно в небольшой статье описать все что удалось реализовать в связке SQL + LabView. Эта связка показала что при переносе основной логики в БД можно относительно быстро и просто реализовать сложные тесты сбора и обработки данных датчиков по методологии ETL и приборные интерфейсы.
Эта связка была положена в следующую разработанную систему - настройка, мониторинг и конфигурирование приборов с интерфейсом Modbus. Она послужила и одной из частей функционального теста электроники приборов с modbus и HART. Специальный режим работы позволяет этой программе взаимодействовать с тестовой программой проверки электроники приборов , автоматизируя проверку регистров и параметров modbus. Но об этом в следующей статье.