О специфике отладки программного обеспечения в автоматизированных системах управления технологическими процессами

Рассматривая вопросы, связанные с проектированием надежного программного обеспечения систем автоматизации, различают понятия корректности и устойчи­вости. Программа является корректной, если она удовлетворяет функцио­нальным требованиям (спецификациям), т. е. программа вырабатывает жела­емые выходные данный до тех пор, пока входные данные соответствуют спецификациям. Таким образом, корректная программа — это программа, на­писанная без ошибок. Программа устойчива, если она обеспечивает определен­ный минимальный уровень полезной работоспособности, несмотря на неожи­данное или неблагоприятное влияние окружающей среды, в том числе при исправностях аппаратуры или некачественных входных данных. Иногда число неисправностей включают и ошибки программы. Эта характеристика носит вероятностный характер, поэтому некоторые авторы называют ее соб­ственно надежностью. Свойство устойчивости иногда описывают терми­ном «толерантность». Таким образом, ПО надежно, если оно соответствует спецификациям и способно противостоять неожиданным и неблагоприятным ситуациям.

Корректность систем автоматизации. Доказательство корректности ПО связано с его анализом для определения пределов выполнения им логических функций, предусмот­ренных разработчиком. Для доказательства корректности применяют тестирование и верификацию программ.

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

Тестирование состоит из четырех этапов: выбора стратегии тестирования; подготовки тестовых дан­ных; прогона программы с тестовыми данными; оценки отклонений выходов программы от соответ­ствующих эталонных данных.

Верификация программ систем автоматизации состоит в формальном доказательстве их правильности. Существует два подхода к верификации программ: статический и конструктивный.

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

В теории доказательства корректности систем управления технологическими процессами разрабо­таны следующие методы: индуктивных утвержде­ний; рекурсивной индукции; структурной индукции; индукции, основанной на подходе «фиксированной (неподвижной) точки»; вычислительной индукции.

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

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

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

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

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

Система отладки ПО включает в себя: входные и выходные языки отладки; систему контроля заданий на отладку; систему интерпретации зада­ний, информирующую и редактирующую систему отладки; систему моделирования и интерпретации команд управляющей с программируемых логических контроллеров (ПЛК); систему корректи­ровки программ; программы-имитаторы внешней информации; анализаторы и обработчики результатов; систему сервисных программ для обеспечения вспомогательных задач отладки.

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

Существуют различные классификационные признаки выделения групп ошибок:

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

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

При разработке отдельных программ наиболее типичны следующие ошибки систем управления технологическими процессами:

• типографские, возникающие при копировании или переписывании операторов языка программирования;
• вызванные неправильным пониманием языковых конструкций, когда программист использует языковую конструкцию, считая правильным способ использования, но компилятор интерпретирует это иначе (например, правильное употребление вложенных операторов IF);
• логические, возникающие в развитии подробной логики решения задачи управления информацией (например, неправильный выход из подпро­грамм, ошибки адресации);
• алгоритмические аппроксимации, которые недостаточно точны на на­боре переменных;
• сингулярности или критические значения (например, при делении на нуль, если не предусмотрены особые случаи ввода-вывода, а также при отсутствии анализа кода ответа устройства);
• дефекты структур данных, несовместимость между спецификациями структуры данных и ее использованием в программе (например, работа с числами в формате с плавающей запятой как с целыми числами);
• неправильная интерпретация спецификаций программы, когда про­граммист неправильно понимает определение задачи;
• неправильные формулировки задачи, неполные, двусмысленные, несовместимые или неправильные требования.

Типичные системные ошибки: неверные связи и интерфейсы (модули обмениваются неправильной информацией и т. п.); переменные величины без начальных значений — при обращении к переменным до того, как про­ведена их .инициализация, вследствие нарушения синхронизации между программой поставщиком данных (программы опроса датчиков, ввода ис­ходных данных и т. п.) и программой-пользователем; использование пере­менных многими модулями (ситуация, при которой модуль А и модуль В пытаются использовать одну и ту же переменную или ячейку памяти в ка­честве рабочего регистра для хранения промежуточных результатов,— один из модулей может испортить то, что другой записал в эту память); ошибки в документации; перегрузка (например, переполнение буферов, счетчиков, внутренних таблиц, элементов очередей и других областей па­мяти); временные ошибки (ошибки зависят от временных режимов и совпа­дающих сочетаний событий внутри системы); ошибки быстродействия и ем­кости (программа может выдавать правильный результат, но затрачивать неприемлемо большое время на его получение или требовать слишком боль­шого объема оперативной или дисковой памяти); попытки работать с дан­ными, как с программой.