Dne 12. prosince 2023 oznámila NASA komunikační problémy se sondou Voyager-1. Voyager prováděl přijmuté příkazy ze Země, ale neodesílal zpět vědecká data. Příčinou byl jeden ze tří palubních počítačů Voyageru 1, systém letových dat (FDS – Flight Data System). Počítač FDS nekomunikoval správně s telemetrickou modulační jednotkou (TMU). V důsledku toho nebyla na Zemi posílána žádná vědecká ani technická data. Dne 3. března 2024 zaznamenal tým mise Voyager 1 aktivitu jedné části FDS. Tato aktivita se lišila od zbytku nečitelného datového toku počítače FDS. Díky pomoci specialistů z Deep Space Network se podařilo dekódovat nečitelný datový tok a zjistit, že obsahuje přečtení celé paměti FDS. V následné aktualizaci se již podařilo zjistit primární příčinu problému a pokračovalo se v řešení celého problému. Dne 19. května pak začal Voyager 1 opět posílat vědecká data. Toto je malé shrnutí o potížích, které potkaly sondu Voyager. Dnes se však nebude zabývat problémem Voyageru, ale podíváme se blíže na samotný výpočetní systém sondy.

Srdce operací Voyageru 

Než se začneme postupně více „nořit“ do systému počítačů sondy Voyager, musíme si něco málo říct o historii použité architektury systému. Důvodem, proč se budeme prvně zabývat historií je fakt, že v počátečních úvahách se uvažovalo o dvou možných systémech. Je nutné si uvědomit, že správný návrh a volba architektury systému je kritická. To samozřejmě platí pro každý systém, který se vydá za hranice zemské atmosféry. U sond se však jedná o velmi specifickou situaci, kdy systémy budou celé roky až desetiletí pracovat ve velmi nepřátelském prostředí. V takovém případě je kritické zvolit takovou architekturu, která dovolí další provoz sondy i přes přibývající problémy či řešení problémů v rámci systému.

V roce 1967 zadalo Marshallovo středisko vesmírných letů studii společnosti General Electric Corp. V rámci této studie měla společnost porovnat dvě možnosti vývoje systémů – centrální počítačovou konfiguraci a systém samostatných počítačů pro jednotlivé subsystémy. Při porovnávání obou struktur použila společnost General Electric (dále už jen GE) vysoce matematický přístup s porovnáním výkonnosti, spolehlivosti, rozměrů hardwaru a hmotnosti. U centrální soustavy došla GE k závěru, že hmotnostní úspory systému, které jsou dané menším množstvím hardwaru, jsou vyváženy jeho nižší spolehlivostí, která je omezena právě centrální strukturou. Naproti tomu systém samostatných počítačů, distribuovaná architektura, nabízel vyšší spolehlivost a možnost oddělení úkolů. Jako možnost se ukázalo využití řídicího počítače CCS (Command Computer Subsystem), který byl použit pro program sondy Viking. U Voyageru by však muselo být použito více kusů CCS, aby pokryly potřebný výpočetní výkon. Podle dostupných informací byl i jeden z důvodů požadavek každé sekce JPL (Jet Propulsion Laboratory) na vlastní počítač, údajně proto, aby nedocházelo k „soupeření“ s ostatními skupinami o zdroje. Tímto měl být zachován i klid v JPL, ale stále platilo, že technické výhody systému měly hlavní slovo. Nutno dodat, že k využití hardwaru z programu Viking vedly i škrty v rozpočtu NASA, které nastaly po éře misí Apollo.

Voyager využívá systém tří duálně redundantních počítačových systémů. To v praxi znamená, že každý počítač je zálohován a křížově provázán, což umožňuje odolnost proti poruše, kdy se využije zbývající část funkční zálohy. Systém je tedy složen z:

• CCS   – Computer Command Subsystem/ Systém počítačových příkazů
• FDS   – Flight Data System/ Systém letových dat
• AACS – Attitude Articulation Control System/ Stabilizační digitální systém

Nyní si budeme postupně rozebírat jednotlivé systémy počítačového systému sondy. Ještě nebyl zmíněn systém TMU (Telecommunications Unit), který se stará o kódování a odeslání dat k Zemi a současně o dekódování přijímaných příkazů. Na přiloženém blokovém schématu systému CCS můžete vidět příklad křížového/redundantního provázání procesorů A a B.

