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

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

Posted on Сентябрь 18, 2012 by Артем Шеин

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

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

В общем, мой код уже летает в составе 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 года работы понимают, что никаких перспектив и возможностей не предвидится и уходят на большие зарплаты. Но на их место уже готов новый набор из студентов.

via metadeus.wordpress.com