Проектируем беспилотник рыбака в 3SL Cradle. Часть 1.

Технологическое начало и постановка задачи

Мадорская Ю.М., Тимофеев А.Н.

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

kvadro

Беспилотники рождают новые возможности и могут зародить новые проблемы — как всегда в ногу идут обе стороны прогресса. Как создать будущее, не создав новых проблем — вот задача каждого системного аналитика и инженера, задача, которую требуется решать на каждом уровне проектирования.

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

Однако беспилотники мы еще не проектировали и тем интереснее.

Этот проект создается для учебных целей, а именно для демонстрации:

  • Принципов применения моделе-ориентированной системной инженерии (MBSE) при разработке требований.
  • Принципов и возможностей трассировки требований.
  • Возможностей 3SL Cradle как профессионального инструмента для системной инженерии.

Данная серия статей познакомит вас с процессом проектирования — от технологической подготовки проекта, до генерации итоговых проектных документов.

Проектирование будет выполняться сначала «вширь», т.е. мы постараемся определить все горизонтальные требования верхнего уровня, верхнеуровневую структуру системы и оттрассировать требования к ее компонентам, а затем выберем какой-то один компонент для более детального проектирования — проектирования «вглубь».  Эта идея проиллюстрирована на рисунке 1.

design

Рисунок 1. Выбранный подход к детализации проектирования — сначала «вширь», потом «вглубь».

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

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

lodki

Рисунок 2. Романтическое рыболовное место.

Кроме вас в лодке есть еще и дети, которым довольно сложно «сидеть смирно» более 15 минут. Чем занять маленьких компьютерных гениев? Разведкой! Водной разведкой. Настроив и запустив беспилотник, они смогут подсказать вам, где будет действительно «клёво». Такая команда непобедима! Представили? Тогда вперед к созданию этого любопытного мира!

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

Модель трассировки требований

Команда уже собрана, роли расписаны, теперь нам необходимо выбрать технологию работы и настроить наш инструмент — 3SL Cradle. Конечно, мы могли взять одну из наших полностью готовых схем настройки, но технологическая подготовка — сама по себе очень интересная тема для системных аналитиков и поэтому мы воспользуемся лишь отработанной концепцией управления требованиями, а все настройки будем выполнять по ходу проекта.

Основное для нас — это модель трассировки требований. Модель трассировки определяет, какие виды проектных данных будут использоваться в проекте и как они связаны. Необходимо ли вести связи требований с кодом и тестами? На какие вопросы о проектных данных необходимо быстро отвечать? Например, все ли требования покрыты тестами? Для всех ли функций определены их характеристики и обрабатываемые данные?

Все эти технологические вопросы должны быть решены в начале проекта и отражены в модели трассировки.

Для Cradle  модель трассировки — это фактически схема базы данных, которая настраивается перед проектом или просто копируется из уже настроенного проекта.

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

Основываясь на принципах ESGRAIN мы «нарисовали» вот такую модель трассировки требований:

traceability_model

Рисунок 3. Часть модели трассировки проекта по проектированию рыболовного беспилотника.

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

Сама диаграмма разработана и сохранена прямо в том проекте  Cradle, который будет использоваться для проектирования. Это удобно — хранить все в одном месте. Также в проекте мы ввели дополнительный тип элементов NOTES (он не отражен в модели), чтобы писать заметки о ходе проекта.

traceability_model_in_Cradle

Рисунок 4. Удобное хранение модели трассировки в проекте 3SL Cradle, для которого она разрабатывалась.

Более подробное описание аналогичной модели трассировки можно найти в книге «Базовый курс по 3SL Cradle».

Какие особые требования к модели трассировки учитывались в данном проекте?

Если мы вдруг захотим сертифицировать наш беспилотник, то, как минимум, программное обеспечение бортовой аппаратуры должно удовлетворять квалификационным требованиям 178B межгосударственного авиационного комитета (это аналог международного стандарта DO-178B), а также стандарту ГОСТ Р 51499-2002. В соответствии с этими документами необходимо подтвердить трассируемость требований разного уровня, например, системных требований и требований к программному обеспечению. Без этого сертификацию не пройти. Поэтому организации, занимающиеся проектированием и разработкой бортовой аппаратуры, не могут обойтись без профессионального инструментария — вести трассировку вручную очень затратно как по времени, так и по ошибкам.

Требования к модели трассировки для данного стандарта проиллюстрированы на рисунке 5 (ревизия 178С) [1]:

DO-178C_Traceability

Рисунок 5. Требования к трассировке требований по DO-178C

На первый взгляд набор артефактов этой модели сильно отличается от того, что есть в нашей модели. Однако это не так. На самом деле, большая часть элементов может быть сопоставлена одному или нескольким элементам нашей модели.  Например, System Requirements отражаются с помощью УСЛОВИЙ, ЗАДАЧ, ФУНКЦИЙ и МОДЕЛЕЙ. Т.е. наша модель более детализирована чем модель, предложенная для КТ178, а значит мы сможем получить необходимые для сертификации представления.

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

