Теоретические аспекты отладки и тестирования программ

Содержание

Введение 3

Глава 1 Теоретические аспекты отладки и тестирования программ 5

1.1 Отладка и тестирование 5

1.2 Методы и алгоритмы тестирования программ 6

1.3 Ограничения тестирования 14

Глава 2 Инструментальные средства отладки и тестирования программ управления АСУ ТП 18

2.1 Разработка и отладка АСУ ТП 18

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

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

Заключение 28

Список литературы 29

Введение

Актуальность исследования. Процесс поиска и исправления ошибок в программе называется отладкой. Ошибки могут возникнуть при наборе, в результате нарушения правил записи программ на языке программирования – так называемые синтаксические ошибки. Обнаружить и исправить их помогают специальные инструментальные программы (программы синтаксического контроля), входящие в состав системы программирования. Система анализирует программу и выдает сообщение о месте и характере ошибки. Часто ошибки связаны с тем, что некоторая синтаксически правильная конструкция не может быть выполнена (например, деление на нуль или попытка присвоить величине целого типа вещественное значение). В этом случае также появляется сообщение о причине отказа и указывается, какая именно команда не может быть выполнена.

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

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

- рассмотреть теоретические аспекты отладки и тестирования программ;

- проанализировать инструментальные средства отладки и тестирования программ управления АСУ ТП.

Объект исследования – отладка и тестирование АСУ ТП.

Предмет исследования - анализ отладки и тестирования программ, основные походы и ограничения.

Структура работы состоит из введения, основной части, заключения и списка литературы.

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

Глава 1 Теоретические аспекты отладки и тестирования программ

1.1 Отладка и тестирование

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

Важным этапом процесса отладки является тестирование программы, т.е. испытание ее путем введения теста – определенного набора исходных данных, для которого результат работы отдельных блоков или программы в целом известен заранее.

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

Умение удачно подобрать такой тест, при котором ошибка (если она есть) наиболее вероятна, и предусмотреть разнообразные варианты хода вычислительного процесса, а также действия пользователя (порой весьма непредсказуемые), и, следовательно, защитить работу программы от всяких неожиданностей – большое искусство программиста^[1].

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

До последнего времени 4, 5 и 6 этапы были необходимыми этапами решения задачи с помощью ЭВМ. При этом языки и системы программирования были теми программными инструментами, с помощью которых создавались новые программы для решения задач пользователя. Однако с расширением круга задач, для решения которых используется компьютер, растет число людей, которые, не будучи профессиональными программистами, применяют компьютер в своей работе^[2].

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

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

1.2 Методы и алгоритмы тестирования программ

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

Широко используемыми методами тестирования являются модульное тестирование, интеграционное тестирование, приемочное тестирование, и тестирование системы. Программное обеспечение подвергается этим испытаниям в определенном порядке.

1) Модульное тестирование;

2) Интеграционное тестирование;

3) Системное тестирование;

4) Приемочные испытания.

Модульное тестирование. В первую очередь проводится модульный тест. Как подсказывает название, это метод испытания на объектном уровне. Отдельные программные компоненты тестируются на наличие ошибок. Для этого теста требуется точное знание программы и каждого установленного модуля. Таким образом, эта проверка осуществляется программистами, а не тестерами.

Для этого создаются тест-коды, которые проверяют, ведет ли программное обеспечение себя так, как задумывалось. Интеграционное тестирование Отдельные модули, которые уже были подвергнуты модульному тестированию, интегрируются друг с другом, и проверяются на наличие неисправностей. Такой тип тестирования в первую очередь выявляет ошибки интерфейса. Интеграционное тестирование можно осуществлять с помощью подхода "сверху вниз", следуя архитектурному сооружению системы. Другим подходом является подход «снизу вверх», который осуществляется из нижней части потока управления.

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

Приемочные испытания - это последний тест, который проводится перед передачей программного обеспечения клиенту. Он проводится, чтобы гарантировать, что программное обеспечение, которое было разработано отвечает всем требованиям заказчика. Существует два типа приемо-сдаточных испытаний - то, которое осуществляется членами команды разработчиков, известно, как внутреннее приемочное тестирования (Альфа-тестирование), а другое, которое проводится заказчиком, известно, как внешнее приемочное тестирования. Если тестирование проводится с помощью предполагаемых клиентов, оно называется приемочными испытаниями клиента. В случае если тестирование проводится конечным пользователем программного обеспечения, оно известно, как приемочное тестирование (бета-тестирование).

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

