CC BY
6Труды МАИ. Выпуск № 92
УДК 004.415.23.
www.mai.ru/science/trudy/
Особенности модульного построения систем контроля и диагностики
инерциальных систем управления
Бусурин В. И.1*, Медведев В.М.2, Карабицкий А. С.1**
1 Московский авиационный институт (национальный исследовательский университет), МАИ, Волоколамское шоссе, 4, Москва, A-80, ГСП-3, 125993, Россия 2Государственный научно-исследовательский институт приборостроения, проспект Мира, 125, Москва, 129226, Россия *e-mail: vbusurin@mai.ru **e-mail: karabox89@gmail. com
Аннотация
В статье описаны особенности модульного построения программного обеспечения систем контроля и диагностики инерциальных систем управления, приведен пример функционального набора модулей для системы контроля, выделены типы дополнительных программных модулей и описаны возможности автоматизированного формирования программного обеспечения систем контроля.
Ключевые слова: контрольно-проверочная аппаратура, модульная система, программное обеспечение, инерциальная система управления, контроль
Введение
Основу технического обеспечения информационно-измерительных и управляющих систем составляют электронные приборы и системы, предназначенные для осуществления связи, сбора, обработки, передачи и отображения информации, которые на стадиях разработки, производства и эксплуатации являются объектами диагностирования.
Для проведения контроля функционирования, работоспособности, поиска мест отказа, определения причин отказа при изготовлении опытного и серийного образца, восстановления, ремонта, для проведения приемосдаточных, механических и прочих видов испытаний инерциальных систем управления, используют контрольно-проверочную аппаратуру (КПА). Аппаратная и программная части КПА разрабатываются индивидуально для нужд диагностирования определённой инерциальной системы управления. Для упрощения разработки и повышения универсальности предлагается переработка методики проектирования программного обеспечения КПА, позволяющая в автоматическом режиме формировать рабочую программу КПА для контроля и диагностики нескольких схожих инерциальных систем управления. Такое решение позволит значительно снизить временные и материальные затраты на разработку аппаратной и программной частей КПА.
Формирование рабочей программы предполагается проводить путём присоединения дополнительных программных модулей, отвечающих за уникальные для определённой инерциальной системы управления (ИСУ) оборудование или функционал, к базовому программному обеспечению (БПО). Разработанное остаётся
неизменным при контроле и диагностике различных ИСУ. БПО выполняет такие функции, как распределение программных потоков и их приоритетов, запуск и контроль дополнительных программных модулей (ДПМ). ДПМ разрабатываются одновременно с КПА и обладают уникальными особенностями. Взаимодействие между модулями осуществляется с использованием области общей памяти и протоколов взаимодействия между модулями. В виду того, что ДПМ предназначены для выполнения конкретных задач, таких как запись телеметрии в выбранном формате, работа с платами мезонинов или запись показаний датчиков, а также в связи с тем, что они разрабатываются как отдельный проект, в их создании могут принимать участие разработчики, не связанные с проектированием базового модуля [1]. Небольшой объем и сравнительная простота разработки каждого модуля значительно ускоряют этот процесс.
Уникальная для каждой КПА аппаратная составляющая, такая как набор датчиков, оптронных плат, линий мультиплексного информационного обмена и других интерфейсов, позволяет, путём самоконтроля при помощи имитатора ИСУ, определить большую часть необходимых ДПМ. Пробный запуск технологического комплекта ИСУ и анализ, с использованием ГОСТ, поступающей телеметрии (выделение командных и ответных слов, определение формата), позволит определить недостающие ДПМ.
Определение перечня типов дополнительных программных модулей
Дополнительные модули системы, необходимые для выполнения задач контроля, можно классифицировать по функциональной принадлежности. Некоторые модули достаточно сложны и выполняют множество функций. Такие модули относятся к нескольким типам одновременно. Примером может служить модуль стендового контроля, решающий такие задачи, как выдача массивов по линии мультиплексного канала информационного обмена (МКИО), так и выдача разовых команд, а также отображение длительности команд в области пользовательского интерфейса.
Следует разделять следующие типы дополнительных модулей: модули работы с МКИО, модули работы с мезонинными платами, модули интерфейса пользователя, модули проведения расчётов, классификация модулей представлена на рисунке 1.
Типы модулей
Г
Модули работы с МКИО
Модуль записи цифровой телеметрии
1
Модуль имитации дополнительных устройств
Модули работы с платами
Модуль проведения стендового контроля
т
Интерфейсные модули
Модуль отображения времени разовых команд
Модуль записи аналоговых данных
Модули проведения расчетов Модуль расчета точностных
параметров
Модуль формирования протокола
Модуль выдачи разовых команд
Рисунок 1 — Типы модулей
«Модули работы с МКИО» отвечают за работу по мультиплексным каналам информационного обмена, работают с драйверами плат MIL-1553B,
генерируют командные слова, посылают и принимают кадры с данными,
контролируют правильность ответных слов [2]. Этот тип может включать следующие модули:
1) модуль контроля ошибок по МКИО,
2) модуль имитации пусковойустановки,
3) модуль записи аналоговой телеметрии,
4) модуль стендового контроля,
5) модуль имитации дополнительных устройств.
«Модули работы с платами» отвечают за работу программы с реле, оптронами и АЦП. С их помощью можно измерить значения параметров, таких как напряжение питания или потребляемый ток, выдать аналоговую команду или проверить наличие признака ИСУ. В этот тип входят модули:
1) модуль выдачи разовых команд,
2) модуль стендового контроля,
3) модуль записи аналоговых данных.
Модули интерфейса пользователя необходимы для общения оператора с машиной. С их помощью на экран выводится необходимая информация, такая как времена приёма разовых команд, данные навигации, расчётные значения углов отклонения от вертикали и пр. Этот тип модулей включает:
1) модуль отображения времени выдачи/приёма разовых команд,
2) модуль расчета точностных параметров,
3) модуль стендового контроля,
Модули проведения расчётов необходимы для вычисления величин, контроль которых описан в алгоритмах контроля ИСУ. Это такие модули, как:
1) модуль расчета точностных параметров,
2) модуль формирования протокола.
На основе этого списка можно представить функционально полный набор программных модулей систем контроля ИСУ.
Функционально полный набор программных модулей системы контроля инерциальных систем управления
Для выполнения базовых задач контроля ИСУ необходимо предусмотреть наличие модулей, выполняющих все минимально необходимые функции. Эти модули могут быть как универсальными, так и уникальными для каждой ИСУ. Примерами универсальных модулей могут служить такие модули, как «Модуль контроля ошибок по МКИО» или «Модуль записи цифровых данных», а примерами уникальных модулей могут быть «Модуль допусков и их контроля» или «Модуль выдачи разовых команд». Минимально необходимые функции, определяемые алгоритмами контроля, должны выполнять модули, работа которых описана ниже.
«Модуль контроля ошибок по МКИО» предназначен для контроля линии МКИО на наличие ошибок путём проверки ответных слов телеметрии в соответствии с ГОСТ [2] и алгоритмами контроля. Его работа связана с несколькими
другими модулями, такими как «Модуль имитации пусковой», который предназначен для осуществления обмена по каналу МКИО с ИСУ в соответствии с протоколом, редактирования и сохранения данных полётных заданий, выдачи некоторых разовых команд в ИСУ; или «Модуль стендового контроля». В задачи «Модуля стендового контроля» входят:
1) выдача массивов стимулов по МКИО,
2) контроль наличия и длительности признаков, выдаваемых ИСУ,
3) замыкание необходимых контактов с помощью драйвера мезонинных плат.
Необходимы также такие модули, как «Модуль допусков и их контроля», который хранит и анализирует информацию о допусках всех контролируемых параметров ИСУ. При работе модуль обрабатывает данные из общей памяти, сравнивая значения с допусками. При выходе значения из допуска модуль помещает в общую память запись об ошибке; модуль расчета точностных параметров, который проводит вычисления таких параметров, как углы отклонения от вертикали, приращение координат, скоростей, углов, получая данные из телеметрии. Вычисленные значения модуль помещает в область общей памяти. Отдельно стоит отметить модули аналоговых измерений и записи цифровых данных. «Модуль аналоговых измерений» получает данные от АЦП, установленных в КПА, с помощью драйвера мезонинных плат. Информация накапливается с необходимой дискретностью и записывается в файл на жестком диске компьютера. Параллельно накопленная телеметрия хранится в области общей памяти для осуществления
возможности доступа к ней для других модулей системы. «Модуль записи цифровых данных» осуществляет настройку одной из плат MIL-1553, входящей в состав КПА как монитора для линии МКИО [2]. После этого, на протяжении всего теста, ведётся запись поступающей информации с добавлением признака времени в файл. Параллельно накопленная телеметрия хранится в области общей памяти для осуществления возможности доступа к ней для других модулей системы. При превышении лимита выделенной общей памяти модуль производит запись об этом и в дальнейшем запись телеметрии ведется только в файл. Необходимы также модули, осуществляющие работу с ИСУ по циклограмме алгоритмов контроля. Это «Модуль выдачи разовых команд», «Модуль отображения времен приёма/выдачи разовых команд», а также «Модуль контроля команд».
«Модуль выдачи разовых команд» предназначен для выдачи разовых команд в ИСУ в соответствии с циклограммой. Для работы модуль использует библиотеки драйвера платы мезонинов. В необходимое время модуль выдаёт команду драйверу на переключение соответствующего реле, отвечающего за выдачу разовой команды. «Модуль отображения времени приёма/выдачи разовых команд» в свою очередь предназначен для визуального отображения времён срабатывания разовых команд, информацию о которых он получает из телеметрии. «Модуль контроля команд», используя драйвер мезонинных плат, следит за наличием аналоговых признаков, выдаваемых ИСУ. Также осуществляет допусковый контроль цифровых параметров, связанных с ИСУ, получая данные из телеметрии.
«Модуль имитации дополнительных устройств» осуществляет имитацию дополнительных устройств, программируя платы М1Ь-1553, входящие в состав КПА как оконечные устройства с определённым адресом и подадресом. Также проводит запись массивов данных в регистры этих плат. Таким образом имитируется готовность к работе дополнительных устройств, таких как рулевой электропривод.
«Модуль формирования протокола» предназначен для объединения результатов и генерацию выводов проведённого теста. После проведения теста, модуль собирает всю необходимую информацию из разных источников: аналоговой, цифровой телеметрии, области общей памяти, и формирует итоговый отчёт о выполненном тесте с указанием величин параметров и наличия ошибок.
«Модуль циклограммы и выбора теста» предназначен для управления процессом тестирования. В соответствии с алгоритмами контроля и циклограммой модуль запускает другие модули и контролирует их взаимодействие в отображаемом файле, тем самым координируя работу программного обеспечения.
Особенности модульной схемы построения ПО для систем контроля ИСУ
Можно выделить следующие особенности модульной системы:
Взаимодействие между модулями обеспечивается через отображаемые в памяти файлы с использованием протоколов взаимодействия между модулями. Каждый модуль имеет набор команд, которые он может поместить в отображаемый файл. Примерами таких данных могут служить: время прихода разовой команды, величина измеренного напряжения, флаг завершения работы модуля. Таким образом, область взаимодействия модулей можно представить как ленту событий,
доступную всем процессам. Технология отображаемых в памяти файлов подразумевает отложенную запись, что позволяет экономить ресурсы системы и улучшить быстродействие.
На рисунке 2 представлена блок-схема алгоритма работы модуля с отображаемым файлом на примере модуля формирования протокола.
Начало
Открыть отображаемый файл
Завершение работы приложения
-ошибка
J
успех
Рисунок 2 — Блок-схема алгоритма работы с отображаемым файлом на примере «Модуля формирования протокола»
Запуск модуля производится после проведения теста. Модуль проверяет состояние объекта-взаимоисключения для получения доступа к отображаемому файлу. В случае ложного состояния (доступ к файлу предоставлен другому процессу), процесс модуля ожидает смены состояния объекта. Как только доступ получен, происходит монополизация доступа к файлу процессом модуля. После этого проводится поиск по ключевым словам (названиям протоколируемых параметров) в теле отображаемого файла. Актуальные значения параметров, зафиксированные другими модулями помещаются в буфер и записываются в файл протокола на жесткий диск компьютера. После этого в тело отображаемого файла помещается флаг (запись) об окончании работы модуля, вида "Report_Module_Ended = true", и переключается состояние объекта-взаимоисключения.
Таким образом, можно выделить типовые операции взаимодействия модуля с отображаемым файлом. Которые представлены в виде блок-схемы на рисунке 3.
Начало
Рисунок 3 — Типовые операции алгоритма взаимодействия модуля с
отображаемым файлом
Разработка алгоритма реализации модульной схемы ПО для систем
контроля ИСУ
Реализация модульного подхода в разработке программного обеспечения контрольно-проверочной аппаратуры требует подробного описания средств
взаимодействия между модулями. Важные задачи при реализации модульной схемы программного обеспечение систем контроля ИСУ можно представить нижеизложенным списком:
1) Определение функций базового программного обеспечения.
Для определения функций базового программного обеспечения необходимо проанализировать существующее программное обеспечение контрольно-проверочной аппаратуры, алгоритмы контроля существующих инерциальных систем управления, выделить необходимые функции, присущие всем без исключения системам контроля и диагностики. Также базовое ПО должно обеспечивать взаимодействие между модулями на уровне memory-mapped file, области общей памяти и контролировать запуск и остановку процессов дополнительных модулей.
2) Определение минимально необходимого перечня дополнительных модулей для конкретной инерциальной системы управления.
Для определения минимально необходимого перечня дополнительных модулей необходимо выделить подсистемы ИСУ, подлежащие контролю, а также проанализировать алгоритмы контроля для выявления комплексных действий по осуществлению контроля и диагностики ИСУ. Такими действиями могут быть проведение стендового контроля или работа КПА в качестве имитатора стороннего устройства.
3) Составление протоколов взаимодействия для каждого выделенного дополнительного модуля системы.
Для каждого дополнительного модуля, выделенного в пункте 2 составляется протокол его взаимодействия с другими дополнительными модулями, а также базовым ПО. Регламентируются форматы команд, общих для всех составляющих системы. При этом учитывается быстродействие системы в целом и её синхронизация по времени.
4) Разработка базового программного обеспечения.
На этапе разработки базового ПО модульной системы контроля и диагностики программист реализует заявленные функции. При этом учитывается синхронизация базового ПО с дополнительными модулями как по реальному времени, так и по областям памяти.
5) Разработка дополнительных модулей.
Разработка дополнительных модулей ведётся с учетом протоколов взаимодействия между модулями и быстродействия системы.
При реализации программного обеспечения в виде модульной системы основную роль в её правильном функционировании играют протоколы взаимодействия между модулями и базовым программным обеспечением. В результате разработки будет представлено ПО, которое может быть сформировано пользователем или машиной.
Возможности автоматизированного формирования модульного ПО для
систем контроля ИСУ
Для облегчения работы программистов и операторов, а также для уменьшения временных затрат на разработку программного обеспечения предусмотрена возможность автоматического формирования рабочей программы контрольно -проверочной аппаратуры исходя из требуемых задач. Процесс формирования рабочей программы включает в себя следующие шаги:
1) Определение модели контролируемой ИСУ. Для этого производится кратковременный калибровочный запуск системы управления. При этом все интерфейсы контрольно-проверочной аппаратуры переводятся в режим монитора, ведется запись показаний с датчиков аналоговых сигналов. После проведения калибровочного запуска, информация, накопленная за короткий промежуток времени работы ИСУ, сравнивается по маске с наборами эталонов.
2) Выбор набора дополнительных программных модулей.
Модель ИСУ Приоритетность
Рисунок 4 — Алгоритм выбора ДПМ
Каждому эталону соответствует набор дополнительных программных модулей. Каждой задаче контроля также соответствует маска выбора модулей. Эти наборы сравниваются, и формируется окончательный набор дополнительных программных модулей для решения задачи контроля конкретной системы управления.
Пример выбора набора дополнительных программных модулей представлен на рисунке 4.
Заключение
Рассмотренная схема построения программного обеспечения должна решить сразу несколько важных задач разработки. Она значительно упрощает задачу отдельного программиста, так как позволяет работнику сосредоточиться на узкой задаче, выполняя конкретные обязанности, не растягивая разработку во времени. При этом также значительно сокращаются временные затраты на отладку программного обеспечения в целом, так как отладка нескольких дополнительных модулей проходит параллельно и выполняется несколькими программистами. Также модульная схема построения программного обеспечения способствует упрощению внесения поправок и доработок по мере развития программного продукта и контролируемой системы управления, упрощению сопровождения программного обеспечения у заказчика. Описанный модульный подход к разработке программ контроля может позволить выполнить задачу в сжатые сроки, предусматривая возможность доработки отдельных элементов, что обеспечивает гибкость,
универсальность и надёжность программного продукта, что не могут предложить традиционные методы разработки.
Библиографический список
1. Рамбо Дж., Блаха М. UML 2.0. Объектно-ориентированное моделирование и разработка. - СПб.: Питер, 2007. - 544 с.
2. Интерфейс магистральный последовательный электронных модулей. ГОСТ Р 52070-2003. -М.: Изд-во стандартов, 2003. - 23 с.
3. Брауде Э. Технология разработки программного обеспечения. - СПб.: Питер, 2004. - 659 с.
4. Куликов А.М. Применение шаблонов проектирования в программном обеспечении системы планирования полетных заданий // Труды МАИ, 2015, №80: http://www.mai.ru/science/trudy/published.php?ID=57007
5. Обносов Б.В., Данеко А.И., Захаров И.В., Трубников А.А., Решетников Д.А. Функциональный контроль подсистем ракеты класса «воздух-воздух» малой дальности // Труды МАИ, 2012, №62: http://www.mai.ru/science/trudy/published.php?ID=35573
6. Авакян А.А. Унифицированная интерфейсно-вычислительная платформа для систем интегральной модульной авионики // Труды МАИ, 2013, №65: http://www.mai.ru/science/trudy/published.php?ID=35845
7. Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно ориентированного проектирования. Паттерны проектирования. - СПб.: Питер, 2007. -366 с.