CCS – Computer Command Subsystem

Prvním systémem, kterým se budeme zabývat je povelový systém CCS. Jak již bylo řečeno, tento systém byl převzat ze sondy Viking. V podstatě byl identický se svou předlohou, ale s jistými úpravami, které propojily systém CCS se systémem FDS (Flight Data System) a AACS (Attitude Articulation Control System) prostřednictvím binárního kódu. Důvodem využití tohoto počítače byly finanční úspory v konstrukci sondy. V době vývoje byl rozpočet NASA značně zatížen vývojem raketoplánu, což se promítalo do ostatních programů. V rámci povídaní o CSS se nyní budeme věnovat přímo CCS sondy Viking, jelikož CCS pro Voyager 1 byl téměř totožný.

CCS byl využit na základě jeho jednoduchosti a menšího počtu kusů hardwaru. Jednalo se o dvojitě redundantní systém, což znamená, že měl zdvojené napájení, procesory, výstupní jednotky či buffery příkazů, přičemž výstupní jednotky a procesory byly navzájem křížově propojeny, aby v případě poruchy jedné části mohlo dojít k přeřazení činnosti na druhou část. Vstupy do CCS byly shodně rozděleny mezi oba procesory. Tento typ redundance označila JPL jako „single fault tolerance/Odolnost proti jedné poruše“. Toto rozvržení umožňovalo rozsáhlé přerozdělení funkcí v případě potřeby. V praxi bylo samozřejmě výhodné mít dva shodné počítače, ale nebylo pravidlem, aby byly oba počítače zároveň v provozu. Samozřejmě bylo možné využít obou počítačů, pokud byl systém přetížen náporem dat. V takovém případě by systém pracoval ve třech různých režimech.

1. Individuální – Každý počítač pracuje na odlišných úkolech
2. Paralelní – Oba počítače pracují na stejném úkolu společně
3. Tandemový – Oba počítače pracují na stejném úkolu nezávisle

Například při setkání s Jupiterem a Saturnem pracovaly počítače v tandemovém režimu. Samotný procesor byl navržen velmi jednoduše a výkonně a kladl relativně malé nároky na zdroje. Nespornou výhodou procesoru byla možnost přeprogramování během mise, což vedlo k vynechání programovaného sekvenceru a dekodéru. Například během průletu kolem Jupiteru došlo celkem osmnáctkrát k nahrání aktualizace softwaru a během dalších cest bylo běžné přehrávání každé tři měsíce. Došlo také k uložení záložních sekvencí softwaru CCS do sesterské sondy Voyager 2. Tato záloha sloužila pro případ poruchy během letu.

Hlavním úkolem CCS je celkové řízení operací sondy, což zahrnuje:

• Sekvenování programů
• Sledování stavu sondy
• Komunikaci s ostatními počítači
• Nahrávání programů do paměti

Systém CCS má celkem pět ochran proti poruchám (Fault-Protection Algorithms – FPA), které jsou uloženy v paměti.

1. RF Loss – Monitoruje hardware budiče a vysílače v pásmech S a X a přepíná na redundantní jednotku, pokud je zjištěna porucha.
2. Command Loss – Přepne na redundantní hardwarové jednotky pro příjem příkazů ve snaze obnovit schopnost příjmu příkazů, pokud příkaz nebyl přijat ve stanoveném intervalu.
3. AACS Power Code Processing – Sleduje informace o stavu systému AACS a vydává před programovanou sekvenci, což je reakce v případě anomálií systému AACS, tedy uvedení do bezpečného provozu
4. CCS Error – Reaguje na kritické anomální stavy hardwaru a softwaru CCS. Reakce obvykle zastaví všechny probíhající sekvenční činnosti, uvede CCS do základního stavu a čeká na akci z  řídicího střediska.
5. Power Check – Reaguje na výpadek detektoru tolerance CCS nebo stav podpětí v kosmické lodi přepnutím na redundantní hardware ve snaze izolovat elektrickou poruchu a poté v případě potřeby eliminovat zátěž napájení předem stanoveným způsobem.

Systém CCS je tedy zodpovědný za řízení celkových operací, včetně sekvenování programů, sledování stavu sondy, komunikaci s ostatními počítači a nahrávání programů do paměti.

