САПР средств контроля и мониторинга систем управления самолётом

В основе разработки ПО авионики лежит основополагающий стандарт RTCA\DO-178B. На первый взгляд, несмотря на его отстранённость от непосредственной рутины программиста, он описывает весь процесс разработки и выдвигает требования к подобному ПО. Тем не менее, в данной статье речь пойдёт и о том, как всё происходит на самом деле, на основе личного опыта разработки систем контроля и управления полётом, систем посадки и пр. для самолётов и вертолётов.

Вступление

Модель разработки

Рис 1. V-образная модель разработки.

Рис 2. Спиральная модель разработки-тестирования ПО

Проектирование и документация

Рис 3. Взаимосвязь документов и требований

Когда определена база на которой будет создаваться система, утверждается план, по которому будет проходить разработка ПО (Software Development Plan) и его сертификация (Qualification Plan — plan for Software Aspects of Certification). Несмотря на то, что главное для заказчика получить готовое ПО управления, параллельным процессом является разработка аппаратной части, которую в разработке ПО нельзя обойти стороной, т.к. разработка ПО авионики очень тесно связана с аппаратной частью; в большинстве своём ПО является хоть и переносимым и встраиваемым кодом, но сильно зависимым от компоновки систем, но об этом чуть позже.

Рис 4. V-образная модель, разбитая на этапы согласно уставным документам

Разработка

Концепция

Программно-аппаратная часть

Далее начинается этап инженерного процесса подготовки, сборки плат и готовых модулей (Control Electronic и т.п.), т.е. непосредственно монтаж, разводка необходимых микроконтроллеров, микросхем, периферии, для которых будет написано необходимое ПО. Для взаимодействия с аппаратной частью должны существовать драйверы и слой взаимодействия (framework layer), на основе которых должно быть построено приложение (application). Тем не менее, зачастую работа программиста начинается уже здесь, когда необходимо дописать необходимые драйверы/функциональность, а чаще всего внести изменения во «всеобъемлющую библиотеку», на основе документа HSI (Hardware-Software Interface). Так, наиболее частой практикой является «урезание» функциональности системы до предела используемой аппаратуры и драйверов, а так же изменение некоторых калибровочных настроек, включая необычную распиновку или оптимизацию под выбранные параметры реального времени.

Рис 5. Организация ПО

Framework

Это принципиальный момент, потому что самая обычная функция strcmp, допустим, не может быть использована напрямую, она должна быть переписана сообразно стандартам и пройти сертификацию. Набор таких сертифицированных стандартных функций, прототипов, шаблонов и есть Common в слое Framework. Особенно критично такое отношение к безопасным математическим операциям (быстрое дробное деление для целочисленных процессоров, модуль, корень, как пример), так и для работы с памятью. Все алгоритмы хоть и немного (как минимум стилем кода), но отличаются от STL.

Рис 6. Архитектура тестового кластера, с возможностью использовать различные интерфейсы контроля и анализа*

Для использования на всевозможных устройствах в состав Framework входят наборы драйверов, имея структуру DrvHigh<->DrvLow. Здесь, в пакете DrvHigh содержатся всевозможные интерфейсы для драйверов устройств (Flash, Eeprom память, цифро-аналоговые, аналого-цифровые преобразователи, часы реального времени, прерывания, чипы CAN, ARINC, LAN и т.п.). В свою очередь, каждый из этих интерфейсов драйверов может использовать один или несколько драйверов под конкретное устройство (ту или иную микросхему памяти, конвертера и т.п.). В целях оптимизации подобные драйвера переконфигурирются или даже используются напрямую без уровня DrvHigh. Быть может, это не самое красивое решение, но в отличие от прикладных программ, работа со встроенными системами жесткого реального времени, где «640кб должно хватить всем» — не просто афоризм, а реалии. Для высоконагруженных и отказоустойчивых систем реалиями являются как пиковые загрузки микросхем, 90-100% загруженность шин передачи данных, синхронизация каналов, устройств и планирование загрузки фрейма в зависимости от входных параметров (frame scheduling) с контролем ошибок (в т.ч. разноуровневым мониторингом с подтверждением статичных и осцилляционных ошибок), так и укладывание всего ПО и объектов данных в объемы порядка 64-128кбайт.

