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