SERPENS: build a mission across universities

SERPENS stands for Sistema Espacial para Realização de Pesquisa e Experimentos com Nanossatélites. AEB organized the program around university cooperation and practical experience across a mission’s life cycle. The first spacecraft was developed by a consortium coordinated by the University of Brasília. Its educational purpose included learning to work across institutions, not simply producing a small object that could be photographed beside its builders.

The first SERPENS was a 3U CubeSat — open definition, using a standardized format roughly equivalent to three basic CubeSat units. Standardization helps teams arrange compatible transport and deployment, but it does not supply a complete design. Power, software, radio operation and experimental objectives still have to fit together. Different teams can build different parts only if they share the requirements for how those parts interact.

SERPENS traveled to the International Space Station aboard Kounotori 5 and was released from Kibo on September 17, 2015. JAXA’s retrospective records two separate releases that evening: S-CUBE was commanded from aboard the station, while SERPENS was commanded by the flight-control team at Tsukuba. Transport to the station and release as an independent spacecraft were separate milestones, involving different hardware and responsibilities.

Imagine a fictional university building a radio while another writes the satellite’s command software. Both teams might pass their own laboratory tests but disagree about a message’s byte order. The assembled system would then misinterpret otherwise valid commands. An agreed interface — open definition document and an integrated command-and-response test address that problem. Separate reports saying that each component worked would leave the connection between them unverified.

Make the partnership work as a system

A student program must preserve knowledge as participants graduate. Useful handover material includes design decisions, test configurations, software versions and records of problems that were actually observed. A diagram showing connections is valuable, but the next team also needs to know which version flew and which limitations remained. These are general engineering practices illustrated by a collaborative mission, not a claim that SERPENS experienced the fictional fault above.

The archive card identifies the flown SERPENS spacecraft; the wider program includes organizational learning beyond that one object. Evaluate those outcomes separately. An independent deployment establishes a flight milestone. A repeatable training process requires evidence that people can understand, operate and improve the system afterward. This distinction makes student missions useful case studies in both space engineering and the continuity of technical knowledge.