Приветствую всех обитателей хабра! Я бы хотел поделиться своей идеей, которую мне частично уже удалось реализовать. Но я не могу оценить значимость такого рода проекта, и мне бы хотелось услышать Ваше мнение и Вашу конструктивную критику по этому поводу.
Краткая предыстория
Придя на родной завод инженером в группу АСОДУ, на меня одной из задач легла обязанность сопровождать механизм сбора данных с различных видов регистрирующих устройств. Замечу, что на заводе не плохой «зоопарк» такого рода оборудования. Как известно, для регистрирующих устройств, всегда идёт специализированное программное обеспечение, которое позволяет осуществить его конфигурирование и опрос. Но далеко не со всеми видами приборов идёт программное обеспечение, с помощью которого можно получить данные с прибора и поместить их в общую среду для дальнейшей обработки и архивирования. Так вот такая проблема была решена ещё до меня, путём написания одной программы, которая бы опрашивала все приборы, имеющиеся в наличие, и выгружающая собранные данные в единую базу данных. Но проблема заключалась в том, что при появлении нового типа прибора постоянно приходилось перекомпилировать данную программу, кроме этого она жёстко привязана с конкретной СУБД. Не имея под рукой ни конфигуратора, ни какого-либо тестера, всё это приводило процесс сопровождения в сплошные муки. Вот тогда и появилась идея реализовать некую систему, которая максимально бы упрощала работу по сопровождению механизма сбора данных. Для такой системы мной были выдвинуты следующие требования:
- Опрашивать любой тип/вид прибора. Достигаться это должно путём расширения программы за счёт модулей.
- Выгружать данные как угодно, сколь угодно и когда угодно. Достигаться такой подход тоже должен за счёт модулей.
- Наличие инструмента, позволяющего как можно проще настроить весь процесс опроса.
- Наличие инструмента позволяющего протестировать и отладить как модули опроса, так и модули выгрузки данных.
- Задача опроса должна работать как служба, но при этом возможность визуального наблюдения за ходом выполнения опроса и выгрузки данных тоже должна присутствовать.
Инструментальные средства
Для реализации своей затеи я использовал следующие инструментальные средства:
Компиляторы: gcc-3.4.2, gcc-4.6.1 и tinyc-0.9.25
Графическая библиотека: wxWidgets-1.8.10 + wxFormBuilder-3.2
База данных: SQLite-3.7.6.2
Реализация
В реализации я кратко расскажу только об основной части программы – сбора данных. Остальные части программного комплекса, на мой взгляд, по своей реализации не столь интересны как эта.
Буфер обмена
Самой главной для меня задачей являлось хранение данных в системе. Реализованный мной буфер принял следующий вид:
Каждый поток опроса имеет доступ к своей ветке буфера, с которой он берёт все стартовые (инициализирующие) настройки, пишет своё состояние и заносит полученные данные. Поток выгрузки данных имеет доступ, как к ветке опроса (с доступом только на чтение), так и к своей ветке экспорта. Доступ к объектам, помеченных на рисунке красным цветом, синхронизируется с помощью критических секций.
Ядро
Ядро программы представлено на рисунке ниже. Оно работает следующим образом. При чтении конфигурационного файла, загрузчиком, формируется конечный буфер (см. рисунок выше), список загруженных плагинов опроса, и список плагинов выгрузки данных. Ядру передаётся как сформированный буфер, так и списки плагинов. Ядро в свою очередь инициализирует на каждый com-порт поток, при этом, передаёт ему ветку буфера и список плагинов устройств. Как только потоки опроса все созданы, ядро начинает инициализировать по такой же схеме и потоки экспорта данных. Но, кроме перечисленного ранее, передаёт каждому константную ссылку на ветку опроса. Таким образом, потоки экспорта могут в любой момент получить всю информацию, как о ходе выполнения процесса опроса, так и получить конечные результаты опроса.
Так как имеется два вида программ опроса (в виде службы и в виде пользовательского графического приложения), то ядро помещается в динамическую библиотеку, которую используют оба приложения.
Все порождённые ядром потоки, кроме всего прочего, получают константную ссылку на само ядро. Таким образом, каждый из потоков может контролировать состояние ядра (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.
Послесловие
Конечно, я бы мог написать гораздо больше, но дабы не утомлять читателя, я не стану этого делать. Вот ссылка на мой проект. На все ваши вопросы я с удовольствием отвечу в комментариях.
Многие недостатки системы выяснились уже при эксплуатации. К таким недостаткам можно отнести следующее:
- Отсутствие типа опрашиваемого канала. Необходимость типа обуславливается тем, что многие приборы, для разных типов значений (аналоговый канал, математический канал, интегральное значение), требуют особо сформированный запрос.
- Отсутствие понятия множителя. Т.е. некоторые приборы при опросе, передают значение в виде целого числа. А позиция запятой в числе, у таких приборов, опрашивается отдельно. И имея такой множитель, пользователь мог бы изменять позицию запятой. К примеру, если по заданному каналу разделитель между целым и дробным значением ставится после первого числа, то множитель 0.1 позволял бы привести число в надлежащий вид. И получив значение 123, система, умножив это число на соответствующий множитель, выдавала бы результат 12.3.
Автор: anmartex