Настройка модели трассировки в Cradle

По разработанной схеме трассировки настроить Cradle можно очень быстро — необходимо создать типы элементов, типы связей и определить правила связей.

Как вы видели на предыдущей иллюстрации из Cradle (Рисунок 4), все созданные типы элементов появляются на панели «База данных». В данной статье мы не будем подробно останавливаться на технических подробностях настройки Cradle, вы можете почерпнуть этот материал из книги или на сайте Центра компетенций по 3SL Cradle.

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

Дополнительные настройки

В проекте был настроен основной пользователь от которого будет проводиться проектирование — АНАЛИТИК.

Базовый пользователь, который всегда есть в проекте —  это MANAGER — пользователь с максимальными правами. Под ним лучше не работать, а использовать только для администрирования проекта.

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

start_page1

Рисунок 6. Первая настройка стартовой страницы для системного аналитика в 3SL Cradle.

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

Постановка задачи

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

Любое проектирование автоматизированной системы, а беспилотник это она и есть, начинается с постановки задачи. Необходимо определить назначение системы и цели ее создания.

По нашей модели трассировки назначение и цели относятся к типу артефактов УСЛОВИЯ, там мы их и создали:

goals

Рисунок 7. Зафиксированные в 3SL Cradle назначение и цели создания системы.

В другом представлении можно посмотреть их сразу с текстом:

goals-text

Рисунок 7.1. Полное представление целей системы.

Также был создан один элемент типа КОМПОНЕНТ, соответствующей системе в целом:

main-component

Рисунок 8. Верхнеуровневый элемент системы — соответствует системе в целом.

В наименовании компонента отражено краткое название системы, а в описании, в поле TEXT — полное:

main-component-text

Рисунок 9. Описание элемента системы в Cradle.

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

Цели — это базовый «фильтр» проекта. Именно они будут определять, какие требования учитывать, а какие нет, в каком направлении продолжать проектирование, какие решения искать. Поэтому их надо постоянно держать в фокусе, чтобы не сбиться с курса. Для этого мы настроили hid-диаграмму, которая показала проставленные по ходу дела связи с главным элементом системы и вывела в удобной форме не только наименования элементов, но и их содержание. Чтобы эта диаграмма была перед глазами, мы открыли ее в отдельной рабочей панели.
Вы можете нажать на картинку ниже, чтобы увеличить ее и познакомиться с назначением и целями создания системы:

goals-cradle-view

Рисунок 10. Иерархическая диаграмма назначения и целей создания системы.

Поскольку мы не проектируем беспилотники каждый день, то в голове у нас нет готового набора требований, поэтому для старта мы решили воспользоваться типовым набором требований МЧС [2].

Для этого была выполнена загрузка документа с требованиями МЧС в Cradle (в тип ИСХОДНЫЕ ТРЕБОВАНИЯ) и настроено представление, которое отражает требования и их статус. После загрузки требований в Cradle мы можем установить статус каждому отдельному требованию — то, что не позволял сделать Word.

С помощью статусов УЧИТЫВАТЬ/НЕ УЧИТЫВАТЬ теперь мы проводим отсев требований. Это выглядит вот так:

reusable_reqs

Рисунок 11. Представление для анализа применимости типовых требований.

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

change_status

Рисунок 12. Изменение статуса исходного требования прямо в аналитическом представлении.

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

Работать с «цветными» требованиями очень удобно, не так быстро устаешь и быстрее ориентируешься в большом объеме текста.

Мы уже успели провести пару часов, анализируя и обсуждая применимость каждого требования, но нам предстоит большая работа, ведь при загрузке Cradle показал, что документ МЧС содержит 292 требования.

Чтобы было повеселей и мы могли отслеживать состояние этой работы, была настроена метрика и над ней панель индикаторов (KPI), которая показывает, сколько требований уже отмечено как применимые:

first_kpi

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

Эта метрика рассчитывается на основании статусов обрабатываемых исходных требований. 9,2% — мы в начале пути!

На этом пока все, если вы хотите поучаствовать — присоединяйтесь к группам журнала «Практика проектирования систем» linkedin и facebook. И подпишитесь на Еженедельник, чтобы узнать, когда выйдет следующая статья из этой серии.

Уже опубликовано Продолжение. Часть 2.!

Литература

1. Статья в википедия «DO-178B» по стандарту Software Considerations in Airborne Systems and Equipment Certification// https://en.wikipedia.org/wiki/DO-178B

2. Временные единые технические требования к робототехническим комплексам, беспилотным летательным аппаратам и прикладному программному обеспечению, приобретаемым за счет субъектов Российской Федерации
http://www.mchs.gov.ru/upload/site1/document_file/FVCQ8zUL4f.pdf

Хотите сослаться на эту статью? Используйте правильную ссылку:

Мадорская Ю.М., Тимофеев А.Н., Проектируем беспилотник рыбака в 3SL Cradle. Часть 1. //Практика проектирования систем.-2015. [электронный ресурс] — Режим доступа: http://reqcenter.pro/bpla-design-1/, свободный. — Загл. с экрана