Dr Piotr Dziuban, dyrektor Inżynierii Creotech Instruments, w rozmowie z ISBtech o projekcie satelity EagleEye, rozwiązaniach, która spółka opracowała dla swojej platformy satelitarnej i ewentualnej polityce patentowej.
Po osiągnięciu space heritage planujecie ogłaszać plany wypuszczania kolejnych satelitów?
W tej chwili pipeline mamy zapełniony mniej więcej na 6 lat do przodu. Teraz poleciał EagleEye, w przyszłym roku lecą trzy kolejne z konstelacji Piast i to będzie duże wyzwanie, bo trzeba będzie jednocześnie trzy satelity zbudować, przygotować, zintegrować, zawieść do USA i przygotować do startu.
Mamy plany na kolejne misje, ale to też zależy od decyzji niezależnych od nas. Jest kilka dyskusji już mocno zaawansowanych z Europejską Agencją Kosmiczną. Dla nich robimy kilka projektów i jest duża szansa, że to się przerodzi się w pełnoprawne, duże misje kosmiczne.
Projekty space żyją swoim cyklem i zanim dojdzie do tego etapu, gdzie już możemy mówić, że lecimy, to zawsze muszą być pierwsze fazy koncepcyjne, na których będziemy decydować, nie tylko my, ale też głównie sponsorzy, czy jest sens, czy jest zasadność finansowania takiej misji. Jest zawsze złożony proces.
My już jesteśmy mocno zaawansowani. W tej chwili dostaliśmy projekt dla ESA na fazę C, gdzie już wykonujemy hardware. Mamy pokazać nie tylko koncepcyjne prace, ale prace już fizyczne, już stojące na biurku i działające.
Na tej samej zasadzie mamy jeszcze kilka wstępnych koncepcyjnych projektów, w kilku uczestniczymy przy targach. Na obecną chwilę 6 lat do przodu jest zapełnione, jeżeli chodzi o różne fazy misji, które powinny przerodzić w formalne misje, czy to w niski, czy w daleki kosmos.
ZOBACZ RÓWNIEŻ:
Najnowszy wywiad z prezesem Creotech Instruments Grzegorzem Broną z 6 września
Czy testowaliście wcześniej połączenie waszego mission roomu z satelitą przed wyniesieniem?
Zanim zdecydowaliśmy, że wywozimy satelitę do USA, przeszedł bardzo mocne testy. To co najczęściej zawodzi to jest właśnie łączność i zasilanie.
Dwa głównie elementy były bardzo mocno testowane. Zasada brzmi w ten sposób, że ostateczny test łączności odbywa się między satelitą, a anteną, która w naszym przypadku albo jest na dalekiej północy na Svalbardzie, albo na dalekim południu w bazie Troll na Antarktydzie.
To są nasze dwie główne stacje. Siłą rzeczy nie można tam zawieść satelity i przetestować czy to działa. Natomiast firma, która udostępnia te stacje naziemne, przywiozła tu analog stacji naziemnych w postaci dużej skrzyni. I myśmy przetestowali działanie satelity, łącząc się z tym analogiem – wzornikiem stacji naziemnej. Dokonaliśmy walidacji tego łącza. Połączyliśmy się z nawet naszym centrum sterowania.
To było przepuszczone przez całe łącze internetowe dokładnie w takim sam sposób jak będzie docelowo. Sprawdziliśmy po kolei wszystkie elementy, wszystkie routery po drodze, wszystkie, VPN-y, wszystko co jest potrzebne do tego, żeby połączyć się ze stacją.
Co jest ważnego w Pana ocenie w procesie wyniesienia EagleEye, co jeszcze nie wybrzmiało, a jest warte podkreślenia?
O EagleEye zostało powiedziane i bardzo dużo i nadal za mało. Można spędzić tygodnie na dyskusjach. EagleEye należy traktować jako pierwszy test technologii opracowanej tu w Polsce i to trzeba zaznaczyć, że kluczowe komponenty, software – największy know-how firmy – jest tu w Polsce wymyślony i wyprodukowany.
To dowodzi tego, że w Polsce można zbudować tak zaawansowane satelity. Bo to jest w tej chwili najbardziej zaawansowany satelita skonstruowany w Polsce. Do tej pory projekty satelitarne opierały się na standardzie CubeSat.
CubeSat jest dobrze określonym standardem, w którym właściwie trochę jak klocki Lego można poskładać własnego satelitę. Nie umniejsza to ich roli jako podmiotom, które zrealizowały misję, bo duża część tych misji naprawdę była całkowicie nową jakością, zwłaszcza w Polsce.
Natomiast my poszliśmy krok dalej. Zrezygnowaliśmy z podejścia CubeSat, które ma być tanie, ale jednocześnie relatywnie ryzykowne. Operuje na gotowych podsystemach, które są wręcz sprzedawane prawie jak klocki Lego w sklepie.
Nie dążymy do tego, żeby być dostawcą robiącym na wielkie misje w stylu ESA czy NASA, bo to jest zabójcze głównie jeżeli chodzi o czas i pieniądze. Myśmy się skoncentrowali gdzieś w połowie, to znaczy czerpiemy co najlepsze z dużego, starego space i bierzemy co jest rozsądne z New Space. W związku z czym jesteśmy w stanie zrealizować taką misję relatywnie szybko i relatywnie tanio. Jednocześnie jesteśmy w stanie zapewnić jakość czy choćby systemy łączności i zgodności do protokołów komunikacyjnych z tym, co nakazuje nam Europejska Agencja Kosmiczna.
Centrum Sterowania Misji, które przygotowaliśmy, jest dopiero początkiem. Dlaczego? Bo będziemy je skalować. Ono jest na razie małym centrum, ale ono już w tej chwili może zostać użyte do sterowania satelitami Europejskiej Agencji Kosmicznej i odwrotnie. My działamy na tym samym oprogramowaniu.
Więc jeżeli przychodzi do nas ESA, czy jakakolwiek inna licząca się agencja kosmiczna, która operuje na tych samych standardach co Europejska Agencja Kosmiczna (a nawet NASA już w tej chwili się powoli dostosowuje do tego samego standardu) to my jesteśmy w stanie zapewnić rozwiązanie, które jednocześnie jest konkurencyjne pod względem cenowym, a do tego jeszcze zgodne z ich wymaganiami. I to można traktować jako game changer w sytuacji, w której Europejska Agencja Kosmiczna szukając klientów, dostawców w Polsce, czy nawet w tej części Europy. Zwłaszcza że rozwiązania Cubesat nie spełniają jej wymagań. My mamy rozwiązania do tego, ich standardu. To chyba jest jedna z takich najważniejszych rzeczy, jeżeli chodzi o to, co reprezentuje sobą EagleEye i nasz standard HyperSat.
Creotech jest po prostu deweloperem nowej platformy, nowego standardu.
To jest nasz standard. Natomiast oparliśmy się na wymaganiach, Europejskiej Agencji Kosmicznej, ich opisach protokołów komunikacyjnych, wymaganiach jakościowych, wymaganiach dotyczących jak zrealizować projekt. Wybraliśmy te, które są najbardziej potrzebne i zostało to zaaprobowane przez odpowiednich ludzi.
Zrobiliśmy coś, co jest jednocześnie relatywnie tanie, relatywnie łatwe w implementacji, elastyczne. Jak trzeba zbudować małego satelitę rozmiaru Piasta oraz dużego satelity, który waży 150-200 kg, używamy tej samej elektroniki, tego samego programowania, tego samego centrum kierowania misji.
Czy o tym software możemy też coś więcej powiedzieć? Rozumiem, że to też jest wewnętrzny development spółki.
Spółka jest w całości właścicielem całego IP software’owego. To co ma robić software, to po pierwsze zarządzać, tak zwanym scheduler’em, czyli tym, gdzie wrzucamy do kolejki rzeczy, które mają być wykonane. Satelita ma wykonać konkretną listę rozkazów. To nie jest autonomiczna sonda, która leci na Marsa, która ma przygotować, reagować w pewien sposób. Owszem, pewne podstawowe reakcje automatyczne zostały zaimplementowane, ale zasadniczo operujemy na tym, że człowiek ma kontrolę nad satelitą.
Druga rzecz – satelita ma niejako trochę jak nasz autonomiczny układ nerwowy, zarządzać podstawowymi, „życiowymi” aspektami działania satelity. I tu zarządzanie generowaniem energii jest podstawą wszystkiego. Satelita bez energii przestaje funkcjonować. W związku z czym najniżej ze wszystkich funkcjonalności satelity jest tak zwany safe mode. W momencie, kiedy satelita „wyczuje”, że dzieje się z nim cokolwiek nie tak lub też wleci na orbitę to pierwszą rzeczą, którą musi zrobić to pilnować energii.
W safe mode satelita ma ustawić się do słońca, ładować akumulatory i czekać na komunikację z nimi. To się wydaje proste, ale w gruncie rzeczy wymaga dosyć skomplikowanej sekwencji zdarzeń. To jest instynkt porównywalny z najprostszymi komórkami, które dążą do tego, żeby zachować życie. Na tej samej zasadzie jest z satelitą, więc ten pierwszy najważniejszy etap, to jest autonomiczne zarządzanie podstawowymi funkcjami.
Energia i łączność, to są dwie rzeczy, które muszą zostać zawsze zachowane. Jeżeli dzieje się cokolwiek takiego, że satelita nie wie, co ma ze sobą zrobić, a oprogramowanie napotkało stan, który jest dla niego czymś nietypowym to satelita podejmuje samodzielnie decyzję, czy to jest coś, co już wymaga przejścia do safe mode, czy jeszcze tylko poinformowania przy następnej sesji komunikacyjnej, że zdarzyło się coś niespodziewanego i żebyśmy zwrócili na to uwagę.
Jest to więc niejako ten poziom zero, najważniejszy i najniższy poziom funkcji życiowych satelity. Nad tym jest właśnie wspomniany scheduler. Po drodze jest jeszcze cały temat łączności. Łączność, zwłaszcza kosmiczna, wymaga specjalnych zasad, jej kontroli, przygotowywania ramek z wysyłanymi danymi do satelity i z satelity do Ziemi. Funkcjonalność całego podsystemu, który zarządza łącznością, to też jest nasz wytwór.
Zresztą w dużej mierze ten podsystem został już przetestowany na orbicie w innej misji kosmicznej na zlecenie Europejskiej Agencji Kosmicznej. Podobnie nasze doświadczenia w zakresie kilku innych podsystemów też zostały zweryfikowane w ten sposób. Więc software to są te główne funkcjonalności, które właściwie zarządzają każdym aspektem działania satelity.
Poza jednym podsystemem, jakim jest superkomputer dostarczony przez Centrum Badań Kosmicznych, który się zajmuje robieniem zdjęć, zapisywaniem ich pamięci, wszystko inne jest wytworem programistów Creotech. Mówimy o takich podsystemach jak główny komputer (on-board computer), który zarządza wykonywaniem rozkazów, całym schedulerem. On również decyduje o tym, czy coś jest nominalne czy nienominalne, czy trzeba coś wykonać. On zarządza niejako głównymi funkcjami życiowymi satelity.
Mamy również system zasilania, który również ma własne oprogramowanie. To jest niezależny podsystem, który ma własny komputer, który zarządza sam sobą. Baterie, generacja energii z paneli słonecznych, również cała centrala zarządzająca zasilaniem, jeden z najbardziej skomplikowanych elementów satelity. To jest też cała osobna część oprogramowania, która tylko tym zarządza. Dlaczego? Bo jak się cokolwiek stanie w komputerze głównym, to nadal mamy funkcjonalności podstawowe systemu zasilania, których na marginesie są dwa. Niezależne od siebie. Jeżeli cokolwiek się stanie z jednym, automatycznie przełączy się na drugi i vice-versa.
To oprogramowanie nie jest w gruncie rzeczy bardzo skomplikowane. Jest dużo prostsze niż to, co jest w telefonie komórkowym. Ale jest przetestowane i jest dedykowane dla tego jednego, konkretnego rozwiązania i zawsze ma zadziałać.
Łączność się okazała wyzwaniem. Były inne rzeczy, które wymagały większego wysiłku, niż to było wcześniej jakoś planowane?
Nie mogliśmy nawet zakładać, że coś będzie zgodnie z planowaniem. My jako firma przecieramy szlaki tu w Polsce. Uczymy się rzeczy, których inne kraje Francuzi, Niemcy uczyli się przez ostatnie kilkadziesiąt lat.
My nadganiamy naprawdę świat zachodni, my nawet nadrabiamy Rosję, bo to Rosja przez kilkadziesiąt lat posiadała know-how potrzebny do tego, żeby wykonać tego typu projekty. My się uczymy na nowo jako kraj, jako firma. Musieliśmy wszystkiego samymi nauczyć i w miarę możliwości korzystać z wiedzy, która była w mniejszym, większym stopniu, dawana nam przez Europejskie Agencje Kosmiczne.
To było dużo pomocy ze strony osób, które były np. naszymi recenzentami. Mamy recenzentów, którzy pomagali nam, mówili, że idziemy w dobrym kierunku i którzy mówili, gdzie nie tak, jak powinno jest to zrobione. Uczyliśmy się jako zespół. Braliśmy dokumenty, podręczniki, standardy głównie europejskie agencje kosmiczne i nie tylko – ESA, JAXA, kilku innych agencji. Warto było to zmiksować, zobaczyć
jak inni do tego podchodzą, a potem budować. Często to było iteracyjne. Coś się udało, coś się nie udało i trzeba było poprawić. Tu nie było łatwych rzeczy, to były wyzwania jak system zasilania, główny komputer, pamięci, przesył danych, radia, integracja, protokoły komunikacyjne, centrum kontroli emisji, które jest samo sobie bardzo skomplikowane. To nie jest parę komputerów na krzyż, ale za tym stoi bardzo dużo ciężkiej pracy.
To też jest wasze rozwiązanie?
To też jest nasze rozwiązanie.
Czy korzystaliście naj jakimś etapie z jakiegoś takiego platformowego rozwiązania?
Z przyczyn oczywistych nie za bardzo chcę wchodzić w pewne niuanse, bo to jest zbyt delikatny temat. Natomiast myśmy się oparli na sprawdzonym rozwiązaniu jednego z dostawców Europejskiej Agencji Kosmicznej, czyli ten główny procesor, który odpowiada za przygotowywanie łączności z satelitą, to jest coś, co jest wspólnie zrobione z jednym z głównych dostawców ESA.
Tym samym to też powoduje, że bardzo uprościła nam się procedura walidacji tego, że te protokoły wszystkie się zgadzają na Ziemi. Po prostu myśmy mieli wzorzec niejako mówiący, że to na pewno jest sprawdzone, więc jak to działa to znaczy, że dobrze to napisaliśmy.
Dość powiedzieć, że udało się nam to potwierdzić stosunkowo szybko. Jakieś drobne poprawki były, ale ta integracja była szalenie szybka. Więc duże ukłony do tej firmy, która nam też pomogła zintegrować. Natomiast nad tym znajduje się wszystko, co widzi użytkownik i to już jest nasz wytwór.
Czy planujecie politykę patentową?
Coca-Cola nie jest opatentowana. Dlaczego? Bo nikt nie chce się chwalić tym, jaki jest jej faktyczny skład. Tak samo jest z oprogramowaniem. Często w danej implementacji oprogramowania my nie odkrywamy „na nowo Ameryki”. My budujemy coś, co jest zgodne ze standardami Europejskiej Agencji Kosmicznej. Natomiast, jak to implementujemy i w jaki sposób, to jest już nasz know-how. To jest know-how, który – zaznaczam – jest jednym z unikalnych w skali europejskiej, czy nie nawet światowej, jeżeli chodzi o całą gamę naszych podsystemów.
Natomiast jeżeli oczywiście w międzyczasie dojdziemy do etapu, gdzie będziemy mieli całkowicie nowe rozwiązanie, na przykład hardware’owe, sprzętowe, programowe, które rozwiązuje jakiś problem w sposób taki, że można to patentować, na pewno to zrobimy.
Natomiast procedura patentowa zawsze jest bardzo skomplikowana i często, decyzja już przechodzi na dział prawny czy na zarząd. Na obecną chwilę my mamy takie rzeczy, które się już proszą do tego, żeby zacząć myśleć o pewnego rodzaju dalszych krokach.
Na pewno najpierw musimy to skomercjalizować, a w międzyczasie lepiej ukryć to jako własną wartość intelektualną, bo patentowanie de facto daje przekaz, jak to zostało zrealizowane. I jest ryzyko rynkowe, że patenty można obejść.
Na co zwrócić uwagę w Waszym hardware podobnie jak omówiliśmy to w software?
Np. komputer z Eagle Eye, który ma naklejkę „postrad”. To oznacza, że ten konkretny komputer wytrzymał solidną dawkę promieniowania po to, żeby sprawdzić czy wytrzyma radiację w kosmosie. I wytrzymał.
To było testowane w Centrum Badań Jądrowych w Świerku. W związku z tym jesteśmy firmą, która ma potwierdzone metodą weryfikacji w faktycznych warunkach w Centrum Badań Jądrowych, że nasza elektronika wytrzyma zakładaną dawkę promieniowania.
To co zabija elektronikę na orbicie okołoziemskiej, czy też w głębokim kosmosie. to jest właśnie promieniowanie. To nie jest CubeSat, to już nie jest rozwiązanie, gdzie tylko zakładamy, że wytrzyma.
My mamy naprawdę żywy dowód na dokumentacji, podpisane przez inżynierów Centrum Badań Kosmicznych, że to zostało zweryfikowane.
Jak to wygląda z żywotnością sprzętu w kosmosie?
Nie opłaca się robić sprzętu jako wiecznego. To znaczy misję się planuje na konkretną ilość lat. Nasz cel to 5 lat żywotności tego sprzętu. To jest zawsze dyskusja jak szybko satelita spadnie, bo spadnie. Paliwo się skończy, trzeba będzie go deorbitować. Sam w końcu spadnie, niezależnie czy będziemy go prosić o to, żeby został czy nie.
Druga sprawa jest taka, że w końcu ta radiacja i warunki na orbicie w końcu zabiją elektronikę. Nie ma takiego rozwiązania, które by wytrzymało wieczność. Podnoszenie niezawodności powyżej pewnego progu przestaje mieć sens, dlatego że robi się to wykładniczo drogie.
Po prostu każdy kolejny rok to są niewyobrażalne pieniądze. Więc my mamy założenie takie jak większość tego typu rozwiązań. Na niskiej orbicie okołoziemskiej 5 lat to jest więcej niż jest wymagane. Oczywiste jest to, że jeżeli przyjdą misje, a już takie przychodzą, w których jest wymaganie, że mamy lecieć dłużej i dalej, to zmienia się również podejście do elektroniki. Naszym celem jest znaleźć balans pomiędzy ceną, a niezawodnością i czasem życia z tego wynikającym.
Znaleźliśmy właśnie ten balans pomiędzy oczekiwaniami klientów, oczekiwaniem co do misji, możliwościami produkcyjnymi i kosztem takiego wykonania.
To jeszcze poproszę o komentarz o jednym z celów, czy zejście na niższą orbitę. Jak skutecznym osiągnięciem to będzie?
Skutecznym osiągnięciem będzie pozostanie na orbicie, bo satelita i tak zdeorbituje. Na 500 km jeszcze jest atmosfera. Ona jest szczątkowa, praktycznie nie wpływa na ruch satelity, ale w skali upływu lat już wpływa. W pewnym momencie opór powietrza, który jest mierzalny nawet na tej orbicie jest minimalny, ale istnieje i spowoduje, że satelita zacznie wytracać swoją prędkość, a tym samym zacznie coraz niżej opadać, aż w końcu wejdzie w tak gęste warstwy atmosfery, które spowodują, że satelita jeszcze szybciej zacznie spadać.
Na tej zasadzie, finalnie, po tych kilku latach, a mamy na to wymagania narzucone przez Europejską Agencję Kosmiczną, nie tylko, również przez FAA, satelita musi zdeorbitować czy nam się podoba, czy nie.
Jeżeli chcemy zejść na 300 km, to po prostu możemy poczekać. Tylko naszym celem nie jest tylko zejść naturalnie w wyniku deorbitacji. My chcemy kontrolować to zejście i my chcemy pozostać, w miarę możliwości dłużej na tej orbicie, niż to jest zakładane przez zwykły opór powietrza. Po prostu chcemy użyć naszych silników jonowych na pokładzie, żeby pozostać na orbicie, dodając prędkości i przeciwdziałając oporowi powietrza.
Ta orbita, to 310 km, to jest trochę taka ziemia niczyja. To znaczy, to jest za nisko dla standardowych satelitów. Te satelity najczęściej znajdują się na krótko, a potem spektakularnie spadają. My chcemy pozostać dłużej, jeżeli to wynika po prostu z normalnego planu misji i chcemy sprawdzić, jak silnik i jak satelita będzie się zachowywał na takiej wysokości. Jednocześnie, jakie zdjęcia będą w stanie być wykonane z takiej dużo niższej orbity niż ta początkowa 510 km.
Jak to jest z obliczeniami autonomicznymi na poziomie satelity? Jak do tego podchodzicie?
ESA definiuje kilka poziomów autonomiczności i myśmy celowo nie poszli wyżej, niżeli to jest zdroworozsądkowo zalecane. I tak jak wspomniałem wcześniej, satelita ma wykonać pewne autonomiczne operacje, które mają zapewnić jego przetrwanie. Wszystkie dodatkowe rzeczy na pewno będą gdzieś w międzyczasie również brane pod uwagę, bo pewna autonomiczność zwykle się przydaje.
