Обновлений каждую весну и осень там не происходит, но космические операционные системы всё же эволюционируют

Космический аппарат Solar Orbiter от ЕКА изучит Солнце, сильнее всего приблизившись к нему после выхода на орбиту Меркурия

Запущенный недавно космический аппарат Solar Orbiter от европейского космического агентства (ЕКА) проведет много лет в одном из самых неприятных районов Солнечной системы: в непосредственной близости к Солнцу. Во время своей миссии Solar Orbiter подлетит на 10 млн км ближе к Солнцу, чем Меркурий. А Меркурий, надо заметить, расположен к нему достаточно близко для того, чтобы температура на его поверхности, обращённой к светилу, достигала 450°C.

Чтобы выдерживать подобные температуры, Solar Orbiter будет полагаться на хитроумно спроектированный тепловой щит. Однако щит этот будет защищать космический корабль только тогда, когда тот будет направлен непосредственно на Солнце – эффективной защиты с боков или с задней части зонда нет. В связи с этим в ЕКА разработали операционную систему реального времени (RTOS), способную работать в рамках жёстких ограничений. Максимальное разрешённое отклонение от направления на Солнце составляет 6,5°. Любое отклонение более, чем на 2,3° допустимо только на краткий промежуток времени. Если что-то пойдёт не так, и будет зафиксировано опасное отклонение, у Solar Orbiter на реагирование будет около 50 секунд.

«На этой миссии у нас чрезвычайно жёсткие требования», — говорит Мария Хернек, глава отдела полётных программных продуктов в ЕКА. «Обычно перезапуск подобной платформы занимает примерно 40 секунд. А здесь у нас есть 50 секунд на то, чтобы найти проблему, изолировать её, привести систему в рабочее состояние и предпринять действия по восстановлению».

То есть, ОС, расположенная где-то далеко в космосе, должна удалённо перезагрузиться и восстановиться за 50 секунд – или Solar Orbiter поджарится.

Бильярдная ОС

Чтобы справиться с подобными безжалостными временными ограничениями, на космических кораблях, подобных Solar Orbiter, почти всегда работают ОС реального времени, устроенные совсем не так, как известные нам системы в ноутбуках. Критерии нашей оценки ОС типа Windows или macOS достаточно просты. Они проводят вычисление, и если его результат оказывается правильным, считается, что задача решена корректно. У ОС, работающих в космосе, есть ещё, по крайней мере, один важный критерий: вычисление нужно провести правильно, и за строго отведённое время. Если выполнение не уложилось в этот промежуток, задача считается не выполненной и её исполнение прерывается. А если вы не уложились в отведённый промежуток времени в космосе, то, скорее всего, ваш корабль уже превратился в огненный шар, или остался на неправильной орбите. Обрабатывать такую задачу дальше смысла нет, поэтому всё должно подчиняться строгому плану.

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

Чтобы сравнить это с известными нам ОС, посмотрите сравнение скоростей современных смартфонов. Вот, например, видео, где iPhone XS Max и Samsung S10 Plus на скорость открывают разные популярные приложения. Перед испытанием оба телефона перезагружены, а кэш удалён. Samsung открывает все приложения за 2 минуты 30 секунд, а iPhone – за 2 минуты 54 секунды. Во втором раунде все приложения закрываются и снова открываются, без перезагрузки и очистки памяти. Поскольку приложения не удалялись из памяти, Samsung заканчивает открытие за 46 секунд, а iPhone за 42 секунды. Огромная разница в две минуты между первым и вторым подходом. Но если бы на телефонах работали такие ОС, которые используются для космических полётов, на открытие приложений уходило бы совершенно одинаковое количество времени, вне зависимости от того, сколько раз вы проводили бы испытания – и с точностью до миллисекунд.

Кроме работы со временем, у космических ОС есть и другие особенности. Одно дело – работа в реальном времени, а другое – детерминизм. Если бы вы убедили Крейга Федериги принять участие в одном из испытаний на скорость загрузки, и дали бы доступ к iPhone, который предполагается испытывать, а потом попросили предсказать, сколько точно времени уйдёт на этот тест – он бы, скорее всего, понятия не имел. Он бы, наверное, сказал бы нечто вроде «немного» или «достаточно немного», или «прямо очень мало», но вряд ли что-то более конкретное. iOS и Android – системы не детерминистские. Количество факторов, способных влиять на скорость, настолько велико, что сделать точные предсказания практически невозможно. Но если бы на телефоне работала ОС космического класса, то инженер, имеющий доступ к системе, знал бы всю последовательность выполнения и смог бы точно подсчитать время, уходящее на выполнение конкретной задачи. Космическое ПО должно работать предсказуемым образом и укладываться в очень жёсткие временные рамки.

