Файл: Отладка и тестирование программ: основные подходы и ограничения (Отладка и тестирование).pdf

ВУЗ: Не указан

Категория: Курсовая работа

Дисциплина: Не указана

Добавлен: 14.03.2024

Просмотров: 21

Скачиваний: 0

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

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

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

Наиболее подходящим инструментом для решения этой проблемы является имитационное моделирование. Для автоматизации процесса отладки и тестирования программ управления АСУ ТП имитационная модель должна быть интегрирована с тестируемой системой. Интеграция заключается в генерации в модели входных сигналов в формате тестируемой системы, посылке сигналов в тестируемую систему вместо реальных входных сигналов от технологического оборудования и получения обратной связи от тестируемой системы. Такой подход был успешно опробован при разработке АСУ ТП Северо-Муйского тоннеля[6] и Системы мониторинга технологической инфраструктуры нефтегазодобывающего предприятия[7].

Программы управления, обычно, выполняются в программируемых логических контроллерах (ПЛК), входящих в состав АСУ ТП. Для более полного тестирования АСУ ТП, в том числе, и работы ПЛК не достаточно рабочей станции, на которой работает модель, а требуется дополнительное оборудование: вычислительные средства, на которых работает АСУ ТП, среда передачи данных, устройства ввода/вывода и др.

2.2 Тестирование программного комплекса


Для проведения такого тестирования в КТИ ВТ СО РАН создан программно- аппаратный отладочный стенд с перечисленным выше оборудованием. Интегрированная модель исполняется на отдельной рабочей станции. Разработка и исполнение модели происходит с использованием визуально-интерактивной системы дискретного имитационного моделирования MTSS[8].

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

Библиотечная модель включает в себя: графический образ элемента оборудования (2D или 3D), набор параметров (входных и выходных сигналов, настраиваемых переменных), набор возможных состояний, способы визуализации состояний, список команд управления, логику нижнего уровня (алгоритм функционирования, описывающий зависимости между параметрами). Аналогичный набор атрибутов содержат и образы технологического оборудования в SCADA-системах, используемых для создания АСУ ТП. Такая структура библиотечного элемента выбрана сознательно. Она облегчает создание моделей, интегрированных с АСУ ТП.

Редактирование модели происходит в режиме 2D. Визуализация исполнения модели может выполняться как в режиме 2D, так и в режиме 3D. Визуализация используется для отладки, валидации и презентации модели. Для возможности визуального наблюдения за исполнением модели имеется средство регулирования "скорости" исполнения модели с помощью параметра, задающего соотношение единиц модельного и процессорного времени исполнения модели. В отладочном режиме модель может исполняться пошагово. Во время исполнения модели пользователь может прервать ее исполнение, изменить значения параметров и продолжить исполнение модели.

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


Такая двухуровневая структура модели соответствует общепринятой структуре АСУ ТП. Совместимость структур облегчает создание моделей, интегрированных с АСУ ТП.

Для моделирования технологических процессов шахт и рудников в MTSS имеется специализированная библиотека технологического оборудования шахт и рудников[9]. В состав библиотеки входят следующие библиотечные модели: забой, бункер, конвейер, насос, водопровод, резервуар, источник технологических и грунтовых вод, трансформатор, трансформаторная подстанция, источник электропитания АСУ ТП, кабель линии электропередач и др.

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

Рис. 2.1. Фрагмент модели системы водоотливной установки

На рис. 2.1 представлен фрагмент модели системы водоотливной установки. Эта система предотвращает затопление шахты. В модели имитируется приток технологических и грунтовых вод, работа насосов, потребление электроэнергии. Основными параметрами модели являются: объем технологических и грунтовых вод, число и производительность насосов, объем резервуаров, пропускная способность водопроводов, электропотребление насосов. С помощью модели были проверены алгоритмы группового включения насосов, аварийного включения насосов, включение насосов в определенных режимах. Решены оптимизационные задачи экономии электроэнергии при соблюдении технологических норм допустимого объема воды в резервуарах.

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

Рис. 2.2. Типовая структура АСУ ТП

На рис. 2.2 представлена типовая структура АСУ ТП. Входные сигналы с датчиков технологического оборудования через устройства ввода поступают на обработку в ПЛК, составляющие нижний уровень АСУ ТП. Состояния объектов технологического оборудования визуализируются на мнемосхемах АРМ оператора. АРМ оператора выполняется на рабочей станции верхнего уровня АСУ ТП. Все вычислительные средства АСУ ТП связаны локальной вычислительной сетью. Команды управления с АРМ оператора в противоположном направлении передаются на исполнительные механизмы технологического оборудования.


Ядром АСУ ТП являются программы управления. Как правило, они выполняются в ПЛК. Программы управления обрабатывают и проверяют на совместимость входные сигналы, определяют возможность исполнения команд управления и формируют команды (или последовательность команд) на исполнительные механизмы в соответствии с технологическим регламентом, осуществляют автоматическое групповое управление объектами технологического оборудования в соответствии с заданным алгоритмом. В силу сложности и важности программ управления требуется разработка инструментальных средств для как можно полной их отладки и тестирования.

Одним из инструментов для отладки и тестирования программ управления АСУ ТП является имитационная модель, интегрированная с реальной системой управления в рамках программно-аппаратного отладочного стенда. Программно-аппаратный отладочный стенд, представленный на рис. 2.3., включает в себя рабочую станцию, в которой исполняется модель в среде моделирования MTSS, вычислительные средства, на которых исполняется АСУ ТП, среду передачи данных, устройства ввода/вывода и другое дополнительное оборудование. В процессе выполнения работы были реализованы три варианта использования отладочного стенда на примере реальной системы управления водоотливной установкой.

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

Автономная имитационная модель может быть использована для достижения следующих целей:

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

2.3 Информационная интегрированная модель

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


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

Как дополнительное средство отладки и тестирования нижнего уровня в программно- аппаратный отладочный стенд могут быть включены реальные датчики. Часть сигналов, генерируемых моделью, в соответствующем формате могут быть заведены на датчики для проверки всей связки: датчик, устройство ввода, ПЛК. Некоторые сигналы могут быть заданы на датчиках вручную.

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

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

  • Отладка программного обеспечения верхнего и нижнего уровней реальной системы управления;
  • Имитация нештатных и аварийных ситуаций;
  • Презентация модели;
  • Тренажер для обучения управляющего персонала.

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

Команды

Отладка программ управления в ПЛК

Рис. 2.3. Использование интегрированной модели

В управляющей интегрированной модели упрощенная реализация программ управления заменяется при исполнении на полную реализацию, которая исполняется в ПЛК реальной системы управления. Программы управления "не знают", в каком окружении они исполняются в реальной системе или в интегрированной модели. Этим достигается адекватность модели.