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

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

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

В результате имитационная математическая модель имеет блочную структуру, в которой связи между блоками соответствуют связям реальной системы между элементами ее структуры.

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

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

 

Вопросы для самопроверки

Функциональные и нефункциональные требования к ПО компьютерных технологий управления СТС.

Качество ПО и технология его производства. Влияние человеческого фактора.

Стандартизация характеристик качества ПО. Управление качеством ПО

Функциональные возможности ПО - функциональная полнота

Безопасность и безотказность ПО.

Системный подход к разработке ПО. Временной и "пространственный " аспекты системного подхода

Этапы жизненного цикла ПО. Каскадная модель жизненного цикла ПО.

Спиральная модель жизненного цикла ПО

«Тяжелые и облегченные»(быстрые) технологии разработки ПО

Классификация ПО. Критические системы.

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

Имитационные математические модели - основное инструментальное средство для КО ПО.

Отладочные комплексы. Отладка распределенного ПО.

Лекция 9. Математическая модель. Численные методы интегрирования уравнений математических моделей. Современные средства для компьютерного моделирования систем автоматизации и управления.

Цена ошибок проектирования. Закон Рамамурти. Проектирование, основанное на моделировании

В разработке ПО сложилась ситуация, которая известна, как закон Рамамурти. В соответствии с этим законом основная часть трудно устранимых ошибок вносится в ПО не на стадиях программирования и эксплуатации, а на стадиях определения требований и проектирования. Кривая изменения по этапам работ стоимости устранения обнаруженных ошибок имеет тенденцию роста с приближением к начальным стадиям разработки (рис. 9.1). Понятно, что чем на более раннем этапе сделана ошибка, тем больший объем уже проделанной работы по переработке кода, его отладке, выпуску документации и т.п. необходимо повторять после её исправления.

Цена исправления ошибки

 

Определение проектирование разработка отладка эксплуатация

требований Этапы работ

 

 

Рис. 9.1 – Цена исправления ошибки

 

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

Можно утверждать, что правильные решения, принятые на ранней стадии проектирования – критически важны. И, наоборот, исправление плохих решений практически всегда очень дорого, если их вообще возможно исправить. Имеются попытки экспериментально доказать это интуитивно правильное утверждение. Например, была рассмотрена статистика по 25 проектам NASA и построена зависимость в координатах перерасход средств – отношение затрат на стадиях определения требований и ранних стадиях проектирования к общим затратам. Если последние находятся в диапазоне до 5%, то перерасход средств в большинстве случаев составлял 100 - 160%. Если отношение затрат на ранние стадии проектирования к общим затратам составляло 10 – 25%, то перерасход средств составил 20-40 процентов. Аппроксимация этих данных плавной кривой методом наименьших квадратов даёт кривую, напоминающую кривую закона Рамамурти.

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

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

 

Метод Эйлера численного интегрирования систем дифференциальных уравнений

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

Рассмотрим –дифференциальное уравнение в форме Коши первого порядка. Функция f(x,t) может быть как линейной, так и нелинейной. Представим производную в известном виде

Тогда

Тогда, рассматривая ряд точек на временной оси с шагом , имеем

Дискретное представление по шагам

Xn+2= Xn+1 + t f(Xn+1,t)

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

Метод Эйлера достаточно груб и в практических случаях применяется редко, поскольку давно придуманы его уточнения, которые, правда, приводят к более сложным выкладкам. Эти уточнения косвенным образом учитывают не только первую производную в начальной точке шага, но и вторую, третью и т.п. Широкое распространение получили методы Рунге – Кутта и Адамса, которые имеются в библиотеках систем программирования. Мы в нашем курсе рассматриваем метод Эйлера, преследуя чисто методологические цели – показать простой и ясный метод численного интегрирования дифференциальных уравнений. Уменьшение ошибки метода связаны с уменьшением шага интегрирования, либо с сокращением интервала интегрирования, так как ошибка накапливается. Приведенные ниже примеры численного интегрирования дифференциальных уравнений методом Эйлера подготовлены в среде Mathсad.

Инерционное звено - дифференциальное уравнение 1го порядка

Дифференциальное уравнение 2го порядка - колебательное звено

Запись системы уравнений в нормальной форме Коши для численного интегрирования

Далее представим систему уравнений замкнутой системы управления ракетой в форме Коши, то есть разрешенной относительно первой производной.

