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

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

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

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

2.3 Заповеди отладки программного средства

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

Ниже приведены рекомендации по организации отладки в форме заповедей.

Заповедь 1. Считайте тестирование ключевой задачей разработки ПС, поручайте его самым квалифицированным и одаренным программистам; нежелательно тестировать свою собственную программу.

Заповедь 2. Хорош тот тест, для которого высока вероятность обнаружить ошибку, а не тот, который демонстрирует правильную работу программы.

Заповедь 3. Готовьте тесты, как для правильных, так и для неправильных данных.

Заповедь 4. Документируйте пропуск тестов через компьютер; детально изучайте результаты каждого теста; избегайте тестов, пропуск которых нельзя повторить.

Заповедь 5. Каждый модуль подключайте к программе только один раз; никогда не изменяйте программу, чтобы облегчить ее тестирование.

Заповедь 6. Пропускайте заново все тесты, связанные с проверкой работы какой-либо программы ПС или ее взаимодействия с другими программами, если в нее были внесены изменения (например, в результате устранения ошибки).

Глава 3 Практический аспект отладки АСУ ТП

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

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

Программы управления, обычно, выполняются в программируемых логических контроллерах (ПЛК), входящих в состав АСУ ТП. Для более полного тестирования АСУ ТП, в том числе, и работы ПЛК не достаточно рабочей станции, на которой работает модель, а требуется дополнительное оборудование: вычислительные средства, на которых работает АСУ ТП, среда передачи данных, устройства ввода/вывода и др. Для проведения такого тестирования в КТИ ВТ СО РАН создан программно- аппаратный отладочный стенд с перечисленным выше оборудованием. Интегрированная модель исполняется на отдельной рабочей станции. Разработка и исполнение модели происходит с использованием визуально-интерактивной системы дискретного имитационного моделирования MTSS [3, 4].

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

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

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

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

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

На рис. 5 представлена типовая структура АСУ ТП. Входные сигналы с датчиков технологического оборудования через устройства ввода поступают на обработку в ПЛК, составляющие нижний уровень АСУ ТП. Состояния объектов технологического оборудования визуализируются на мнемосхемах АРМ оператора. АРМ оператора выполняется на рабочей станции верхнего уровня АСУ ТП. Все вычислительные средства АСУ ТП связаны локальной вычислительной сетью. Команды управления с АРМ оператора в противоположном направлении передаются на исполнительные механизмы технологического оборудования. Ядром АСУ ТП являются программы управления. Как правило, они выполняются в ПЛК. Программы управления обрабатывают и проверяют на совместимость входные сигналы, определяют возможность исполнения команд управления и формируют команды (или последовательность команд) на исполнительные механизмы в соответствии с технологическим регламентом, осуществляют автоматическое групповое управление объектами технологического оборудования в соответствии с заданным алгоритмом. В силу сложности и важности программ управления требуется разработка инструментальных средств для как можно полной их отладки и тестирования. Одним из инструментов для отладки и тестирования программ управления АСУ ТП является имитационная модель, интегрированная с реальной системой управления в рамках программно-аппаратного отладочного стенда. Программно-аппаратный отладочный стенд, представленный на рис. 6., включает в себя рабочую станцию, в которой исполняется модель в среде моделирования MTSS, вычислительные средства, на которых исполняется АСУ ТП, среду передачи данных, устройства ввода/вывода и другое дополнительное оборудование. В процессе выполнения работы были реализованы три варианта использования отладочного стенда на примере реальной системы управления водоотливной установкой. Автономная модель. В этом варианте (рис. 5) модель не связана с реальной системой управления. Но, структура модели соответствует структуре реальной системы управления, что облегчает ее использование в качестве модели, интегрированной с реальной системой. Технологическое оборудование реальной системы управления заменено моделью технологического оборудования. Программы управления в модели являются упрощенной реализацией программ управления реальной системы.

Автономная имитационная модель может быть использована для достижения следующих целей: • Проектирование несуществующей системы; • Решение оптимизационных задач; • Эксперименты с моделью системы, когда эксперименты с моделируемой системой дороги или небезопасны; • Определение граничных условий функционирования моделируемой системы; • Модернизация системы. Информационная интегрированная модель. Информационная интегрированная модель является источником входных сигналов для реальной системы управления вместо реального технологического оборудования. Структура информационной модели представлена на рис. 6, если убрать из рисунка штрихпунктирные стрелки. Информационная модель предназначена для отладки и тестирования всего программного обеспечения реальной системы управления (верхнего и нижнего уровней) за исключением программ управления. Для отладки нижнего уровня реальной системы управления и устройств ввода/вывода часть сигналов, генерируемых моделью, преобразуются к формату сигналов от реальных датчиков технологического оборудования. Для отладки верхнего уровня реальной системы управления часть сигналов, генерируемых Модель оборудования АСУ ТП ПЛК Программы управления АРМ оператора (рабочая станция) Устройства ввода Сигналы Команды Автономная модель (рабочая станция) Программы управления АРМ разработчика Устройства вывода Технологическое оборудование

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

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

Информационная интегрированная модель может быть использована для достижения следующих целей: • Отладка программного обеспечения верхнего и нижнего уровней реальной системы управления; • Имитация нештатных и аварийных ситуаций; • Презентация модели; • Тренажер для обучения управляющего персонала. АСУ ТП ПЛК Программы управления АРМ оператора (рабочая станция) Устройства ввода Сигналы Команды Отладка программ управления в ПЛК Интегрированная модель (рабочая станция) Программы управления АРМ разработчика Устройства вывода Модель оборудования