Сбор данных с регистрирующих устройств

в 0:07, , рубрики: последовательный порт, Программирование, сбор данных, я пиарюсь, метки: ,

Приветствую всех обитателей хабра! Я бы хотел поделиться своей идеей, которую мне частично уже удалось реализовать. Но я не могу оценить значимость такого рода проекта, и мне бы хотелось услышать Ваше мнение и Вашу конструктивную критику по этому поводу.

Краткая предыстория

Придя на родной завод инженером в группу АСОДУ, на меня одной из задач легла обязанность сопровождать механизм сбора данных с различных видов регистрирующих устройств. Замечу, что на заводе не плохой «зоопарк» такого рода оборудования. Как известно, для регистрирующих устройств, всегда идёт специализированное программное обеспечение, которое позволяет осуществить его конфигурирование и опрос. Но далеко не со всеми видами приборов идёт программное обеспечение, с помощью которого можно получить данные с прибора и поместить их в общую среду для дальнейшей обработки и архивирования. Так вот такая проблема была решена ещё до меня, путём написания одной программы, которая бы опрашивала все приборы, имеющиеся в наличие, и выгружающая собранные данные в единую базу данных. Но проблема заключалась в том, что при появлении нового типа прибора постоянно приходилось перекомпилировать данную программу, кроме этого она жёстко привязана с конкретной СУБД. Не имея под рукой ни конфигуратора, ни какого-либо тестера, всё это приводило процесс сопровождения в сплошные муки. Вот тогда и появилась идея реализовать некую систему, которая максимально бы упрощала работу по сопровождению механизма сбора данных. Для такой системы мной были выдвинуты следующие требования:

  1. Опрашивать любой тип/вид прибора. Достигаться это должно путём расширения программы за счёт модулей.
  2. Выгружать данные как угодно, сколь угодно и когда угодно. Достигаться такой подход тоже должен за счёт модулей.
  3. Наличие инструмента, позволяющего как можно проще настроить весь процесс опроса.
  4. Наличие инструмента позволяющего протестировать и отладить как модули опроса, так и модули выгрузки данных.
  5. Задача опроса должна работать как служба, но при этом возможность визуального наблюдения за ходом выполнения опроса и выгрузки данных тоже должна присутствовать.

Инструментальные средства

Для реализации своей затеи я использовал следующие инструментальные средства:
Компиляторы: gcc-3.4.2, gcc-4.6.1 и tinyc-0.9.25
Графическая библиотека: wxWidgets-1.8.10 + wxFormBuilder-3.2
База данных: SQLite-3.7.6.2

Реализация

В реализации я кратко расскажу только об основной части программы – сбора данных. Остальные части программного комплекса, на мой взгляд, по своей реализации не столь интересны как эта.

Буфер обмена

Самой главной для меня задачей являлось хранение данных в системе. Реализованный мной буфер принял следующий вид:
image

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

Ядро

Ядро программы представлено на рисунке ниже. Оно работает следующим образом. При чтении конфигурационного файла, загрузчиком, формируется конечный буфер (см. рисунок выше), список загруженных плагинов опроса, и список плагинов выгрузки данных. Ядру передаётся как сформированный буфер, так и списки плагинов. Ядро в свою очередь инициализирует на каждый com-порт поток, при этом, передаёт ему ветку буфера и список плагинов устройств. Как только потоки опроса все созданы, ядро начинает инициализировать по такой же схеме и потоки экспорта данных. Но, кроме перечисленного ранее, передаёт каждому константную ссылку на ветку опроса. Таким образом, потоки экспорта могут в любой момент получить всю информацию, как о ходе выполнения процесса опроса, так и получить конечные результаты опроса.

Так как имеется два вида программ опроса (в виде службы и в виде пользовательского графического приложения), то ядро помещается в динамическую библиотеку, которую используют оба приложения.

image

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

Интерфейс плагина опроса устройств

Для того, чтобы опросить прибор необходимо иметь две функции: функцию, которая формирует конечный пакет, отправляемый прибору, и функцию обрабатывающую полученный ответ от прибора. Таким образом, интерфейс плагина состоит из двух функций формирования и обработки пакета и ещё одной функции, которая возвращает информацию о нём. Данная информация, нужна как пользователю, так и программе, в связи с тем, что в её содержимом имеется информация о длине формируемого и отправляемого пакетов. В результате имеем следующие функции:

  • GetInfo – информация о плагине;
  • GetPackage – формирование пакета;
  • GetData – обработка полученного пакета.

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