Тестирование методом черного ящика осуществляется без каких-либо знаний внутренней работы системы. Тестер будет стимулировать программное обеспечение для пользовательской среды, предоставляя различные входы и тестируя сгенерированные выходы. Этот тест также известен как Black-box, closed-box тестирование или функциональное тестирование.

Тестирование методом "Белого ящика", в отличие от "черного ящика", учитывает внутреннее функционирование и логику работы кода. Для выполнения этого теста, тестер должен иметь знания кода, чтобы узнать точную часть кода, имеющую ошибки. Этот тест также известен как White-box, Open-Box или Glass box тестирование. Подробнее о тестирование методом белого ящика^[3].

Тестирование методом серого ящика или Gray box тестирование, это что-то среднее между White Box и Black Box тестированием, где тестер обладает лишь общими знаниями данного продукта, необходимыми для выполнения теста. Эта проверка осуществляется посредством документации и схемы информационных потоков. Тестирование проводится конечным пользователем, или пользователям, которые представляются как конечные. Нефункциональные тесты

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

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

Тестирование эффективности как подсказывает название, эта методика тестирования проверяет объем кода или ресурсов, которые используются программой при выполнении одной операции. Юзабилити-тестирование Это тестирование проверяет аспект удобства и практичности программного обеспечения для пользователей. Легкость, с которой пользователь может получить доступ к устройству формирует основную точку тестирования. Юзабилити-тестирование охватывает пять аспектов тестирования, - обучаемость, эффективность, удовлетворенность, запоминаемость, и ошибки. Тесты в процессе разработки программного обеспечения

Каскадная модель использует подход "сверху-вниз", независимо от того, используется ли она для разработки программного обеспечения или для тестирования. Основными шагами, участвующими в данной методике тестирования программного обеспечения, являются:

• 1. Анализ потребностей
  2. Тест дизайна
  3. Тест реализации

Тестирование, отладка и проверка кода или продукта Внедрение и обслуживание В этой методике, вы переходите к следующему шагу только после того, как вы завершили предыдущий. В модели используется не-итерационный подход. Основным преимуществом данной методики является ее упрощенный, систематический и ортодоксальный подход. Тем не менее, она имеет много недостатков, так как баги и ошибки в коде не будут обнаружены до этапа тестирования. Зачастую это может привести к потере времени, денег, и других ценных ресурсов^[4].

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

Rapid Application Development (RAD). Методология быстрой разработки приложений Название говорит само за себя. В этом случае методология принимает стремительный эволюционный подход, используя принцип компонентной конструкции. После понимания различных требований данного проекта, готовится быстрый прототип, а затем сравнивается с ожидаемым набором выходных условий и стандартов. Необходимые изменения и модификации вносятся после совместного обсуждения с заказчиком или группой разработчиков (в контексте тестирования программного обеспечения). Хотя этот подход имеет свою долю преимуществ, он может быть неподходящим, если проект большой, сложный, или имеет чрезвычайно динамический характер, в котором требования постоянно меняются.

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

Rational Unified Process (RUP). Рациональный унифицированный процесс Методика RUP также похожа на спиральную модель, в том смысле, что вся процедура тестирования разбивается на несколько циклов. Каждый цикл состоит из четырех этапов - создание, разработка, строительство, и переход. В конце каждого цикла продукт/выход пересматривается, и далее цикл (состоящий из тех же четырех фаз) следует при необходимости. Применение информационных технологий растет с каждым днем, также и важность правильного тестирования программного обеспечения выросло в разы. Многие фирмы содержат для этого штат специальных команд, возможности которых находятся на уровне разработчиков.

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

Перейдем к видам тестирования, в которых применяется автоматизация.

• Нагрузочное тестирование, при котором имитируется работа большого количества пользователей, выполняющих различные действия.
• Регрессионное тестирование - это различного рода ошибки, появляющиеся после каждой поставки для ПО или внесения других изменений. Данный вид тестирования приходится повторять очень часто, что бы убедиться в отсутствии проблем на уже разработанном и установленном функционале.
• Функциональное тестирование, данный вид тестирования необходимо проводить для выявления ошибок на определенном функционале программного обеспечения.
• Конфигурационное тестирование - это проверка компонента системы в разных средах и настройках. Например, работа веб. приложения в различных браузерах и при различных настройках.
• Установочное тестирование - это проверка корректности установки приложения в тех или иных условиях, продиктованных заказчиком.

