Seit dem „SpaceTeamSat1“ Kick Off im August 2020 konnten einige bedeutende Schritte in der Entwicklung unseres CubeSats gemacht werden, die wir in diesem Blogpost vorstellen wollen.

Wie bereits zuvor angekündigt, fand im Oktober 2020 unser erstes Review – das Preliminary Design Review (PDR) – statt. Daher arbeiteten wir im Herbst noch intensiv an der Ausarbeitung unserer Mission, was die Definition der verschiedenen Subsysteme des Satelliten miteinschließt. Beim 5-stündigen PDR, welches mit Space Team Mitgliedern sowie externen Experten durchgeführt wurde, bekamen wir viele Anmerkungen und wurden auf sehr viele wichtige Aspekte hingewiesen. Die Hauptpunkte waren die Educational Payload – die bis dahin auf der Arduino Platform basierte – nochmals im Hinblick auf Accessability und Usability für Schülerinnen und Schüler von AHS und BHS zu hinterfragen. Zudem waren die Konzepte für unsere Subsysteme zu komplex und somit für Space Anwendungen nicht zuverlässig anwendbar. Aus diesen Gründen wurde die Mission bzw. das Konzept nochmals überarbeitet. Auf der aktualisierten Seite finden sich detailliertere Informationen zur überarbeiteten CubeSat Mission.

Anfang 2021 hatten wir dann ein erneutes Review, bei dem wir unsere angepasste Mission vorstellten und die Hauptänderungen etwas genauer beschrieben und diskutierten. Dieses Mal konzentrierten wir uns auf die wesentlichen Punkte und präsentierten ein High-Level Konzept unserer Mission. Die Educational Payload unserer überarbeiteten Mission ist nun ein Raspberry Pi, auf dem Schülerinnen und Schüler Python Code ausführen werden können, um damit Sensoren und Kameras an Board des Satelliten auslesen zu können. Wir hoffen, dass diese Wahl unser Projekt für Schülerinnen und Schüler noch zugänglicher macht und wir dadurch mehr junge Menschen für Technik und Naturwissenschaften begeistern können.

In der Entwicklung unseres CubeSats werden wir in Zukunft mehrere Reviews abhalten, um den Fortschritt etwas genauer analysieren zu können und auch um unsere Subsysteme kritisch zu hinterfragen. Ein weiterer wichtiger Schritt in der Realisierung unserer Mission ist ein High-Altitude Flight, den wir vor einem Start ins All durchführen möchten. Dabei soll die CubeSat Plattform und die Infrastruktur – das heißt die Ground Station sowie die ganze RF Kommunikationsstrecke – unter realen Bedingungen getestet werden. Der CubeSat soll dazu an einen Wetterballon oder ähnlichem angebracht werden und auf einige km Höhe geflogen werden. Natürlich soll dabei auch schon ein Szenario durchgespielt werden, wie es dann in der Mission im All stattfinden wird. Im Moment sind wir hier noch in der konkreten Planungsphase – weitere Details werden demnächst folgen.

Engineering

Da unser Konzept von externen Experten für gut empfunden wurde, haben wir uns dazu entschieden mit der Entwicklung des Electrical Power Systems (EPS) und des Communication and On-board Computers (COBC) zu beginnen. Der Hintergrund ist, dass diese beiden Systeme missions-entscheidend sind und somit bedeutend länger und intensiv getestet werden müssen. Zudem sollte zu einem möglichst frühen Zeitpunkt der Dataflow sowie die Architektur der gesamten CubeSat Mission definiert sein. Auf diese drei Punkte wird im Folgenden etwas genauer eingegangen.

Dataflow

Um den Dataflow bzw. die Software Architektur zu definieren, haben wir damit begonnen diese Thematik als Spiel nachzubilden. Das heißt, dass verschiedene Personen innerhalb des Dataflows die Rolle der einzelnen Subsysteme übernehmen und dann entscheiden, wie mit den Daten umgegangen wird. Das Ganze kann mit der Concurrent Design Facility der ESA verglichen werden. Die folgende Abbildung zeigt das Spielbrett, welches wir Corona-bedingt, auf der Onlineplattform miro erstellt haben.

Durch das Dataflow Game haben wir herausgefunden, welche Interfaces, etc. nötig sind, damit man Daten von der Ground Station zum CubeSat schicken kann und auch wieder Daten erfolgreich zurückbekommt. Im Moment haben wir alle wichtigen Datentypen und Szenarien definiert und sind daher mit der Dokumentation beschäftigt, damit wir bald wieder in ein Review starten können. Zudem werden wir dann innerhalb des Reviews den Dataflow auf Fehler – zum Beispiel keine Solarenergie, etc. – testen, um das jetzige Konzept auf den Prüfstand zu stellen.

Electrical Power System (EPS)

Hier wurde bereits ein Konzept ausgearbeitet. Dieses wurde auch schon in einem Review besprochen und ist somit bereit, genauer evaluiert zu werden. So wurde zum Beispiel darauf verzichtet Spannungsversorgungen mit mehreren Prioritäten bereitzustellen. Die Aufgabe des Power Management wurde somit auf den COBC ausgelagert. Dieser Ansatz soll die Testbarkeit und Zuverlässigkeit der EPS erhöhen. Im Moment sind wir damit beschäftigt einen Prototypen aufzubauen und die Funktionalität zu testen. Besonderes Augenmerk wird auf die LiFePo Akkuzellen und deren Eigenheiten gelegt. Zudem sind wir in Kontakt mit anderen europäischen Universitäten und deren Space Teams, um deren Feedback zu unserem EPS Design in die weitere Entwicklung einfließen lassen zu können.

Communication and On-board Computer (COBC)

Hier haben wir uns zwischenzeitlich für die STM32 Familie als Main Processing Unit entschieden. Dies ermöglicht es uns ein Real-Time Operating System (RTOS) zu verwenden. Derzeit evaluieren wird das Betriebssystem RODOS (https://gitlab.com/rodos/rodos), welches vom DLR und der Julius-Maximilians-Universität Würzburg speziell für Satelliten Missionen entwickelt wurde. Erste Tests stimmen uns so weit zuversichtlich, dass RODOS für unseren CubeSat eine geeignete Wahl darstellt.

Nächste Schritte

Unser nächstes Etappenziel ist es bis Ende 2021 einen Flat Sat* zu entwickeln, auf dem wir verschiedenste Szenarien unserer Satelliten Mission simulieren können. Natürlich werden wir auch ein CubeSat Modell fertigen, um auch elektromagnetische Einflüsse der Subsysteme berücksichtigen können. Wir sind zuversichtlich, dass uns die Flat Sat Platform ermöglichen wird, unser Dataflow Konzept zu evaluieren und unsere gesamte Satelliten Platform auf Herz und Nieren zu testen.

Just dieser Tage kam zudem die Notification der Small Satellite Konferenz 2021 (https://smallsat.org/), dass wir unsere Mission mit einem Poster bei der – leider – wieder virtuellen Konferenz vorstellen dürfen. Weitere Infos dazu in Kürze.

* Flat Sat bezeichnet einen Aufbau bei dem alle Subsystem PCBs offen auf einem Mainboard platziert sind. Dies ermöglicht es, dass Messungen leicht zugänglich gemacht werden können. Somit kann das System gut analysiert werden und verschiedene Szenarien simuliert werden.