Session
Pre-Conference Workshop Session 1: Coordinating Successful Educational Programs
Location
Utah State University, Logan, UT
Abstract
‘Fly Your Satellite!’ (FYS) is a recurring hands-on programme conducted by the ESA (European Space Agency) Academy Unit of ESA’s Education Office. Fly Your Satellite! was established to support university student teams in the development of their own CubeSats by enabling a transfer of knowledge and experience from ESA specialists to students. Selected teams are guided through project reviews and supervised through design consolidation and verification activities, conducted according to ESA professional practice and to standards tailored to fit the scope of university CubeSat projects.
This paper focuses on key lessons learned and issues identified during the ongoing verification activities of the CubeSats in the second cycle of FYS (FYS2), and on how that experience is used to the benefit of participants of future cycles, including the teams in the third cycle (FYS3), who are now in the late stages of their Critical Design Review. Special attention is given to the lessons learned during the manufacturing, assembly, integration and testing phases as experience shows that first-time developers tend to underestimate the number of issues which arise when the design is translated from documentation and models into physical hardware. The lessons learned are categorised into the topics of Development, AIV, Project Management, and Product Assurance.
In the Development category, the lessons learns suggest attention should be focused on emphasizing the importance of development models and FlatSats for early testing, proactive development of aspects which don’t appear to be immediately critical or appear to be on the project’s critical path (such as software and test GSE), and anticipating the need for compatibility with a range of possible orbit scenarios.
The Assembly, Integration, and Verification category contains a large variety of lessons learned from the preparation for AIV activities, anomalies encountered, and reflection on what was done well in the programme. These lessons cover topics such as dimensional requirement non-conformances, electromagnetic interferences, and recommendations for system level testing preparation.
Lessons learned for the Project Management category mostly arise from the understandable lack of (space) project management experience of the student teams, and the discussion focuses on possible mitigation approaches that can be implemented. Specific topics covered include delayed project schedules, management of student resources, risk management, and experiences with legal and regulatory requirements.
The lessons learned on Product Assurance stem primarily from the difficulties in applying standard methodologies to educational small spacecraft projects. Problems with configuration control, clean room practices, and anomaly investigation methods are discussed, with recommendations for how student teams could solve such issues, primarily through the creation of additional documentation to track modifications and processes implemented.
Lessons Learned from AIV in ESA’s Fly Your Satellite! Educational CubeSat Programme
Utah State University, Logan, UT
‘Fly Your Satellite!’ (FYS) is a recurring hands-on programme conducted by the ESA (European Space Agency) Academy Unit of ESA’s Education Office. Fly Your Satellite! was established to support university student teams in the development of their own CubeSats by enabling a transfer of knowledge and experience from ESA specialists to students. Selected teams are guided through project reviews and supervised through design consolidation and verification activities, conducted according to ESA professional practice and to standards tailored to fit the scope of university CubeSat projects.
This paper focuses on key lessons learned and issues identified during the ongoing verification activities of the CubeSats in the second cycle of FYS (FYS2), and on how that experience is used to the benefit of participants of future cycles, including the teams in the third cycle (FYS3), who are now in the late stages of their Critical Design Review. Special attention is given to the lessons learned during the manufacturing, assembly, integration and testing phases as experience shows that first-time developers tend to underestimate the number of issues which arise when the design is translated from documentation and models into physical hardware. The lessons learned are categorised into the topics of Development, AIV, Project Management, and Product Assurance.
In the Development category, the lessons learns suggest attention should be focused on emphasizing the importance of development models and FlatSats for early testing, proactive development of aspects which don’t appear to be immediately critical or appear to be on the project’s critical path (such as software and test GSE), and anticipating the need for compatibility with a range of possible orbit scenarios.
The Assembly, Integration, and Verification category contains a large variety of lessons learned from the preparation for AIV activities, anomalies encountered, and reflection on what was done well in the programme. These lessons cover topics such as dimensional requirement non-conformances, electromagnetic interferences, and recommendations for system level testing preparation.
Lessons learned for the Project Management category mostly arise from the understandable lack of (space) project management experience of the student teams, and the discussion focuses on possible mitigation approaches that can be implemented. Specific topics covered include delayed project schedules, management of student resources, risk management, and experiences with legal and regulatory requirements.
The lessons learned on Product Assurance stem primarily from the difficulties in applying standard methodologies to educational small spacecraft projects. Problems with configuration control, clean room practices, and anomaly investigation methods are discussed, with recommendations for how student teams could solve such issues, primarily through the creation of additional documentation to track modifications and processes implemented.