FDS   – Flight Data System

Nyní se budeme věnovat systému letových dat, o kterém mohli čtenáři slyšet posledních několik měsíců asi nejčastěji. Právě tento systém byl zdrojem problémů, které postihly sondu. Postupným zkoumáním se podařilo zjistit, že došlo k poškození části paměti jednoho ze tří kusů FDS. Expertům se podařilo zjistit, že jediný čip zodpovědný za ukládání části paměti systému FDS (včetně softwarového kódu počítače FDS) nefunguje. Absence tohoto kódu způsobila nepoužitelnost vědeckých a inženýrských dat.

Tolik krátké shrnutí k problémům s FDS. Samotný systém se stará o shromažďování dat z vědeckých přístrojů a technických dat o stavu sondy, která se pak spojí do jediného datového „balíčku“, který prostřednictvím telemetrické modulační jednotky TMU pošle k Zemi. Systém přenosu je schopen pracovat ve dvou režimech. V prvním režimu se jedná o přímý přenos dat, který ovšem vyžaduje vysokou rychlost, aby nedošlo k jejich ztrátě. V druhém režimu se data nahrají do DDS (Data Storage System) a teprve poté se odesílají. V praxi to znamená, že se data uloží na magnetofonový pásek. Tento režim se využívá v případech, kdy není možné odeslat data přímo k Zemi. Příkladem může být nezdařené navázání spojení se sledovací stanicí. Vysoká přenosová rychlost byla klíčová pro provoz sondy, protože vědecké vybavení a jeho rozlišení se stávalo sofistikovanější a zvyšoval se tak nárok na datový tok přenosu.

Základem FDS se stala volatilní paměť CMOS. Pro zajímavost uvedu, že se mělo jednat o první počítač s tímto typem paměti. Tento typ obvodů má velmi nízkou spotřebu energie, je rychlý a snáší široký rozsah napětí. Přesto se tomuto typu „nestálého“ obvodu konstruktéři předchozích pilotovaných i nepilotovaných misí vyhýbali pro jeho jistou nevýhodu – citlivost na ztrátu napájení. To znamená, že pokud dojde ke ztrátě napájení, dojde ke ztrátě paměti. Z tohoto důvodu došlo k přímému propojení s radioizotopovým generátorem dodávající DC napájení. V průběhu vývoje panoval názor, že pokud dojde k poškození či vyřazení radioizotopového generátoru z provozu, počítač FDS by pravděpodobně už nebyl potřeba.

Na začátku návrhu FDS stál inženýr Jack L. Wooddell, který definoval prvotní návrh a určil seznam funkcí, které měl navrhovaný počítač poskytovat. Funkce zahrnovaly:

• Odesílání řídicích signálů pro sekvencování vědeckých přístrojů
• Schopnost zpracovat širokou škálu datových rychlostí a formátů z různých přístrojů
• Možnost přepracování mise v jejím průběhu (Nahrání nového programu či úprava)
• Technická telemetrie a udržení spolehlivosti (Žádná ztráta dat z více vědeckých přístrojů při jedné poruše)

V průběhu vývoje řešil Wooddell několik kompromisů mezi softwarem a hardwarem. Jeden z příkladů může být určení funkcí, které mohou být zpracovány hardwarem a který by měly být ponechány flexibilitě softwaru. Dalším krokem v návrhu byla tvorba sady instrukcí, V této fázi navázal Wooddell spolupráci s programátorem Richardem J. Ricem působícím v JPL. Právě Rice se začal věnovat návrhu softwaru. Prototyp letového programu vyvinutého Ricem umožnil zdvojnásobit rychlost procesoru. Zdvojnásobení rychlosti umožnilo přidání obvodu pro přímý vstup k paměti, což znamenalo,  že některá data mohla být odeslána přímo do paměti, aniž by šla přes procesor. Dalším důležitým krokem řešící rychlost byla již zmíněná volatilní paměť.