Рассмотрим положительные и затем отрицательные стороны автоматизации тестирования.

• 1. При автоматизации тестирования исключается так называемый "человеческий фактор", так как людям время от времени свойственно допускать ошибки и неточности, а скрипт выполнит все необходимые проверки и безошибочно зарегистрирует результаты.
  2. Быстрота выполнения, скрипту для работы не нужно заглядывать в документацию или сверять значения со справочниками.
  3. Отсутствие необходимости постоянно следить за процессом проверки. Специалист по тестированию может запустить скрипт и на время его выполнения заняться другими делами.
  4. Меньшие затраты ресурсов на поддержку актуальности тестовых скриптов. Стоит один раз написать скрипт и после этого на его обновления необходимо затрачивать меньше сил, нежели на тестирование вручную.
  5. Автоматическая отчетность. Автоматическое сохранение результатов и внесение их в отчет.

К недостаткам автоматизации тестирования можно отнести следующее.

1. Внимание к деталям. Тестовый скрипт всегда будет выполняться по одному алгоритму, без шага вправо и влево, при этом, не обращая внимания на детали и появившиеся дефекты.

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

Выбор инструмента для автоматизации тестирования зависит от требований к объекту тестирования, требований к тестовым сценариям и бюджету. Для примера инструмента рассмотрим - IBM Rational Functional Tester. Это инструмент автоматического функционального и регрессионного тестирования. Это ПО предоставляет функции автоматического тестирования для функционального, регрессионного тестирования, тестирования графических пользовательских интерфейсов и тестирования, ориентированного на данные. Rational Function Tester поддерживает ряд приложений, таких как веб-приложения, приложения для .Net, Java, Siebel, SAP, приложения на основе эмулятора терминала, PowerBuilder, Ajax, Adobe Flex, Dojo Toolkit, GEF, документы Adobe PDF, zSeries, iSeries и pSeries. Пример использования^[5].

• Сначала в среде создается новый проект.
• Выполняется запись пользовательских действий в тестируемом предложении.
• Создается проверочная точка в процессе выполнения записи.
• Далее необходимо сохранить результаты записи.
• Сформировываем bat - файл, который будет вызывать скрипт тестирования. Bat - файл вызывается IBM Rational Functional Tester с необходимыми параметрами.
• IBM Rational Functional Tester записывает результаты в отчет в формате HTML.
• Далее мы анализируем полученный результат.

1.3 Ограничения тестирования

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

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

Можно выделить следующие, наиболее распространенные и обоснованные цели (а, соответственно, виды) тестирования:

Приёмочное тестирование (Acceptance/qualification testing). Проверяет поведение системы на предмет удовлетворения требований заказчика. Это возможно в том случае, если заказчик берет на себя ответственность, связанную с проведением таких работ, как сторона «принимающая» программную систему, или специфицированы типовые задачи, успешная проверка (тестирование) которых позволяет говорить об удовлетворении требований заказчика. Такие тесты могут проводиться как с привлечением разработчиков системы, так и без них.

Установочное тестирование (Installation testing). Из названия следует, что данные тесты проводятся с целью проверки процедуры инсталляции системы в целевом окружении.

Альфа- и бета-тестирование (Alpha and beta testing). Перед тем, как выпускается программное обеспечение, как минимум, оно должно проходить стадии альфа (внутреннее пробное использование) и бета (пробное использование с привлечением отобранных внешних пользователей) версий. Отчеты об ошибках, поступающие от пользователей этих версий продукта, обрабатываются в соответствии с определенными процедурами, включающими подтверждающие тесты (любого уровня), проводимые специалистами группы разработки. Данный вид тестирования не может быть заранее спланирован.

Функциональные тесты/тесты соответствия (Conformance testing/Functional testing/Correctness testing). Эти тесты могут называться по разному, однако, их суть проста — проверка соответствия системы, предъявляемым к ней требованиям, описанным на уровне спецификации поведенческих характеристик.

Достижение и оценка надежности (Reliability achievement and evaluation). Помогая идентифицировать причины сбоев, тестирование подразумевает и повышение надежности программных систем. Случайно генерируемые сценарии тестирования могут применяться для статистической оценки надежности. Обе цели — повышение и оценка надежности — могут достигаться при использовании моделей повышения надежности.

