|
|
|||||||||||||||||||||||||||||
|
САПР средств контроля и мониторинга систем управления самолётомИсточник: isicad Илья Верещагин
В основе разработки ПО авионики лежит основополагающий стандарт RTCA\DO-178B. На первый взгляд, несмотря на его отстранённость от непосредственной рутины программиста, он описывает весь процесс разработки и выдвигает требования к подобному ПО. Тем не менее, в данной статье речь пойдёт и о том, как всё происходит на самом деле, на основе личного опыта разработки систем контроля и управления полётом, систем посадки и пр. для самолётов и вертолётов. ВступлениеСовременные решения для контроля и мониторинга систем управления самолётом (Flight Control System) - сложный программно-аппаратный комплекс, работу которого, пожалуй, в целом не знает ни один из сотрудников и разработчиков. Это сродни проектам разработки атомной бомбы времён второй мировой войны, где каждый хорошо знает часть своей работы, но не особо представляет, почему это работает вместе. Впрочем, авионика не единственный пример таких сложных систем, и сложность тех же Microsoft Excel или GNU GCC, конечно, порождает схожие проблемы, но, тем не менее, для ПО авиации существуют нюансы и типичные решения, на которых я постараюсь отдельно остановить своё внимание. Стоя перед проблемой эффективности управления процессом разработки, менеджмент, стараясь следовать оптимизации параметров затрат и качества проекта, порождает информационный и организационный дефицит. Это связано, в первую очередь, с высокой стоимостью специалистов и/или их обучением в области авиационного ПО, т.е. с персоналом, т.к. зачастую в крупных проектах его численность может достигать порядка Модель разработкиДля разработки критически важных систем необходимо обеспечить минимальную возможность ошибки (для самого высокого уровня в авионике установлена вероятность отказа 10^-9), а так же минимизировать расходы на разработку и исправления кода. Из-за сложности системы и взаимосвязи с другими частями (другим ПО, другой аппаратурой), модель водопада или гибкой разработки может быть не лучшим вариантом, поэтому, основополагающим принципом разработки подобного ПО выбрана Рис 1. В первую очередь, такая модель позволяет обеспечить синхронизацию всех участников проекта на каждой итерации, а так же предоставляет возможность использовать уже наработанные данные и готовую методологию, т.к. на старте любого проекта Рис 2. Спиральная модель разработки-тестирования ПО Проектирование и документацияДля контроля каждого этапа и для последующей возможности сертификации процесс разбит на различные уровни, каждому из которых соответствует свой документ, для которого создаётся в последствие документ, контролирующий его (отчёт). В итоге каждый этап разработки, все ошибки и исправления классифицируются и документируются. Повторяя каждый раз итерации разработки вероятность ошибки снижается. Данные документы так же создаются на основе внутренних стандартов компании и требований, предъявленных заказчиком. Рис 3. Взаимосвязь документов и требований Во главе всего стоит, естественно, заказчик, который зачастую не особо представляет, что ему надо, но вполне способен сказать, что он хочет, чтобы его самолёт летал, имел систему рулёжки и кондиционирования на все случаи жизни, а так же чтобы это система работала так, как он этого хочет, и ещё даже с бонусами. Поэтому первая часть - это анализ требований заказчика и определение базовой функциональности системы, на основе которой создаётся общая концепция и схема системы, включая технические подробности используемого оборудования, т.е. создания первоначальных спецификаций системы (Equipment Specification) и требований (System Requirements). Когда определена база на которой будет создаваться система, утверждается план, по которому будет проходить разработка ПО (Software Development Plan) и его сертификация (Qualification Plan - plan for Software Aspects of Certification). Несмотря на то, что главное для заказчика получить готовое ПО управления, параллельным процессом является разработка аппаратной части, которую в разработке ПО нельзя обойти стороной, т.к. разработка ПО авионики очень тесно связана с аппаратной частью; в большинстве своём ПО является хоть и переносимым и встраиваемым кодом, но сильно зависимым от компоновки систем, но об этом чуть позже. Рис 4. РазработкаКонцепцияПрежде, чем переходить дальше, стоит сказать, что в основе первоначального проектирования лежат основополагающие принципы, которые присутствуют во всем процессе разработки, и главный из них - это "различие" (dissimilarity), которое определяет то, что каждая часть из систем управления должна быть реализована разными группами людей на разной аппаратной начинке с использованием разных программных средств (в том числе средств разработки, языков программирования). Таким образом, система разделяется на программно- и аппаратно- независимые части, а процесс разработки контролируется разными группами людей для разных задач и на разных уровнях соответственно сообразно вышестоящим требованиям и плану. Программно-аппаратная частьРезультатом первичного проектирования является модель системы, обычно выполненная в средах Matlab/Simulink, Labview. На основе модели создаются документы, регламентирующие, какие аппаратные средства должны быть использованы и какие связи они должны иметь между собой. Как минимум результатом этого этапа является создание двух документов: определяющих аппаратную компоненту (hardware) и программно-аппаратную (hardware-software). Далее начинается этап инженерного процесса подготовки, сборки плат и готовых модулей (Control Electronic и т.п.), т.е. непосредственно монтаж, разводка необходимых микроконтроллеров, микросхем, периферии, для которых будет написано необходимое ПО. Для взаимодействия с аппаратной частью должны существовать драйверы и слой взаимодействия (framework layer), на основе которых должно быть построено приложение (application). Тем не менее, зачастую работа программиста начинается уже здесь, когда необходимо дописать необходимые драйверы/функциональность, а чаще всего внести изменения во "всеобъемлющую библиотеку", на основе документа HSI (Hardware-Software Interface). Так, наиболее частой практикой является "урезание" функциональности системы до предела используемой аппаратуры и драйверов, а так же изменение некоторых калибровочных настроек, включая необычную распиновку или оптимизацию под выбранные параметры реального времени. Рис 5. Организация ПО FrameworkСоответственно, универсальная библиотека Framework включает в себя всевозможные драйверы для устройств, сертифицированных для использования в авиации, а так же сертифицированных стандартных функций и процедур. Это принципиальный момент, потому что самая обычная функция strcmp, допустим, не может быть использована напрямую, она должна быть переписана сообразно стандартам и пройти сертификацию. Набор таких сертифицированных стандартных функций, прототипов, шаблонов и есть Common в слое Framework. Особенно критично такое отношение к безопасным математическим операциям (быстрое дробное деление для целочисленных процессоров, модуль, корень, как пример), так и для работы с памятью. Все алгоритмы хоть и немного (как минимум стилем кода), но отличаются от STL. Рис 6. Архитектура тестового кластера, с возможностью использовать различные интерфейсы контроля и анализа* Для использования на всевозможных устройствах в состав Framework входят наборы драйверов, имея структуру DrvHigh<->DrvLow. Здесь, в пакете DrvHigh содержатся всевозможные интерфейсы для драйверов устройств (Flash, Eeprom память, цифро-аналоговые, аналого-цифровые преобразователи, часы реального времени, прерывания, чипы CAN, ARINC, LAN и т.п.). В свою очередь, каждый из этих интерфейсов драйверов может использовать один или несколько драйверов под конкретное устройство (ту или иную микросхему памяти, конвертера и т.п.). В целях оптимизации подобные драйвера переконфигурирются или даже используются напрямую без уровня DrvHigh. Быть может, это не самое красивое решение, но в отличие от прикладных программ, работа со встроенными системами жесткого реального времени, где "640кб должно хватить всем" - не просто афоризм, а реалии. Для высоконагруженных и отказоустойчивых систем реалиями являются как пиковые загрузки микросхем, ПрограммированиеТребованияНо вернёмся к циклу разработки ПО. Как только установлена и сконфигурирована аппаратная часть, создаётся документ требований к ПО (Software Requirement Document), который описывает то, что должно ПО делать, а так же как это делать. Это тот документ, на основе которого должно быть разработано ПО (application). Тут и начинается, собственно, работа программиста вкупе с работой тестировщика. Итак, другими словами, программист ПО авионики не видит полной картины того, для чего он создаёт программу на самом деле, но оперирует необходимыми требованиями и архитектурой, которую он должен создать на основе требований. Требованиями для программиста являются следующие документы:
На основе первого документа разработчику устанавливается способ решения его задачи: какие технические средства он может использовать, какие и куда он должен заносить результаты, а так же каких правил (rules) и советов (guidelines) он должен придерживаться. Если говорить совсем просто, то этот документ устанавливает инструментарий разработчика (язык программирования, среду разработки и отчётов). На основе второго документа разработчику устанавливается стиль его кода и разрешённые приёмы. Например, использование венгерской нотации, арифметических операций, стилистики написания кода и его сложности. Так же для работы разработчика, как я уже упоминал, могут потребоваться знания низкоуровневых требований (HSI, ICD (Interface Communication), Datasheets (документов, описывающих работу устройств, как правило от создателей устройств (на различные чипы)). ПроцессНепосредственно сам процесс разработки состоит из следующих этапов:
Рис 7. "Электронная птица" Sukhoi SuperJet 100* Все эти семь пунктов составляют одну итерацию, как правило выполняющуюся только для своей части требований. Из-за изменения функционала или внесения исправлений/поправок в уже протестированный код необходимо составление Change Request"ов, на основе которых, как документа, будут внесены корректировки в существующую отчётную документацию или код, обычно это происходит в системе. По закрытии одного из Baseline, последующие изменения в код или документацию не вносятся, а лишь могут быть инициированы на основе Problem Report"ов. Такая сложность нужна, чтобы избежать несанкционированного и опасного изменения кода и документации, и стабилизировать код так, как есть до соответствующей активности. Само же изменение кода и/или спецификации после разрешения на Change Request, где документируется, какие именно правки были внесены. СпецификацияПо завершении каждого из Baseline проводится формирование документа SDD (Software Description Document), в котором содержится информация о дизайне приложения, а так же низкоуровневых требований, предоставленных разработчиком тестировщику. Однако, прежде чем передать его тестировщикам, производится анализ и ревью (design review) этого документа на наличие ошибок и возможности тестирования на приведённых в документе требований (производится другим разработчиком, обычно отвечающим за другую часть функциональности). На этом работа разработчика заканчивается, и он переходит либо к следующему Baseline или, если проект закончен, к следующему проекту. При этом, естественно, разработчик вступает в качестве консультанта в связь с тестировщиком, оказывая ему необходимое содействие. Тем не менее, необходимо упомянуть, что каждое из звеньев (системный инженер, программист, тестировщик) должно быть разделено во избежание возможного влияния и давления с их стороны. Но, конечно же, всегда есть спорные вопросы и нюансы, и иногда, несмотря на чёткость процесса, чтобы не загромождать техпроцесс итерациями из-за опечаток в комментариях (например), зачастую применяется модель agile-разработки, не затрагивающей главный функционал. ТестированиеРабота же тестировщика - это почти половина, если не 2/3 всего времени разработки ПО. Это кропотливый и длительный труд, который включает в себя: Низкоуровневое тестированиекоторое состоит, в свою очередь, из:
В последующих итерациях процесс может быть минимизирован до delta-тестирования и delta-ревью, т.е. Тестирования только изменившихся частей программы/документа или исправления предыдущих ошибок тестирования. Это должно экономить время, однако, зачастую, как показывает практика, ошибки присутствуют и до конца всего процесса разработки, поэтому нередко тестировщики тестируют систему полностью каждый раз на основе готовых тестов. Это можно рассматривать как регрессионное тестирование, за исключением высоких временных затрат и зачастую повышенного процента изменений в коде/тестах. Здесь, подчеркну, что это происходит из-за того, что тесты создаются на основе системы, а не параллельно с ней. Как можно догадаться, из-за такого подхода, главные проблемы ложатся на плечи программистов, которые должны выдать превосходный баланс из архитектуры, кода и низкоуровневой спецификации. Параллельная же разработка почти невозможна из-за необходимости иметь возможность проследить ошибку вплоть до функции и переменной, вызывающей сбой. Не только в тестах, но и на уровне требований. Хотя, это выглядит как тяжелый минус, от такой модели постепенно стараются перейти к более гибким моделям, и сделать процесс black-box, чтобы тесты исходили не от кода, а шли от этапа проектирования архитектуры. В идеале составлять спецификации до написания кода. Рис 8. Испытательные стенды электроники и сопутствующих систем* Высокоуровневое тестирование
Чуть реже, на заключающих этапах разработки встречается чисто аппаратное тестирование, которое подразумевает собой тестирование на реальном оборудовании с составлением акта. Обычно это происходит на стендовых испытаниях собранной модели самолёта, а в последствие в полёте на реальном самолёте. Между каждым этапом, естественно, формируется "пакет поставки", включающий в себя как спецификацию использованного оборудования, версии всех устройств и документов, так и само ПО и сопутствующие документы. Этим занимаются специализированные менеджеры (package manager), а координацией и отслеживанием состояния различных групп занимаются координаторы (coordinator manager). Сами же этапы разработки и тестирования регламентируются внутренними планами (roadmap), которые так же являются отчётным документом для менеджеров (actual status). СертификацияНа основе тестов составляется общий документ SVR (Software Verification Review), который на том или ином этапе разработки определяет состояние ошибок. На основе которого, в зависимости от их важности, составляется документ об окончании этапа (SAS, Software Accomplishment Summary). Этот документ определяет, необходим ли старт нового этапа разработки/переработки (включая переработку SWRD), либо разработка прекращается, и вся документация передаётся на сертификацию и заказчику. Этот документ является финальным для отдела технического контроля, работа которого проводится постоянно для каждого Baseline в фоне, обычно не имея сильного влияния на техпроцесс. На этом моменте начинается аудит и проверка всего проекта, на основе которого создаются последние три документа:
Естественно, если на одном из этих этапов возникнут проблемы, вполне возможна ситуация для инициации ещё одной (как минимум) переработки ПО. Как правило, такая сертификация из-за обилия документации (это порядка ЗаключениеЧто же касается гигантских объемов работ, время, отведённое на разработку относительно простой системы (система рулёжки и выпуска шасси) - Из-за чрезвычайной сложности и громоздкости систем отчёта и рутины тестирования для работы привлекаются ресурсы аутсорса в Индии, чуть реже - в Китае, восточной Европе. Вся сертификация, как правило, проходит на территории, где действителен сертификат (для EASA - Европа, для FAA - Америка), ну и для Российский стандартов - Россия. Оборудование сертифицируется отдельно, либо уже должно иметь свой сертификат, поэтому, к сожалению, или к счастью, в авиации используются относительно "устаревшие" модели и решения, проверенные в температурных, временных и агрессивных условиях эксплуатации. Несмотря на огромную сложность и востребованность, хороших специалистов не так уж и много, и даже в Америке и Европе - электронные системы управления - только начинающееся направление, которое, конечно, содержит хоть и небольшую, но порцию ошибок... впрочем, чтобы не пугать, о безопасности и отказоустойчивой архитектуре речь пойдёт в следующий раз. Ссылки по теме
|
|