Одна небольшая перезагрузка

Во время спуска Базз Олдрин и Нил Армстронг оставили включённой антенну радара и направили её на командный модуль «Аполлон», оставшийся на орбите вокруг Луны. Это было сделано для безопасности, чтобы посадочный модуль знал, где находится командный, на случай, если ему понадобилось бы прервать посадку. Но оказалось, что радар начал переполнять компьютер данными, из-за чего в бортовом управляющем компьютере «Аполлона» быстро закончилась память. Печально известные ошибки 1201 и 1202 говорили о том, что у компьютера не осталось свободных ячеек памяти на магнитных катушках и свободных векторных аккумуляторов соответственно. Из-за отсутствия памяти программы посадки не смогли отработать вовремя, из-за чего компьютер постоянно перезагружался. И всё-таки, благодаря встроенным в ОС мерам безопасности, во время этих перезагрузок не было потеряно критически важных навигационных данных, и посадка прошла по плану. ОС просто запускала запланированные программы с того места, где они обрывались.

Достреливаем до Луны (и далее) при помощи VxWorks

Во времена «Аполлона» для каждой миссии создавались специальные операционки. Часть кода, конечно, использовали повторно – части программ, написанных для миссии «Аполлон», к примеру, попали в программы Skylab и «Шаттл». Но по большей части всё нужно было делать с нуля.

В итоге в НАСА решили остановиться на варианте ОС, разработанном калифорнийской компанией WindRiver. WindRiver выпустила полностью рабочую коммерческую ОС реального времени VxWorks в 1987 году. Хотя VxWorks стала не первой системой такого рода, она быстро стала наиболее популярной из всех – а, значит, вскоре попала в поле зрение разработчиков миссий НАСА.

Первой миссией, использовавшей VxWorks, стал зонд "Клементина". В начале 1990-х «Клементина» отметила разворот НАСА от монструозных программ типа «Аполлон». Всё нужно было разрабатывать быстро и на скромный бюджет. В результате одним из решений по программе стало использование VxWorks, и система произвела достаточно хорошее впечатление для того, чтобы состоялось второе свидание. VxWorks выбрали для миссии Mars Pathfinder.

Но с этой ОС тоже не всё было идеально. Один из багов – проблема инвертирования приоритетов – причинил центру управления НАСА немало хлопот. Вскоре после посадки система Pathfinder начала беспричинно перезагружаться, что задерживало передачу собранных данных на Землю. На поиски проблемы ушло три недели, а на её исправление – ещё 18 часов. Оказалось, что проблема затаилась в глубинах механики работы VxWorks.


Введение в VxWorks

Анатомия VxWorks

В сердце VxWorks находится микроядро. Оно заведует всеми взаимодействиями работающих в системе программ и железа. В VxWorks микроядро отвечает за планирование выполнения задач с 256-ю уровнями приоритетов. Поддерживается преимущественная и не преимущественная версии алгоритма планирования round-robin, а также обмен данными между задачами.

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

Коммуникации между задачами в VxWorks могут идти либо через систему обмена сообщениями, позволяющую задачам обмениваться данными, или через семафоры, переменные, существующие для того, чтобы задачи по мере необходимости взаимно блокировались или синхронизировались. В VxWorks есть два типа семафоров. Первый – двоичные, принимающие значения «полный» или «пустой». Полные семафоры доступны для задач, а пустые – недоступны. После запуска задача берёт доступный семафор, и делает его «пустым», недоступным для других задач. Когда задача завершает выполнение, она возвращает семафор, что делает его доступным для других задач.

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

Кроме двоичных, в VxWorks имеется второй тип семафоров – семафоры взаимного исключения, или мьютекс [mutual exclusion / mutex]. Они позволяют задачам эксклюзивно использовать ресурсы. Главное его отличие состоит в инициализации семафора. Двоичные семафоры всегда создаются пустыми. Мьютексные семафоры всегда создаются полными. Задача просто создаёт полный семафор и сразу же перехватывает его, из-за чего он становится недоступным для всех остальных задач, пока эта задача не закончит свою работу. Такие семафоры часто используются для доступа к коммуникационному оборудованию. Задаче нужно занять подобное оборудование – к примеру, информационную шину – до тех пор, пока не закончится передача данных. Обрывать передачу до её завершения смысла нет, отсюда и возникает необходимость в мьютексных семафорах.

