У чому вбудовано програмне забезпечення Mars Curiosity Rover?

Марс Curiosity марсохід успішно приземлився, і один з промо - відео «7 хвилин жаху» хвалиться там бути 500000 рядків коду. Це складна проблема, без сумніву. Але це дуже багато коду, безумовно, за ним стояло досить велике зусилля програмування. Хтось знає щось про цей проект? Я можу лише уявити, що це якась вбудована С.

Він працює на 2,5 мільйона ліній C на процесорі RAD750 виробництва BAE . JPL має трохи більше інформації , але я підозрюю , що багато деталей не розголошують. Здається, сценарії тестування були написані в Python.

Основною операційною системою є VxWorks RTOS від Wind River . Розглянутий RTOS можна запрограмувати на C, C ++, Ada або Java. Однак стандартні для ОС тільки C і C ++, Ада та Java підтримуються розширеннями. Wind River надає величезну кількість деталей щодо того, як виходити і хотіти VxWorks .

Основний чіпсет майже абсурдно надійний . Спочатку його характеристики можуть здатися не дуже схожими, але дозволяється мати один і лише один "блюскрін" на кожні 15 років. Майте на увазі, це знаходиться під обстрілами від радіації, яка вбивала б людину багато разів. У космосі надійність виграє над швидкістю. Звичайно, така надійність приходить дорожче. У цьому випадку це круті від 200 000 до 500 000 доларів.

Програміст Erlang розповідає про особливості комп’ютерів та кодової бази в Curiosity.

Код ґрунтується на принципі MER ( Spirit and Opportunity ), який базувався на першому землевласнику, MPF ( Sojourner ). Це 3,5 мільйони ліній С (значна частина його автогенерована), що працює на RA50-процесорі виробництва BAE та операційної системи VxWorks . Понад мільйон ліній було кодовано вручну.

Код реалізований у вигляді 150 окремих модулів, кожен з яких виконує різні функції. Сильно зв'язані модулі організовані в компоненти, які абстрагують модулі, які вони містять, і "задають або конкретну функцію, діяльність або поведінку". Ці компоненти далі організовані в шари, і їх "не більше 10 компонентів верхнього рівня".

Джерело: Основна бесіда Бенджаміна Кіші на семінарі-практикумі з програмного забезпечення польотів космічних кораблів 2010 року (FSW-10) , слайдів, аудіо та відео (починається з огляду місії, обговорення архітектури на слайді 80).

Хтось із новин Hacker News запитав "Не впевнений, що означає, що більшість кодів C створюється автоматично. З чого?"

Я не впевнений на 100%, хоча, ймовірно, є окрема презентація в тому році чи іншому році, яка описує процес їх автоматичного генерування. Я знаю, що це була популярна тема взагалі на конференції ЖКС-11.

Simulink - це можливість. Це компонент MATLAB, популярний серед інженерів-механіків, а тому більшість інженерів навігації та управління, і дозволяє їм «кодувати» та імітувати речі, не думаючи, що вони кодують.

Модельне програмування - це, безумовно, річ, про яку галузь поступово усвідомлює, але я не знаю, наскільки добре це стосується JPL або якщо вони вирішили би використовувати її під час запуску проекту.

Третя і найімовірніша можливість - це код зв'язку. З усіма космічними системами вам потрібно надсилати команди до польотного програмного забезпечення від наземного програмного забезпечення та отримувати телеметрію від польотного програмного забезпечення та обробляти його наземним програмним забезпеченням. Кожен пакет команд / телеметрії є неоднорідною структурою даних, і необхідно, щоб обидві сторони працювали з точно однакового визначення пакету, і відформатували пакет так, щоб він був правильно відформатований з однієї сторони і проаналізований з іншого боку. Це передбачає правильну роботу багатьох речей, включаючи тип даних, розмір та витривалість (хоча останні зазвичай є глобальною річчю; у вас може бути кілька процесорів на борту з різною витривалістю).

Але це лише поверхня. Вам потрібно багато повторюваних кодів з обох сторін, щоб обробляти такі речі, як реєстрація, перевірка команд / телеметрії, перевірка меж та обробка помилок. І тоді ви можете робити більш складні речі. Скажімо, у вас є команда встановити значення апаратного регістра, і це значення буде відправлено назад в телеметрії в певному пакеті. Ви можете створити наземне програмне забезпечення, яке відстежує цю точку телеметрії, щоб гарантувати, що коли встановлено це значення регістру, з часом телеметрія зміниться, щоб відобразити зміни. І звичайно, деякі точки телеметрії важливіші за інші (наприклад, струм основної шини) і призначені для спускання в декількох пакетах, що передбачає додаткове копіювання на стороні польоту та дедублювання даних наземній стороні.

З усім цим набагато простіше (на мою думку) написати одну колекцію статичних текстових файлів (у XML, CSV або деяких DSL / що-у вас є), запустити їх через сценарій Perl / Python та presto! Код!

Я не працюю в JPL, тому я не можу надати жодної деталі, яка відсутня у відео, за одним винятком. Я чув, що автогенерований код C записується сценаріями Python, і кількість автокодування в проекті сильно змінюється в залежності від того, хто веде FSW.