Как у нас пишут ПО для космических аппаратов

Предисловие (от 23 апреля 2015 г.)

Основная часть

Хотелось бы рассказать вам немного о разработке ПО для космических аппаратов «у нас», в отличие о того, что мы наблюдаем «у них«.

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

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

Все мои наблюдения оформлю в виде небольших тезисов.

  1. Большая часть ПО написана не профессиональными программистами.
    В основном функциональные системы написаны либо людьми имеющими инженерное образование связанное с летательными и космическими аппаратами, либо физиками и математиками, которым в силу необходимости пришлось научиться перекладывать свои знания на абстракции низкоуровневых языков программирования (типа C).
    Соответственно и на результаты такого написания кода без слёз взглянуть сложно.
  2. При написании бортовой части ПО используются технологии 20-30 летней давности.
    Это и устаревшие морально операционные системы, подходы к проектированию, реализации и тестированию программных продуктов. До сих пор можно найти документацию в виде страниц напечатанных на матричном принтере, которая в цифровом виде хранится у какого-нибудь дядечки на персональном компьютере под управлением MS-DOS, в одному ему известном месте.
  3. Для управления версионностью ПО не используются соответствующие программные продукты (Subversion, Git и т.п.).
    Даже если они и используются, то находится один (а чаще несколько) уникумов, которые не в состоянии их освоить, но в то же время являющиеся незаменимыми людьми, поэтому половина проекта находится под контролем системы управления версиями, а половина нет, что в итоге приводит к тому, что система начинает больше мешать, чем помогать в разработке.
  4. «Незаменимые» люди существуют.
    Существуют люди без которых разработка встает на месте. Чаще всего это связано с тем, что такой «незаменимый» держит в голове некие тайные знания на протяжении десятков лет и активно сопротивляется их формализации и оформлению в виде документации.
    Это может доходить до такого состояния, что с уходом «незаменимого» человека пропадают исходные тексты программ и целые пласты знаний, из-за чего приходится переписывать объемные системы с нуля.
  5. Отсутствие систем документооборота.
    Иногда таких систем просто нет, но чаще их просто не используют или использовать их крайне проблематично.
    В некоторых случаях система документооборота используется только для внешних по отношению к организации документов, для внутренней же документации используется переписка по e-mail, совещания и т.п.
  6. Бесконечные как по времени, так и по количеству совещания.
    Любое, даже самое мелкое действие для своей реализации может потребовать сбора совещания из 10-20 человек на срок 1,5-2 часа. Таких совещаний проводится 1-2 в день.
    На каждом таком совещании обсуждается сразу все вопросы, причем обсуждаются они по группам, т.к. эти вопросы редко касаются всех присутствующих, а в это время все остальные разговаривают между собой, играют или даже спят.
  7. Отсутствуют методология и системы модульного тестирования.
    Чаще всего, разработчик должен сам подумать и реализовать собственную систему модульного тестирования своего компонента, т.к. кроме него этим просто некому заняться.
  8. Слабо развиты методология и системы интеграционного тестирования.
    Чаще всего процесс слабо формализован и не поддается изменению. То есть, существуют формальные методики и люди занимающиеся тестированием, но получить что-то вменяемое от них практически невозможно.
    Все ошибки, в отсутствие системы учета багов, могут заноситься в бумажные журналы, которые сам разработчик должен отслеживать и после этого бежать к тестировщику для выяснения обстоятельств возникновения ошибки.
  9. Единственное, что спасает (далеко не всегда) ПО от багов это длительная многостадийная отработка.
    Зачастую при поступлении ПО на заключительную стадию тестирования в первые же несколько дней находят сотни ошибок.
    Иными словами, удивительно не то, что некоторые космические аппараты у нас не летают, удивительно то, что другие летают.
  10. Бессбойность работы не является приоритетом при проектировании и реализации.
    Многие предложения по повышению надежности ПО требующие лишь некоторого времени на реализацию отклоняются на том основании, что менеджер не видит или не понимает проблемы.
    Даже простейшие системы контроля параметров попадающих на борт внедрялись с большим трудом под предлогами «оптимизации» или недопустимости изменения интерфейса существующих функций используемых десятком разработчиков.
  11. Преждевременные псевдооптимизации при явной пессимизации.
    В программах почти всех инженеров ставших программистами по необходимости можно увидеть псевдомикрооптимизации, которые делают код нечитаемым (например: использование операций сдвига вместо умножения, использование битовых операций для ускорения исполнения программы, отказ от выделения функций для экономии на вызовах и т.д. и т.п.). Программы приобретают поистине кошмарный вид с десятком уровней вложенности и переиспользованием одной переменной для разных задач в пределах одной функции, с затейливой битовой арифметикой и шаманскими макросами имеющими глобальную область видимости.
    Вместе с тем при компилировании релизной бортовой версии могут быть сознательно выключены все оптимизации компилятора и линковщика для обеспечения какой-нибудь редкоиспользуемой низкоуровневой функции (например: реализации бинарных патчей). Что в конечном счете приводит к тому, что бортовой код становится медленным как черепаха и выходит за такт жесткого реалтайма, и в свою очередь вызывает новую волну дебильных микрооптимизаций по включению тела функций в места их вызова и замены нормальных вычислений сдвигами и т.п.
  12. Системная текучка кадров. Текучка кадров встроена в систему — такого слоя специалистов как грамотные опытные разработчики не пред пенсионного возраста практически нет. Есть два лагеря: профессионалы старой школы сопротивляющиеся всему новому и держащиеся за свои рабочие места (про них говорят: «Эти люди не читают книг — они их пишут»), и бывшие студенты ещё ничему не научившиеся и зачастую просто «отсиживающиеся» от призыва в армию. Большинство адекватных людей через 2-3 года работы понимают, что никаких перспектив и возможностей не предвидится и уходят на большие зарплаты. Но на их место уже готов новый набор из студентов.

