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

Введение.Требованиякотладочнойсреде

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

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

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

• 1.    У разработчиков и тестировщиков ПО есть все необходимые инструменты.

• 2.    ПО отлаживается в полной конфигурации, отсутствуют выброшенные или добавленные для отладки фрагменты.

• 3.    Отладка ПО проводится на ЭВМ той же архитектуры и конфигурации, что и в реальной системе. В крайнем случае, системная ЭВМ может эмулироваться в инструментальной при наличии доказательств полноты эмуляции.

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

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

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

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

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

Рис 1. Структурная схема СТС и структура и место имитационной математической модели внешней среды для отладки ПО. СБВУИ – система более высокого уровня иерархии; ИО – исполнительные ор- ганы

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

Преимущества математического моделирования внешней среды при отладке ПО

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

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

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

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

Поэтому наиболее целесообразны методы проведения комплексной отладки путем исполнения отлаживаемого ПО совместно с цифровой математической моделью (ММ) внешней по отношению к ПО среды (см. рис. 1).

Рекомендуя при отладке ПО работать с ММ, мы отдаем себе отчет в обязательности встречи ПО с реальной аппаратурой системы до завершения ее разработки, но на другом этапе жизненного цикла ПО СТС. Для этого имеется этап ЖЦ ПО – отработка ПО совместно с системой [1]. Проверку работы отлаженного на цифровой модели внешней среды ПО в дальнейшем возможно проводить на стендах (экспериментальных установках – ЭУ и образцах системы) с реальной аппаратурой. Цели и критерии при проведении этих работ уже другие и отличаются от целей и критериев при отладке ПО. Наличие отлаженного ПО позволяет не заниматься отладкой ПО на этих ЭУ, а заниматься проверкой реальных электрических связей системы.

Имитационные математические модели – основное инструментальное средство для комплексной отладки ПО

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

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

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

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

Основные требования к данной имитационной ММ внешней среды при ее использовании для комплексной отладки ПО следующие.

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

• 2.    Модель должна воспринимать всю выходную информацию из отлаживаемого ПО и отображать ее в согласованном виде. В модели должны быть реализованы контуры обратных связей там, где они имеются в реальной системе.

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

• 4.    Использование алгоритмов отлаживаемого ПО в другой программной реализации не имеет смысла, так как не соответствует целям отладки.

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

Двойное применение математической имитационной модели внешней среды. Жизненный цикл имитационной ММ внешней среды

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

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

Другое важное применение ИММ в контуре управления СТС – контроль правильности подготовки данных для работы ПО СТС в системах более высокого уровня иерархии. Ошибки в операции подготовки данных для работы для сложных систем (где объем закладываемых в ПО системы данных велик, а также сами данные имеют сложную логическую внутреннюю структуру) весьма вероятны, как показывает практика, что приводит к тяжелым последствиям, особенно для критических систем.

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

Исследования в области ПО показали связь между размером программной функции в строках исходного текста и числом точек входов и выходов в ПО (числом имен входных и выходных данных) [2]. Эта базовая связь корректируется, например, в модели «функциональных точек» с учетом особенностей работы ПО, в том числе и в жестком реальном времени, с учетом среды, в которой работает ПО, и т.п.

Если учесть, что входные данные ПО – это выходные данные модели внешней среды, а входные данные в модель – выходные данные ПО, то сложность и размер имитационной математической модели внешней среды должны иметь, по крайней мере, тот же порядок, что и у отлаживаемого ПО. В конкретных случаях СТС сложность и размер имитационной ММ для отладки ПО достигает 60-80% от сложности и размера отлаживаемого ПО [2 ].

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

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