Как 3SL Cradle обеспечивает поддержку процессов разработки по ARP-4754 (Р-4754) и ARP-4761 (Р-4761)

Краткая характеристика ARP 4754 и 4761

Стандарт ARP 4754 (аналогичный отечественный стандарт — Р-4754) определяет рекомендации по процессу разработки гражданских самолетов и их систем.

Его взаимосвязь с другими стандартами, регламентирующими процессы создания авиационных систем, отражены на следующем рисунке 1:

standard_schema

Рисунок 1. Стандарты покрывающие процессы создания и эксплуатации авиационных систем.

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

arp4754_process

Рисунок 2. Жизненный цикл разработки самолета или его систем в соответствии с ARP 4754A.

С точки зрения описания проектируемой системы в ARP 4754 используются следующие ключевые категории:

  • Концепция
  • Требование
  • Функция
  • Интерфейс
  • Архитектура
  • Реализация
  • Верификация
  • Валидация
  • Отказ
  • Риск
  • Задача

Они же являются основными элементами учета и управления.

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

  • Требования к безопасности
  • Функциональные требования
  • Требования заказчика
  • Операционные требования
  • Требования к производительности
  • Требования к физическим компонентам и установке
  • Требования к сопровождаемости
  • Требования к интерфейсам
  • Дополнительные сертификационные требования
  • Производные требования.

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

Соответственно процесс проектирования организован вокруг этих категорий — от разработки концепции до тестирования и модификационного сопровождения системы.

Поддержка ARP 4754 и 4761 в Cradle

I. Поддержка модели данных, заложенной в ARP 4754 и 4761

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

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

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

II. Поддержка процессов ARP 4754 и 4761 функциями 3SL Cradle

Все функции Cradle можно условно разделить на несколько классов:

  1. Фиксация проектных данных и связей между ними. Например, разработка требований, функций, архитектуры, тестов. Распределение требований и (аллокация) функций по компонентам архитектуры.
  2. Использование проектных данных и связей для анализа и валидации проекта.
  3. Вспомогательные функции, такие как конфигурационное управление, загрузка исходных требований, публикация документов и др..

В рамках каждого процесса по ARP 4754 и 4761 используются все три класса функций 3SL Cradle.

Рассмотрим на примере взаимосвязанных процессов Разработка функций (Aircraft Function Development) и Распределение функций по системам (allocation of Aircsraft Functions to Systems):

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

functions

Как видно на этом рисунке функции могут быть структурированы любым удобным способом. При этом количество уровней вложенности не ограничено.

Для удобства работы тоже самое дерево может быть выведено в режиме иерархического документа с возможностью сразу же отредактировать данные:

functions2

При необходимости возможно задать значения атрибутов функций, открыв диалог редактирования элемента:

funciton_edit

или прямо в дополненном документном представлении:

function_status

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

2. Аналогично создается структура компонентов проектируемой системы

sbs_structure

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

sbs_hid

Ее легко опубликовать в PowerPoint, воспользовавшись контекстным меню, и пойти с готовыми слайдами на презентацию или переслать для согласования тем, у кого Cradle не подключен (например, сторонним организациям).

Таким образом, в соответствии с двумя выбранными процессами ARP 4754 было разработано (на каком-то витке проектирования) два типа проектных данных: ФУНКЦИИ и КОМПОНЕНТЫ (архитектура).

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

diagrams

4. После того, как определены функции и системы, в соответствии с ARP 4754 необходимо провести распределение функций по подсистемам (functional allocation), т.е. определить какие подсистемы какие функции будут выполнять.

В терминах Cradle это означает создать связи между этими данными. Связи создаются очень легко — перетаскиванием или с помощью горячих клавиш. (Опытные пользователи чаще применяют горячие клавиши, что обеспечивает высокую скорость работы):

create_links

В процессе создания связей возможно видеть трассировку и контроллировать правильность создания связей в любом направлении, как от функций к подсистемам, так и от подсистем к функциям:

trace1

5. Теперь можно применить дополнительные представления проектных данных для контроля корректности и полноты распределения функций по подсистемам, например, вложенные таблицы:

trace2

иерархические диаграммы:

trace3

матрицы трассировки:

traceability_matrix

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

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

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

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

Заключение

3SL Cradle полностью поддерживает работу по стандартам ARP-4754 (Р-4754) и ARP-4761 (Р-4761)  как по структуре модели данных, так и по задачам управления проектными данными и предоставляет уникальные аналитические возможности для того, чтобы повысить качество и скорость верификации проектных решений на всех уровнях проектирования.

3SL Cradle имеет функции, позволяющие полностью поддержать процессы системной инженерии, определенные в ARP-4754 и ARP-4761, а именно позволяет:

  1. Фиксировать все типы проектных данных (требования, риски, отказы, функции и любые другие) и связей между ними (например, functional allocation) в разных режимах работы в формализованных форматах, настроенных индивидуально под каждую проектную роль.
  2. Использовать зафиксированные проектные данные, их формат и связи для валидации требований и проектных решений с помощью запросов и аналитических представлений по любым срезам.
  3. Разрабатывать модели в распространенных нотациях, например, блок-схемы алгоритмов, архитектурные и др. – полная поддержка MBSE с обеспечением сквозной трассируемости системных требований к спецификациям моделей.
  4. Управлять конфигурацией требований и проектных решений. Система конфигурационного управления включает возможность управления версиями каждого отдельного элемента данных (например, требования, модели), базовые линии, возможность использования формального механизма проведения изменений – запросы и задачи на изменение, средства отслеживания влияния изменений и др.
  5. Поддерживать двустороннуюю интеграцию с документо-ориентированное технологией – загрузка и публикация документов с сохранением всех связей на уровне каждого отдельного требования. Поддерживается возможность управления версиями публикуемых документов.
  6. Обеспечивать интеграцию с инструментами всего жизненного цикла для обеспечения сквозной трассируемости требований и валидации проектных решений на всех уровнях проектирования.
  7. Обеспечивать коллективную работу над проектом за счет гибкой системы распределения прав доступа с возможностью поддержки иерархических организационных структур, модели компетенций и классификаций секретности.
  8. Обеспечивать контроль хода проекта и валидацию проектных решений применяя метрики и панели KPI.
  9. Настраивать пользовательский интерфейс для каждой роли, что позволяет повысить продуктивность работы каждого специалиста.

 

Примечания

(1) — Может быть импортирована из готового проекта.

(2) — Cradle поддерживает любую схему данных — выбор категорий управления и типов связей между ними осуществляется проектной организацией.

 

Добавить комментарий