Ядром разработки является программная модель объекта управления
Модельно-ориентированное проектирование
Модельно-ориентированное проектирование (МОП) — это математический и визуальный метод решения задач, связанных с проектированием систем управления, обработки сигналов и связи[1][2]. МОП часто используется при управлении движением в промышленном оборудовании, аэрокосмической и автомобильной промышленности. МОП является методологией, применяемой при разработке встроенного программного обеспечения.
МОП определяет общую структуру взаимодействия в процессе проектирования, эффективно реализуя V-образный цикл разработки.
Модели процесса разработки программного обеспечения:
· Каскадная модель
В 1970 году в своей статье Ройс описал в виде концепции то, что сейчас принято называть «каскадная модель», и обсуждал недостатки этой модели. Там же он показал как эта модель может быть доработана до итеративной модели.
В исходной каскадной модели следующие фазы шли в таком порядке:
1. Определение требований
2. Проектирование
3. Конструирование (также «реализация» либо «кодирование»)
4. Воплощение
5. Тестирование и отладка (также «верификация»)
6. Инсталляция
7. Поддержка
Переход от одной фазы к другой происходит только после полного и успешного завершения предыдущей
Следуя каскадной модели, разработчик переходит от одной стадии к другой строго последовательно. Сначала полностью завершается этап «определение требований», в результате чего получается список требований к ПО. После того как требования полностью определены, происходит переход к проектированию, в ходе которого создаются документы, подробно описывающие для программистов способ и план реализации указанных требований. После того, как проектирование полностью выполнено, программистами выполняется реализация полученного проекта. На следующей стадии процесса происходит интеграция отдельных компонентов, разрабатываемых различными командами программистов. После того, как реализация и интеграция завершены, производится тестирование и отладка продукта; на этой стадии устраняются все недочёты, появившиеся на предыдущих стадиях разработки. После этого программный продукт внедряется и обеспечивается его поддержка — внесение новой функциональности и устранение ошибок.
|
|
|
Тем самым, каскадная модель подразумевает, что переход от одной фазы разработки к другой происходит только после полного и успешного завершения предыдущей фазы, и что переходов назад либо вперёд или перекрытия фаз — не происходит.
· V модель VEE
Концепция V-образной модели была разработана Германией и США в конце 1980-х годов независимо друг от друга:
|
|
|
Современной версией V-Model является V-Model XT, которая была утверждена в феврале 2005 года. V-модель используется для управления процессом разработки программного обеспечения для немецкой федеральной администрации. Сейчас она является стандартом для немецких правительственных и оборонных проектов, а также для производителей ПО в Германии. V-Model представляет собой скорее набор стандартов в области проектов, касающихся разработки новых продуктов. Эта модель описывает методы как для проектного управления, так и для системного развития.
Основные принципы
V-Model процесса разработки ИС[3].
Основной принцип V-образной модели заключается в том, что детализация проекта возрастает при движении слева направо, одновременно с течением времени, и ни то, ни другое не может повернуть вспять. Итерации в проекте производятся по горизонтали, между левой и правой сторонами буквы.
Применительно к разработке информационных систем V-Model — вариация каскадной модели, в которой задачи разработки идут сверху вниз по левой стороне буквы V, а задачи тестирования — вверх по правой стороне буквы V. Внутри V проводятся горизонтальные линии, показывающие, как результаты каждой из фаз разработки влияют на развитие системы тестирования на каждой из фаз тестирования. Модель базируется на том, что приёмо-сдаточные испытания основываются, прежде всего, на требованиях, системное тестирование — на требованиях и архитектуре, комплексное тестирование — на требованиях, архитектуре и интерфейсах, а компонентное тестирование — на требованиях, архитектуре, интерфейсах и алгоритмах
|
|
|
Цели
V-модель обеспечивает поддержку в планировании и реализации проекта. В ходе проекта ставятся следующие задачи:
· Минимизация рисков: V-образная модель делает проект более прозрачным и повышает качество контроля проекта путём стандартизации промежуточных целей и описания соответствующих им результатов и ответственных лиц. Это позволяет выявлять отклонения в проекте и риски на ранних стадиях и улучшает качество управления проектов, уменьшая риски.
· Повышение и гарантии качества: V-Model — стандартизованная модель разработки, что позволяет добиться от проекта результатов желаемого качества. Промежуточные результаты могут быть проверены на ранних стадиях. Универсальное документирование облегчает читаемость, понятность и проверяемость.
|
|
|
· Уменьшение общей стоимости проекта: Ресурсы на разработку, производство, управление и поддержку могут быть заранее просчитаны и проконтролированы. Получаемые результаты также универсальны и легко прогнозируются. Это уменьшает затраты на последующие стадии и проекты.
· Повышение качества коммуникации между участниками проекта: Универсальное описание всех элементов и условий облегчает взаимопонимание всех участников проекта. Таким образом, уменьшаются неточности в понимании между пользователем, покупателем, поставщиком и разработчиком
Достоинства
· Пользователи V-Model участвуют в разработке и поддержке V-модели. Комитет по контролю за изменениями поддерживает проект и собирается раз в год для обработки всех полученных запросов на внесение изменений в V-Model
· На старте любого проекта V-образная модель может быть адаптирована под этот проект, так как эта модель не зависит от типов организаций и проектов
· V-model позволяет разбить деятельность на отдельные шаги, каждый из которых будет включать в себя необходимые для него действия, инструкции к ним, рекомендации и подробное объяснение деятельности
Преимущества
· В модели особое значение придается планированию, направленному на верификацию и аттестацию разрабатываемого продукта на ранних стадиях его разработки. Фаза модульного тестирования подтверждает правильность детализированного проектирования. Фазы интеграции и тестирования реализуют архитектурное проектирование или проектирование на высшем уровне. Фаза тестирования системы подтверждает правильность выполнения этапа требований к продукту и его спецификации[10].
· В модели предусмотрены аттестация и верификация всех внешних и внутренних полученных данных, а не только самого программного продукта[10][11][12].
· В V-образной модели определение требований выполняется перед разработкой проекта системы, а проектирование ПО — перед разработкой компонентов[10].
· Модель определяет продукты, которые должны быть получены в результате процесса разработки, причём каждые полученные данные должны подвергаться тестированию[10][12].
· Благодаря модели менеджеры проекта могут отслеживать ход процесса разработки, так как в данном случае вполне возможно воспользоваться временной шкалой, а завершение каждой фазы является контрольной точкой[10][12].
Принципы МОП существенно отличаются от традиционной методологии проектирования СУ. Вместо создания сложных программных кодов разработчики могут применять МОП для улучшения характеристик модели, используя стандартные функциональные блоки с непрерывным и дискретным временем. Построенные таким образом модели вместе с использованием инструментов для моделирования могут быстро привести к созданию прототипа системы управления, тестированию и верификации программного обеспечения. В некоторых случаях аппаратно-программное моделирование может быть использовано в качестве инструмента проектирования для более быстрого и эффективного тестирования динамических воздействий на систему, в отличие от традиционного метода проектирования.
Некоторые из наиболее заметных преимуществ МОП в сравнении с традиционным подходом:
· МОП предоставляет общую среду разработки, что способствует взаимодействию группы разработчиков в процессе анализа данных и проверки системы
· Инженеры могут найти и исправить ошибки на ранних стадиях проектирования системы, когда время и финансовые последствия изменения системы сводятся к минимуму
· МОП способствует повторному использованию модели для улучшения системы и создания производных систем с расширенными возможностями.
В модельно-ориентированном проектировании систем управления разработка происходит в 4 этапа:
Основные этапы МОП
1. Построение модели объекта. Построение модели может быть эмпирическим и теоретическим. При эмпирическом построении модели используются такие методы, как идентификация системы. При идентификации системы собираются и обрабатываются исходные данные, полученные от реальной системы, и некоторый алгоритм используется для определения математической модели объекта. Перед построением системы управления модель может быть использована для анализа и построения различных симуляторов. При теоретическом моделировании строятся блок-схемы модели, которые реализуют известные дифференциально-алгебраические уравнения, описывающие динамику объекта. К этому типу относится физическое моделирование, где модель создается с помощью соединяющихся блоков, представляющих собой физические элементы, из которых фактически состоит модель. Данный подход реализован, например, в продукте Simscape в составе среды MATLAB[3].
2. Анализ и построение системы управления. Математическая модель, сконструированная на шаге 1, используется для определения динамических характеристик модели объекта. На основе этих характеристик строится система управления.
3. Офлайн-моделирование и моделирование в реальном времени. Время отклика динамической системы на входные данные, изменяющиеся во времени, исследуется с помощью симуляции модели в виде простой линейной стационарной системыили нелинейной системы. Симуляция позволяет немедленно найти характеристики модели, требования, накладываемые на неё, и ошибки построения до начала проектирования. Моделирование в реальном времени может быть осуществлено с помощью автоматической генерации кода системы управления, построенной на шаге 2. Этот регулятор может быть запущен на специальном компьютере, управляющем работой объекта в реальном времени. Если прототип объекта отсутствует или тестирование на прототипе опасно или дорого, код прототипа может автоматически генерироваться из модели объекта и запускаться на специальном компьютере, работающем в реальном времени и соединенном c целевым процессором с меняющимся кодом управления. Таким образом система управления может быть протестирована в реальном времени на модели объекта.
4. Реализация регулятора. В идеале это делается с помощью автоматической генерации кода из системы управления, полученной на шаге 2. Маловероятно, что система управления будет работать в реальной системе так же хорошо, как это было при моделировании, поэтому итерационный процесс отладки осуществляется на основе анализа результатов на фактическом объекте и обновления модели регулятора. Инструменты МОП позволяют выполнить все эти итерационные шаги в единой визуальной среде.
Эти проблемы решаются с помощью графических инструментов моделирования, уже используемых во всех областях проектирования. Такие инструменты образуют единую среду графического моделирования, уменьшают сложность построения модели, разбивая её на отдельные блоки, каждый из которых проектируется самостоятельно. Таким образом, конструкторы могут достигать высокого уровня точности, просто заменяя один блок на другой. Графические модели также являются лучшим способом документирования идей инженеров. Это помогает инженерам осмыслить всю систему и упрощает процесс переноса модели от одной стадии к другой во время проектирования.
При разработке встроенных систем управления конструкторы столкнулись с двумя проблемами — сокращением циклов разработки и ростом сложности проекта. Стратегия «разделяй и властвуй» для развития таких сложных систем означает координацию людей, имеющих опыт в широком спектре дисциплин. Традиционный текстовый подход к проектированию встроенных систем управления недостаточно эффективен, чтобы справляться с продвинутыми сложными системами.
Трудности традиционного подхода к проектированию систем управления заключаются в том, что на этапе составления требований и спецификаций используемые текстовые документы несовершенны при итеративном подходе, физические прототипы на этапе проектирования также несовершенны, сложны и дороги; на этапе реализации при ручной разработке применение других программных средств и человеческие ошибки делают процесс ненадежным, а на этапе проверки традиционное тестирование приводит к обнаружению ошибок лишь в конечной стадии разработки ПО.
Метод для решения всего комплекса перечисленных задач в рамках единой среды разработки на платформе MATLAB/Simulink модельно ориентированное проектирование. Этот метод объединяет в непрерывный рабочий процесс разные этапы разработки системы, такие как формирование спецификаций и системных требований, имитационное моделирование, разработка системы, отладка и тестирование. Модельно ориентированное проектирование помогает координировать работу различных групп разработчиков и позволяет выявлять ошибки на ранних стадиях, значительно сокращая время разработки и повышая эффективность проектирования.
ядром разработки является программная модель объекта управления
Эта модель является единой для разработчиков — специалистов в различных областях знаний (инженеров-разработчиков систем управления, физиков, математиков, проектировщиков электрических, механических, гидравлических систем и др.). Требования, предъявляемые к математической модели объекта и к конечному продукту, связываются с программной моделью. Такая связь с единой моделью обеспечивает прозрачность разработки и, как следствие, соблюдение одних и тех же требований всеми участниками проекта. Алгоритмы, разработанные для математической модели объекта управления, проверяются на программной модели. Благодаря этому удается избежать затрат на раннее прототипирование (создание аппаратных прототипов устройств), а также поломок прототипов. После программной проверки из модели автоматически генерируется программный код для управляющего устройства
Основные возможности модельно ориентированного проектирования при проектировании встраиваемых систем на микроконтроллерах:
· разработка моделируемых спецификаций;
Исполняемая спецификация может также включать входные данные и предполагаемые выходные данные или критерии соответствия и условия эксплуатации, а также ссылки на требования. Цель исполняемой спецификации заключается в однозначной формулировке цели разработки, а также в возможности анализа осуществимости и совместимости требований посредством моделирования.
· проектирование и моделирование динамически систем с компонентами различной физической природы
· автоматическое генерирование кода;
· непрерывное тестирование и верификация.
При модельно-ориентированном проектировании эффективность работы инженеров повышается благодаря следующим возможностям:
· использование общей для всех проектных групп среды проектирования;
· прямая привязка разработок к требованиям;
· интеграция тестирования и разработки для непрерывного выявления и исправления ошибок;
· совершенствование алгоритмов посредством многодоменного моделирования;
· автоматическая генерация встроенного ANSI C, Verilog и VHDL кода;
· разработка в том числе и автоматизированная и многократное использование комплексных тестов;
· автоматическое создание документации;
· многократное использование разработок для развертывания системы на многоядерных процессорах и кластерах.
Автоматическая генерация кода обеспечивает генерацию ANSI/ISО С кода из моделей Simulink для применения в конечном продукте и ускорения имитации (для микропроцессоров, DSP), а также быстрого создания прототипов и тестирования в аппаратном режиме. Тестирование и верификация осуществляются на основе технических требований, прослеживаются требования в коде, осуществляется непрерывное тестирование в процессе имитационного моделирования, создания прототипов, программ, на уровне микроконтроллера и аппаратном уровне.
При проверке и тестировании применяется программное, процессорно-программное и аппаратно-программное тестирование. Основывается на требованиях, задание группы входных сигналов выполняется с помощью Signal Builder, а задание ожидаемого поведения выходов с помощью блоков проверки.
Использование машин реального времени типа Speedgoat быстрое прототипирование
Программное тестирование sil
Процессорно-программное тестирование PIL
HIL программно-аппаратное тестирование
Отчеты о проведенном тестировании и проверке создаются в форматах HTML, PDF и DOC
Преимущества модельно ориентированного проектирования:
· снижается себестоимость за счет минимизации использования прототипов, облегчается повторное использование наработок в других проектах;
· сокращаются сроки проектирования за счет более быстрого ввода в производство и улучшения обмена информацией между группами;
· улучшаются эксплуатационные качества, что способствует инновациям и улучшает качество.
Дата добавления: 2019-02-22; просмотров: 286; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!