Программирование

Требования

Но вернёмся к циклу разработки ПО. Как только установлена и сконфигурирована аппаратная часть, создаётся документ требований к ПО (Software Requirement Document), который описывает то, что должно ПО делать, а так же как это делать. Это тот документ, на основе которого должно быть разработано ПО (application). Тут и начинается, собственно, работа программиста вкупе с работой тестировщика. Итак, другими словами, программист ПО авионики не видит полной картины того, для чего он создаёт программу на самом деле, но оперирует необходимыми требованиями и архитектурой, которую он должен создать на основе требований. Требованиями для программиста являются следующие документы:

• Software Design Standard — стандарт, определяющий общий стиль приложения и подход к созданию архитектуры.
• Programming Standard — стандарт программирования, определяющий, что разрешено писать в коде и каким стилем.
• Software Requirements Document — требования к ПО, задокументированные и разделённые на различные Baseline и iteration package внутри них (high-level specificaction).

На основе первого документа разработчику устанавливается способ решения его задачи: какие технические средства он может использовать, какие и куда он должен заносить результаты, а так же каких правил (rules) и советов (guidelines) он должен придерживаться. Если говорить совсем просто, то этот документ устанавливает инструментарий разработчика (язык программирования, среду разработки и отчётов).

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

Так же для работы разработчика, как я уже упоминал, могут потребоваться знания низкоуровневых требований (HSI, ICD (Interface Communication), Datasheets (документов, описывающих работу устройств, как правило от создателей устройств (на различные чипы)).

Процесс

Непосредственно сам процесс разработки состоит из следующих этапов:

1. Design — дизайн (разработка дизайна в UML и/или системе моделирования (используя такое ПО как Ameos, SCADE, Simulink и т.п.) —
2. Low-Level Requirements — Описание функциональности и алгоритма решения реализуемого требования для тестировщика (используя модель чёрного ящика: описание входа и ожидаемой реакции). Т.е. низкоуровневая спецификация.
3. Coding — процесс непосредственного написания кода (в чём угодно, если не используется автоматический кодогенератор, как в SCADE/Matlab, т.к. среда разработки (IDE) может быть любой и может быть испльзована под любой ОС (я использую Eclipse, CodeBlocks, хотя и другие решения не возбраняются).
4. Debugging — процесс отладки, а точнее процесс переработки и сборки до состояния отсутствия ошибок (отсутствия Errors, Warnings с установленными параметрами выбранного компилятора).
5. Static check — процесс проверки и исправления кода на основе анализаторов кода (xLite, Polyspace, MISRA, QAC).
6. Engineering tests — процесс запуска и интеграции ПО на симуляторе (т.е. на прототипе оборудования, финальный вариант которого в последствие будет установлен в полёт, с выведенными по возможности интерфейсами и инструментами манипуляции (обычно это связка Labview + Trace32 debugger)). В некоторых случаях функциональность симулятора расширяется путём установки дополнительных устройств (датчиков, цепей разрыва, генераторов сигнала и даже приборов управления и контроля, таких как ручка пилота и т.п.). В особо редких случаях для немногих систем управления это можно проделать на настоящей полномасштабной стендовой модели самолёта.
7. Внесение результатов в систему контроля версий и отчётов (IBM Rational ClearCase/ClearQuest).

Рис 7. «Электронная птица» Sukhoi SuperJet 100*

Все эти семь пунктов составляют одну итерацию, как правило выполняющуюся только для своей части требований. Из-за изменения функционала или внесения исправлений/поправок в уже протестированный код необходимо составление Change Request’ов, на основе которых, как документа, будут внесены корректировки в существующую отчётную документацию или код, обычно это происходит в системе. По закрытии одного из Baseline, последующие изменения в код или документацию не вносятся, а лишь могут быть инициированы на основе Problem Report’ов. Такая сложность нужна, чтобы избежать несанкционированного и опасного изменения кода и документации, и стабилизировать код так, как есть до соответствующей активности. Само же изменение кода и/или спецификации после разрешения на Change Request, где документируется, какие именно правки были внесены.

Спецификация

По завершении каждого из Baseline проводится формирование документа SDD (Software Description Document), в котором содержится информация о дизайне приложения, а так же низкоуровневых требований, предоставленных разработчиком тестировщику. Однако, прежде чем передать его тестировщикам, производится анализ и ревью (design review) этого документа на наличие ошибок и возможности тестирования на приведённых в документе требований (производится другим разработчиком, обычно отвечающим за другую часть функциональности). На этом работа разработчика заканчивается, и он переходит либо к следующему Baseline или, если проект закончен, к следующему проекту. При этом, естественно, разработчик вступает в качестве консультанта в связь с тестировщиком, оказывая ему необходимое содействие.

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

Тестирование

Работа же тестировщика — это почти половина, если не 2/3 всего времени разработки ПО. Это кропотливый и длительный труд, который включает в себя:

Низкоуровневое тестирование

которое состоит, в свою очередь, из:

• Code review — ревью исходного кода на предмет соответствия стандарту программирования, а так же на предмет соответствия кода и требований (SDD).
• Low-Level Testing — низкоуровневое тестирование, такое, как unit-testing и unit-integration-testing (Razorcat Tessy + эмуляторы среды и процессоров), т.е. тестирование на основе требований непосредственно кода, используя метрику Маккейба и Modified Condition/Decision Coverage (используя стандарт NASA MCDC). Так же тут проверяются все граничные значения, а так же реакция системы на выход из допустимых условий (реакция на недопустимые математические операции, на операции с памятью, указателями, выход за пределы диапазона и пр. (robustness testing)).
• Создания документа отчётности (Software Verification Cases and Procedures / Software Unit and Integration Verification Cases and Procedures).
• VoV (Verification of Verification) — процесс проверки проверки, на которой проверяется правильность выполнения тестов а так же созданного документа, с занесением результатов в QAR (Quality Assurance Record), которое в последствии будет использоваться на следующей итерации для исправления возникших ошибок (выполняется другим тестировщиком). Естественно, все ошибки фиксируются помимо QAR и в багтрекинговой системе, чтобы по Iteration можно было найти и исправить проблему.

В последующих итерациях процесс может быть минимизирован до delta-тестирования и delta-ревью, т.е. Тестирования только изменившихся частей программы/документа или исправления предыдущих ошибок тестирования. Это должно экономить время, однако, зачастую, как показывает практика, ошибки присутствуют и до конца всего процесса разработки, поэтому нередко тестировщики тестируют систему полностью каждый раз на основе готовых тестов. Это можно рассматривать как регрессионное тестирование, за исключением высоких временных затрат и зачастую повышенного процента изменений в коде/тестах. Здесь, подчеркну, что это происходит из-за того, что тесты создаются на основе системы, а не параллельно с ней. Как можно догадаться, из-за такого подхода, главные проблемы ложатся на плечи программистов, которые должны выдать превосходный баланс из архитектуры, кода и низкоуровневой спецификации. Параллельная же разработка почти невозможна из-за необходимости иметь возможность проследить ошибку вплоть до функции и переменной, вызывающей сбой. Не только в тестах, но и на уровне требований. Хотя, это выглядит как тяжелый минус, от такой модели постепенно стараются перейти к более гибким моделям, и сделать процесс black-box, чтобы тесты исходили не от кода, а шли от этапа проектирования архитектуры. В идеале составлять спецификации до написания кода.

Рис 8. Испытательные стенды электроники и сопутствующих систем*

Высокоуровневое тестирование

• Document review (SWRD review) — ревью документа на предмет наличия ошибок и тестируемости с точки зрения требований и спецификации к системе, а так же Hardware-Software соответствий (ICD, HSI).
• Hardware-Software testing — процесс создания и запуска высокоуровневых тестов на симуляторе, которые могут быть автоматическими (скриптовыми), ручными (скриптовыми, с необходимостью где-то что-то аппаратно переключить, померить мультиметром или осциллографом), Unit-тестами (в случае, когда нельзя проверить на симуляторе, изымается тест/тесты из низкоуровневых). Такое тестирование очень близко к Engineering тестам, которые проводит разработчик, за исключением того, что их результаты заносятся в файл отчёта (Hardware/Software Integration Verification Cases and Procedures), а весь процесс, как правило, автоматизирован.
• HwSw VoV — процесс проверки проверки, на которой проверяется правильность выполнения тестов а так же созданного документа, с занесением результатов в QAR (Quality Assurance Record), которое в последствии будет использоваться на следующей итерации для исправления возникших ошибок (выполняется другим тестировщиком).

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

Между каждым этапом, естественно, формируется «пакет поставки», включающий в себя как спецификацию использованного оборудования, версии всех устройств и документов, так и само ПО и сопутствующие документы. Этим занимаются специализированные менеджеры (package manager), а координацией и отслеживанием состояния различных групп занимаются координаторы (coordinator manager). Сами же этапы разработки и тестирования регламентируются внутренними планами (roadmap), которые так же являются отчётным документом для менеджеров (actual status).

Сертификация

На этом моменте начинается аудит и проверка всего проекта, на основе которого создаются последние три документа:

• First Delivery Review (FDR) — документ о поставке пакета,
• First Flight Review (FFR) — отчёт о первом полёте,
• Software Certification Review (SCR) — решение сертификационной комиссии.

Естественно, если на одном из этих этапов возникнут проблемы, вполне возможна ситуация для инициации ещё одной (как минимум) переработки ПО. Как правило, такая сертификация из-за обилия документации (это порядка 100-200 тысяч страниц) проверяется исключительно выборочно на низком уровне, а на высоком по ответам заказчика, сертификационной комиссии и лётчиков-испытателей составляется требования на доработки. Как правило, количество этапов лётной проверки равно двум-трём, а сертификационной — 1-2.

Заключение

Что же касается гигантских объемов работ, время, отведённое на разработку относительно простой системы (система рулёжки и выпуска шасси) — 1,5-2 года, для систем управления поверхностями (электрическими актуаторами и гидросистемами) составляет 5-6 лет. Таким образом, в среднем система проходит от 2-3 больших итераций (baseline) до 18-20 для больших и сложных систем, и более 40 для слоя Framework.

Из-за чрезвычайной сложности и громоздкости систем отчёта и рутины тестирования для работы привлекаются ресурсы аутсорса в Индии, чуть реже — в Китае, восточной Европе. Вся сертификация, как правило, проходит на территории, где действителен сертификат (для EASA — Европа, для FAA — Америка), ну и для Российский стандартов — Россия. Оборудование сертифицируется отдельно, либо уже должно иметь свой сертификат, поэтому, к сожалению, или к счастью, в авиации используются относительно «устаревшие» модели и решения, проверенные в температурных, временных и агрессивных условиях эксплуатации. Несмотря на огромную сложность и востребованность, хороших специалистов не так уж и много, и даже в Америке и Европе — электронные системы управления — только начинающееся направление, которое, конечно, содержит хоть и небольшую, но порцию ошибок... впрочем, чтобы не пугать, о безопасности и отказоустойчивой архитектуре речь пойдёт в следующий раз.

* Тестовая система подготовлена в сотрудничестве с Cosateq.