В предыдущих статьях про модельно-ориентированное проектирование Как не повторить Чернобыль, Электропривод с бесколлекторным двигателем постоянного тока, и Создание достоверной модели, на примере авиационного теплообменника, я показал на примерах, что не все методики модельно-ориентированного проектирования (МОП) одинаково полезны.
Начиная свою инженерную деятельность в атомной отрасли, я привык, что первым этапом проектирования является создание модели объекта. Модель объекта в атомной отрасли, является обязательной частью проекта. Средства моделирования для АЭС проходят аттестацию, где экспертиза определяет их применимость для расчетного моделирования процессов АЭС. И если есть модель объекта, то модель системы управления естественно разрабатывается совместно в виде комплексной модели. Именно это и является в моем представление методом модельно-ориентированного проектирования.
По моему мнению, моделирование одной только системы управления без создания модели объекта является ущербным. Поэтому, когда вы слушаете рассказы поставщиков моделирующего софта для разработки ПО, необходимо понимать о чем идет речь: о новых передовых методиках разработки систем или о модельно-ориентированном проектировании в понимании авиационного стандарта DO-331.
Нужно помнить, что МОП в авиационных стандартах отражает устаревший и консервативный подход к модельно-ориентированной разработке ПО. И в этом подходе, даже если ваша модель – это только набор UML диаграмм, где собраны требования к ПО, это все равно будет модельно-ориентированное проектирования в терминах DO-331.
Предлагаю перевод статьи «DO-331 Model based development for engineer and manager», публикуемый мной с любезного разрешения автора Vance Hilderman (vance.hilderman@afuzion.com) Vance Hilderman www.afuzion.com
Данный текст позволит сориентироваться в основных положениях стандарта DO-331, терминах и понятиях, которые в нем используются.
Введение
«DO-331 Модельно-ориентированная разработка и верификация», является дополнением для стандартов DO-178C и DO-278A и содержит в себе 125 страниц руководства по использованию модельно-ориентированной разработки (Мodel_Based Development (MBD)) при разработке бортового и наземного авиационного программного обеспечения. Хотя концепция МОП относительно нова для авиационного программного обеспечения, перед авторами DO-331 стояла большая проблема: как предоставить разумное руководство для людей, которые в своей массе не знакомы с модельно-ориентированной разработкой?
Спросите любого разработчика ПО или его руководителя: «что является Святым Граалем в разработке ПО?» и самый распространённый ответ будет: «ПО автоматически создаваемое из модели с 100% многоразовым использованием.» Конечно такой ответ будет сопровождаться улыбкой (или ухмылкой, с точки зрения руководителя). Но, как правило, ПО очень редко на 100% автоматически генерируется и используется повторно без изменений. В авиации существует достаточно большое количество повторно используемого ПО, и мало кто в мире будет отрицать, что авиационное ПО находится среди лучшего, если не самого лучшего критического ПО, существующего в мире.
Регулирующие органы в авиации исходят из следующего постулата: нет хорошего ПО, любое ПО в конечном итоге может отказать. Этот факт не оспаривается, и ПО пишется так, чтобы оно могло выявлять ошибки и смягчать их последствия. Распространение современных практик разработки приводит к оценке МBD как следующей «большой надежды» на то, чтобы продвинуться немного ближе к этому Святому Граалю.
Многие читатели участвовали в тренингах по созданию безопасного и критического ПО, которые проводит автор. Такие участники знают, что одним из секретов удержания внимания студентов к скучной технической теме является комбинация методов обучения Сократа и частые тесты. Это позволяет держать студентов в тонусе и понимать, что они усваивают во время учебы, а не только в конце, когда уже поздно менять программу обучения. Приняв это во внимание, давайте рассмотрим следующий легкий тест по DO-331 MBD
| N | Вопрос | Ответ |
| 1 | Если вы используете моделирование, но не используете автоматическую генерацию кода, необходимы ли вам «Стандарты моделирования ПО» и «Анализ покрытия модели?» | Да, Нет, Может быть |
| 2 | При использовании модели для верификации должны ли быть определены результаты перед выполнением тестов? | Да, Нет, Может быть |
| 3 | Может ли быть разработана Проектная модель из системных требований без первичной декомпозиции системных требований до требований к ПО высокого уровня? | Да, Нет, Может быть |
| 4 | Должны ли системные требования быть декомпозированы до требований к ПО высокого уровня, прежде чем разработана Проектная модель? | Да, Нет, Может быть |
| 5 | Если системные требования используются как источник требований к проектной модели, можно ли обращаться с этими требованиями, как с требованиями к ПО высокого уровня, и содержит ли Проектная Модель в этом случае требования низкого уровня? | Да, Нет, Может быть |
Почему моделирование?
Моделирование ПО существует почти столько же, сколько и разработка ПО. Модели активно использовались для помощи инженерам в первых лунных проектах NASA. Сейчас моделирование является основной частью активности, посредством которой структура и поведение объектов определяются на более высоком уровне абстракции, чем разработка логики. Обычное использование «модели» означает, в первую очередь, разработку модели структуры и поведения объекта, а во вторую очередь, модель используется для генерации актуального ПО или «железной» (hardware) логики. (В мире авиации термин «hardware» включает логику, встроенную в кремний, ранее известную как «firmware», современный термин «complex electronic hardware» via DO-254). Однако, моделирование на самом деле происходит после процесса разработки логики, а не до него. Для многих существующих накопленных кодов осуществляется постфактум создание моделей для того, чтобы было проще понимать, верифицировать, улучшать или повторно использовать готовый код, особенно в области авионики, где большинство систем, по крайней мере частично базируются на предыдущих похожих системах. Такой процесс известен как «реверс-инжиниринг».
Почему возрастает важность моделирования для авионики, что подтверждается выпуском дополнения DO-331 в декабре 2011 года? Причин много. Некоторые из них приведены ниже:
- Улучшение работы с комплексными системами. Модель позволяет улучшить понимание и управление увеличением сложности.
- Улучшение повторного использования кода. Модель поощряет повторное использование, позволяя разработчику абстрактно описывать функциональность.
- Возможность автоматической генерации кода. Модель предоставляет потенциальную возможность для автоматической генерации кода.
- Повышение прозрачности логики. Модель позволяет использование графических языков Simulink или SysML.
- Общий язык = меньше допущений. Инженеры по системам и разработчики используют общий язык моделирования.
- Улучшения прослеживаемости. Инструменты моделирования могут автоматизировать прослеживаемость от требований до кода.
- Ранняя верификация. Моделирование позволяет осуществлять раннюю проверку требований и верификацию проекта.
Преимущества моделирования
Как показано выше, есть много преимуществ при моделировании комплексных систем и ПО. В других областях техники, например, в телекоммуникации, моделирование применяется в течении многих лет. Авионика постепенно их догоняет. Нужно отметить, что реальность разработки авиационного ПО такова, что сертификационные процессы полностью игнорируют здравый смысл в части стоимости и времени разработки. Никто не хочет и не ожидает разорения разработчиков авионики, но они сами разорятся, пытаясь выполнить требования сертификации. А что останавливает всех разработчиков от широкого применения моделирования в организациях, разрабатывающих авионику? Перечислим наиболее частые причины, по которым разработчики авиационной техники избегают частичного или полного использования моделирования:
- Неоднозначность интерпретации DO-331 или ограничения при слишком консервативной интерпретации;
- Cтоимость лицензирования инструментов моделирования;
- Необходимость обучения средствам моделирования;
- Восприятие сложности или необходимости квалификации инструментов по DO-330;
- Базовая культура традиционных системных инженеров, предпочитающих работать исключительно с английским текстом, избегая использования любых моделирующих инструментов;
- Боязнь сделать что по-новому;
- Недостаток уверенности в качестве автоматически генерируемого из модели кода;
- Беспокойство о недостатках контроля над специфическим конструкциями кода, сгенерированного из модели.
Справедливы ли вышеперечисленные причины для отказа от моделирования? Честный ответ, соответствующий объективной реальности некоторых людей – «может быть». Но по мере изучения предмета убеждения людей могут меняться.
Во-первых, DO-331 обеспечивает возможность использования моделирования в рамках стандартов моделирования и верификации моделей. Так же как для традиционных требований к ПО и процессу проектирования ПО, которые должны быть верифицированы для демонстрации соответствия пользовательским стандартам, то же самое верно для моделирования авиационной техники.
Во-вторых, стоимость лицензирования средств моделирования не такая высокая с учетом с экономии, получаемой за счет увеличения производительности инженерной работы. А некоторые средства моделирования такие как IBM’s Rhapsody and Magic Draw вполне доступны и при этом содержат все необходимы ключевые инструменты.
В-третьих, так же как и с затратами на лицензирование, обучение инструментам моделирования проводится за несколько недель, или самое большое – несколько месяцев, и это относительно быстро, принимая во внимание многолетнюю продолжительность разработки для большинства авиационных систем.
В-четвертых, нет необходимости для квалификации инструментов для моделирования. Хотя квалификация сама по себе представляет ценность (сокращение ручного описания кода, автоматическая генерация кода, верификация на уровне модели), все перечисленные выше преимущества моделирования сохраняются, вне зависимости квалифицированы средства или нет.
В-пятых, все инженеры могут освоить новые техники, и большинство оценят такие знания для повышения собственной квалификации.
Таким образом, все выше описанные опасения развеиваются. В добавок инструменты моделирования, такие как IBM’s Rhapsody, имеют 20-летнюю историю развития и применения, и обладают достаточно высоким качеством сгенерированного кода и возможностями управлять и настраивать генерацию данного кода.
Терминология в области моделирования
В области моделирования есть собственный глоссарий терминов, часть которых приведена ниже, с пояснениями.
| Генерация кода (Code Generation) | Генерация кода из проектной модели на определенном языке программирования, таком как С, С++, Ada |
| Проектная модель (Design Model) | Модель, которая подробно описывает любую часть проекта, такую как требования низкого уровня, архитектура ПО, компоненты внутренней структуры данных, поток данных и (или) поток управления. Модель, используемая для генерации исходного кода, является проектной моделью. |
| Модель (Model) | Абстрактное представление заданного набора аспектов системы, используемое для анализа, верификации, моделирования, генерации кода или любой комбинации из них. Она должна быть непротиворечивой, несмотря на уровень абстракции. |
| Модельно-ориентированная разработка и верификация (Model-Based Development and Verification) |
Технология, в которой модели представляют требования ПО и (или) описание проекта ПО для поддержки процесса разработки и верификации. |
| Модельно-ориентированное тестирование (Model-Based Test) | Создание тестовых наборов на языке моделирования и с инструментами для верификации модели и (или) сгенерированного исходного кода. |
| Проверка модели (Model Checking) | Применение формализованных правил для подтверждения корректности моделей, например, достижение требуемого состояния и правильное использование языка моделирования. |
| Анализ покрытия модели (Model Coverage Analyses) | Анализ, определяющий, какие требования, заложенные в проектной модели, не вычисляются верификацией, основанной на требованиях, из которых проектная модель была сформирована. Предназначен для выявления функций проектной модели, которых никто не закладывал (непреднамеренных). |
| Элемент модели (Model Element) | Элементарная единица, из которых состоит модель. |
| Библиотека элементов модели (Model Element Library) | Набор элементов, используемых как база для создания модели. Модель может использовать или не использовать библиотеки элементов. |
| Моделирование (Model Simulation) | Деятельность по отработке поведения модели с использованием симулятора модели. |
| Симулятор модели (Model Simulator) | Устройство, компьютерная программа или система, которая позволяет осуществить выполнение модели для демонстрации ее поведения в поддержку верификации или валидации. |
| Техника моделирования (Modeling Technique) | Комбинация языка моделирования и способов использования этого языка моделирования. Определяется уровнем абстракции информации, которую необходимо представить с помощью модели и выбранного средства моделирования. |
| Генерация отчетов (Report Generation) | Генерация документа из модели для определенного применения, часто генерация по шаблонам в стандартизированном формате. |
| Обратный инжиниринг (Reverse Engineering) | Создание модели по готовому исходному коду. |
| Модель спецификации (Specification Model) | Модель, представляющая требования высокого уровня, обеспечивающая абстрактное представление о функциях разрабатываемого ПО, производительности, интерфейсах или характеристиках безопасности. Не включает в себя такие детали как внутренняя структура данных, внутренние потоки данных или внутренние потоки управления. |
| Символизация (Symbology) | Графическое представления элементов модели. Некоторые средства моделирования позволяют настраивать внешний вид модели. |
| SysML | Язык системного моделирования, специализированный вариант UML для использования в системном моделировании. |
| UML | Unified Model Language, Унифицированный язык моделирования, который является самым распространённым языком моделирования ПО. UML содержит в себе элементы языка для определения структуры ПО, поведения, функциональности и взаимосвязей внутри ПО. |
Модель спецификации и проектная модель.
Важно помнить основные положения стандарта DO-178C, а именно, последовательность создания ПО: системные требования должны предшествовать требованиям высокого уровня (high level requirements (HLR’s), а требования высокого уровня должны предшествовать требованиям низкого уровня (low-level requirements (LLR’s) Необходимо избегать создания кода ПО непосредственно из требований высокого уровня. Моделирование позволяет выразить HLR’s и LLR’s непосредственно в модели. Ключевая особенность моделирования по стандарту DO-331 – это различие между моделью спецификации и проектной моделью, как показано на следующем рисунке:
Проектная модель и модель спецификации отличаются, так же как отличаются HLR’s и LLR’s. И также должна соблюдаться последовательность разработки: сначала – модель спецификации, потом проектная модель. Также как требования высокого и низкого уровня могут находится в одной спецификации требований, так и модель спецификации и проектная модель могут находится в одной модели. Но когда разрабатываются обе модели, модель спецификации должна разрабатываться раньше, чем начинается разработка проектной модели.
По правилам UML модель спецификации обычно использует диаграммы сценариев использования (user cases) для кластеризации требований, а затем – различные механизмы UNL (машины состояния, моделирование сценариев и моделирование активности) для уточнения и устранения неясностей в требованиях. Проектная модель определяет требования низкого уровня (LLR’s) для проверки уточненных требований и модели спецификации. Трассировка требований определяет связи между требованиями, моделью спецификации и проектной моделью.
Сам процесс моделирования не определяется стандартами DO-178C или DO-331, хотя эти стандарты определяют цели, которым должен соответствовать этот процесс, и доказательства, которые процесс моделирования должен предоставить. Общим процессом является «Harmony Process for Embedded Software» (можно посмотреть Real-Time Agility или Real-Time UML Workshop for Embedded Systems 2nd Edition, Bruce Powel Powel Douglass). Ниже приведены различные типы моделей.
Диаграмма пользовательских сценариев user case (использовано с разрешения Dr. Bruce Douglass, IBM)
Диаграмма классов (использовано с разрешения Dr. Bruce Douglass, IBM)
Пример диаграммы состояний (использовано с разрешения Dr. Bruce Douglass, IBM)
Модель Simulink (использовано c разрешения Mr Eric Dillaber, Simulink Certification Manager)
Подобно живописи, музыке и изысканной кухне, моделирование означает разные вещи для разных людей, и существует огромное множество способов применения моделирования. Для сокращения возможных вариантов применения моделирования DO-331описывает 5 различных способов моделирования и советует пользователям адаптировать для своих целей один из них. Следующая таблица демонстрирует 5 рекомендованных способов от MB1 до MB5.
Как и в большинстве случаев в жизни, нет единого, подходящего всем решения. Но если проанализировать откуда вы пришли, где находитесь и куда направляетесь, то предпочтительный выбор можно сделать вполне осознано.
Плюсы и минусы каждого способа:
MB1 — традиционный процесс разработки, с добавлением проектной модели:
+ Добавляет моделирование в процесс разработки ПО, возможна генерация кода.
- Разделение создания системы и создания ПО. Требования выского уровня (HLR) не зависят от модели.
MB2 – Традиционный процесс разработки с моделью спецификации и проектной моделью:
+ Использование моделирования для спецификаций и для проектирования, возможна генерация кода.
- Разделение проектирование системы и разработки ПО.
MB3 – Традиционный процесс с моделью спецификации:
+ Добавляет модель спецификации для требований высокого уровня (HLR)
- Нет генерации кода, возможны проблемы с обновлением модели при изменениях в коде.
MB4 – Требования высокого уровня к ПО сливаются с требованиями к системе. Разработчики ПО создают проектную модель:
+ Требования к системе включают требования к ПО высокого уровня. Возможна генерация кода.
- Не используется модель спецификаций и для сложных моделей возможен пропуск последовательных уточнений требований.
MB5 – Требования высокого уровня к ПО сливаются с требованиями к системе. Системные инженеры создают проектную модель:
+ Обеспечивают сильную системно-ориентированную разработку и контроль за требованиями высокого уровня (HLR), очень мало неоднозначностей, обеспечивает генерацию кода.
- Не используется модель спецификаций и возможен большой шаг между требованиями и кодом ПО.
Входные данные для моделирования. Верификация модели.
В некоторых областях программирования разработчик начинает с чистого листа или концепта и постепенно разрабатывает готовую модель ПО. Но в авиации работает парадигма «виновен, пока не доказано обратное»: инженерным работам не доверяют, пока они не будут квалифицированы или верифицированы. Поэтому давайте рассмотрим верификацию модели. Может ли модель быть верифицирована только путем ее проверки? Конечно нет. Верификация модели требует формального рассмотрения набора входных данных, как это показано ниже:
Какие из перечисленных выше типов исходных данных необходимы для проверки модели? Все перечисленные вместе и каждый из них в отдельности должны находиться под управлением конфигурации, т.е. иметь уникальный идентификатор, и могут быть в точности воспроизведены в любое время для каждой проверки модели в будущем. Заметим, что основное назначение модели – проверка требований, следовательно модель должна содержать требования (функциональности ПО), которые будут использованы для проверки корректности и полноты самой модели.
Верификация тестированием
В дополнение к проверке, которая оценивает соответствие модели требованиям стандартов моделирования и требованиям системы и управляющего ПО, модель сама по себе может быть верифицирована путем тестирования. Средства UML для тестирования определяют стандартные средства для создания спецификации сценариев тестирования, архитектуры тестирования и анализа. То же самое можно сделать «вручную», создавая тестовые элементы и используя средства моделирования/исполнения, чтобы убедится, что результат совпадает с ожиданием. Также можно использовать инструменты типа ад-дон Test Conductor для IBM Rhapsody’s для автоматизации этих шагов.
Формальные методы – это другой ключевой способ верификации моделей, особенно когда у вас есть набор моделей. Некоторые инженеры предпочитают верифицировать всю систему с помощью формальных методов, и это якобы позволяется стандартом DO-333 (добавление к стандарту DO-178C и DO-278A). Однако, «лучшие практики» предполагают вместо фокусирования на формальной верификации всей системы осуществлять верификацию отдельных алгоритмов или набора связанных алгоритмов с моделью для максимизации вероятности.
Моделирование. (Исполнение модели)
Другое преимущество моделирования – это симуляция. Симулятор модели может исполнять модель на ранних стадиях проектирования. Моделирование может быть использовано для верификации в следующих аспектах:
- Соответствие системным требованиями (Модель спецификации)
- Соответствие требованиям высокого уровня (Проектная модель)
- Точность и полнота
- Верифицируемость
- Алгоритмы работы
Однако моделирование не предназначено для верификации следующих аспектов:
- Совместимость с целевым вычислителем
- Соответствие стандартам
- Прослеживаемость
- Целостность частей
Модель и верификация кода.
UML Testing Profile (www.omg.org) предлагает стандартный подход для задания, исполнения и анализа тестовых сценариев в языке UML. Это означает, что все преимущества моделирования могут быть получены не только от модели спецификации и проектной модели, но и от средств верификации данных моделей.
Надстройка Test Conductor для IBM Rhapsody’s реализует этот стандарт и поставляются с квалификационным комплектом для DO-178. Этот инструмент автоматизирует генерацию, выполнение и анализ тестов, и может предоставить подробную статистику по покрытию модели и при объединении с инструментами верификации кода обеспечивает статистику покрытия кода.
Анализ покрытия модели и прослеживаемость .
Поскольку модели разрабатываются инженерами, а инженеры в процессе разработки могут пренебречь добавлением необходимых деталей модели или удалить ненужные части модели, необходимо выполнять анализ покрытия модели. Анализ покрытия модели позволяет определить, какие элементы модели не полностью верифицированы, а так же обнаружить не декларируемую функциональность в модели. Анализ покрытия модели может быть выполнен путем расчетного моделирования или формальными методами, хотя структурное покрытие ПО проверяется путем реального тестирования.
Прослеживаемость модели (трассировка) должна существовать также для доказательства того, что каждый элемент модели имеет основания для своего существования. Каждая часть модели должна быть связана с:
- Требованиями, которые предъявляются.
- Кодом, который ее реализует.
Конечно, отслеживаемость модели может быть выполнена вручную, но моделирующие инструменты имеют встроенные функции для поддержки и обеспечения прослеживаемости
Заключение
Моделирование – это мощное средство, которое все больше и больше применяется в авионике. Стандарт DО-331 предоставляет основу для понимания принципов моделирования, использования всей мощи технологий моделирования и описывает способы докозательствао корректности модели.