Регрессионное тестирование (Regression testing). Определение успешности регрессионных тестов (IEEE 610-90 «Standard Glossary of Software Engineering Terminology») гласит: «повторное выборочное тестирование системы или компонент для проверки сделанных модификаций не должно приводить к непредусмотренным эффектам». На практике это означает, что если система успешно проходила тесты до внесения модификаций, она должна их проходить и после внесения таковых.

Тестирование производительности (Performance testing). Специализированные тесты проверки удовлетворения специфических требований, предъявляемых к параметрам производительности. Существует особый подвид таких тестов, когда делается попытка достижения количественных пределов, обусловленных характеристиками самой системы и ее операционного окружения.

Нагрузочное тестирование (Stress testing). Необходимо понимать отличия между рассмотренным выше тестированием производительности с целью достижения ее реальных (достижимых) возможностей производительности и выполнением программной системы c повышением нагрузки, вплоть до достижения запланированных характеристик и далее, с отслеживанием поведения на всем протяжении повышения загрузки системы.

Сравнительное тестирование (Back-to-back testing). Единичный набор тестов, позволяющих сравнить две версии системы.

Восстановительные тесты (Recovery testing). Цель — проверка возможностей рестарта системы в случае непредусмотренной катастрофы, влияющей на функционирование операционной среды, в которой выполняется система.

Конфигурационное тестирование (Configuration testing). В случаях, если программное обеспечение создается для использования различными пользователями, данный вид тестирования направлен на проверку поведения и работоспособности системы в различных конфигурациях.

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

Разработка, управляемая тестированием (Test-driven development). По-сути, это не столько техника тестирования, сколько стиль организации процесса разработки, жизненного цикла, когда тесты являются неотъемлемой частью требований (и соответствующих спецификаций) вместо того, чтобы рассматриваться независимой деятельностью по проверке удовлетворения требований программной системой.

Глава 2 Инструментальные средства отладки и тестирования программ управления АСУ ТП

2.1 Разработка и отладка АСУ ТП

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

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

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

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

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

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

Для проведения такого тестирования в КТИ ВТ СО РАН создан программно- аппаратный отладочный стенд с перечисленным выше оборудованием. Интегрированная модель исполняется на отдельной рабочей станции. Разработка и исполнение модели происходит с использованием визуально-интерактивной системы дискретного имитационного моделирования 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). Системное тестирование охватывает целиком всю систему. Большинство функциональных сбоев должно быть идентифицировано еще на уровне модульных и интеграционных тестов. В свою очередь, системное тестирование, обычно фокусируется на нефункциональных требованиях — безопасности, производительности, точности, надежности т.п. На этом уровне также тестируются интерфейсы к внешним приложениям, аппаратному обеспечению, операционной среде и т.д.

Список литературы