Звучит хитроумно, и так оно и есть. Семафорная система проприетарна, и стала одним из конкурентных преимуществ VxWorks. Но всё равно, за первые несколько недель, которые Pathfinder провёл на Красной планете, RTOS красочно облажалась.

Марсианский баг

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

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

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

Такие перезагрузки за две недели произошли где-то раз пять – но в итоге винить VxWorks и схему её работы было не за что. Система могла разбираться с такими проблемами при помощи трюка под названием «наследование приоритета», после которого задача с низким приоритетом могла временно получить более высокий приоритет другой задачи, которую она заблокировала мьютексом. Если бы на Pathfinder работало наследование приоритета, то задача по сбору метеорологических данных просто приняла бы на себя высокий приоритет от задачи управления шиной, пока та ждала доступ к семафору. А это не дало бы коммуникационной задаче со средним приоритетом получить преимущество. Всё, что нужно было сделать – это включить наследование приоритета перед запуском.

Поэтому, в итоге, проблемы с Pathfinder произошли из-за человеческой ошибки. VxWorks оказалась невиновной, и продолжала летать практически на всех вездеходах, опускавшихся с тех пор на Марс. Всего через несколько десятилетий после того, как VxWorks стала самой популярной RTOS на Земле, она смогла стать самой популярной ОС и на Марсе.


Миссия BepiColombo в представлении художника. Совместный проект европейского и японского космических агентств, который отправит два космических корабля в сложные условия Меркурия

ЕКА не устояла перед RTEMS

В последнее десятилетие ландшафт космических ОС оставался стабильным. В США НАСА вполне удовлетворялось использованием проприетарной VxWorks в самых своих ответственных миссиях. Но в Европе ЕКА нашло собственную рабочую лошадку. Космическое агентство положилось на разработку системы RTEMS с открытым кодом – которая, по словам Марии Хернек, обладает такими же возможностями, но не требует затратных лицензионных отчислений.

Изначально RTEMS создавалась не для того, чтобы управлять европейскими космическими кораблями. Её первоначальной целью было управление американскими ракетами. История RTEMS началась с исследования, которое провели в центре исследований, разработок и инженерных решений авиационного и ракетного командования армии США в 1988. Военные исследователи пришли к выводу, что использование частных закрытых операционных систем реального времени приводит к различным проблемам. В первую очередь, проблема в том, что код не принадлежит правительству, поэтому оно не может его модифицировать. Более того, в исследовании утверждалось, что ответственность за отказ программ получается размытой, а RTOS того времени работали слишком медленно, чтобы их можно было использовать в ракетах. По всем указанным причинам американские военные решили сделать собственную RTOS под названием Real-Time Executive for Missile Systems [выполнение в реальном времени для ракетных систем]. Они стремились сделать ОС реального времени, работавшую достаточно быстро для самонаводящихся ракет, принадлежащую правительству, без проблем запускающуюся на процессорах разных семейств, и свободную от лицензионных отчислений.

В процессе создания RTEMS военные начали понимать, что варианты её применений выходят за рамки пуска ракет. Поэтому название системы довольно быстро поменялось на более общее, Real-Time Executive for Military Systems [выполнение в реальном времени для военных систем]. А с 4 мая 1995 года, когда код RTEMS был выложен в свободный доступ, и уже не обязан был носить военную форму, она стала известной, как Real-Time Executive for Multiprocessor Systems [выполнение в реальном времени для мультипроцессорных систем].

ЕКА полюбило эту систему по двум причинам. Первая – RTEMS с нуля разрабатывали с тем, чтобы её легко было портировать на процессоры новых семейств. Поэтому было относительно просто заставить её работать на новых чипах SPARC LEON с защитой от радиации, разработанных в Европе для миссий ЕКА. Вторая – система была очень гибкой. Основываясь на тех же принципах, что и VxWorks, RTEMS давала программистам больше свободы, позволяя менять практически всё. ЕКА свободно могло играться с кодом.

Планирование задач – одна из настраиваемых областей, в которых RTEMS отличается от VxWorks. В VxWorks программисту достаётся преимущественный планировщик на основе приоритетов, для задач с разными приоритетами и алгоритмом round-robin для задач с одинаковым приоритетом. Менять его нельзя. WindRiver так всё запрограммировала, и всё тут. RTEMS предлагает совершенно другой подход.

