В основе разработки ПО авионики лежит основополагающий стандарт RTCADO-178B. Несмотря на первый взгляд на его отстранённость от непосредственной рутины программиста, он описывает весь процесс разработки и выдвигает требования к подобному ПО. Тем не менее, в данной статье речь пойдёт и о том, как всё происходит на самом деле, на основе личного опыта разработки систем контроля и управления полётом, систем посадки и пр. для самолётов и вертолётов.
Вступление
Современные решения для контроля и мониторинга систем управления самолётом (Flight Control System) – сложный программно-аппаратный комплекс, работу которого, пожалуй, в целом не знает ни один из сотрудников и разработчиков. Это сродни проектам разработки атомной бомбы времён второй мировой войны, где каждый хорошо знает часть своей работы, но не особо представляет, почему это работает вместе. Впрочем, авионика не единственный пример таких сложных систем, и сложность тех же Microsoft Excel или GNU GCC, конечно, порождает схожие проблемы, но, тем не менее, для ПО авиации существуют нюансы и типичные решения, на которых я постараюсь отдельно остановить своё внимание. Стоя перед проблемой эффективности управления процессом разработки, менеджмент, стараясь следовать оптимизации параметров затрат и качества проекта, порождает информационный и организационный дефицит. Это связано, в первую очередь, с высокой стоимостью специалистов иили их обучением в области авиационного ПО, т.е. с персоналом, т.к. зачастую в крупных проектах его численность может достигать порядка 2-3 тысяч человек на одну только систему управления (не говоря о динамической модели и физическом исполнении планера, а тем более всего изделия). Во вторую очередь — с организацией связи и подачей информации, её синхронизацией между участниками разработки, а так же ограничения на чрезмерно большие количества данных, проходящих через тот или иной уровень. Поэтому для разработки подобных систем утверждён особый, тщательно задокументированный и регламентированный технический процесс разработки требований, создания аппаратной и программной части, выполнения и отладки системы, а так же её тестирования и составления сертификационной документации. Тем не менее, процесс постоянно модифицируется и совершенствуется, исходя из реалий проекта и из картины окружающего мира.
Модель разработки
Для разработки критически важных систем необходимо обеспечить минимальную возможность ошибки (для самого высокого уровня в авионике установлена вероятность отказа 10^-9), а так же минимизировать расходы на разработку и исправления кода. Из-за сложности системы и взаимосвязи с другими частями (другим ПО, другой аппаратурой), модель водопада или гибкой разработки могут быть не лучшим вариантом, поэтому, основополагающим принципом разработки подобного ПО выбрана V-образная модель разработки.
Рис 1. V-образная модель разработки.
В первую очередь, такая модель позволяет обеспечить синхронизацию всех участников проекта на каждой итерации, а так же предоставляет возможность использовать уже наработанные данные и готовую методологию, т.к. на старте любого проекта V-образная модель (рис 1.) может быть адаптирована под этот проект, так как эта модель не зависит от типов организаций и проектов. V-model позволяет разбить деятельность на отдельные шаги, каждый из которых будет включать в себя необходимые для него действия, инструкции к ним, рекомендации и подробное объяснение деятельности. Это особенно важно для многоитерационного цикла разработки и тестирования ПО авионики, т.к. позволяет, фактически, разбить непосредственно разработку ПО на отдельные подциклы. Обычно V-model обобщается в спиральную модель разработки (рис 2). Которая, в свою очередь, уже позволяет оценить риски на каждом этапе разработки, а так же оптимально распределяет занятость специалистов (workload) в условиях дефицита сотрудников и времени на короткие промежутки времени (Iteration Packages, синхронизирующиеся с V-образной моделью в каждый Baseline).
Рис 2. Спиральная модель разработки-тестирования ПО
Проектирование и документация
Для контроля каждого этапа и для последующей возможности сертификации процесс разбит на различные уровни, каждому из которых соответствует свой документ, для которого создаётся в последствие документ, контролирующий его (отчёт). В итоге каждый этап разработки, все ошибки и исправления классифицируются и документируются. Повторяя каждый раз итерации разработки вероятность ошибки снижается. Данные документы так же создаются на основе внутренних стандартов компании и требований, предъявленных заказчиком.
Рис 3. Взаимосвязь документов и требований
Во главе всего стоит, естественно, заказчик, который зачастую не особо представляет, что ему надо, но вполне способен сказать, что он хочет, чтобы его самолёт летал, имел систему рулёжки и кондиционирования на все случаи жизни, а так же чтобы это система работала так, как он этого хочет, и ещё даже с бонусами. Поэтому первая часть – это анализ требований заказчика и определение базовой функциональности системы, на основе которой создаётся общая концепция и схема системы, включая технические подробности используемого оборудования, т.е. Создания первоначальных спецификаций системы (Equipment Specification) и требований (System Requirements).
Когда определена база на которой будет создаваться система, утверждается план, по которому будет проходить разработка ПО (Software Development Plan) и его сертификация (Qualification Plan — plan for Software Aspects of Certification). Несмотря на то, что главное для заказчика получить готовое ПО управления, параллельным процессом является разработка аппаратной части, которую в разработке ПО нельзя обойти стороной, т.к. разработка ПО авионики очень тесно связана с аппаратной частью; в большинстве своём ПО является хоть и переносимым и встраиваемым кодом, но сильно зависимым от компоновки систем, но об этом чуть позже.
Рис 4. V-образная модель, разбитая на этапы согласно уставным документам
Разработка
Концепция
Прежде, чем переходить дальше, стоит сказать, что в основе первоначального проектирования лежат основополагающие принципы, которые присутствуют во всем процессе разработки, и главный из них – это «различие» (dissimilarity), которое определяет то, что каждая часть из систем управления должна быть реализована разными группами людей на разной аппаратной начинке с использованием разных программных средств (в том числе средств разработки, языков программирования). Таким образом, система разделяется на программно- и аппаратно- независимые части, а процесс разработки контролируется разными группами людей для разных задач и на разных уровнях соответственно сообразно вышестоящим требованиям и плану.
Рис 5. Модель планера, для рассчитанных нагрузок и требований которого будут созданы требования к ПО.
Программно-аппаратная часть
Результатом первичного проектирования является модель системы, обычно выполненная в средах MatlabSimulink, Labview. На основе модели создаются документы, регламентирующие, какие аппаратные средства должны быть использованы и какие связи они должны иметь между собой. Как минимум результатом этого этапа является создание двух документов: определяющих аппаратную компоненту (hardware) и программно-аппаратную (hardware-software).
Далее начинается этап инженерного процесса подготовки, сборки плат и готовых модулей (Control Electronic и т.п.), т.е. непосредственно монтаж, разводка необходимых микроконтроллеров, микросхем, периферии, для которых будет написано необходимое ПО. Для взаимодействия с аппаратной частью должны существовать драйверы и слой взаимодействия (framework layer), на основе которых должно быть построено приложение (application). Тем не менее, зачастую работа программиста начинается уже здесь, когда необходимо дописать необходимые драйверыфункциональность, а чаще всего внести изменения во «всеобъемлющую библиотеку», на основе документа HSI (Hardware-Software Interface). Так, наиболее частой практикой является «урезание» функциональности системы до предела используемой аппаратуры и драйверов, а так же изменение некоторых калибровочных настроек, включая необычную распиновку или оптимизацию под выбранные параметры реального времени.
Рис 6. Организация ПО
Framework
Соответственно, универсальная библиотека Framework включает в себя всевозможные драйверы для устройств, сертифицированных для использования в авиации, а так же сертифицированных стандартных функций и процедур.
Это принципиальный момент, потому что самая обычная функция strcmp, допустим, не может быть использована напрямую, она должна быть переписана сообразно стандартам и пройти сертификацию. Набор таких сертифицированных стандартных функций, прототипов, шаблонов и есть Common в слое Framework. Особенно критично такое отношение к безопасным математическим операциям (быстрое дробное деление для целочисленных процессоров, модуль, корень, как пример), так и для работы с памятью. Все алгоритмы хоть и немного (как минимум стилем кода), но отличаются от STL.
Рис 7. Тестовый (not-for-flight) модуль электроники MACE, содержащий плату управления, контроля и тестирования (последний только для разработки и отладки).
Для использования на всевозможных устройствах в состав 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).
На основе первого документа разработчику устанавливается способ решения его задачи: какие технические средства он может использовать, какие и куда он должен заносить результаты, а так же чему он должен придерживаться. Если говорить совсем просто, то этот документ устанавливает инструментарий разработчика (язык программирования, среду разработки и отчётов).
На основе второго документа разработчику устанавливается стиль его кода и разрешённые приёмы. Например, использование венгерской нотации, арифметических операций, стилистике написания кода и его сложности.
Так же для работы разработчика, как я уже упоминал, могут потребоваться знания низкоуровневых требований (HSI, ICD (Interface Communication), Datasheets (документов, описывающих работу устройств, как правило от создателей устройств (на различные чипы)).
Рис 8. Модель «кабинета», включающая в себя различные модули электродистанционной системы управления (ЭДСУ) самолёта (спойлерами, рулями, элеваторами, элеронами).
Процесс
Непосредственно сам процесс разработки состоит из следующих этапов:
1. Design — дизайн (разработка дизайна в UML иили системе моделирования (используя такое ПО как Ameos, SCADE, Simulink и т.п.) —
2. Low-Level Requirements — Описание функциональности и алгоритма решения реализуемого требования для тестировщика (используя модель чёрного ящика: описание входа и ожидаемой реакции). Т.е. низкоуровневая спецификация.
3. Coding – процесс непосредственного написания кода (в чём угодно, если не используется автоматический кодогенератор, как в SCADEMatlab, т.к. среда разработки (IDE) может быть любым и под любую ОС (я использую Eclipse, CodeBlocks, хотя и другие решения не возбраняются).
4. Debugging — процесс отладки, а точнее процесс переработки и сборки до состояния отсутствия ошибок (отсутствия Errors, Warnings с установленными параметрами выбранного компилятора).
5. Static check – процесс проверки и исправления кода на основе анализаторов кода (xLite, Polyspace, MISRA, QAC).
6. Engineering tests — процесс запуска и интеграции ПО на симуляторе (т.е. на прототипе оборудования, финальный вариант которого в последствие будет установлен в полёт, с выведенными по возможности интерфейсами и инструментами манипуляции (обычно это связка Labview + Trace32 debugger)). В некоторых случаях функциональность симулятора расширяется путём установки дополнительных устройств (датчиков, цепей разрыва, генераторов сигнала и даже приборов управления и контроля, таких как ручка пилота и т.п.). В особо редких случаях для немногих систем управления это можно проделать на настоящей полномасштабной стендовой модели самолёта.
7. Внесение результатов в систему контроля версий и отчётов (IBM Rational ClearCaseClearQuest).
Рис 9. Стенд симулятора с оборудованием отладки электроники модуля управления шасси
Все эти семь пунктов составляют одну итерацию, как правило выполняющуюся только для своей части требований. Из-за изменения функционала или внесения исправленийпоправок в уже протестированный код необходимо составление Change Request'ов, на основе которых, как документа, будут внесены корректировки в существующую отчётную документацию или код, обычно это происходит в системе. По закрытии одного из Baseline, последующие изменения в код или документацию не вносятся, а лишь могут быть инициированы на основе Problem Report'ов. Такая сложность нужна, чтобы избежать несанкционированного и опасного изменения кода и документации, и стабилизировать код так, как есть до соответствующей активности. Само же изменение кода иили спецификации после разрешения на Change Request, где документируется, какие именно правки были внесены.
Спецификация
По завершении каждого из Baseline проводится формирование документа SDD (Software Description Document), в котором содержится информация о дизайне приложения, а так же низкоуровневых требований, предоставленных разработчиком тестировщику. Однако, прежде чем передать его тестировщикам, производится анализ и ревью (design review) этого документа на наличие ошибок и возможности тестирования на приведённых в документе требований (производится другим разработчиком, обычно отвечающим за другую часть функциональности). На этом работа разработчика заканчивается, и он переходит либо к следующему Baseline или, если проект закончен, к следующему проекту. При этом, естественно, разработчик вступает в качестве консультанта в связь с тестировщиком, оказывая ему необходимое содействие.
Тем не менее, необходимо упомянуть, что каждое из звеньев (системный инженер, программист, тестировщик) должно быть разделено во избежание возможного влияния и давления с их стороны. Но, конечно же, всегда есть спорные вопросы и нюансы, и иногда, несмотря на чёткость процесса, чтобы не загромождать техпроцесс итерациями из-за опечаток в комментариях (например), зачастую применяется модель agile-разработки, не затрагивающей главный функционал.
Тестирование
Работа же тестировщика — это почти половина, если не 23 всего времени разработки ПО. Это кропотливый и длительный труд, который включает в себя:
Низкоуровневое тестирование
которое состоит, в свою очередь, из:
- 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, чтобы тесты исходили не от кода, а шли от этапа проектирования архитектуры. В идеале составлять спецификации до написания кода.
Рис 10. Испытательные стенды электроники и сопутствующих систем
Высокоуровневое тестирование
- 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).
Рис 11. Испытания системы управления полётом (ЭДСУ Fly-by-Wire) в полёте на Sukhoi Superjet 100
Сертификация
На основе тестов составляется общий документ SVR (Software Verification Review), который на том или ином этапе разработки определяет состояние ошибок. На основе которого, в зависимости от их важности, составляется документ об окончании этапа (SAS, Software Accomplishment Summary). Этот документ определяет, необходим ли старт нового этапа разработкипереработки (включая переработку SWRD), либо разработка прекращается, и вся документация передаётся на сертификацию и заказчику. Этот документ является финальным для отдела технического контроля, работа которого проводится постоянно для каждого Baseline в фоне, обычно не имея сильного влияния на техпроцесс.
На этом моменте начинается аудит и проверка всего проекта, на основе которого создаются последние три документа:
- First Delivery Review (FDR) — документ о поставке пакета,
- First Flight Review (FFR) — отчёт о первом полёте,
- Software Certification Review (SCR) — решение сертификационной комиссии.
Естественно, если на одном из этих этапов возникнут проблемы, вполне возможна ситуация для инициации ещё одной (как минимум) переработки ПО. Как правило, такая сертификация из-за обилия документации (это порядка 100-200 тысяч страниц) проверяется исключительно выборочно на низком уровне, а на высоком по ответам заказчика, сертификационной комиссии и лётчиков-испытателей составляется требования на доработки. Как правило, количество этапов лётной проверки является 2-3, а сертификационной — 1-2.
Заключение
Что же касается гигантских объемов работ, время, отведённое на разработку относительно простой системы (система рулёжки и выпуска шасси) — 1,5-2 года, для систем управления поверхностями (электрическими актуаторами и гидросистемами) составляет 5-6 лет. Таким образом, в среднем система проходит от 2-3 больших итераций (baseline) до 18-20 для больших и сложных систем, и более 40 для слоя Framework.
Из-за чрезвычайной сложности и громоздкости систем отчёта и рутины тестирования для работы привлекаются ресурсы аутсорса в Индии, чуть реже — в Китае, восточной Европе. Вся сертификация, как правило, проходит на территории, где действителен сертификат (для EASA – Европа, для FAA — Америка), ну и для Российский стандартов — Россия. Оборудование сертифицируется отдельно, либо уже должно иметь свой сертификат, поэтому, к сожалению, или к счастью, в авиации используются относительно «устаревшие» модели и решения, проверенные в температурных, временных и агрессивных условиях эксплуатации. Несмотря на огромную сложность и востребованность, хороших специалистов не так уж и много, и даже в Америке и Европе — электронные системы управления — только начинающееся направление, которое, конечно, содержит хоть и небольшую, но порцию ошибок… впрочем, чтобы не пугать, о безопасности и отказоустойчивой архитектуре речь пойдёт в следующий раз.
Автор: wwakabobik
