Дали сте се запрашале што е потребно и како изгледа софтверот кој ги придвижува вселенските летала и целата логистика за мисии во вселената? Не толку одамна дел од тимот на Stackoverflow имаше можност да интервјуира дел од инженерските и софтверските тимови на SpaceX. Стивен Гeринг е лидер во тимот кој го развива софтверот за вселенската капсула Dragon.
Уште од првите летови софтверот кој се користел во леталата, но и на земја бил клучен дел од напредокот на вселенските мисии. Сепак од она што може да го прочитаме на блогот на Stackoverflow, во SpaceX и Starlink ова е подигнато на сосем ново, и повисоко ниво. Со оглед на тоа дека од минатата година Falcon 9 ракетите се користат и за транспорт на екипаж во вселената, ова е и разбирливо. На 24 април 2021 година првиот екипаж кој летал со Falcon 9 пристигна на Меѓународната вселенска станица.
Програмскиот јазик во кој е напишан софтверот кој се користи во леталата и капсулите на SpaceX е C++. Компанијата го користи од почетоците. Софтверот може да прочита текст фајлови за конфигурација, a софтверските инженери во SpaceX креирале едноставен специјализиран јазик за нивната апликација. Ова овозможува софтверот да може едноставно да го користат и инженерите кои не се програмери.
Концептот на кој работи софтверот на SpaceX е контролен циклус. Во првиот дел се преземаат влезните податоци. Од „Air Data Computer (ADC)“ се преземаат информациите од сензорите кои се читаат преку него; се добиваат пакетите од мрежата; податоците од „Inertial measurement unit“ (IMU); апдејти од сензорите за наведување; команди од контролата. Компјутерот потоа ги процесира овие информации и ја утврдува новата состојба; локацијата; состојбата со „одржувањето на живот“ (life support)… Овие податоци се запишуваат и во следниот чекор од циклусот, сè започнува од почеток, вели Геринг.
Карактеристично за системот е што сите процеси не се со иста фреквенција на циклусот. Некои од циклусите се со брзина од 10 Hz, а некои со брзина од 50 Hz. Главниот компјутер за лет на пример е со фреквенција од 10 Hz, дел од командните компјутери треба да реагираат побрзо и тие се со фреквенција 50 Hz.с
Целта е леталото да биде во целост автономно и да може да пристигне и да се поврзе со вселенската станица без човечка интервенција. Сепак оставен е простор и пилотот да преземе контрола ако тоа е потребно.
Сензори
Има најразлични машини, опрема и сензори кои се во постојана комуникација со главниот компјутер. Податоците за параметрите кои влијаат на состојбата најчесто се добиваат преку сензори. Дел од сензорите мерат надворешни параметри, а дел од сензорите мерат што се случува во кабината. На пример дел од важните информации кои се отчитуваат од внатрешноста се концентрацијата на CO2 и кислород, колкава е температурата, притисокот. Овие информации се важни за здравјето на посадата.
Дел од надворешните сензори се важни за навигацијата. GPS, уредот за мерење инерција (IMU), сензорите за следење на ѕвезди, помагаат за навигацијата.
Овие податоци може да се обработат или да се користат необработени. На пример нема потреба да од посебна обработка за измерената температура во кабината, па овој податок само се покажува. Друг дел од податоците можеби треба да оди на обработка и процесирање пред да биде прикажан како релевантен податок за посадата и тимот кој управува со работата.
Во текот на тестирањата информациите од леталото се испраќаат преку директна врска. Ова секако не може да се користи по полетувањето, па во овој случај сите информации се испраќаат безжично, преку системи кои можат независно да испраќаат различни информации кон тимовите на земја.
Што ако има грешка?
Со оглед на потенцијалните последици од грешка во системот речиси е недозволиво да се дозволи софтверски баг. Токму поради ова дури и поголем дел од работата е тестирање, верификација и валидација на софтверот.
Ако се појави некоја грешка тогаш таа мора да влијае на минимален број на системи. Потенцијалното влијание на оваа грешка мора да биде речиси во целост изолирано на зафатениот систем.
Секако постои цел сет на кодови за грешки кои им помагаат на операторите да имаат целосен увид во состојбата на леталото.
„Секогаш ги проверуваме кодовите на грешките и повратните вредности. Ако затреба операторите и екипажот можат да отфрлат различни делови од алгоритамот“, вели Геринг.
Геринг кој претходно бил дел и од тимот на Google раскажува и за разликата помеѓу софтверот во двете компании.
Во Google сакате процесите да престанат ако има некоја аномалија. Ако повеќе процеси престанат да работат инженерите треба да ја проверат причината за ова.
Во SpaceX навистина не сакаме нашите процеси да престанат како резултат на грешка на софтверот. Подобро е софтверот што всушност не е зафатен да продолжи да работи. Сè уште треба да знаеме за таа грешка, и тука е вклучена телеметријата, но сакаме работата да продолжи, контролирајќи ја најдобро што можеме“.
Стани премиум член и доби пристап до сите содржини, специјален попуст на над 2.200 производи во ИТ маркет, верификуван профил и можност за огласување на ИТ Огласник. Плус ќе го поддржиш медиумот кој го градиме цели 16 години!
Доколку веќе имаш премиум членство, најави се тука.
