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

Нормативная база - контроль полноты системных требований

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

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

Исходный документ с требованиями был загружен в Cradle, Cradle его распарсил и показал, что необходимо проанализировать 292 требования. Мы начали их изучать, раскрашивая обработанные требования с помощью статусов УЧИТЫВАТЬ/НЕ УЧИТЫВАТЬ, и эта задача пока в процессе выполнения.

Для оценки полноты собираемых/разрабатываемых требований можно воспользоваться нормативной базой — стандартами, которые определяют классы требований верхнего уровня (классы системных требований). Чтобы правильно подобрать стандарты, надо сначала определиться с классом проектируемой системы.

Класс системы

За это время мы успели дать название нашей системе и теперь ее зовут «Цапля». Давайте разберемся, к какому классу она относится, а для этого познакомимся с ее структурой.

Уже понятно, что Цапля будет состоять как минимум  из трёх компонентов: беспилотного летательного аппарата, устройства дистанционного управления и того, кто этим будет управлять — «пилота».

Международная организация гражданской авиации (ICAO) классифицирует такие системы как дистанционно пилотируемые [1]:

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

Состав такой дистанционно пилотируемой авиационной системы показан на рисунке 1:

dps

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

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

Если опуститься на следующий уровень детализации, то типовая структура систем аналогичных Цапле выглядит так, как показано на рисунке 2.

conceptual_schema

Рисунок 2. Обобщенная структурная схема дистанционно пилотируемой системы.

При этом бортовая система размещается на планере и обычно обеспечивает:

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

Станция представляет собой автоматизированное рабочее место внешнего пилота. Обычно она обеспечивает:

  • дистанционное пилотирование воздушным судном;
  • управление функциями полезной нагрузки в режиме реального времени;
  • работу с полётными заданиями и картами;
  • ведение записи полёта;
  • взаимодействие со службами управления воздушным движением (СУВД) по каналам связи
  • и многие другие функции реального пилота.

Функции и полномочия внешнего пилота согласно положениям ICAO почти не отличаются от функций и полномочий командира пилотируемого воздушного судна находящегося на его борту [1].

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

Наличие в системе человека — пилота и комплекса средств автоматизации его деятельности, которые совместно реализуют«информационную технологию выполнения установленных функций» и обеспечивают работу дистанционно пилотируемого воздушного судна, позволяют отнести Цаплю к классу автоматизированных систем [2].

Существуют два варианта проектирования таких систем. В первом случае в качестве исходных условий задана конкретная конструкция планера и начинка его бортовой аппаратуры. Далее в эту конструкцию «встраивается» автоматизированная система и конструкция накладывает ограничения на АС.

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

Мы будем проектировать систему по второму варианту — от системных требований к конструкции.

Нормативная база

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

Итак, мы определили, что проектируемая нами система относится к классу автоматизированных систем (АС). В свою очередь АС — это продукт, а в военной терминологии — изделие. Эта классификация отражена на рисунке 3. На этом рисунке также показаны стандарты, так или иначе задающие классы системных требований, которые должны быть разработаны при проектировании системы.

class_of_the_system

Рисунок 3. Класс проектируемой системы и стандарты, определяющие классы требований верхнего уровня

Разработку продукции и постановку её на производство обычно выполняют на основе технических заданий. Для продукции гражданского применения разработка ТЗ регламентируется ГОСТ Р 15.201-2000 [10], который, однако, не детализирует классы системных требований, определяя их на слишком общем уровне, не достаточном для контроля полноты требований. В отличие от него его военный собрат ГОСТ РВ 15.201-2003 [11] содержит детализированную классификацию требований к изделию. Но Цапля не является продуктом военного применения, поэтому мы будем использовать гражданские стандарты.

При создании автоматизированных систем разработка ТЗ регламентируется ГОСТ 34.602-89 «Разработка технического задания на создание автоматизированной системы», в котором, также как и ГОСТ РВ 15.201-2003, есть детализированная классификация системных требований. Это нам и нужно для оценки полноты требований к системе на верхнем уровне.

Заметим, что ГОСТ 34.602-89 применяется при разработке любых видов автоматизированных систем — не только гражданского, но и военного назначения, о чем говорят, например, положения ГОСТ Р 51189-98 [9]. Вообще автоматизированные системы исторически сформировались  в 50-х годах прошлого века в недрах оборонных ведомств и впервые проявили себя в качестве автоматизированных систем управления полётами ракет, автоматизированных систем управления подводными лодками и надводными кораблями. Возможно поэтому классификации требований в ГОСТ РВ 15.201-2003 и  ГОСТ 34.602-89 практически совпадают.

