Мабуть з теми ви вже здогадались що мова про SpaceX та їх ракети Falcon й корабель Dragon.
Компанію, що повернула людству цікавість до космосу.
Мені ж, як інженеру з забезпечення якості, завжди цікаво було що там в них з софтом, й власне якістю 🙂
Натрапив на вихідних на одне відео на ютубі, поділюся з вами тими моментами, що окрім звичайної зацікавленості викликають ще й професійну.
🚀 Залізо
В космосі електронні системи мають бути надійно захищені від радіації. Якщо спростити, то є два шляхи досягнути потрібного рівню надійності: 1) використовувати дійсно захищене від радіації залізо 2) використовувати “звичайне” залізо, але надлишково його дублювати.
Перший підхід надає високий рівень відмовостійкості, але він не для SpaceX, тому що по перше: спеціальні радіаційно захищені процесори не тільки доволі повільні, але й дуже багато коштують (наприклад 200-300.000$ за 1 IBM RAD6000 CPU – такий встановлений на марсіанських роверах Spirit та Opportunity), по друге, що навіть важливіше: такі процесори мають свою власну архітектуру й дуже обмежену кількість інструментів й відповідно інженерів, які знаються на них.
Тому SpaceX обрала другий підхід: надмірне дублювання систем. Якщо бути точним – потрійне.
Dragon має три двоядерні x86 CPU, які постійно виконують одні й ті самі задачі, перевіряючи чи не схибив бува один з них із обчисленнями. Якщо один схибив – він одразу ж перезавантажується й синхронізується з двома іншими для продовження роботи. Окрім CPU в кораблі є ще 18 систем, що мають процесори – всі вони також трикратно дубльовані.
Falcon9 так само має по 3 процесори на кожну систему: CPU – 3 процесори + на кожен з 9 двигунів по 3 процесори.
🚀 Софт
Оскільки SpaceX обрала “звичайні наземні” процесори для своїх ракет та корабля, то й в якості ОС – очікувано Linux. Як на комп’ютерах розробників, так й в кораблях, й ракетах. Мова програмування – C++.
Цікаво (й логічно), що SpaceX намагається перевикористовувати якомога більше коду між Falcon9, Falcon Heavy та Dragon – це дозволяє фіксити один баг відразу в трьох девайсах 🙂
Було б дивно, якби в SpaceX не практикувався Continuous Integration – код збирається та тестується юніт-тестами.
Щодо тестів – велика їх частина (нажаль достеменно невідомо яка саме) робиться на актуальному апаратному забезпеченні, але про це нижче.
🚀 Моніторинг
Моніториться все – тобто логи пишуться на кожну дрібничку. До того ж, якщо система моніторингу вбачає відхилення якоїсь метрики від цільових показників на одному з пристроїв, то логи разом із версією софта, притаманною саме цьому пристрою, вивантажуються в спеціальне тестове середовище для аналізу.
🚀 Тестування
Кому доводилось тестувати системи, які безпосередньо взаємодіють із “залізом”, тому напевно знайомий такий термін як “тестовий стенд”. В моєму досвіді “тестовим стендом” були як дошки ДСП з прикрученим контролером дверних замків, так і повноцінна ізольована кімната-лабораторія з купою різних пристроїв для системи відеоспостереження.
SpaceX звісно також має купу різноманітних тестових стендів. Й варіюються вони так само – від десятків процесорів на чиємусь робочому столі (ще пам’ятаєте про вартість процесорів як один з чинників обраного підходу?) до повністю зібраних до купи електронних компонентів ракети Falcon9, з якими можна провести повноцінну симуляцію польоту для знаходження потенційних проблем.
Нажаль це поки що все.
Відео, якщо захочете подивитись – тут.
Перелік першоджерел для відео – тут.
Сподіваюсь вам було так само цікаво як й мені 🙂
Тема “Тестування в SpaceX” взагалі цікава, якщо маєте ще якусь інформацію – поділіться будь ласка.