Как я собрался писать открытую библиотеку для разработки и управления спутниками

Зачем и почему?

В жизни каждого человека есть время разбрасывать камни, а есть время собирать. После 12 лет работы в космической отрасли настало и мое время.  И как мне видится есть противоречие между трендом в спутникостроении и технологическим процессами. 

В чем суть? Главный тренд – это снижение стоимости аппаратов за счет более адекватной оценки рисков. И по идее весь процесс должен выглядеть так: вначале создается  адекватная модель того, как будет жить и существовать спутник, затем с опорой на нее мы его строим, потом запускаем,  получаем данные, корректируем нашу модель.

Но реальность такова:

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

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

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

 Одно кольцо объединит их… К-хм... Понятно, что это только инструмент и чтоб исправить вышеозначенную проблему нужно еще много организаторский работы, но при такой схеме сделать это проще. Почему? Отвечаю:

1. Классическое преимущество разделенного кода - меньше времени на отладку и на внедрение исправлений.

2. Уже при разработке моделей можно разработать методики автоматизированной проверки на земле и обработки данных в процессе лета.

3. Позволяет проектировать опираясь на то, как будут аппаратом управлять и как его будет принимать заказчик.

Начинаем собирать камни

Прежде, по крайне мере в мире свободного ПО, такой задачи никто не ставил. Поэтому будем действовать по принципу: «Новое вино следует наливать в новые мехи». Сформулируем наши желания, пока не утруждая структурированием и конкретизацией:

• Хочется, чтобы созданная библиотека не должна навязывать разработчикам язык программирования, на котором они будут писать;

• Хочется, чтобы возможно было разрабатывать как клиент-серверные приложения, так и однопользовательские;

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

 Из этого следует два вывода:

• Выбирать приходится из С++ и Rust. В противном случае, всем остальным придется писать на том же языке, что и мы, быть может, добавится пара-тройка скриптовых, типа Python.

• Нам точно потребуется ОРП-библиотеки, с помощью которых можно легко (относительно) переключится между серверной БД, например PostgreSQL и встроенной, такой как SQLLite. И желательно, чтобы он были на том языке, на котором написана вся библиотека.

И, казалось бы, все очевидно: Rust спроектирован с учетом накопленного опыта развития Си\C+, значит надо переходить на него, но не все так просто. Java, C#, D, были также разработаны с учетом того же, но C++ по-прежнему жив и активно развивается. А все дело в  цене – сборщике мусора, который как не крути, приводит к увеличения времени исполнения, объему потребляемой памяти, а также порождает проблему неопределенности во времени высвобождения объекта. Это видно по многочисленным тестам.

 Мой же опыт еще добавляет к этому, что проблемы с утечками памяти, хоть и уменьшаются, но не исчезают, а вот трудность обнаружения возрастает на порядки. 

У Rust же другая беда. С++ хоть и считается мультипарадигменном, но сквозь весь язык просвечивает понятие «объект». А вот у нашего пациента в основу положена другая сущность - «данные».  Казалось бы, в чем проблема? А она есть.

Хотя я уверен, что все знают основное свойство информации, но все же напомню: «Если Вы знаете математику, а Толя нет, то если вы передадите свои знания, то и Вы и Толя будут знать математику».  

А вот «объект» пришел из физического мира, и там совсем другие свойства: «Если у Вас есть апельсин, а у Толи нет, то если Вы его передадите, то у Толи будет апельсин, а у вас нет». И принципы ООП тоже взяты оттуда же, вы только  вспомните всех этих уточек у классиков.

Именно наличие повседневного опыта облегчает мозгу уложить эту абстракцию в голову. А вот с «данными» у нас ничего подобного нет, и по первости подсознательно пытаемся натянуть сову на глобус. Естественно, это не проходит бесследно ни для качества кода, ни для его производительности. И еще два года назад подобное можно было наблюдать в популярных математических библиотеках.

И надо сказать, что последнее обстоятельство сыграло немалую роль в том, что я поначалу отвернулся от Rust, и первый маленький прототип был создан  на C++. Когда же я стал писать статью я решил проверить, как сейчас обстоят дела. Как оказалось много лучше чем в 2020.

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

Что можно сказать: разработка Rust ведется гораздо более централизовано чем C++ . В этом есть как плюсы, например, скорость внедрение нововведений, так и минусы, например разработчики и менеджеры могут видеть будущее языка по-разному.

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

С++ древний язык, да при этом обеспечивающий прозрачную совместимость с С. Хороших проектов написанных на нем много. А Qt, по моему опыту, лучшее что существует для кроссплатформенной разработки пользовательского интерфейса.

Но и в Rust дела уже идут в гору. Глядя на структуру diesel в его будущее верится без проблем. А вот что с будет с Azul мне лично не очень ясно. Но опять же, никто не мешает в проектах на Rust использовать сишное наследие в виде GTK, благо есть специальный пакет, актуальность которого поддерживается скриптами.

Так что считаем, что по основным параметрам паритет. Но есть еще один беспокоящий момент: поддержка cстандартной библиотеки в операционных системах реального времени.

Убедил, что Rust не нужно рассматривать? Нет? Вот и я себе не убедил, хотя, повторюсь, у меня был уже минимальный рабочий проект на C++. Но чтобы понять куда двигаться дальше придется его реализовать и на ржавчине. И вот подобный поворот я не ожидал, когда сел писать эту статью. Он поломал всю логику повествования и то, что я хотел сейчас сказать. И в следующей статье, которые неизвестно когда будет, по всей видимости, я буду сравнивать Rust и C++.