Реализация диагностической задачи управления. Сигналы, триггеры, точки измерения. Компонентные архитектуры логического анализатора и осциллографа

ActiveX технологии. Свойства, методы, события. Стандартные и пользовательские Property page. Место элементов ActiveX в системе управления. Способы создания элементов ActiveX на базе MFC и на базе ATL.

Пакет Microsoft Foundation Classes (MFC) - библиотека на языке C++, разработанная Microsoft и призванная облегчить разработку GUI-приложений для Microsoft Windows путем использования богатого набора библиотечных классов.

Библиотека MFC, как и её основной конкурент, Borland VCL, облегчает работу с GUI путем создания каркаса приложения - «скелетной» программы, автоматически создаваемой по заданному макету интерфейса и полностью берущей на себя рутинные действия по его обслуживанию (отработка оконных событий, пересылка данных между внутренними буферами элементов и переменными программы и т. п.). Программисту после генерации каркаса приложения необходимо только вписать код в места, где требуются специальные действия. Каркас должен иметь вполне определенную структуру, поэтому для его генерации и изменения в Visual C++ предусмотрены мастера.

Кроме того, MFC предоставляет объектно-ориентированный слой оберток (англ. wrappers) над множеством функций Windows API, делающий несколько более удобной работу с ними. Этот слой представляет множество встроенных в систему объектов (окна, виджеты, файлы и т. п.) в виде классов и опять же берет на себя рутинные действия вроде закрытия дескрипторов и выделения/освобождения памяти.

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

Второй способ используется для добавления обработчиков оконных событий. Мастер создает внутри каркасов классов, связанных с окнами, специальные массивы - карты (оконных) сообщений (message map), содержащие пары «ИД сообщения - указатель на обработчик». При добавлении/удалении обработчика мастер вносит изменения в соответствующую карту сообщений.

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

Если указатель или ссылка ссылается на объект, производный от класса CObject, то в этом случае предусмотрен механизм определения реального типа объекта с помощью макроса RUNTIME_CLASS(). Хотя в С++ имеется механизм RTTI, механизм, реализованный в MFC, намного более эффективен по производительности.

Каждый класс, производный от CObject, может по запросу проверить свое внутреннее состояние и выдать диагностическую информацию. Это интенсивно используется в MFC при отладке.

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

Некоторые классы порождаются непосредственно от CObject. Наиболее широко используемыми среди них являются CCmdTarget, CFile, CDC, CGDIObject и CMenu. Класс ССmdTarget предназначен для обработки сообщений. Класс СFile предназначен для работы с файлами. Класс CDC обеспечивает поддержку контекстов устройств. Об контекстах устройств мы будем говорить несколько позднее. В этот класс включены практически все функции графики GDI. CGDIObject является базовым классом для различных DGI-объектов, таких как перья, кисти, шрифты и другие. Класс СMenu предназначен для манипуляций с меню. От класса CCmdTarget порождается очень важный класс CWnd. Он является базовым для создания всех типов окон, включая масштабируемые ("обычные") и диалоговые, а также различные элементы управления. Наиболее широко используемым производным классом является CFrameWnd. Как Вы увидите в дальнейшем, в большинстве программ главное окно создается с помощью именно этого класса.

От класса CCmdTarget, через класс CWinThread, порождается, наверное, единственный из наиболее важных классов, обращение к которому в MFC-программах происходит напрямую: CWinApp. Это один из фундаментальных классов, поскольку предназначен для создания самого приложения. В каждой программе имеется один и только один объект этого класса. Как только он будет создан, приложение начнет выполняться.

Большинство функций, вызываемых в MFC-программе, являются членами одного из классов, определенных в библиотеке. Большинство функций API доступны через функции-члены MFC. Тем не менее, всегда можно обращаться к функциям API напрямую. Иногда это бывает необходимым, но все же в большинстве случаев удобнее использовать функции-члены MFC.

Глобальные функции в MFC. В библиотеке есть ряд глобальных функций. Все они начинаются с префикса Afx. (Когда MFC только разрабатывалась, то проект назывался AFX, Application Framework. После ряда существенных изменений AFX была переработана в MFC, но прежнее название сохранилось во многих идентификаторах библиотеки и в названиях файлов.) Например, очень часто используется функция AfxMessageBox(), отображающая заранее определенное окно сообщения. Но есть и член-функция MessageBox(). Таким образом, часто глобальные функции перекрываются функциями-членами.

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

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

Триггеры используют для формирования события, устанавливающего границы измерительного горизонта. Разнообразные их варианты представлены в табл. 1.

Таблица 1. Основные типы триггеров

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

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

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

Подсистема диагностики построена по типу виртуальной машины и имеет многоуровневую структуру (рис. 15).

Рис. 15. Подсистема диагностики.

Рис. 16. Распределенная архитектура подсистемы диагностики

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

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

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

Рис.17. Распределенная архитектура логического анализатора

Уровень виртуальных приборов предлагает средства интерактивного конфигурирования и визуализации измерений. На прикладном уровне эти приборы встроены в приложение с доступом к приборам через OLE-интерфейс.

Систему, построенную на основе виртуальной модели подсистемы ди-агностики, назвали логическим анализатором.

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