Интерфейс плагина экспорта

Интерфейс плагина экспорта состоит из четырёх функций:

  • About – информация о плагине;
  • Begin – функция выполняется единожды, после того как ядро переходит в режим RUN. Она ориентирована на то, чтобы осуществить какое-либо подключение к хранилищу данных. Если функция вернёт ошибку, то поток пишет ошибку в буфер и завершает свою работу.
  • Export – непосредственно экспорт данных;
  • End – функция выполняется единожды, после того как ядро переходит в режим STOP. Выполняется только в том случае, если функция Begin не вернула какую-либо ошибку. Функция ориентирована на то, чтобы осуществить отключение от хранилища данных.

Структуры, которыми оперируют эти функции, я также не буду описывать по причине указанной выше.

Результат

На данный момент в комплекс входит следующее программное обеспечение:

  • Editor – редактор конфигураций опроса;
  • ReaderGUI – программа опроса в виде пользовательского приложения;
  • ReaderSvc – программа опроса в виде службы Windows;
  • ReaderSvcCtrl – управление службой опроса;
  • TestExport – тестирование плагинов экспорта;
  • TestRequest – тестирование плагинов опроса.

Комплекс ориентирован на ОС Windows, хотя жёсткая привязка к WinAPI имеется только в классе, который осуществляет работу с COM-портом. Ну и естественно служба опроса устройств. Всё остальное же базируется на классах и функциях библиотеки wxWidgets.

Пример работы

Предположим, что имеется два прибора типа «rmt-59» и «ecograph-t». Каждый из них подключен на отдельный порт к преобразователю интерфеса «RS-485 – Ethernet». На компьютере, который осуществляет опрос, стоит драйвер преобразующий «Ethernet – RS232». Таким образом, мы имеем два com-порта (к примеру com-10 и com-11), на котором располагается по одному прибору. У обоих приборов, предположим, адрес 1. Оба прибора настроены на скорость передачи данных на 19200 бит/с.

Для начала нужно удостовериться, что имеющиеся плагины подходят для работы с данными приборами. Для этого запускаем программу TestRequest и пытаемся опросить эти приборы

После этого, следует создать конфигурацию опроса. Запускаем программу Editor и настраиваем опрос.

Если Вы создали новую базу, то необходимо прописать путь к ней в файле Reader.ini. Для теста работы опроса запускаем программу ReaderGUI

Теперь, нужно позаботиться об экспорте данных. Специализированных плагинов я не создавал. Для теста работы экспорта в комплект входит один тестовый плагин, который экспортирует данные в текстовый файл. Для начала следует проверить его работу с помощью программы TestExport.

Теперь, когда мы удостоверились в верной работе плагина, можно добавить его в конфигурацию опроса.

Всё, конфигурирование и тестирование закончено. Теперь можно установить и запустить службу. Управление сервисом осуществляем при помощи программы ReaderSvcCtrl.

Послесловие

Конечно, я бы мог написать гораздо больше, но дабы не утомлять читателя, я не стану этого делать. Вот ссылка на мой проект. На все ваши вопросы я с удовольствием отвечу в комментариях.

Многие недостатки системы выяснились уже при эксплуатации. К таким недостаткам можно отнести следующее:

  1. Отсутствие типа опрашиваемого канала. Необходимость типа обуславливается тем, что многие приборы, для разных типов значений (аналоговый канал, математический канал, интегральное значение), требуют особо сформированный запрос.
  2. Отсутствие понятия множителя. Т.е. некоторые приборы при опросе, передают значение в виде целого числа. А позиция запятой в числе, у таких приборов, опрашивается отдельно. И имея такой множитель, пользователь мог бы изменять позицию запятой. К примеру, если по заданному каналу разделитель между целым и дробным значением ставится после первого числа, то множитель 0.1 позволял бы привести число в надлежащий вид. И получив значение 123, система, умножив это число на соответствующий множитель, выдавала бы результат 12.3.

Автор: anmartex

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js