Обозначим = x₀; = x₁; δ = x₂

Начальные условия: t₍₀₎ = 0, = = δ = 0 (х₀ = х₁ = х₂ = 0).

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

Моделирование, как метод имитации поведения СТС при выполнении ею целевой задачи, традиционно применяется при проектировании СТС:

для выбора структуры и параметров объектов управления и системы управления,

для проверки проектных решений в штатных и нештатных ситуациях и получения характеристик динамических процессов,

для статистических исследований с учетом вероятных разбросов характеристик параметров модели и возмущающих факторов,

для прогнозирования поведения СТС на будущие времена,

для идентификации параметров системы по экспериментальным данным.

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

Что касается использования готового ПО встроенных вычислительных средств СТС, то оно, как правило, на проектной стадии отсутствует, так как разрабатывается параллельно и вполне достаточно использовать предполагаемые алгоритмы (или исследуемые алгоритмы) решения задач СТС, исполняемые на универсальных ЦВМ.

Принципиально важно, что проектные модели должны имитировать работу СТС в реальном времени.

Роль математического моделирования, как средства генерации данных на отладку ПО встроенных в систему ЦВМ.

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

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

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

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

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

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

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

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

И, наконец, нужно ли использовать реальную аппаратуру в контуре моделирования или математические модели её обеспечат необходимую достоверность результатов?

Ниже даются ответы на эти вопросы.

Задачи математического моделирования на этапах испытаний и эксплуатации жизненного цикла СТС

Моделирование работы СТС при испытаниях собранной СТС. Как правило, при таких испытаниях невозможно запустить в реальную работу объект управления по соображениям безопасности. Здесь наличие реальной аппаратуры СТС обязательно, так как целью моделирования работы собранной системы является проверка физических связей между всеми элементами аппаратного комплекса и правильность его функционирования в различных вариантах использования СТС. Это – хоть и частичная (объект управления в основном моделируется) экспериментальная отработка собранной системы.

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

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

Моделирование широко применяется в процессе эксплуатации КА ДЗЗ и систем в двух случаях:

1 Для проверки гипотез по причинам нештатных ситуаций. При этом используются доступные реальные данные полученные в процессе нештатной ситуации.

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

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

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

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

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

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

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

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

Решение задач 1 и 2 возможно как с применением реальной датчиковой аппаратуры и исполнительных органов в контуре моделирования, так и с использованием математических моделей этих устройств.

Для решения задач 1 и 2 использование реального ПО системной ЦВМ со всеми тонкостями взаимодействия и синхронизации его внутренних процессов и потоков при многозадачной работе представляется обязательным

Альтернативой использованию реальной аппаратуры встроенной системной ЦВМ является использование программного эмулятора системной ЦВМ с загруженным в него реальным ПО системы, что при моделировании вполне соответствует целям задач 1 и 2.

Использование реальной БЦВМ накладывает однозначное требование на процесс моделирования - моделировать надо в реальном времени.

С одной стороны это может потребовать доработки ЦВМ под старт-стопный режим, если уравнения моделей объекта, датчиков и исполнительных органов будут решаться слишком долго - больше, чем время периода решения задач управления в ЦВМ.

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

 

Реальная аппаратура в контуре моделирования. Принцип повторяемости результатов при моделировании

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

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

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

В третьих, существенная часть моделирования – проверка работы СТС в нештатных ситуациях. На реальной аппаратуре трудно имитируются нештатные ситуации в аппаратуре. Не ломать же её?! Моделирование же нештатных ситуаций на математической модели осуществляется буквально «росчерком пера».

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

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

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

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

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

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

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

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

 

Современные технологии и средства для компьютерного моделирования систем автоматизации и управления

Рассмотрев основную компьютерную технологию создания систем управления для СТС – имитационное математическое моделирование имеет смысл остановится на средствах и инструментах, облегчающих её применение.

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

выполнять действия с векторами и матрицами,

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

проводить статистическую обработку результатов.

аппроксимировать функции, заданные таблично,

решать задачи оптимизации и т.п.

Пакет SIMULINK позволяет моделировать динамические процессы путем создания структурной схемы, состоящих из различных звеньев и блоков На экране дисплея создается модель исследуемой системы. Меняя параметры системы схему связей между её звеньями можно исследовать динамические процессы, протекающие в системе.