1. Артемов А.В. Информационная безопасность. Курс лекций. - Орел: МАБИВ, 2014.
2. Бармен Скотт. Разработка правил информационной безопасности. - М.: Вильямс, 2012. - С. 208.
3. Гмурман А.И. Информационная безопасность. М.: "БИТ-М", 2014 г.
4. Журавлев С.С., Окольнишников В.В., Рудометов С.В. Разработка системы мониторинга с использованием имитационного моделирования / Андрюшкевич С.К., Журавлев С.С., Золотухин Е.П., Ковалёв С.П., Окольнишников В.В., Рудометов С.В. Проблемы информатики. 2010. № 4. С. 65-75.
5. Журнал «Секретарское дело» №1 2010 год
6. Информационная безопасность и защита информации Мельников В. П. и др. / Под ред. Клейменова С. А.- М.: ИЦ «Академия», 2012.336 с.
7. Окольнишников В.В. Использование имитационного моделирования при разработке Автоматизированной системы управления технологическими процессами Северомуйского тоннеля // Вычисл. технологии. 2014. Т. 9, № 1. С. 82-101.
8. Окольнишников В.В., Рудометов С.В., Журавлев С.С. Использование имитационного моделирования для тестирования и отладки программ управления АСУ ТП // Сборник докладов Шестой всероссийской научно-практической конференции "Имитационное моделирование. Теория и практика" (ИММОД-2013). - Казань. - 2013. - Т. 2. - С. 131-134.
9. Петров В. А., Пискарев А.С., Шеин А.В. Информационная безопасность. Защита информации от несанкционированного доступа в автоматизированных системах. Учебное пособие. - М.: МИФИ, 2015.
10. Рудометов С.В. Визуально-интерактивная система имитационного моделирования технологических систем // Вестник СибГУТИ. 2011. № 3. С. 14-27.
11. Рудометов С.В. Система имитационного моделирования MTSS. Новосибирск, ФАП СО РАН, 2011, URL: http://fap.sbras.ru/node/2325
12. Современная компьютерная безопасность. Теоретические основы. Практические аспекты. Щербаков А. Ю. - М.: Книжный мир, 2009.- 352 с.
13. Соляной В.Н., Сухотерин А.И. Взаимодействие человека, техники и природы: проблема информационной безопасности. Научный журнал (КИУЭС) Вопросы региональной экономики. УДК 007.51 №5 (05) Королев. ФТА. - 2010.
14. Справочно-правовая система «Консультант Плюс».
15. Стандарты информационной безопасности Галатенко В. А.- М.: Интернет-университет информационных технологий, 2012. - 264 с.
16. Хачатурова С.С. Информационные технологии в юриспруденции: учебное пособие. // Фундаментальные исследования. - 2015. - № 9. - С. 8-9.
17. Хачатурова С.С. Организация предпринимательской деятельности. Создание собственного дела // Международный журнал экспериментального образования. - 2012. - № 2. - С. 137-138.
18. Шаньгин В.Ф. Защита компьютерной информации. Эффективные методы и средства. - М.: ДМК Пресс, 2008. - С. 544.
19. Шутова Т.В., Старцева Т.Е. Высокотехнологичный комплекс России - платформа для инновационного прорыва. Научный журнал (КИУЭС) Вопросы региональной экономики. УДК 007.51 №2 (11) г. Королев. ФТА. 2012г.
20. Victor Okolnishnikov, Sergey Rudometov, and Sergey Zhuravlev. Simulation Environment for Development of Automated Process Control System in Coal Mining // International Journal of Systems Applications, Engineering & Development. 2013. Issue 5, Volume 7. P. 255-262.

1. Хачатурова С.С. Организация предпринимательской деятельности. Создание собственного дела // Международный журнал экспериментального образования. - 2012. - № 2. - С. 137-138. ↑

2. Соляной В.Н., Сухотерин А.И. Взаимодействие человека, техники и природы: проблема информационной безопасности. Научный журнал (КИУЭС) Вопросы региональной экономики. УДК 007.51 №5 (05) Королев. ФТА. - 2010. ↑

3. Шутова Т.В., Старцева Т.Е. Высокотехнологичный комплекс России - платформа для инновационного прорыва. Научный журнал (КИУЭС) Вопросы региональной экономики. УДК 007.51 №2 (11) г. Королев. ФТА. 2012г. ↑

4. Хачатурова С.С. Информационные технологии в юриспруденции: учебное пособие. // Фундаментальные исследования. - 2015. - № 9. - С. 8-9. ↑

5. Петров В. А., Пискарев А.С., Шеин А.В. Информационная безопасность. Защита информации от несанкционированного доступа в автоматизированных системах. Учебное пособие. - М.: МИФИ, 2015. ↑

6. Окольнишников В.В. Использование имитационного моделирования при разработке Автоматизированной системы управления технологическими процессами Северомуйского тоннеля // Вычисл. технологии. 2014. Т. 9, № 1. С. 82-101. ↑

7. Журавлев С.С., Окольнишников В.В., Рудометов С.В. Разработка системы мониторинга с использованием имитационного моделирования / Андрюшкевич С.К., Журавлев С.С., Золотухин Е.П., Ковалёв С.П., Окольнишников В.В., Рудометов С.В. Проблемы информатики. 2010. № 4. С. 65-75. ↑

8. Рудометов С.В. Визуально-интерактивная система имитационного моделирования технологических систем // Вестник СибГУТИ. 2011. № 3. С. 14-27. ↑

9. Окольнишников В.В., Рудометов С.В., Журавлев С.С. Использование имитационного моделирования для тестирования и отладки программ управления АСУ ТП // Сборник докладов Шестой всероссийской научно-практической конференции "Имитационное моделирование. Теория и практика" (ИММОД-2013). - Казань. - 2013. - Т. 2. - С. 131-134. ↑