Как выглядит процесс обеспечения качества программного обеспечения для NASA SLS?

Я получил через запрос FOIA «Программу системы космического запуска (SLSP), приложение для полетов, план обеспечения программного обеспечения (SAP)». Это основной документ, описывающий процессы разработки программного обеспечения для бортового компьютера (часть, отвечающая за предварительный запуск, запуск и подъем корабля SLS на стартовой площадке) и прикладного программного обеспечения Green Run (программное обеспечение для наземных испытаний управляющего оборудования). а также 13 других утилит.

В нем изложено все, от стандартов программного обеспечения, практики и соглашений для усилий по разработке программного обеспечения до информации о средстве разработки программного обеспечения (SDF).

Программное обеспечение полета для SLS определяется как программное обеспечение класса А, что означает, что оно разработано в соответствии с самыми высокими стандартами и проходит тщательную проверку и проверку.

Применимые стандарты (стр. 12-13, раздел 2.0):

• SLS-PLAN-180 Программа космических запусков (SLS) План управления рисками и возможностями
• SLS-RQMT-014 Требования к системе космического запуска (SLS) для обеспечения безопасности и обеспечения полета (SMA)
• NASA-STD-8739.8 Стандарт гарантии программного обеспечения NASA
• NPR 7150.2B Требования к разработке программного обеспечения НАСА
• IEEE 730-2002 [PDF] Стандарт IEEE для планов обеспечения качества программного обеспечения
• Стандарт безопасности программного обеспечения NASA-STD-8719.13
• И большое количество документов НАСА, которых нет в Интернете, таких как требования, административные стандарты, процессы, процедуры и т. д.

Инструменты, используемые в процессах Software Assurance (стр. 37, раздел 9.1):

Вы можете найти полный pdf здесь

Хорошей отправной точкой являются требования к разработке программного обеспечения НАСА NPR 7150.2B.

3.6 Software Assurance и Software IV&V 3.6.1 Менеджер проекта должен планировать и внедрять Software Assurance в соответствии с NASA-STD-8739.8. [SWE-022] Примечание. Действия по обеспечению качества программного обеспечения выполняются на протяжении всего жизненного цикла проекта. Некоторые из фактических анализов и действий могут быть выполнены в рамках проектирования или проекта. 3.6.2 Для проектов, достигших ключевой точки принятия решения (KDP) A после даты вступления в силу редакции настоящей директивы, руководитель программы должен обеспечить выполнение IV&V программного обеспечения для следующих категорий проектов: [SWE-141]

а. Проекты категории 1, как определено в NPR 7120.5.

б. Проекты категории 2, как определено в NPR 7120.5, которые имеют классификацию риска полезной нагрузки класса A или класса B в соответствии с NPR NPR 7150.2B - Глава 3.

в. Проекты, специально отобранные NASA CSMA для программного обеспечения IV&V.

...

3.6.3 Если для проекта выполняется IV&V программного обеспечения, менеджер проекта должен обеспечить разработку Плана выполнения проекта IV&V (IPEP). [SWE-131] Примечание. Объем услуг IV&V определяется проектом и поставщиком услуг IV&V и документируется в IPEP. IPEP разрабатывается провайдером IV&V и служит рабочим документом, который будет передан проекту, получающему поддержку IV&V. В соответствии с обязанностями, определенными в NPD 7120.4, раздел 5.J.(5), проекты гарантируют, что поставщики программного обеспечения разрешат доступ к программному обеспечению и связанным с ним артефактам для реализации IV&V. Шаблон и инструкции для IPEP можно найти в Системе управления НАСА IV&V, доступной по адресу http://www.nasa.gov/centers/ivv/ims/home/index.html .

3.7.1 Когда определено, что проект имеет критическое для безопасности программное обеспечение, руководитель проекта должен выполнить требования NASA-STD-8719.13. [SWE-023]

SLS попадет в класс A (человеческий рейтинг).

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

Фундаментальные парадигмы проектирования, повлиявшие на разработку архитектуры, следующие:
1. Использование простых, проверенных, проверенных алгоритмов и процессов. Основываясь на более чем пятидесятилетнем опыте успешной разработки НАСА средств управления полетом для больших ускорителей, сохраняется использование классического ПИД-управления, смешивания гироскопа скорости на нескольких станциях, линейных фильтров оптимального изгиба и планирования усиления.
2. Расширьте возможности алгоритма, если это возможно, с помощью компактных и проверяемых методов. Использование оптимального реконфигурируемого распределения линейного управления было использовано для максимального увеличения полномочий управления и повышения отказоустойчивости, а также была применена новая механизация классической разгрузки. Кроме того, повышение устойчивости достигается за счет использования схемы адаптивного управления простой эталонной модели.
3. Максимальная устойчивость к сбоям. В качестве программного требования архитектура поддерживает допуск хотя бы одного отказа двигателя в любой точке режима полета с незначительным влиянием на характеристики управления полетом. Стойкость к отказам датчиков и серьезным нестандартным условиям была продемонстрирована с помощью тщательного анализа моделирования.
4. Полная интеграция с программой SLS для облегчения сертификации полетов. В поддержку краткой передачи проектного запаса от элемента управления полетом новые показатели, такие как показатель технических характеристик управления полетом (TPM), используются для облегчения прямой оценки достоинств конструкции и возможностей транспортного средства на системном инженерном уровне.

Эта презентация дает общий обзор процесса разработки.