У RTEMS, конечно, есть планировщик на основе приоритетов с 256 уровнями приоритетов – так же, как и у VxWorks. Доступен там и метод round-robin. Они используются в качестве планировщиков по умолчанию на однопроцессорных платформах. Однако в RTEMS можно отказаться от любого из них и использовать один из множества других механизмов планирования. Там есть, например, планировщик с простыми приоритетами – облегчённая версия планировщиков по умолчанию, способная работать в очень жёстких ограничениях по объёму памяти. У него есть ещё один вариант, для симметричных мультипроцессорных систем, где множество процессоров работают параллельно. Есть другой вариант планирования – с расстановкой по хронологии дедлайнов. А если вам не нравится то, что есть в RTEMS, можно написать собственный планировщик – RTEMS будет работать и с ним.

Выбрав эту RTOS, ЕКА много сил и времени вложило в то, чтобы довести надёжность RTEMS до уровня B – это второй по счёту уровень надёжности программ по шкале агентства. Уровень В у программы в ЕКА означает, что отказ в работе приведёт к «критическим» последствиям. Чтобы довести надёжность до такого уровня, тестировщикам ЕКА приходится выполнять каждую строку и проверять каждую вилку решений в коде RTEMS. Выше уровня В находится только уровень А, отказы на котором имеют «катастрофические» последствия. К сожалению, в документах ЕКА не даётся точных определений «критических» и «катастрофических» последствий – но можно представить себе, например, падение МКС на Брюссель.

«Насколько я помню, последний раз мы использовали VxWorks в одном из инструментов на корабле Sentinel 1», — говорит Хернек. Во всех современных европейских космических миссиях, включая и самую последнюю, Solar Orbiter, на борту кораблей стоит RTEMS.

RTOS на задании

На сегодня VxWorks и RTEMS используются уже несколько десятилетий и показали себя с потрясающе хорошей стороны. В переписке по емейл касательно ОС реального времени от 2004 года, Грегори Менке, программист из НАСА, писал, что по быстродействию RTEMS и VxWorks идут ноздря в ноздрю, и их практически невозможно отличить. Поэтому нет ничего удивительного в том, что в ЕКА иногда использовали VxWorks, а в НАСА нередко обращались к RTEMS. Бывало даже, что две этих основных полётных ОС работали сообща на одном и том же космическом корабле, управляя разными инструментами.

Но это не значит, что за последние десять лет в мире космических ОС не было ничего, кроме VxWorks и RTEMS. А иногда новые вызовы рождаются в неожиданных местах – к примеру, в посте на форуме, посвящённом биткоину.

В 2013 году один из главных разработчиков биткоин Джефф Гарзик опубликовал на форуме Bitcoin Talk скромную идею: не повысить ли надёжность биткоинов за счёт космоса?

«Я исследовал вопрос повышения надёжности сети биткоин, — говорит Гарзик. – У меня было любительское знакомство с освоением космоса – мой отец брал меня с собой на запуски космического Шаттла, он работал на полигоне Уайт-Сэндс». Гарзик видел два потенциальных пути. Первый: арендовать часть канала на существующем спутнике и передавать через него данные блокчейна. «Но с точки зрения блокчейн-сообщества в этом плане было слишком много точек отказа, и слишком большой риск закрытия», — признаёт он.

Второй вариант – подключиться к идущей революции наноспутников. Гарзик представил себе размещение кольца микрсопутников на орбите вокруг Земли, связанных между собой посредством собственной сети, хранящих и передающих данные по блокчейну.

«Я назвал проект SpaceChain, — говорит Гарзик. – Он был спланирован как самовосстанавливающаяся меш-сеть из множества спутников, способных строить маршруты для данных, обходящие отказы отдельного оборудования и спутников в целом. Мы изучали нечто вроде облачного хранилища, состоящего из множества дешёвых компонентов, в которой отказы оборудования компенсировались программно».

Идея Гарзика быстро вылилась в фонд SpaceChain, и он быстро начал разрабатывать SpaceChain OS, которая должна работать на всех этих спутниках.

Краудфандинг космических кораблей

У SpaceChain OS есть два ключевых компонента. Первый – типичная RTOS на основе ядра Sylix. Гарзик говорит, что Sylix OS активно использовалась в Китае для разных военных и космических целей. В этом смысле она похожа на RTEMS. Помните, что этот акроним сегодня расшифровывается, как Real Time Executive for Multiprocessor Systems, но раньше М обозначала missile, «ракетный». История возникновения Sylix похожа – отличается только страна.

«Её реально подготовили к битвам, — говорит Гарзик, — эта система надёжна, проверена, способна поддерживать самые популярные встраиваемые космические процессоры. Она лёгкая, благодаря чему её легко поддерживать и не допускать появления баков. В ядре Linux порядка пяти миллионов строк кода. Ядро Sylix в пять раз меньше».

