Файл: ОТЛАДКА И ТЕСТИРОВАНИЕ ПРОГРАММ: ОСНОВНЫЕ ПОДХОДЫ И ОГРАНИЧЕНИЯ ( Теоретические аспекты отладки и тестирования программ).pdf

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Команды

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

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

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

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

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

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

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

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

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

Управляющая интеграционная модель может быть использована для достижения перечисленных выше целей информационной модели, а также для достижения дополнительных целей:

• Сопровождение реальной системы управления на всех этапах ее жизненного цикла (проектирование, разработка, отладка, тестирование, пуско-наладка, опытная эксплуатация, оптимизация, развитие);
• Предсказание поведения реальной системы управления в зависимости от определенной ситуации и действий (бездействия) оператора;
• Использование модели внешней среды.

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

Заключение

Тестирование обычно производится на протяжении всей разработки и сопровождения на разных уровнях. Уровень тестирования определяет «над чем» производятся тесты: над отдельным модулем, группой модулей или системой, в целом. При этом ни один из уровней тестирования не может считаться приоритетным. Важны все уровни тестирования, вне зависимости от используемых моделей и методологий.

Модульное тестирование (Unit testing). Этот уровень тестирования позволяет проверить функционирование отдельно взятого элемента системы. Что считать элементом — модулем системы определяется контекстом. Наиболее полно данный вид тестов описан в стандарте IEEE 1008-87 «Standard for Software Unit Testing», задающем интегрированную концепцию систематического и документированного подхода к модульному тестированию.

Интеграционное тестирование (Integration testing). Данный уровень тестирования является процессом проверки взаимодействия между программными компонентами/модулями.

Системное тестирование (System testing). Системное тестирование охватывает целиком всю систему. Большинство функциональных сбоев должно быть идентифицировано еще на уровне модульных и интеграционных тестов. В свою очередь, системное тестирование, обычно фокусируется на нефункциональных требованиях — безопасности, производительности, точности, надежности т.п. На этом уровне также тестируются интерфейсы к внешним приложениям, аппаратному обеспечению, операционной среде и т.д.