Таким образом, ГОСТ 34.602-89 определяет классы системных требований верхнего уровня. Когда требования этих классов определены, на их основании должны быть разработаны требования следующего уровня — требования к техническому обеспечению и программного обеспечению Цапли [2]. ТЗ на эти части автоматизированной системы разрабатывается в соответствии с ГОСТ 15.201 и ГОСТ 19.201, что отражено на рисунке 4.

tz_structure

Рисунок 4. Иерархия технических заданий

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

Помимо ГОСТ 34.602-89 для разработки ТЗ на АС нам понадобятся следующие стандарты из этой серии:

  • ГОСТ 34.601-90 Автоматизированные системы. Стадии создания.
  • ГОСТ 34.602-89 Информационная технология. Техническое задание на создание автоматизированной системы
  • ГОСТ 34.603-92 Информационная технология. Виды испытаний автоматизированных систем.
  • РД 50-34.698-90 Методические указания. Информационная технология. Автоматизированные системы. Требования к содержанию документов.
  • РД 50-680-88 Методические указания. Автоматизированные системы. Основные положения.

Также будем учитывать то, что на АС «Цапля» распространяются действия нормативных документов Межгосударственного авиационного комитета, в частности, квалификационные требования КТ-178В к программному обеспечению бортовой аппаратуры  [12-14].

Необходимость использования иных стандартов, регламентирующих создание АС «Цапля», будет определяться в ходе разработки требований и проектирования .

Контроль полноты системных требований  в 3SL Cradle

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

В этот раз мы воспользуемся своей стандартной заготовкой — файлом экспорта Cradle, который содержит все разделы ГОСТ 34.602 и который мы используем из проекта в проект.export_file

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

search_replace

Рисунок 5. Файл экспорта Cradle — замена типа элементов.

Примечание: изменить тип данных DOC SECTION на СЕКЦИЯ в файле экспорта можно просто с помощью поиска/замены текста, то есть это задача 10 секунд.

 

 

 

 

Итак, схема проекта дополнена: — создан новый тип данных DOC SECTION, для него определены правила связей и в него импортированы разделы ГОСТ 34.602. На панели базы данных Cradle это выглядит следующим образом:

tz_sections

Рисунок 6. Структура разделов ТЗ по ГОСТ 34 в Cradle.

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

Чтобы иметь под рукой оценку — насколько мы продвинулись в этом процессе, была настроена метрика, которая показывает сколько элементов типа DOC SECTION, определяющих классы требований, оттрассировано к другим элементам.

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

polnota

Рисунок 7. Панель KPI с новым показателем «Полнота требований по ГОСТ 34.602″.

Действительно, к моменту настройки этой метрики мы определили только цели создания системы и ее назначение. Впрочем, это такие же системные требования. Поэтому после того, как эти назначение и цели были связаны с соответствующими секциями ТЗ (рисунок 8), наш KPI «Неполнота» стал показывать чуть более дружественные цифры (рисунок 9).

linked_goals

Рисунок 8. Разделы ТЗ с заполненными назначением и целями создания системы.

kpi

Рисунок 9. Панель KPI с показателем «Полнота требований по ГОСТ 34.602″ после подсоединения целей и назначения

Теперь у нас есть еще один ориентир, который мы будем использовать при разработке требований.

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

Литература

  • Циркуляр 328 ИКАО, «Беспилотные авиационные системы (БАС)», 2011 г.
  • ГОСТ 34.003-90 Информационная технология. Автоматизированные системы. Термины и определения.
  • ГОСТ 34.201-89 Информационная технология. Виды, комплектность и обозначения документов при создании автоматизированных систем.
  • ГОСТ 34.601-90 Автоматизированные системы. Стадии создания.
  • ГОСТ 34.602-89 Информационная технология. Техническое задание на создание автоматизированной системы.
  • ГОСТ 34.603-92 Информационная технология. Виды испытаний автоматизированных систем.
  • РД 50-34.698-90 Методические указания. Информационная технология. Автоматизированные системы. Требования к содержанию документов.
  • РД 50-680-88 Методические указания. Автоматизированные системы. Основные положения.
  • ГОСТ Р 51189-98 Программные средства систем вооружения. Порядок разработки.
  • ГОСТ Р 15.201-2000/ Система разработки и постановки продукции на производство. Продукция производственно-технического назначения. Порядок разработки и постановки продукции на производство.
  • ГОСТ РВ 15.201-2003. Система разработки и постановки продукции на производство. Военная техника. Тактико-техническое (техническое) задание на выполнение опытно-конструкторских работ.
  • Межгосударственный Авиационный Комитет. Авиационный Регистр. Квалификационные требования часть 178В «Требования к программному обеспечению бортовой аппаратуры и систем при сертификации авиационной техники».
  • Руководство Р-4754 по сертификации сложных бортовых систем воздушных судов гражданской авиации.
  • Руководство Р-4761 по методам оценки безопасности систем и бортового оборудования воздушных судов гражданской авиации.

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

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