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

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

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


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

Ну. И что?
Реклама
Комментарии 21
  • –3
    Я бы хотел поделиться своей идеей… Но я не могу… (поэтому ниже будет левый текст)
    Придя на родной завод инженером, … на меня … легла обязанность … (обязанность — не только инженер, но ещё и ложится на автора)
    И т.д., и т.п.

    Тяжёлый для моего восприятия текст, будто читаю курсовую работу.
  • –2
    Не могли бы Вы воложить проект в другое место? Sourceforge сломался, похоже, 4 дня назад, и до сих пор не работает. Видимо, надолго это «the team is aware and is working on a fix».
    • 0
      У меня все хорошо: видимо, починили.
    • +2
      У меня тоже всё работает
    • +1
      Каким образом формируются запросы в TestReqest? Перебираются все адреса устройств или шлют запросы на определенный адрес (например 1)? Я бы предложил сделать функцию полностью автоматического опроса.

      Предусмотрена возможность получения текущих значений каналов другой программой?

      Может было бы лучше сделать выбор плагина в TestReqest не диалоговым окном открытия файла, а из списка, как это сделано в редакторе?

      В ридере было бы здорово сделать выбор базы данных их GUI. И я почему-то не добился чтобы у меня отображались тех. имена каналов, которые я задал в редакторе.
      • 0
        > Перебираются все адреса устройств или шлют запросы на определенный адрес (например 1)?
        На тот прибор, адрес которого вы указали в настройках

        > Я бы предложил сделать функцию полностью автоматического опроса.
        TestReqest служит для того, чтобы проверить подходит ли плагин к данному устройству, так что автоматический опрос здесь по определению не нужен. К дополнительным функциям данной утилиты относится проверка связи после физического подключения прибора.

        >Предусмотрена возможность получения текущих значений каналов другой программой?
        Только через последовательный порт

        > В ридере было бы здорово сделать выбор базы данных их GUI.
        Непосредственно для GUI это реально сделать

        > И я почему-то не добился чтобы у меня отображались тех. имена каналов, которые я задал в редакторе.
        Хм… Эта вещь на самом деле ключевая. Не пойму почему у вас не получилось. С этим у меня вообще проблем не было.
      • +2
        «Компиляторы: gcc-3.4.2, gcc-4.6.1 и tinyc-0.9.25
        Графическая библиотека: wxWidgets-1.8.10 + wxFormBuilder-3.2
        База данных: SQLite-3.7.6.2»

        в сочетании с

        «Комплекс ориентирован на ОС Windows»

        Вызывает у меня когнитивный диссонанс.

        Почему бы не использовать, скажем Qt? Или VS Express. Я понимаю, что вопрос довольно бессмысленный, но правда интересно, чем вы руководствовались при выборе инструментальных средств и ОС.

        Вообще, поздравления, очень круто! :) Осталось гуй прикрутить и можно продавать как АРМ для диагностики.

        Мы для ЖД похожую систему разрабатываем, но у нас опросом оборудования занимаются отдельные устройства, которые подключены в коммутатор, который уже подключён непосредственно к ком-порту (т.к. на ЖД станции диагностируемых устройств очень до хрена).
        • 0
          Балда! Он же написал — опрос регистриующих устройств! Такая же как у вас система!
          • +3
            > Почему бы не использовать, скажем Qt? Или VS Express.
            Согласен, но чем wxWidgets хуже? Да ладно, это уже из разряда религиозных войн. :-)

            >«Комплекс ориентирован на ОС Windows»
            А вот это легко исправить. Я же написал, что привязка к WinAPI выполняется только в классе работы с последовательным портом. Ну и плюс сама служба. Всё остальное привязано только к библиотекам. Перевести на *nix это дело техники.
            • –1
              Никакой религии, я хотел узнать как раз о практичности :) Ведь Qt это не только виджеты — это кроссплатформенный фреймворк.
          • 0
            Всё это на раз реализуется zabbix'ом. Сам организовывал съём показаний с устройств по rs232. Вердикт — очередной велосипед.
            • –2
              Zabbix больше под сетевые устройства заточен, насколько я понимаю. Графики рисовать и алярмы по смс это конечно здорово, но какой-нибудь специфичный мониторинг реализовывать на нём — как раз и будет являться велосипедом.
              • 0
                Что вы подразумеваете под словами «специфичный мониторинг»?
                • 0
                  Ну, к примеру, вот такое:

                  www.syst.ru/vnedren/bem_25.htm

                  Ни в коем случае не реклама, просто первое что нагуглилось. Такое заббикс может?
                  • 0
                    По вашей ссылке систем АСУТП, а не мониторинга. Это другая ниша. Другие требования к софту. Сравнение не корректно, имхо.
                    • 0
                      Ок, мы разрабатываем АРМ исключительно для диагностики. Никакого управления, только интерпретация и отображение данных с устройств. Просто циферки мало кому интересны — нужна мнемосхема и ещё стопицот вариантов представления данных. Текущие вариант системы ТС конечно сравним с простой системой оповещения, но я вижу в ней потенциал для роста в гораздо более комплексное решение.

                      Наш спор довольно неконструктивен без участия ТС, т.к. видение нами его системы испорчено профессиональной деятельностью :)
                    • 0
                      Насколько я понимаю, софт о котором рассказывается в статье, тоже такого не может.
                  • 0
                    Уточню, я снимал показания с тепло/электросчётчиков.
                  • +1
                    Моей целью было собрать данные с приборов и отдать их плагину выгрузки и всё. Никаких систем мониторинга и в мыслях не было создавать. А плагин вы можете написать под что угодно.

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое