Пользователь
0,0
рейтинг
28 мая 2012 в 13:03

Разработка → Разработка ПО авионики из песочницы

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

image

Вступление


Современные решения для контроля и мониторинга систем управления самолётом (Flight Control System) – сложный программно-аппаратный комплекс, работу которого, пожалуй, в целом не знает ни один из сотрудников и разработчиков. Это сродни проектам разработки атомной бомбы времён второй мировой войны, где каждый хорошо знает часть своей работы, но не особо представляет, почему это работает вместе. Впрочем, авионика не единственный пример таких сложных систем, и сложность тех же Microsoft Excel или GNU GCC, конечно, порождает схожие проблемы, но, тем не менее, для ПО авиации существуют нюансы и типичные решения, на которых я постараюсь отдельно остановить своё внимание. Стоя перед проблемой эффективности управления процессом разработки, менеджмент, стараясь следовать оптимизации параметров затрат и качества проекта, порождает информационный и организационный дефицит. Это связано, в первую очередь, с высокой стоимостью специалистов и\или их обучением в области авиационного ПО, т.е. с персоналом, т.к. зачастую в крупных проектах его численность может достигать порядка 2-3 тысяч человек на одну только систему управления (не говоря о динамической модели и физическом исполнении планера, а тем более всего изделия). Во вторую очередь — с организацией связи и подачей информации, её синхронизацией между участниками разработки, а так же ограничения на чрезмерно большие количества данных, проходящих через тот или иной уровень. Поэтому для разработки подобных систем утверждён особый, тщательно задокументированный и регламентированный технический процесс разработки требований, создания аппаратной и программной части, выполнения и отладки системы, а так же её тестирования и составления сертификационной документации. Тем не менее, процесс постоянно модифицируется и совершенствуется, исходя из реалий проекта и из картины окружающего мира.

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


Для разработки критически важных систем необходимо обеспечить минимальную возможность ошибки (для самого высокого уровня в авионике установлена вероятность отказа 10^-9), а так же минимизировать расходы на разработку и исправления кода. Из-за сложности системы и взаимосвязи с другими частями (другим ПО, другой аппаратурой), модель водопада или гибкой разработки могут быть не лучшим вариантом, поэтому, основополагающим принципом разработки подобного ПО выбрана V-образная модель разработки.

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

В первую очередь, такая модель позволяет обеспечить синхронизацию всех участников проекта на каждой итерации, а так же предоставляет возможность использовать уже наработанные данные и готовую методологию, т.к. на старте любого проекта V-образная модель (рис 1.) может быть адаптирована под этот проект, так как эта модель не зависит от типов организаций и проектов. V-model позволяет разбить деятельность на отдельные шаги, каждый из которых будет включать в себя необходимые для него действия, инструкции к ним, рекомендации и подробное объяснение деятельности. Это особенно важно для многоитерационного цикла разработки и тестирования ПО авионики, т.к. позволяет, фактически, разбить непосредственно разработку ПО на отдельные подциклы. Обычно V-model обобщается в спиральную модель разработки (рис 2). Которая, в свою очередь, уже позволяет оценить риски на каждом этапе разработки, а так же оптимально распределяет занятость специалистов (workload) в условиях дефицита сотрудников и времени на короткие промежутки времени (Iteration Packages, синхронизирующиеся с V-образной моделью в каждый Baseline).

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

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


Для контроля каждого этапа и для последующей возможности сертификации процесс разбит на различные уровни, каждому из которых соответствует свой документ, для которого создаётся в последствие документ, контролирующий его (отчёт). В итоге каждый этап разработки, все ошибки и исправления классифицируются и документируются. Повторяя каждый раз итерации разработки вероятность ошибки снижается. Данные документы так же создаются на основе внутренних стандартов компании и требований, предъявленных заказчиком.

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

Во главе всего стоит, естественно, заказчик, который зачастую не особо представляет, что ему надо, но вполне способен сказать, что он хочет, чтобы его самолёт летал, имел систему рулёжки и кондиционирования на все случаи жизни, а так же чтобы это система работала так, как он этого хочет, и ещё даже с бонусами. Поэтому первая часть – это анализ требований заказчика и определение базовой функциональности системы, на основе которой создаётся общая концепция и схема системы, включая технические подробности используемого оборудования, т.е. Создания первоначальных спецификаций системы (Equipment Specification) и требований (System Requirements).

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

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

Разработка


Концепция

Прежде, чем переходить дальше, стоит сказать, что в основе первоначального проектирования лежат основополагающие принципы, которые присутствуют во всем процессе разработки, и главный из них – это «различие» (dissimilarity), которое определяет то, что каждая часть из систем управления должна быть реализована разными группами людей на разной аппаратной начинке с использованием разных программных средств (в том числе средств разработки, языков программирования). Таким образом, система разделяется на программно- и аппаратно- независимые части, а процесс разработки контролируется разными группами людей для разных задач и на разных уровнях соответственно сообразно вышестоящим требованиям и плану.

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

Результатом первичного проектирования является модель системы, обычно выполненная в средах Matlab\Simulink, Labview. На основе модели создаются документы, регламентирующие, какие аппаратные средства должны быть использованы и какие связи они должны иметь между собой. Как минимум результатом этого этапа является создание двух документов: определяющих аппаратную компоненту (hardware) и программно-аппаратную (hardware-software).

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

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

Framework

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

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

image
Рис 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).

image
Рис 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, чтобы тесты исходили не от кода, а шли от этапа проектирования архитектуры. В идеале составлять спецификации до написания кода.

image
Рис 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).

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


На основе тестов составляется общий документ SVR (Software Verification Review), который на том или ином этапе разработки определяет состояние ошибок. На основе которого, в зависимости от их важности, составляется документ об окончании этапа (SAS, Software Accomplishment Summary). Этот документ определяет, необходим ли старт нового этапа разработки\переработки (включая переработку SWRD), либо разработка прекращается, и вся документация передаётся на сертификацию и заказчику. Этот документ является финальным для отдела технического контроля, работа которого проводится постоянно для каждого Baseline в фоне, обычно не имея сильного влияния на техпроцесс.

На этом моменте начинается аудит и проверка всего проекта, на основе которого создаются последние три документа:
  • 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.
Верещагин Илья @wwakabobik
карма
138,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (96)

  • +11
    "… привлекаются ресурсы аутсорса в Индии..." О Боже!!! Я больше не полечу!
    • –11
      Ждемс когда похолодает, океан замерзнет, бум пешком ходить через океан.
    • –14
      Пытаются экономить, а потом сотни невинных жертв.
      • +11
        У Вас есть статистика о проценте авиакатастроф по причине ошибки автоматики/управляющего ПО?

        У меня было впечатление, что за счёт огромного консерватизма и процедур разработки/тестирования, а также дублирования систем, гражданская авиация является очень надёжной.
        • 0
          Наверное вы имели ввиду технику гражданской авиации?
          • 0
            Так точно.
    • +3
      На самом деле не зависит от расовой принадлежности разработчика. Там идиотов не держат. Более того что пишут эти люди — проходит строжайший контроль.
      • +1
        Там идиотизм несколько на другом уровне и не зависит от принадлежности: процесс разработки авиационного ПО настолько бюрократизирован, что зачастую заставить даже очень сильного разработчика его выполнять — задача не из легких.
        • +4
          Вы правы. Индусы действительно работают плохо. Но большей частью из-за того, что так всех устраивает. Ими удобно заткнуть дырку, в которой надо произвести, допустим, 100.000 страниц текста, состоящего из логов тестов. И не особо важно, что эти тесты будут очень плохими. Если высокоуровневые тесты будут хорошими (а так обычно оно и есть), то никто в работе индусов разбираться не будет.

          Быть может это звучит плохо и не идеально, а какие-то ошибки будут пропущены, но это хороший вариант решить проблемы перегруженной системы в целом. Потому как для инициации изменения на поздних этапах одного typo или добавления лишней функции нужно менять неимоверно много готовых результатов. Механизм защищает систему от изменений и возможно новых ошибок, и заставляет учитывать максимально возможное количество нюансов на этапе проектирования. Это уменьшит и риски и стоимость продукта, избавляя его от бесконечных переработок.

          В этом есть и плюсы, и минусы. Но такова реальность. Поэтому находить ошибки стараются на ранних этапах, привлекая не индийскую сторону, а, в том числе, русских специалистов для работы в режиме жестких deadline. И все заинтересованы не прокручивать машину по лишней итерации, а использовать хороших специалистов. Но, к сожалению, это не всегда возможно и не всегда просто даже для них. В худшем случае влетит не индусам, а руководителям проектов и архитекторам, которые осуществили ошибки управления.
          • 0
            Коллега, вы меня простите, но если вы глянете в мой профайл, то увидите, что я вам не только не оппонирую, но еще и нахожусь с вами на одном игровом поле. И в целом, знаком и с разработкой авиационного ПО и с индусами в этой прекрасной области.

            Как-то пришлось пару суток не спать из-за нагенеренных индусами тестовых логов.
            • 0
              Так я и не спорю с вами.

              Раз люди спрашивают про индусов, то развёрнуто ответил им в первую очередь. По логике, в это дерево, в подтверждение ваших слов.
      • 0
        Ничего не имею против индийских разработчиков, но в индийской культуре присутствует несколько наплевательское отношение к жизни и смерти. Обратите внимание на новости: постоянно то поезд сойдет с рельс и куча народу погибнет, то полный автобус с пассажирами в пропасть рухнет, то еще что-то аналогичное. Просто люди не заморачиваются чрезмерным соблюдением техники безопасности. Ну утонул паром с сотней пассажиров, ну бывает :)
  • +47
    И это из «песочницы»?
    • +57
      Действительно, такой контраст с постами топ-авторов Хабра :)
      • 0
        Ну, топ-авторы в своё время тоже по одной-две статьи аналогичной крутости написали (а как иначе в топ было попасть?). Другое дело, что постоянно писать на том же уровне не получается — никто не является спецом во всём, а на одну и ту же тему писать постоянно не будешь. Вот Вам эта статья понравилась, вторую на ту же тему тоже прочитаете с удовольствием. А пятую? А семнадцатую?
        • 0
          На эту тему, да если без повторений — с удовольствием :)
          • +2
            Да конечно с удовольствием. Вот только мне кажется, что люди, способные написать такой объем текста на одну тему без повторов и чтобы было интересно — спокойно могут идти рубить миллионы, повторяя путь Джоан Роулинг и Дэна Брауна, а не тусоваться тут в комментариях :)
  • –10
    Не удержалась и вспомнила вот эту статью:) www.anafor.ru/other/russianproject.htm
    Надеюсь, аналогии безосновательны
    • +13
      А вот эта ссылка уже ближе к уровню этого сайта. Котиков только забыли.
      • –2
        Вы слишком серьезны :) Котиков много поисквиков предоставляют по соответствующему запросу — зачем составлять им конкуренцию??
      • +6
        favicon там котик
  • +10
    Если не секрет, откуда происходит личный опыт автора?
    Я работал на МиГе, все описанное здесь не имеет ничего общего с суровой реальностью этого предприятия.
    Что-то заграничное или Иркут?
    • +8
      А ваш опыт секретен или вы можете изложить его в статье? Интересно.
      • +2
        Сейчас уже не секретен, подписка о неразглашении не действует. Да и не видел я ничего секретного.
        В одном из комментариев ниже человек «поностальгировал» так, что будто рядом со мной работал.
        Но у меня все-таки были свои особенности:
        Для начала, я пришел туда в 2010 году на должность техника-стажера (студент 3 курса). В мою задачу входило моделирование САУ — так вот, моё рабочее место состояло из компьютера с 386 процессором и матлабом версии, кажется, 2.1. Без гуя, естественно. При этом это рабочее место я делил с человеком, который уже давно там работал. То есть если за компьютером был он (программировал на паскале), то я слонялся по территории или читал книжки.
        Однажды в своей зарплатной ведомости увидел сумму около 100 тысяч рублей (при зарплате в 3). Поинтересовался что это — оказывается со студентов они не платят какой-то налог и через меня провели банкет. Восхитительно!

        О плюсах — во многих отделах работают ребята-энтузиасты, которые пробивают получение нового оборудования, внедряют новые системы, занимаются интересными вещами. Моё наблюдение: если количество молодежи (<40 лет) переваливает за 30%, то отдел начинает работать. В моем, например, я был единственным человеком, который попытался узнать — а вообще кому-то нужна наша работа?
        Энтузиастов мало ввиду смешной зарплаты. Растет она исключительно от выслуги лет, никак не от достижений.

        Кажется, на этом мой поток сознания окончен.
        p.s. О разработке даже не заикаюсь, в своём отделе ни разу не видел работающего программиста.
        • +1
          Да, к сожалению, в нашей науке и промышленности финансовые перспективы не радужные.

          Хотя у молодежи желания работать над наукой куда больше, чем над софтом, считающим бублики в дырках. Даже при меньших зарплатных ожиданиях. С большим энтузиазмом. Но не все могут себе это позволить.
        • 0
          Мне по работе приходилось бывать в ГСС, КБ Туполева, общаться с сотрудниками КБ Сухого. Соглашусь с Вами полностью — в тех отделах, где треть — молодежь — движуха и интерес.
          Единственное предприятие, выбивающееся из списка — Пермский Авиадвигатель. КБ очень продвинуто в сфере ИТ и у всех горят глаза. И молодежи там работает больше, чем 30%.
    • +1
      ГосНИИАС?
      • +8
        Гугл сообщил, что автор — сотрудник Ауриги.
    • +2
      Напишите статью, если не секрет.
    • 0
      Если в этой статье речь про суперджет, то понятно откуда столько новшеств в процессе.
      • +1
        Это не новшества. Это переложение западных стандартов на наши рельсы.
        • +1
          все описанное здесь не имеет ничего общего с суровой реальностью этого предприятия
          Видимо, для МиГа было бы новшеством.
          • +7
            МиГ занимается военной авиацией, в которой действуют правила кардинально отличающиеся от правил разработки ПО для гражданской.
            • 0
              Там самолеты по-другому что ли летают?
              Автор комментария явно посетовал на убогость процесса на МиГе. Разве нет? Видимо, он желает внедрения некоторого подобия процесса, описанного в статье, и там.
              • 0
                Насколько я знаю, военные как-раз чем-то таким сейчас и занимаются. Но это процесс небыстрый.
              • +1
                Подозреваю, что требования несколько отличаются. Вернее их приоритет. Скажем разная соотношение цен ошибок первого и второго рода. Или если для пассажирских самолетов основным требованием является, наверное, безопасность пассажиров любой ценой, то для военных это может быть возможность выполнения боевой задачи, пускай даже ценой гибели машины и пилота.
                • 0
                  Да, именно так.
                  В пассажирской главное — жизнь людей.
                  В военной допускается снижение безопасности экипажа ради повышения боевой эффективности.
            • 0
              Вы не правы. В военных проектах, во всяком случае, проектах Евросоюза действуют те же самые правила и зачастую те же версии документов и стандартов. Только компьютеры всегда под замком, документы в сейфах. Человек за спиной.
              • +1
                Ну тут речь идет не о Евросоюзе)
                • 0
                  Порой притормозить и как-то задокументировать русского заказчика очень тяжело.
                  Ибо в лучшем случае «мы придумали\хотим вундервафлю, надо сделать, запускай». С техпроцессами наследственная беда в России.
                  • 0
                    да я знаю..)
              • 0
                А в Российских ключ от сейфа лежит прямо на сейфе :)

                Кстати, меня очень забавляли безопасники — флешки и фотоаппараты проносить не разрешалось, а современный смартфон с камерой и чем угодно еще — конечно, пожалуйста!
    • +6
      Liebherr-Aerospace, которая как раз делала систему управления RRJ.

      Не только Суперджет, да с ним я и не так много работал. В-основном все процессы, описанные тут — опыт разработки с нуля Superjet'a (в нём, как в первом блине, не всё так гладко) и опыта работы Bombardier и Airbus.
      • +1
        основаны на*
  • +5
    Огромное спасибо за статью, очень толково написана и читать просто.

    Единственное, чего я не понимаю, это как гигантские объемы работы и количество кода сочетается с вероятностью отказа = 10^-9. В общем, с нетерпением жду следующую часть )
    • +4
      Контроль процесса разработки, следование заранее определенным мерам и т.д.
  • +12
    А можно маленькие примеры кода? Интересно посмотреть на стиль написания, именования и т.п.
    • +10
      Ок, в следующей статье приведу подробные примеры.
    • +1
      Яростно плюсую, может кто где видел?
    • +3
      www2.research.att.com/~bs/JSF-AV-rules.pdf
      • 0
        Это хороший пример Coding Standart'a.

        Для представления можно ещё погуглить MISRA отдельно со всеми её правилами.
  • +4
    Вот это топик! Читал с удовольствием.
    Спасибо!
  • +1
    7. Внесение результатов в систему контроля версий и отчётов (IBM Rational ClearCase\ClearQuest).

    На всякий случай: простая система контроля версий в разработке авиационного ПО применена просто так быть не может. Нужна система конфигурационного управления (7-я глава КТ-178B).

    Вкратце: в стандарте сформулировано большое количество целей, достичь которые без специальной настройки внедрения административно-инструментальных ограничений невозможно. Причем, некоторые из этих ограничений в принципе не могут быть достигнуты на современных широко распространенных системах версионного контроля и учета изменений.
    • +1
      Так и есть. Это относительно «шага» в труде программиста. А «версией» в данном случае является целый набор документов, отчётов и т.п…
      • +1
        И кстати, я видел процессы, когда все начиналось не с Design Document, а с SRD — например, изменение уже готовой функциональности.
        • 0
          В моём случае, к счастью, такое только встречалось для драйверов Framework'a. В плане исследования или упрощения кода.
          • 0
            ТО есть флайт-тестов еще не было?
            • +1
              В смысле? Framework один на все проекты, и на большие, и на малые самолёты. Но у него отдельная система итераций. В проекте конкретной системы управления указывается, какая именно версия используется (что подразумевает собой, что разработка framework завершена).

              Для Суперджета флайт-тесты были и успешно все прошли. Соответственно и эти драйверы отлетали и сертифицированы. Но фреймворк же развивается на перспективу, и в новом проекте его код когда-нибудь тоже пойдёт во флайт-тест.
  • 0
    Возможно, не очень внимательно прочёл.

    Какие, собственно, языки принято использовать для разработки в этой сфере?
    Я слышал что Ada считается де-факто стандартом «надёжного» языка.
    • +5
      Pure C, assembler.
      • +1
        Т.е. в аппаратных оковах данной сферы более высокоуровневые языки малополезны?
        И процессоры каких архитектур обычно используются для авионики? RISC/CISC?

        В любом случае, спасибо за статью и за ответ.
        • +4
          Они не приняты. Так как на язык накладывается уйма ограничений, justification. И пользоваться тем же C++ или C# в его «модифицированном варианте» будет сложнее. Плюс, опять-таки кто-то такое исследование должен сделать, проанализировать байт-код на выходе, тулзы сертифицировать. Это долгий процесс. Потихоньку им занимаются.

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

          а) дорого
          б) долго, что ведёт к «запаздыванию» в технологиях до десятилетия

          По поводу аппаратной части — в следующий раз.
          • 0
            Кто не приняты? Высокоуровневые?
            В том же семействе IEC 61508 явно говорится, что в чистом виде C использовать нельзя, потому что есть огромное количество возможностей выстрелить себе в ногу. Не уверен, что в России есть стандарты на авиационку в этом семействе, но у атомщиков есть, у железнодорожников.
            Вы используете какие-нибудь руководящие документы по использованию C?
            • 0
              >на язык накладывается уйма ограничений, justification

              В том числе и на C. Высокоуровневые сложнее и мощнее => работы над настраиванием системы justification больше. Для этого как раз нужен Coding стандарт.

              >в России есть стандарты на авиационку в этом семействе
              КТ-178B?

              По поводу внутренних стандартов не скажу, но исходя из вышеуказанного, они должны быть.
              • +1
                А, я подумал, что аду не используете из-за того, что на нее много ограничений :)
                Тогда вопросы снимаются, конечно же.
  • НЛО прилетело и опубликовало эту надпись здесь
    • +5
      Просто ответить «потому что» не получится. Тут выше уже сказали, что машина имеет свойство сильно бюрократизироваться. Объясню с точки зрения влияния на ПО. В идеале есть план, по плану надо поэтапно реализовывать спецификацию. Отчитываться. Однако, программам свойственно получать от их создателей ошибки, а спецификации — от своих. Тогда, после того, как ошибка обнаружена за пределами Iteration Package (т.е. за пределами того, когда программист написал свой код и отдебажил), чтобы хоть что-то изменить, надо менять уже документы, которые так легко не меняются. Т.е. каждое новое изменение в коде будет занимать почти вдвое больше времени в отличие от предыдущего почти исключительно по бюрократическим причинам.
      Однако, это не так плохо. Такой процесс как раз направлен на ловлю ошибок и недопущение их.

      Поэтому, если взгляните на картинку со спиральной моделью, можно заметить, о чём я сейчас говорю. Хотя тестирование на ней явно преуменьшено, но, в целом, проверка-перепроверка документации и сверка со всеми изменениями занимает половину всего времени. Процесс разработки авиационного ПО — процесс перманентной валидации.

      Тем не менее, факторами, которые мешают просто написать, скажем, лимитирование команды актуатора являются то, что:

      — существуют ошибки в симуляторе, и результат инженерных тестов и дебага не такой, как ожидается, и надо тогда допиливать симулятор.
      — особенность аппаратной архитектуры такова, что 1 из 100 фреймов приходит неверный, что не ожидалось в спецификации (допустим, из-за округления на ADC Resolver'a), тогда, вероятно, надо менять калибровочные параметры или по-другому обрабатывать данные.
      — внесены изменения в SRD — меняется архитектура и требования, что равносильно ещё одной незапланированной итерации
      — появился justification от заказчика (нет, даже не технического плана). Нет, это без проблем, это он доплатил и увеличил сроки. Но, тем не менее, это значит, что на данной и последующей итерации должен быть проведет анализ на изменения всех документов на изменения кегля шрифтов или нежелания видеть в LLR намёки на ASSERT'ы.
      — косяк сопряженной команды (я об этом расскажу в следующий раз), который приведёт к тому, что слишком сложный для исправления баг превращается в фичу для них, но ведёт к исправлениям для текущей команды разработчиков, т.к. они менее критичны и ресурсоёмки.

      В итоге, если бы не надо было делать идеальный код и идеальные тесты, вылизанные до запятой и каждой опечатке в слове «menue», то код можно было бы написать и проинтегрировать за 0,5 года. Но качество порождает процесс, проверки и перепроверки. Отчёты и отчёты об отчётах.
      • НЛО прилетело и опубликовало эту надпись здесь
        • +2
          Сейчас не буду углубляться в архитектуру и аппаратную часть, но тем не менее:

          — есть код, который создается сертифицированными кодогенераторами
          — есть код, который пишется вручную, да, даже переписываются драйвера
          — есть комбинации

          Для шасси используются все эти походы.

          Могу оценить исключительно рукописную часть, которая, естественно, была наименьшей по объему. Порядка 100 модулей (если бы это было бы ООП, скажем, C++ то модули — аналоги классов). На каждый модуль в среднем 500-1000 строк кода, описывающего его интерфейс и методы. Итого порядка 50 тысяч строк кода. Плюс, помножив на два — 100.00-200.000 строк кода в зависимости от нерациональности кодогенераторов и наличия комментариев.
  • +1
    «чтобы не пугать, о безопасности и отказоустойчивой архитектуре речь пойдёт в следующий раз»

    А я вот попугать вас хочу… про специалистов-разработчиков сложных систем, которых нехватает не то, что у нас, но и в Америке. У меня есть знакомый, из города, где производят ПО, для спутников(вроде бы там же их и запускают)…

    Общаясь с ним, года 2 назад, он сообщал свою з\плату — аж 20 тыщ рублей. При бюджете на запуск одного спутника в 200 миллионов рублей… и говорил — если кто-то что-то не то накодил, то спутник улетел не туда… и такое, он отметил, бывает довольно часто. :)
    • 0
      З\п в США? Не хочу ставить под сомнение ваши слова, но у меня знакомый в США работает продавцом в местной ликёрке и то получает вдвое больше в пересчёте на рубли.

      Да и про ГЛОНАСС наслышан из первых уст. Бардак-с.
      • 0
        Про 20 тыщ, как я понял, имелось ввиду не в США, а у нас.
        А вообще да, ситуация с з\п в авиаотрасли плачевна.
        Я вот тоже занимаюсь разработкой авиаПО, но свою зарплату даже озвучивать не стану, а то можете не поверить, что за эти деньги работать можно.
        • 0
          Не, не так надо — «свою зарплату даже озвучивать не стану» — а то летать перестанете… :)
          • 0
            Ну качество работы (моё по крайней мере) не сильно зависит от зарплаты. С голоду я не умираю, т.к. имею дополнительный доход, который позволяет мне работать в своей отрасли — авиации.

            То есть в каком-то смысле получается, что я доплачиваю за возможность работать в авиации ))
  • 0
    В начале было сказано:
    «модель водопада или гибкой разработки могут быть не лучшим вариантом».

    Насчет гибкой разработки понятно, а чем Waterfall здесь не подходит?
    • 0
      Как минимум необратимостью. Все ошибки выгодно обнаруживать на ранней стадии проекта.
      В худшем случае он может быть полностью переработан вместе с требованиями (на моей практике такое случалось, хоть и в мелком проекте). Плюс, контроль и тестирование происходят при максимально разумно малом изменении кода. Это минимизирует, в конечном итоге, стоимость проекта и, главное, позволяет избежать ошибок в нём. Плюс, ошибка может быть пропущена в 39 итерациях, но обнаружена на 40. И такое случается.
      • +1
        Водопад предлагает неплохие приемы по раннему обнаружению и предотвращению рисков разработки (вспоминая 5 приемов от Ройса).
        С вашего комментария выбор именно В-методологии не ясен.
        • 0
          Насколько я понимаю, классическая модель водопада предполагает необратимость процесса.
          Даже если принять во внимание обратные связи между этапами на одном уровне, о которых говорил Ройс, то что вы будете делать на этапе тестирования, если обнаружена ошибка в требованиях? Или, вообще как обеспечить возможность изменения требования без перезапуска всего водопада?

          Я молчу про этап внедрения (т.е. полётов), когда обнаруживается необычное поведение, вызванное замерзанием конденсата внутри поверхностей крыла, требующее усовершенствования кода и протоколирования в документации. Эти риски, пусть и со скрипом, но учитывает V-модель.

          Не всего можно избежать на ранних этапах, особенно при предельной сложности и многокомпонентности системы, требующей максимально возможное отсутствие ошибок.
  • +6
    Понастольгировал. Довелось поработать в смежной области, правда для боевых ЛА (работал над СППЗ). Из собственного опыта могу сказать следующее:
    1) Действительно бюрократизированный аппарат;
    2) Лично у нас никаких систем контроля (кроме бумажек и total commander) впомине не было (там даже и не знают, что такое git/svn);
    3) Очень трудно контактировать с людьми и получать более или менее внятное Т.З. Обычно на то, чтобы понять задачу и формализовать — уходило очень много времени (трудно понимать лётчика — а ему программиста);
    4) Никаких тестировщиков(всё было на уровне — сам нагадил — сам и протестил);
    5) Попытка включить что-либо новое(тот же git) — каралась расстрелом :);
    6) Виноводочные напитки решали многие проблемы (неформальные отношения процветают и растут);
    7) Чем сильнее вы программируете — тем сложнее работать в команде;
    8) Иногда доходило до маразма получения библиотеки от стороннего отдела (куча бумажек, «тянемвремя» и т.д.) — но это пункт 1 (в общем то он главный).
    9) Никакого единого стиля кода и т.д. (каждый пишет так как хочет) — к примеру со мной же работал дедок (довольно умный дяденька) — всю жизнь проработавший там программистом — но стиль его написания был С-подобным — о классах/шаблонах и т.д. не было и речи. (хотя и ТАКИМ людям от всей души выражаю благодарность), ибо именно благодаря ему, я познал всю тайну битовых полей, указателей на указатель на указатель и т.д.
    10) Если есть женщины(бальзаковского возраста) в отделе — «чёс языка» — неизбежен.
    В общем далеко от идеала. И самое интересное то, что попытки привлечь грамотных специалистов — заканчивались провалом — обычно они просто уходили — поняв «систему».

    • 0
      Искренне надеюсь, что дела в гражданской авиации обстоят иначе.
  • +2
    Надо нашему начальнику отдела качества и директорам дать это почитать. Ато ведь так и будет «ладно, на станции доделаем как всегда».
  • 0
    Я один картинок не вижу?
    • 0
      Хостинг от хабраэффекта поломался, сейчас перезалью.
  • 0
    Если кто-то не читал: Они пишут правильную вещь
  • 0
    Скажите, а есть ли какая-то объективная причина, кроме проблем с сертификацией оборудования, по которой ПО ютится в 128 кБ? Мне кажется, дешевле выйдет сэкономить на оптимизации, при такой-то стоимости каждой правки кода, купив вдвое больше памяти, чем нужно. То же относится к вычислительной мощности.
    • +1
      Проблемы сертификации оборудования.
      Микросхемы должны иметь приёмку по стандартам авионики. Таких не так уж и много.
      На самом деле, -O2 обычно хватает для всего (главная и критическая часть программы — это планирование задач). Если используются планируемые подпрограммы (задачи), которые куда-то надо записать, или, особенно, программы для наземного обслуживания, содержащие много кода для работы с терминалом, то обычно добавляется дополнительная быстрая Flash, которая почти неограниченно резиновая. Однако есть критичная часть программы, которая должна работать в режиме жесткого реального времени, что исключает возможность «просто добавить память».

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

      bBoolValue = (bool_t)((0-(nVar1^TargetConst_C))>>SHIFT_31_BIT_C)^0x1;

      плавно превращается в обычный:

      if (nVar1 == TargetConst_C)
         bBoolValue = TRUE;
      else 
         bBoolValue = FALSE;
  • 0
    Вопрос, везде написано, что используется схема с двумя компьютерами, собранными на разной элементной базе, с независимым программным обеспечение т.п. Как осуществляется резервирование? Как узнать какой из компьютеров выдаёт ложные команды? Если бы их было три, то можно было бы предположить резервирование, но их-то два.
    • 0
      Это одна из главных тем следующей статьи.
      Разные решения используются. Одновременно два вычислителя не используются, один из них в горячем резерве. Либо используются три. Плюс для каждого «компьютера» (Flight Control Unit'a) есть самодиагностика и самоконтроль.
  • 0
    Спасибо за статью. Заглянуть за кулисы такой закрытой области — дорогого стоит :)

    Вопрос по тексту. Вы говорите
    > Внесение результатов в систему контроля версий и отчётов (IBM Rational ClearCase\ClearQuest).

    Я правильно понимаю — внесение идёт только после всех предыдущих шагов? Как насчёт сохранения промежуточных результатов? Обмен дельтой внутри команды? Можно где-то подробнее прочитать именно про SW configuration management и version control в вашем проекте?
    • 0
      Правильно понимимаете. После всех шагов, т.е. после окончания baseline.
      Процесс ориентирован на то, чтобы не было промежуточных результатов => не было расхождений. Каждый разработчик выполняет свою часть, т.е. свою iteration package. Не трогая функциональности других людей (т.к. все пересечения должны быть выполнены на уровне создания архитектуры).
      Однако, как вы правильно заметили, CVS действительно отсутствует, и если надо сравнить что-то, то используются разные компарсеры. Будь то в NPP или diff. И обмен в команде copy-paste. Се ля ви.
      Возможно, в других местах используются git\svn, но в моей практике их не было.
      • 0
        Тогда другой вопрос — как часто выпускатся бэйзлайны? Ведь если между ними недели работы, то хранение нескольких версий кода ложится на плечи девелопера, а не SCM организации… Это чревато потерей данных, невозможность отследить разные версии своего кода и вообще много чем нехорошим. Лично вы как код сохраняете между бэйзлайнами и как это обычно делают другие?
        • 0
          В зависимости от проекта. В среднем 3-6 месяцев.
          К сожалению всё так, как вы говорите. Можно локально для себя поднять SVN, можно складывать всё в разные папочки по версиям и по «Release_Super_New_Updated_3_1». Т.к. у меня были разные машины в разных местах планеты, то приходилось пользоваться вторым вариантом. В лучшем случае на удалённом диске на общем сервере, в худшем — на флешке.
          Вообще это большая проблема, но из-за консерватизма с ней централизовано тяжело бороться. Хотя локально никто не мешает сделать жизнь лучше. Если есть походный ноут — так вообще без проблем.
          • 0
            Понятно. Что ж, остается только пожелать проявлять побольше «инициативы снизу», чтобы правильные практики SCM проникали в консервативные области индустрии :) Разумеется, после правильной и полной апробации :)
  • 0
    Если не секрет, какие операционные системы используются в авиации. Ну на нижнем уровне там понятно, скорее всего «голый си» на микроконтроллерах, а на верхних? Отображение, логика, etc?

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