Второй ключевой компонент – технология блокчейна, который должен работать в этой сети. Блокчейн позволяет запускать спутники, финансируемые общественностью. Множество компаний, организаций и даже отдельных личностей могут скинуться, чтобы профинансировать спутник с SpaceChain OS на борту. Если Sylix отвечает за работу спутника примерно так, как RTEMS или VxWorks управляют оборудованием современных космических кораблей, то блокчейн-ПО позволяет делить ресурсы спутников между несколькими владельцами.

«Работает это так: чтобы добавить узел в сеть SpaceChain, вам нужно сначала пройти квалификационный процесс в организации SpaceChain, и после этого вас добавляют в белый список», — поясняет Гарзик. «Затем вы можете либо заплатить SpaceChain за постройку вашего спутника, или сделать его самостоятельно на основе открытых спецификаций, общественных стандартов и протоколов – всё, как с интернетом». Далее организация должна запустить спутник или передать это дело в SpaceChain. После успешного вывода спутника на орбиту владельцу нужно заплатить за регистрацию, чтобы получить смарт-контракт блокчейна, позволяющий новому узлу авторизоваться у остальных узлов сети.

Звучит претенциозно, если не сказать – фантастично, однако идея Гарзика, пусть медленно, но развивается. SpaceChain уже вывела несколько биткоин-узлов в космос: в 2018 году с помощью ракеты CZ-4B Y34, а в 2019 – прицепом к SpaceX Falcon 9. Их работа оказалась достаточно интересной, чтобы привлечь инвестиции даже со стороны ЕКА.


Как видите, космос не работает на плохо прифотошопленных версиях Windows 95.

Реакция старой гвардии

Разработка новых космических ОС – концепция, без сомнения, интересная. Но пока что люди, реально запускавшие что-либо к поясу астероидов и за его пределы, скептически относятся к идеям SpaceChain.

«SpaceChain OS не заменит RTEMS, пока не предложит какой-то новой функциональности, которая нам очень нужна, и отсутствует у RTEMS», — говорит Хернек из ЕКА.

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

«Мы не играемся с новыми программами для космоса потому, что это прикольно. У нас всегда есть для этого весомые причины, — сказала Хернек. – Это всегда происходит потому, что имеющееся у нас ПО либо не решает наших проблем, либо причиняет нам проблемы, либо что-то в этом духе».

Кроме того, медленно, но верно винтажные космические ОС подбираются к долгосрочным целям, которых рассуждает Гарзик. Они просто делают это путём инкрементальных изменений. В последней версии VxWorks 7 Wind River ввела несколько новых особенностей, по большей части предназначенных для облегчения и ускорения процесса разработки. Вся система стала чрезвычайно модульной, а у разработчиков появилась возможность испытать разные версии критически важных компонентов типа файловой системы, и посмотреть, какая из них решает их проблему. Не нужно ждать следующего обновления всей системы, как это происходит в случае, например, с macOS. Также компания добавила поддержку продвинутых графических пользовательских интерфейсов, чтобы VxWorks могла работать с сенсорными экранами и другими дружественными дисплеями, которые, вероятно, появятся в кораблях будущего. Подобную функциональность уже реализовали и в RTEMS.

И всё же Хернек признаёт заманчивой идею SpaceChain, когда доступ к спутникам имеет много людей одновременно. «Они утверждают, что нам не хватает функциональности, связанной с доступом многих пользователей, и это действительно так, — говорит Хернек. – Лучшее, на что мы сегодня способны – система с двумя пользователями». Однако по её словам, ЕКА сейчас пытается решить эту проблему через разделение полётных программ. «Мы экспериментируем с частями „интегрированной модульной авионики“ (IMA), позволяющей множеству воздушных судов работать в распределённой сети с поддержкой разных приложений. Эту систему используют в реактивных истребителях 4-го поколения», — поясняет она.

Так что, пока расширяется список причин, по которым нужно запускать аппараты в космос, расширяются и возможности современных ОС, где даже верных сторонников индустрии могут заставить выучить что-то новое выскочки, появляющиеся на интернет-форумах. Прекрасным примером служат Хернек и её команда в ЕКА: сейчас они разрабатывают различные программы, которые позволят реализовать подобную многопользовательскую архитектуру в космических аппаратах.

«Конечно, было бы интересно изучить SpaceChain OS и понять, как они справляются с этой проблемой. Но пока что у нас разделением занимается IMA. Мы дойдём до этого».