Nyní si dovolím citovat fakta o FDS z Computing in Spaceflight: the NASA experience. FDS sám o sobě vyžaduje 14 wattů energie při hmotnosti 16,3 kilogramů. Počítač potřebuje pouze třetinu výkonu při napájení 10 voltů, což je méně než energie potřebná pro teplotní senzor. Zpočátku byla odhadovaná požadovaná propustnost 20 000 16bitových slov za sekundu. V době letu byla datová rychlost byla 115 000 bitů za sekundu, což je mnohem více než u předchozích letových datových systémů. Architektura dvou procesorů a dvou pamětí řídicího počítače a počítače pro řízení polohy se opakuje v datovém počítači. V případě poruchy nebylo zajištěno automatické přepnutí. K rekonfiguraci je nutný příkaz ze Země směrovaný řídicím počítačem. Zde je nutné upozornit, že počítač pro řízení polohy může být přepnut řídicím počítačem bez zásahu ze Země, protože je nutné zachovat požadovanou orientaci sondy. V dalším kroku bylo potřeba definovat několik funkcí, jako například základní časování sondy. Další důležitý bod je možnost čtení paměti všech tří počítačů na příkaz z řídicího počítače. Vývoj softwaru vlastně neskončil vypuštěním sondy, jedná se o proces, který nikdy neskončil. Některé programy byly vyvíjeny záměrně až po startu. Příkladem může být program řešící setkání se Saturnem. V tomto případě se jednalo především o komunikační rozsah a nastavení vědeckých přístrojů.

Je vhodné zmínit se o další důležité osobě z vývoje Voyageru. Don Johnson, inženýr, který stanovil požadavky a rozhraní s vědeckými přístroji. Programátor Rice ho nazýval „pan PDS“ a tvrdil, že Johnson často věděl o vědeckém vybavení mnohem více než samotní vědci. V dalším odstavci si dovolím opět citovat Computing in Spaceflight z důvodů jasného vysvětlení tématu paměti sondy.

V roce 1976 stanovil Frewing, inženýr softwarového systému, limit 90 % kapacity paměti. Ačkoli bylo toto omezení později zrušeno, svědčí o raných obavách softwarového managementu z přetížení paměti. Vzhledem k tomu, že stroj může přímo adresovat dolních 4 kB paměti, měly být programy uloženy právě tam, zatímco horní část měla sloužit pro přechodná data. Později se letová konfigurace počítače vyvinula tak, že jeden procesor přistupoval k oběma pamětem. Proto je kopie programů uložena v dolní části každé paměti, ale obě horní části může jeden procesor používat jako pracovní paměť. Pokud je vyžadován duální režim, jsou paměti odděleny. Zkušenosti vedly ke zvýšení důvěry v paměti. Zpočátku bylo při aktualizaci nutné odesílat kompletní soubory, ale v poslední době je možné do programů vkládat části softwaru. Plná redundance mezi paměťmi nyní není automaticky udržována.

AACS – Attitude and Articulation Control System

Jak napovídá samotný název, jedná se o systém určující orientaci a směrování sondy k Zemi. Počátek vývoje stabilizačního systému sahá už do období sond Mariner a Viking. U Voyageru se NASA rozhodla v roce 1972 financovat studii systémů pro řízení polohy vesmírných zařízení. Výsledkem studie bylo použití konfigurace analogového a digitálního programovatelného systému s označením HYPACE (Hybrid Programmable Attitude Control Electronics). Dále citace z Computing in Spacefligh:

HYPACE používal stejnou 4K, 18bitovou paměť s pokovenými vodiči jako počítač Viking Orbiter a navíc přidal tranzistor-tranzistorovou logiku (TTL) středně velkých integrovaných obvodů, aby vytvořil relativně rychlý (28mikrosekundový cyklus) procesor s indexovými registry pro adresování. Byte-sériová architektura byla možná, protože čipy TTL byly navrženy pro 4bitový paralelní provoz, takže 18bitová slova mohla být přesouvána v pěti cyklech namísto 18, které by potřeboval sériový stroj, což zvýšilo celkovou rychlost. Indexové registrování znamenalo, že stejný blok kódu mohl být použit pro všechny tři osy, což snížilo požadavky na paměť.

Voyager měl být první sondou s tímto systémem a budoucí sondy měly těžit právě z tohoto systému. Další skutečností pro nový systém byla rozdílná konstrukce Voyageru oproti  předchozím sondám. Přesněji řečeno, rozdílná především v tuhosti konstrukce, kdy došlo k umístění radioizotopového generátoru na předsunutý nosník (eliminace ovlivnění vědeckých přístrojů radiací). To samé platilo pro magnetometr, který byl také na předsunutém nosníku a další. Toto uspořádání vedlo k výrazně menší tuhosti konstrukce, která byla pak citlivější na práci stabilizačního a orientačního systému, tzn. jisté „chvění“ nosníků při práci trysek a s tím spojené ovlivnění polohy.

