Мы часто рассказываем про космические технологии, поскольку в этой сфере активно используются современные изобретения и тестируются новейшие гипотезы, но при этом значительная часть используемых инструментов существует несколько лет, а то и десятилетий. Это касается не только облачных технологий, но и операционных систем. Вот о них Cloud4Y сегодня и расскажет. Поскольку статья большая, мы разбили её на две части. Уверены, вам будет интересно.
Недавно запущенный Европейским космическим агентством (ЕКА) Solar Orbiter проведет годы в одном из самых неприятных мест Солнечной системы: около Солнца. Во время своей миссии Solar Orbiter будет на 10 миллионов километров ближе к Солнцу, чем Меркурий. И, заметьте, Меркурий находится достаточно близко, чтобы температура на обращенной к Солнцу поверхности достигала 450°C. Подробнее о миссии рассказано тут.
Чтобы не сгореть от таких температур, Solar Orbiter использует особый тепловой экран. Однако этот экран будет защищать космический аппарат только в том случае, если он находится напротив Солнца, поскольку — по бокам или позади зонда защиты нет. Соответственно, ЕКА разработало операционную систему реального времени (RTOS) для Solar Orbiter, которая способна работать при очень строгих требованиях. Максимально допустимое отклонение от Солнца составляет всего 6,5 градусов. Любое отклонение, превышающее 2,3 градуса, допустимо только в течение очень короткого периода времени. Когда что-то пойдет не так и будет обнаружено опасное отклонение, у Solar Orbiter будет всего 50 секунд, чтобы среагировать.
«У нас очень высокие требования к этой миссии», — поделилась секретами своей работы Мария Хернек, руководитель отдела систем программного обеспечения для полета в ЕКА. «Обычно перезагрузка такой платформы занимает около 40 секунд. Здесь у нас было всего 50 секунд, чтобы найти проблему, изолировать ее, снова запустить систему и предпринять действия по восстановлению».
Повторим: эта операционная система, находящаяся далеко в космосе, требует удалённой перезагрузки и восстановления работоспособности за 50 секунд. В противном случае Solar Orbiter зажарится до хрустящей корочки.
Чтобы добиться соблюдения столь жёстких сроков, космические аппараты наподобие Solar Orbiter почти всегда управляются операционными системами реального времени, которые работают совершенно иначе, чем те, которые установлены на ваших домашних или рабочих устройствах. Критерии, по которым мы оцениваем Windows или macOS, довольно просты. Они выполняют вычисление, и если результат этого вычисления правильный, то задача считается выполненной правильно.
Операционные системы, используемые в космосе, добавляют по крайней мере еще один базовый критерий: вычисления должны выполняться правильно в строго определенный срок. Если этот срок не соблюден, задача считается невыполненной и завершается. А в космических полётах несоблюдение срока довольно часто означает, что ваш космический аппарат уже превратился в огненный шар или сбился на неправильную орбиту. Нет смысла обрабатывать старые задачи дальше. И облачные технологии, про которые мы писали ранее, здесь помочь пока не в состоянии.
Как решается проблема
Время, измеряемое часами, условно делится на единичные тики (неофициальная единица измерения времени, равна продолжительности одного импульса тактового генератора или часов – прим. переводчика). Чтобы людям было проще, космические операционные системы обычно проектируются таким образом, чтобы каждая задача выполнялась в пределах установленного числа тиков. Для загрузки данных с датчиков может потребоваться три тика; еще четыре тика отданы на запуск двигателей и так далее. Каждой возможной задаче назначается определенный приоритет, то есть задача с высоким приоритетом будет выполняться раньше задачи с низким приоритетом. В результате разработчик программного обеспечения точно знает, какая задача будет выполнена в том или ином сценарии и сколько времени потребуется на её выполнение.
Чтобы сравнить это с известными нам операционными системами, просто посмотрите любое сравнение скорости современных смартфонов. В этом, сделанном EverythingApplePro, iPhone XS Max и Samsung S10 Plus идут ноздря в ноздрю, открывая некоторые популярные приложения. Перед тестом оба телефона перезагружаются, и в них очищается кэш. Samsung открывает все приложения за 2 минуты 30 секунд, а iPhone заработает через 2 минуты 54 секунды. Во втором раунде все приложения закрываются и снова открываются без перезапуска и очистки ОЗУ. Поскольку приложения все еще находятся в ОЗУ, Samsung открывает их за 46 секунд, а iPhone — за 42 секунды.
Это колоссальная двухминутная разница во времени между первой и второй попыткой. Но если бы телефоны должны были работать под управлением операционных систем реального времени, используемых для космических полетов, открытие этих приложений заняло бы одинаковое количество времени, сколько бы раз вы это ни пробовали, — вплоть до миллисекунд.
У космических операционных систем есть много особенностей. Одно дело — работа в реальном времени, другое — детерминизм. Если бы вы предложили одному из создателей смартфонов принять участие в подобном сравнении скорости, попросив его точно предсказать, сколько времени потребуется на полную загрузку приложений, он бы наверняка ответил «понятия не имею». Там могут быть и другие формулировки, вроде «достаточно быстро» или даже «невероятно быстро», но суть одинаковая. Ни iOS, ни Android не являются детерминированной системой. Количество факторов, которые потенциально могут повлиять на результаты скорости, настолько велико, что сделать такие точные прогнозы практически невозможно.
В случае, если на телефоне была установлена ОС космического уровня, в которой известно, что запускается и в какой последовательности, то можно рассчитать точное время, необходимое для выполнения любой задачи. Космическое ПО должно быть полностью предсказуемым и работать в строго определенных временных рамках сроки.
Во времена Apollo операционные системы создавались индивидуально для каждой миссии. Конечно, часть кода использовалась повторно. Например, часть ПО, созданного для программы Apollo, попали в программу Skylab и Shuttle. Но по большей части всё приходилось делать с нуля.
Маленькое отступление
Во время лунной миссии Базз Олдрин и Нил Армстронг оставили включенной антенну радара и указали на командный модуль «Аполлон», вращающийся вокруг Луны. Это было необходимой мерой предосторожности для того, чтобы знать, где находится модуль, на случай, если потребуется прервать посадку. Но оказалось, что радар не переставая загружал компьютер данными, из-за чего память быстро переполнялась. Появившиеся ошибки 1201 и 1202 вызвали панику на Земле. Из-за нехватки памяти программы посадки не могли завершиться вовремя, что, в свою очередь, приводило к цикличной перезагрузке компьютера. Тем не менее, благодаря мерам безопасности, встроенным в ОС, во время этих перезагрузок не было потеряно никаких важных навигационных данных — посадка могла продолжаться по плану. ОС просто выполняла запланированные задачи, продолжая работу с того места, на котором остановилась.
В конце концов, в НАСА стали использовать софт от калифорнийской компании WindRiver. WindRiver выпустила полностью работоспособную операционную систему реального времени под названием VxWorks еще в 1987 году. Хотя VxWorks не была первой системой такого типа, она быстро стала популярной, что и привлекло внимание разработчиков миссии НАСА.
Первым полетом под управлением VxWorks стал зонд Клементина. Еще в начале 1990-х Клементина обозначила попытку НАСА отказаться от гигантских космических программ, подобных Apollo. Всё должно было быть разумным с точки зрения бюджетных вливаний, но при этом хорошо развиваться. В ходе полёта система произвела достаточно хорошее впечатление, чтобы получить ещё один шанс. VxWorks был выбран для миссии Mars Pathfinder.
Не стоит думать, что у этой RTOS всё было замечательно и безоблачно. Из-за ошибки с приоритетами наземная команда НАСА получила массу проблем. Вскоре после приземления система Pathfinder начала перезагружаться без видимой причины, что задерживало передачу собранных данных обратно на Землю. На поиск проблемы ушло три недели и еще 18 часов на её устранение. Проблема оказалась скрытой глубоко в недрах кода VxWorks.
Архитектура VxWorks
В основе VxWorks лежит микроядро. Его задача заключается в управлении всеми взаимодействиями между приложениями, работающими в системе, и оборудованием. Микроядро отвечает за планирование задач со всеми 256 уровнями приоритета, которые могут быть назначены задаче. Поддерживается как упреждающее, так и не вытесняющее циклическое планирование, а также все коммуникации между задачами.
Задачи в системе могут находиться в одном из четырех состояний. Состояние «готово» — это состояние задачи при её запуске. Может либо работать, пока не будет выполнена, либо ей может быть назначено определенное количество времени. Задача переходит в состояние «заблокировано», когда её вытесняет другая задача с более высоким приоритетом или когда для неё закончилось выделенное количество тиков. Третий вариант — это «отложенное» состояние. Задача задерживается, пока она ожидает ресурсов, необходимых для выполнения своей работы (возможно, данных с датчиков). Задержка всегда измеряется таймером, работающим независимо от обработки, обычно это счётчик тиков, постоянно поддерживаемый ядром. Когда такие задержки превышают некоторые установленные значения, система предполагает, что что-то действительно пошло не так, и начинает перезагрузку. Наконец, есть еще четвертое состояние — «приостановлено».
Обмен данными между задачами в VxWorks может осуществляться либо через службу обмена сообщениями, либо через семафоры, которые необходимы для обеспечения блокировки или синхронизации задач. В VxWorks есть два типа семафоров. Первые — это двоичные семафоры, которые могут принимать два значения: «полный» или «пустой». Для задач доступны полные семафоры, а пустые — недоступны. Когда задача запускается, она получает доступный семафор, делая его «пустым» и недоступным для других задач. Когда задача завершает выполнение, она освобождает семафор, тем самым делая его доступным для других задач.
Такие двоичные семафоры используются для синхронизации или блокировки различных задач. Имя «семафор» имеет железнодорожный оттенок, поэтому давайте продолжим его аналогию: представьте себе два поезда, которым необходимо встретиться в какой-то момент для обмена грузами. В реальности VxWorks поезд, которому необходимо забрать груз, создал бы пустой семафор и передал бы его поезду, который в данный момент перевозит этот груз. Как только грузовой поезд выгрузит его в пункте обмена, этот поезд освобождает семафор. Первый поезд (тот, который создал семафор) получает уведомление о том, что семафор доступен, и может забрать груз.
Помимо двоичных семафоров, VxWorks использует взаимное исключение или «мьютекс»-семафоры. Основное отличие этого метода заключается в том, как инициализируется семафор. Двоичные семафоры всегда создаются пустыми. Семафоры мьютексов всегда создаются полными. Задача просто создает полный семафор и немедленно принимает его, тем самым делая его недоступным для всех других задач, пока не завершит всё, что делает. Такие семафоры часто используются для доступа к коммуникационному оборудованию. Задаче необходимо использовать такое оборудование, скажем, информационную шину, до тех пор, пока не закончится передача данных. Прерывание передачи до ее завершения было бы бессмысленным, отсюда и необходимость в мьютексных семафорах.
Это звучит заумно, но так оно и есть. Система семафоров является проприетарной и стала одним из преимуществ VxWorks. Но в течение тех первых нескольких недель, которые Mars Pathfinder провел на Красной планете, ОСРВ всё же с энтузиазмом пошла под откос.
Марсианский жук
«Информационная шина», работающая на борту Mars Pathfinder, была общей памятью, используемой для передачи данных между различными компонентами посадочного модуля. Как и следовало ожидать, эта область стала ресурсом, заблокированным семафором мьютекса. Выяснилось, что причиной загадочных перезагрузок стали три задачи. Первой была высокоприоритетная задача, которая отвечала за управление работой информационной шины. Вторая задача была с низким приоритетом, но она время от времени использовала мьютекс информационной шины для обмена метеорологическими данными. Третий виновник — коммуникационная задача среднего приоритета.
Планировалось, что система будет работать следующим образом: задача по сбору метеорологических данных должна была периодически инициировать мьютекс информационной шины. В случаях, когда задача управления информационной шиной должна была выполняться во время выполнения задачи сбора метеорологических данных, задача с более высоким приоритетом пыталась удержать тот же мьютекс — и поэтому в конечном итоге она блокировалась до тех пор, пока метеорологическая задача с более низким приоритетом не выполнялась. Вроде всё в порядке, поскольку передача данных должна осуществляться от начала до конца. Но вышла третья задача связи средней важности, которая и вызвала проблемы.
Закавыка была в том, что существовала маловероятная последовательность событий, которая могла бы запланировать выполнение задачи со средним приоритетом при выполнении задачи метеорологии с низким приоритетом после того, как она вызвала блокировку высокоприоритетной задачи управления шиной на мьютексе. Для этого оставалось только окно в доли секунды, но когда это происходило, задача со средним приоритетом вытесняла задачу с низким приоритетом. Одна из многих задач, которые остановленный сбор метеорологических данных не мог выполнить случаях, — это передача семафора мьютекса для высокоприоритетной задачи управления шиной. Как следствие, задача со средним приоритетом косвенно блокировала выполнение задачи с более высоким приоритетом, отсюда и инверсия приоритета. И как только независимый таймер, работающий в ядре, замечал, что важный поток не работает, как планировалось, он предполагал, что что-то действительно пошло не так, и инициировал полную перезагрузку.
Перезагрузки происходили примерно шесть раз за две недели, но в конечном итоге VxWorks не были виноваты. Система могла бы справиться с такими проблемами с помощью трюка, называемого «наследование приоритета», которое заставляло низкоприоритетную задачу временно принимать более высокий приоритет другой задачи, которую она только что заблокировала на мьютексе. Если бы наследование приоритетов работало в Mars Pathfinder, задача сбора метеорологических данных просто приняла бы высокий приоритет задачи управления шиной на то время, пока задача управления шиной ждала семафор. Это, в свою очередь, помешало бы задаче связи со средним приоритетом вытеснить его. Все, что нужно было сделать, это включить опцию наследования приоритета перед запуском.
Следовательно, в конце концов, проблемы Pathfinder возникли из-за человеческой ошибки. VxWorks, признанный невиновным, с тех пор использовался практически на всех марсоходах. Спустя всего несколько десятилетий после того, как система стала наиболее широко применяемой ОСРВ на Земле, ей также удалось стать самой популярной операционной системой на Красной планете.
Конец первой части.
Что ещё интересного есть в блоге Cloud4Y
→ Найдено давно утерянное руководство к самому старому компьютеру в мире
→ Пограничный патруль США планирует 75 лет хранить данные из гаджетов путешественников
→ ИИ снова победил пилота F-16 в воздушном бою
→ Рассказываем про государственные защищенные сервисы и сети
→ Внутри центра обработки данных Bell Labs, 1960-е
Подписывайтесь на наш Telegram-канал, чтобы не пропустить очередную статью. Пишем не чаще двух раз в неделю и только по делу