25 thoughts on “Как у нас пишут ПО для космических аппаратов

    • Да уж, человек мало понимающий в политике перепостил человека, мало понимающего в разработке. Ну, может я во втором и ошибаюсь, но то что «база знаний» переводится вами с английского как «база данных» (т.е. путаются два существенно разных понятия), а жёсткий реалтайм именуется «технологии 30-летней давности», это очень печально.

      • Может вы и в первом и во втором ошибаетесь? Погадайте на кофейной гуще, что вам ещё остается?

        Где это я перевел с английского «база знаний» как БД? Я не занимаюсь переводами с английского.

        > жёсткий реалтайм именуется “технологии 30-летней давности”

        И это тоже вы сами придумали.

        Уровень грамотности большинства комментаторов — вот что действительно печально.

        • Не обращайте внимания. Это был бот, состоящий из говнокода и микрооптимизаций:)

  1. Если главный менеджер в отделении программистов не в состоянии запустить тотал коммандер, когда на экране висят три кнопки (1, 2, 3) и надпись «нажмите 1», а в качестве оправдания фраза типа «Я специалист другого уровня, мне этого уметь не надо», то о нормальном ПО речи и быть не может. А еще эти ГОСТы 80х годов….
    Кстати, так дела обстоят не только в программировании. Например, как можно пускать деталь в производство, когда заказчик думает внести изменения, а расчет на прочность еще не произведен?

  2. А вот такой вопрос — а как в отделении программистов появился Total Commander, который МОЖЕТ ПОЗВОЛИТЬ себе просить нажать 1, 2 или 3??? Неужто нет денег на лицензию?

    • А вы думали, что везде пиратство, а в крупных корпорациях не будет пиратства? Никого особо этот вопрос не волнует, т.к. никто туда с проверкой не придет.

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

  3. Согласен полностью с автором статьи. Работал в отраслевом НИИ пищевого профиля. Среди старпёров везде разговоры: «я крупный специалист в …. области, могу позволить себе не уметь работать на компьютере и буду писать на бумаге ручкой. Потом придет человек, который наберет этот письменный текст в ворде за 2,5 тыс. руб.» Как правило люди, готовые работать за такие деньги не находятся.

  4. Подписываюсь под каждым словом. 2.5 года работал в НПО, которое делает системы управления для кораблей и подводных лодок. О том, что само НПО является разлагающимся трупиком совкового предприятия (в самом худшем смысле), говорить не буду.
    Что же касается разработки ПО. Очень часто давали задания типа «сделай что-то, сам не знаю что». Начальство отдела разработки (не программеры, но инженеры, описывающие как и что мы должны накодить) было совершенно неадекватно и с трудом понимало, чем занимается его собственный отдел. А то, что делают программисты, она даже и не догадывалась.
    Успехи Computer Science и Software Engineering? А что это? Системы контроля версий и багтрекинг? Не, не слышали. Использовать отладчик? Зачем, поставим побольше отладочной печати и будем вдумчиво курить логи. Система сборки? А что, такое возможно? Совершенствовать методы кодирования и применять современные технологии? Нееее, чистый C на системе 15-летней давности — наше всё.
    Апофеозом творившегося во время моей работы в НПО маразма стали два явления. Во-первых, когда пришёл мой заслуженный отпуск, на меня навесили два проекта, которые надо было к концу следующей недели сдать. Пришлось работать в отпуск (попутно вести поиск другой работы). Так вот, реализовывая одну специфичную функциональность, пришлось влезть в ядро разрабатываемой системы (~500 строк кода), на что вышестоящие инженеры ответили, что идея очень плоха, так как «вот завтра тебя тут не будет, а нам с этим разбираться». Несколько дней я пытался им объяснить механизм работы того места, куда я собирался влезть, но так и не получилось. Меня просто не слышали. Пришлось городить высокоуровневые костыли. Во-вторых, в НПО молодые сотрудники часто занимались не тем, чем они хотели. Так, проектировщики судовых движков рисовали гуишки, а программисты забивали данные в БД. И есть у меня подруга, которая занимается тем, что просматривает сериалы и выполняет редкую бумажную работу. У подруги должность — техник-программист. После универа станет инженером. Из программирования за всю свою жизнь прочла только оглавление книги по С++. Подруга недавно прошла курсы по Qt (серьёзный фрэймворк на С++). Что-нибудь осело в её светлой головке? Отнюдь.
    Кстати, о зарплате. При полном рабочем дне я получал меньше, чем в макдональдсе. А некоторые начальники отделов имели зарплату под миллион (реально видели расчётный листок).

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

    Специфика нашей косм. отрасли — очень много совершенно независимых предприятий (хотя это сейчас меняется в сторону интеграции, как известно). Возможно, что дойдёт и до некоторой унификации технологий программирования. Попытки работы экспертных групп в этом направлении уже были: http://i.ermakov.pw/pubs.php#space).

    Культура программирования у этих разнороных предприятий тоже совершенно различная. А автор статьи побывал только в одном из них — и даёт своим «мемуарам» такое громкое название. Всякие желчно настроенные субъекты эту его статью уже затаскали по форумам, в том числе политического характера.

    Возьмите НПО Решетнева с их технологией полного цикла, где внизу лежит Модула-2 (http://www.inr.ac.ru/~info21/pdf/AAKpaper2006.pdf и http://www.inr.ac.ru/~info21/info/koltashev.jpg).

    Возьмите РКК «Энергия», где за ПО отвечают команда академика Микрина (у них базовые кафедры в МГТУ им. Баумана).
    У них хорошо поставленный техпроцесс на базе современных инструментов (UNIX-экосистема GCC, системы контроля версий.. ОС на МКС используются QNX и Windows), своя архитектура на основе изолированных процессов и протоколов обмена сообщениями и т.п.

    Возьмите НПЦ АП с их Графит-Флоксом, с которым они имеют техпроцесс надёжной разработки сложных СУ на железе уровня не самого сильного микроконтроллера.

    Возьмите НПОА Семихатова, где люди разрабатывают свои DSL на базе конечноавтоматных формализмов.

    Это не опровергает того, что на МНОГИХ стратегических предприятиях нет НОРМАЛЬНОЙ культуры разработки ПО.
    Но делает некорректным название и первый абзац статьи:
    «Как у нас пишут ПО для космических аппаратов
    Хотелось бы рассказать вам немного о разработке ПО для космических аппаратов «у нас», в отличие о того, что мы наблюдаем «у них«».

    • Насколько я понимаю, автор как раз и пишет про подразделения «Aкадемика» Микрина… Кстати, а что там у «Aкадемика» с публикациями? Никто их не читал? 😉

    • > плохой эффект от неё в том, что читатель сразу делает вывод обо всей нашей косм. отрасли

      Ну если читатель дурак, то это не проблема автора. С другой стороны, судя по всему он будет не так уж далек от истины, т.к.:

      > Специфика нашей косм. отрасли — очень много совершенно независимых предприятий

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

      > Возьмите РКК «Энергия», где за ПО отвечают команда академика Микрина (у них базовые кафедры в МГТУ им. Баумана).
      У них хорошо поставленный техпроцесс на базе современных инструментов (UNIX-экосистема GCC, системы контроля версий.. ОС на МКС используются QNX и Windows), своя архитектура на основе изолированных процессов и протоколов обмена сообщениями и т.п.

      т.к. этот пост был именно об РКК «Энергия» и о «команде Микрина» и поставленным там «техпроцессе на базе современных инструментов». В части использования QNX — она на время написания поста на борту использовалась вне системной бортовой части, то, что было написано на ней впоследствии переписывалось и в результате переписывания имело к QNX слабое отношение, т.к. основные механизмы ОСРВ это управление процессами и IPC, а тут они были написаны в обход QNX (так называемая «своя архитектура», а попросту говоря — велосипед). Спросите лучше как и главное зачем в РКК вообще попала QNX?
      Нигде в системной бортовой части никакой QNX или Windows естественно не используется.
      Название и первый абзац считаю абсолютно корректными.

      • Хм, у меня возникло ощущение, что речь была об НПОЛ.

        Внутри РКК «Энергия» я не был, на одном из мероприятий в Бауманке (зимой этого года) мы общались с Микриным и его людьми, у них была серия докладов, достаточно подробная.
        Выступала, в том числе, молодая команда разработчиков, как раз акцентировали внимание на том, что у них там, «в отличие от многих предприятий», процесс разработки поставлен «по ИТ-шному», на UNIX-стеке технологий, с нормальным тестированием и проч.
        Про ОС, с их слов — Windows использовалась на АРМах («а-х рабочих местах»), а QNX — в системной части.
        Про «так называемая «своя архитектура», а попросту говоря — велосипед» — рассказывали про средство формального описания и контроля протоколов межпроцесснного обмена (типа грамматик на обмен сообщениями).

        Дезинформация? Или что-то поменялось у них таки в последнее время?

        Микрин на том мероприятии акцентировал внимание на том, что «инструменты, роль языка программирования и проч. — ерунда, молодёжный предрассудок, главное — поставленный процесс разработки» (в плане принижения роли инструментов и языков лично я с ним категорически не согласен, т.к. чем раньше отловлена ошибка, например, за счёт системы типов в Ada, тем дешевле она обходится; чем если её ловить уже тестами и проч. «поставленным процессом разработки»).

        • В РКК есть несколько групп и проектов, и в них местами сильно по-разному. Местами действительно лучше, и там действительно применялись по-нормальному системы контроля версий, хотя бы. Но, нормального тестирования мне видеть не приходилось нигде, за исключением сугубо наземной части. То, что было сделано «на UNIX-стеке технологий» впоследствие было решено выбросить полностью (не знаю чем это закончилось в результате).
          Использовать Windows на рабочих станциях много ума не нужно. QNX же именно в системной части борта не использовался, кроме как в полезной нагрузке.
          > рассказывали про средство формального описания и контроля протоколов межпроцесснного обмена (типа грамматик на обмен сообщениями)
          Да, было такое. Своя система IPC в обход QNX’овой, для кроссплатформенности. Это даже не страшно, только имея при этом ещё и свой планировщик процессов — зачем этот QNX вообще сдался? Нужных драйверов под него все равно нету.

          > «инструменты, роль языка программирования и проч. — ерунда, молодёжный предрассудок, главное — поставленный процесс разработки»
          Ну для них вообще там использование автоматизации это молодежный предрассудок, а процесс выглядит не иначе как — есть пул бойцов, которые уже что-то подобное делали — пусть повторят подвиг.

        • Ну так те же ребята Вам и рассказали бы, что это всё реализуется во многом ВОПРЕКИ системе, созданной Микриным и Co. Что удалось это внедрить лишь на одном из проектов и с большими трудностями, т.к. руководство В ПРИНЦИПЕ не понимает зачем это нужно.

          Точнее понимает, но это уже дело скорее уголовное…

          Можно было попросить Микрина рассказать о созданной им (а им ли?) системе разработки и отработки ПО для служебного борта, жизнеспособной лишь в условиях отсутствия конкуренции и гос.заказа, т.к. требует безумного количества людей. А заодно, о частоте и полноте тестирования 😉
          Но учтите, что «академик» знает, что Вы его проверить не сможете.

    • Скажу про НПЦАП. Проработал там 5 лет, писал бортовое ПО. Про Графит-Флокс впервые услышал сейчас от Вас. То, что происходило у нас в отделе, гораздо больше похоже на то, что описал автор.

  6. Сначала скажу, что согласен с Ильей Ермаковым: не надо обобщать на всю космическую отрасль.
    У нас есть и очень впечатляющие положительные примеры в разработке БПО.

    Например, в ОАО ИСС (Красноярский край) и МОКБ «Марс» (Москва). Где и контроль версий, и полностью электронный документооборот. В котором и электронные «подписис» и согласование, и привязывается версия программы к версии документации на нее, что тоже весьма существенно. А в бумажном виде документы создаются только для сдачи в архив. И даже — в МОКБ «Марс» — автоматическая генерация бортовых программ по графической спецификации алгоритма. Они целый отдел бортовых программистов уволили, а сроки разработки существенно сократили.

    Не хотелось бы также, чтобы складывалось неверное впечатление о неадекватности тестирования ПО в космической отрасли. Как критические важное ПО, оно проходит многостадийный процесс отладки на стендах с участием как реальной бортовой аппаратуры и БЦВМ, так и специально создаваемого комплекса программ-моделей, имитирующих полет и поведение бортовых систем.
    И автоматизация процессов здесь тоже применяется. Например, в ЦСКБ-Прогресс, г. Самара, автономная отладка программных модулей автоматизирована в значительной степени за счет специальной среды в которой используется специальный символьный язык отладки, на котором можно составлять и затем прогонять отладочные задания.

    И, кстати — не стоит идеализировать Запад и то, что и как там происходит. Нам, русским, к сожалению, это испокон веков свойственно. Могу и по личному опыту сказать, как человек, работавший в Силиконовой Долине программистом, и по Интернет-публикациям конкретно касающимся разработки ПО для космоса. Дурного менеджмента там своего хватает.
    Да и конкретно по Шаттлу на научной конференции одной, помню, выступал человек «оттуда», который сказал, что реально там такой «зоопарк» на разных ЭВМ разного программного кода на разных языках, что когда специально проводили анализ по поводу возможной унификации и систематизации, поняли, что это нереально и лучше даже «не лезть».

    Интересующимся разными аспектами вопроса также советую почитать специализированную статью http://cyberleninka.ru/article/n/puti-povysheniya-nadezhnosti-i-kachestva-programmnogo-obespecheniya-v-kosmicheskoy-otrasli

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Google photo

Для комментария используется ваша учётная запись Google. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

Connecting to %s