V průběhu vývoje systému AACS panoval značný tlak na využití starší a již osvědčené technologie. Samozřejmě svou roli hrály i finance, protože změnou konfigurace bylo možné ušetřit až 300 000 dolarů. Plán byl prostý, využít stejného počítače, jako u sondy Viking a to ve všech systémech Voyageru. AACS mohl využívat CCS počítač, ale rozhodně ho nebylo možné použít pro FDS kvůli jeho vysokým požadavkům na vstup a výstup dat. Projektový tým se tak musel rozhodnout, kterou variantu zvolí. Rozhodnutí padlo na počítač CCS, a to hned ze dvou důvodů:

1. Vyhnutí se nákladům na nový vývoj
2. Přeškolení personálu

Kancelář vývoje AACS však měla i podmínky k použití CCS, a to  jeho zrychlení. Výkonný počítač pro řízení polohy se lišil od povelového systému CCS i od počítače Flight Data System. Počítač pro řízení polohy potřeboval spouštět podprogramy s různou rychlostí, což vyžadovalo několik cyklů, jako v případě misí Apollo, Skylabu a raketoplánu. Oddělení Guidance and Control požadovalo taktovací frekvenci 1 megahertz, ale v realitě se dostali na i tři čtvrtiny této hodnoty. Inženýři také přidali indexové registry, které se osvědčily během experimentu HYPACE. Programátoři měli velmi náročnou práci, vzhledem k pomalému procesoru a omezené paměti. Při startu sondy zbývala v 4K paměti pouze dvě slova volného místa. Nedostatek paměti je tak nyní problémem i kvůli opotřebení trysek.

Vývoj softwaru pro Voyageru pokračoval až do konce 80. let. Inženýři, kteří byli úzce spojeni s vývojem hardwaru počítačů, se poté věnovali už dalším projektům. Richard J. Rice a jeho kolegové dále pokračovali v programovaní systému CCS a AACS. Postupně připravovali Voyager 1 a 2 na důležité milníky misí sond. Sondy od svého vzletu překonaly značné vzdálenosti, které mají přímý vliv i na šířku přenosového pásma. Šířka pásma se postupně zmenšovala a nyní načítání dat trvá hodiny. V létě 1984 trvalo načtení softwaru letového datového systému 4 hodiny. Tyto skutečnosti vedly vedoucí projektu Voyager v roce 1984 k rozhodnutí poprvé použít letový datový systém FDS v režimu využití dvou procesorů pro setkání s Uranem. Důvodem bylo zajištění komprese obrazových dat. Informační obsah tak zůstal na vysoké úrovni, i když byla přenosová rychlost výrazně snížena.

Cílem článku byl hlavně základní popis hlavní výpočetní struktury sondy Voyager. Konstruktéři museli řešit, stejně tak jako i v jiných projektech, mnoho technických překážek a stálý tlak na úsporu financí. Struktura Voyageru umožňuje dodnes, díky promyšlené práci konstruktérů a programátorů, stálé odesílání dat a především možnost řešit závady systémů. Pro čtenáře, kteří by se rádi více ponořili do tématu výpočetní techniky vesmírných zařízení, mohu doporučit publikaci Computing in Spaceflight: the NASA experience.

Zdroje informací:
Computers in Spaceflight, The NASA Experience , Autor James E. Tomayko, Rok vydání 1988
Voyager Telecommunications, Autor Roger Ludwig a Jim Taylor, Rok vydání 2002
VOYAGER DESIGN STUDY VOLUME I DESIGN SUMMARY, Autor GENERAL@ ELECTRIC, Ro vydání 1963
allaboutcircuits.com
hackaday.com/
fosstodon.org/

Zdroje obrázků:
denik.cz/
allaboutcircuits.com/
allaboutcircuits.com/
wikimedia.org/wikipedia/
cdn.fosstodon.org/
theguardian.com/science
airandspace.si.edu/
.wikimedia.org/