Распределенная архитектура подсистемы диагностики, представленная на рис. 17, ориентирована на работу с внешними программируемыми контроллерами, а также с встроенными в систему управления. Функции компонентов архитектуры показаны на рис. 18.

Рис. 18. Компонентная модель диагностики программируемого контроллера

Система диагностики программируемого контроллера построена на основе СОМ-сервера, в котором специфицированы пять интерфейсов

• IDiagnosticData - интерфейс измерительных данных стандартных типов (BIT, BYTE, WORD, DWORD);

• IDiagnosticManage - интерфейс управления процессом измерений;

• IDiagnosticMeasure - интерфейс выдачи параметров результатов измерений;

• IDiagnosticTriggerConfig - интерфейс конфигурации условий запуска-окончания измерений;

• IDiagnosticSignalConfig- интерфейс конфигурации точек измерений.

Каждый из интерфейсов имеет неизменный набор функций. Сами интерфейсы реализованы как вложенные классы (nested classes) в классе CDiagnosticServer.

Любой виртуальный прибор реализован как ActiveX-элемент и может быть встроен в стандартный или пользовательский контейнер в среде MSWindowsNT.

ActiveX конфигуратора предназначен для конфигурационных настроек (рис. 18). Конфигурация измерения может быть сохранена, отредактирована или практически использована при измерении. Измеренные данные могут быть прочитаны и отображены ActiveX логического анализатора (рис. 19). При просмотре отображаемые сигналы можно масштабировать, сравнивать между собой и т.д.

Рис. 19. Виртуальный прибор конфигурации измерений для программируемого контроллера

При работе подсистемы диагностики пользовательское приложение, как правило, не замечает СОМ-сервера диагностики, оно взаимодействует с ActiveX-элементом диагностики при помощи механизма OLE Automation.

Рис. 20. Виртуальный прибор считывания измерений программируемого контроллера

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

Компонентная модель позволяет использовать пользовательское приложение для диагностики разных систем управления без перекомпиляции исходного кода. Для этого необходимо лишь разработать новый СОМ-сервер с учетом специфики новой системы управления, но с прежними интерфейсами.

Реализация осциллографа. Оптимальная настройка регуляторов следящих приводов подачи невозможна без тщательного анализа их динамических характеристик с помощью осциллографа подсистемы диагностики. Особенность распределенной архитектуры осциллографа (рис. 21) состоит в использовании «процесс-СОМ-сервера», в котором собраны все операции над сигналами, независимо от устройства-источника этих сигналов. В числе возможных операций над сигналами такие, как: масштабирование, сдвиг, практически любые математические вычисления.

Рис. 21. Распределенная архитектура осциллографа

Компонентная модель диагностики следящих приводов использует следующие интерфейсы:

• IOscManage для управления процесс-сервером, использует методы работы с внутренней базой данных объектов;

• IOscMeasureConfig для конфигурирования измерений, использует методы создания, удаления, установки триггеров, установки и считывания свойств триггеров;

• IOscMeasureData для работы с измерениями, содержит методы добавления, удаления, запуска и остановки измерений, а также условия срабатывания ручного триггера;

• IOscProcDataLoad для ввода-вывода исходных данных, содержит методы добавления и удаления серверов физических устройств, загрузки и сохранения данных и конфигурационных настроек;

• IOscScaling для управления отображением сигналов, содержит методы масштабирования и сдвига сигнала или группы сигналов, методы добавления и удаления сигнала из группы;

• IOscSignalData для работы с сигналами, содержит методы установки и считывания свойств и значений сигналов;

• IOscVisObjData для работы с визуальными объектами (сетками, курсорами и координатными осями), содержит методы добавления и удаления визуальных объектов, получения данных для этих объектов;

• IOscWindowData для управления параметрами отображения данных, содержит методы установки и считывания ширины и высоты области отображения.

Рис. 22. Виртуальный прибор отображения данных в графическом виде

Виртуальный прибор ActiveX конфигуратора работает в двух режимах: конфигурации измерения и отображения измерительных данных в текстовом формате. Виртуальный прибор ActiveX осциллографа отображает сигналы в графическом виде (рис. 22). ActiveX имеет возможности визуальной настройки свойств - цветов, шрифтов, стилей изображения сигналов. Приложение осциллографа подсистемы диагностики, помимо стандартных процедур конфигурации и отображения измерения, позволяет строить с помощью процесс-сервера амплитудно-частотные и фазочастотные характеристики следящих приводов (рис. 23).

Современные системы управления располагают свободными ресурсами вычислительной мощности, которые должны быть использованы наиболее эффективно. В этом смысле наибольший интерес представляют создание и развитие подсистемы диагностики. В первую очередь следует диагностировать логическую и геометрическую задачи управления. Концепция виртуальных приборов, построенных по типу ActiveX-элементов, позволяет использовать разработанные средства диагностики в самых различных приложениях, которые представляют наибольший интерес для конечных пользователей. Особенности СОМ-подхода и СОМ-технологии таковы, что разработанные диагностические системы могут быть применены в любых устройствах СУ.

Рис. 23. Амплитудно-частотная характеристика в логарифмической системе координат (Боде-диаграмма)

Дата добавления: 2014-01-20