e-st@r-I and -II

I led the design and development of the ADCS of e-st@r-II.
Here some activities are mentioned:

• Design and simulation in Matlab®-Simulink®
• HW selection (e.g. Inertial Measurement Unit) and manufacturing (e.g. magnetic torquers)
• IMU characterisation by means of Allan Deviation analysis
• Magnetic torquers characterisation and functional testing
• Algorithms development: B-dot control, Y-Thompson control, QUEST, QMethod, ESOQ, ESOQ2 and recursive filter (Multiplicative Extended Kalman Filter) for a specific under-observable case (3-axial magnetometer plus gyroscopes)
• Implementation of the algorithms on flight microcontroller (ARM9) using C programming language
• Testing and verification of the implemented algorithm with comparisons with Matlab/Simulink code
• PWM outuput of microcontroller characterisation

Taking the heritage of e-st@r-I, I worked to define and implement new operative modes and telecommands first with my colleague Fabrizio and then with Lorenzo. In addition, the activation sequence of the satellite was completely changed to meet new requirements.

The desing of the subsystem was done by two radio-amateurs of Bra (currently they work at ESA as RF engineers), so my contribution is limited to soldering of SMD components and verification at subsystem level (e.g. signal analysis using oscilloscope) .

I was in charge of three important characterisation:

• Batteries (e.g. charge and discharge curves)
• Solar panels (e.g. V-I graph and power output)
• Telemetry

I was involved in all the activities concerning the assembly and integration (from component level up to system level) of the satellite and the verification: the contributions range from soldering to epoxy application, from single equipment test up to whole satellite verification. Among various activities, it is worth mentioning the functional test campaign at ambient condition conducted at Politecnico di Torino during 2014 and the environmental test campaign performed at ESA-ESTEC during 1Q-2Q of 2015. The first consists of basic and full functional tests and mission tests. The other instead consists of Vibration Tests (random, quasi-static, sinusoidal) and Thermal Vacuum Cycling Test (1 non-operative cycle and 3 operative cycles). For each test, a detailed as-run procedure was established and followed. To recap:

• Assembly, Integration and Verification of e-st@r-II CubeSat
• Functional test campaign at PoliTo
• Environmental test campaign at ESA-ESTEC
• Integration campaign into P-POD at ESA-ESTEC
• Integration campaign on-board launcher at CSG, Kourou, French Guiana

For e-st@r-II, it was adopted a mixture of document-based and SysML-based approaches. I dealt with typical System Engineering activities: mission objectives and success criteria definitions, functional trees, N2 diagram, block diagrams, requirements derivation and traceability.
Here is provided a list of documents in which I participated concretely. The documents are part of the ADP of e-st@r-II:

• Assembly Sequence, it aims at providing information about the assembly of the e-st@r-II CubeSat through detailed instruction on the correct sequence to be followed
• Critical Item List, it describes the critical items present in the e-st@r-II CubeSat
• CubeSat Acceptance Checklist, it is the document used to verify compliance of the CubeSat with respect to the specifications
• CubeSat Design Description, it describes into the details the e-st@r-II CubeSat, from the system point of view
• Declared Component List, it aims at providing a list of all components of e-st@r-II CubeSat
• Declared Material List, it aims at providing a list of all materials of e-st@r-II CubeSa
• Demande d'Utilisation Arianespace, it is required by launch provider and contains relevant information about the CubeSat
• Environmental Test Plan, it aims at providing information about the planning of the environmental tests to be performed on e-st@r-II CubeSat. The document guides the developer through the definition of the vibration and thermal-vacuum tests, giving information about the GSE and test facilities to be used, the personnel, organisation and management of the environmental tests campaign and its schedule
• Environmental Test Procedure, it aims at providing all the information required to fully define each test activity foreseen in Environmental Test Plan for the environmental test campaign. In particular, the requirements to be verified, the test approach and requirements for each related activity, the precise set-up, the GSE and pass/fail criteria for each test are described
• Environmental Test Reports, they were produced for TVC test campaign and Vibrations Test campaign. Each document is aimed at describing the tests conducted during the environmental test campaigns at ESA-ESTEC facilities, and at presenting the outputs and anomalies
• Environmental Test Specification, it provides the requirements for the activities identified in the Environmental Test Plan and it is used as a basis for writing the Environmental Test Procedure and the Environmental Test Report
• FDS-VCD, it is the Verification Control Document for Fly Your Satellite! Design Specifications. It defines, in matrix form, for each requirement to be verified, the combination of the selected verification methods for the different verification levels at the applicable verification stages
• Functional Test Reports, they were numerous. One for each basic and full functional test performed during Fly Your Satellite! programme. It derives from the information contained in the Test Plan, Specification and Procedure document, and includes additional elements such as the completed as run procedure
• Functional Test Specification and Procedure, the purpose of this document is to describe the test requirements applicable to the functional test campaign of e-st@r-II CubeSat, test approach, item under test and set-up, required GSE, test tools, test instrumentation and measurement accuracy, test conditions, test sequence, test facility, pass/fail criteria, required documentation, participants and test schedule. The Test Specification provides the requirements for the activities identified in the Test Plan and it is used as a basis for writing the Test Procedures included at the end of this document. The Test Specification gives emphasis on requirements, the Test Procedures on the operative step by step instructions
• Memo, several memorandum were produced to provide to ESA specific information, ranging from info at component level up to system level, in a more concise way
• Mission Description Document, it is aimed to describe the e-st@r-II mission. The purpose is to give a description of the mission, to provide input for the selection of the best architecture meeting the mission statement in iteration with the definition of the system specification. It presents how the objectives, operation profile, major system events and capabilities, contingencies and performance are expected to be achieved.The document structure goes through the definition of the mission requirements and mission architecture. Then a description of the mission scenario is provided, in terms of main mission phases, satellite operational modes, nominal orbit activities and contingencies, from the perspective of space and ground segments
• Mission Test Report, it is structured in a similar way to functional test reports, but it provides information about the mission test
• NCR, during the verification campaigns, several non-conformance occurred. A non-conformance report documents the details of a non-conformance identified in a quality audit or other process review. The objective of the report is to make an unambiguous, defensible, clear and concise definition of the problem so that corrective action can and will be initiated by management
• Outreach Planning Document, it describes the outreach activities planned and executed by the Team, as regards the e-st@r-II CubeSat and the participation into FYS programme
• Registration Status, it describes the activities performed by the CubeSat Team regarding ITU, IARU and UNOOSA registrations
• Request For Deviation, during the e-st@r-II life-cycle, some RFD were needed. The objective of the request for deviation is to be the vehicle for requiring and agreeing the departure from a customer's requirement that is part of an approved configuration baseline
• Request For Waiver, the objective of the RFW is to be the vehicle for requiring and agreeing to the use or the delivery of a product that does not conform to its approved product configuration baseline
• Review Item Discrepancy, more than 100 RIDs were created in FYS programme. RIDs are prepared to record identified problems and questions arising from the examination of the review documentation
• Safety Submission, it is required by launch provider and contains relevant safety information about the CubeSat
• Shipment Plan, it aims at providing information about the shipment of e-st@r-II to ESA/ESTEC facilities where environmental tests campaign will be conducted. The document includes the detailed description of all GSE items needed to conduct the environmental tests campaign that will be shipped to ESA/ESTEC in addition to the CubeSat. Moreover, a description of transportation method, responsible personnel and legal required documentation is provided
• Space Debris Mitigation Report, it reports the assessments, justifications and verification of compliance with ESA requirements about space debris regulations
• SSD-VCD, it is the VCD for system specifications. It defines, in matrix form, for each requirement to be verified, the combination of the selected verification methods for the different verification levels at the applicable verification stages
• System Specification Document, it includes all the requirements of e-st@r-II. For this project, requirements are classified as mission reqs, program reqs, functional reqs, physical reqs, design reqs, configuration reqs, and environmental reqs
• Test Report, several test reports were produced. They range from tests at component level up to system level. They include about the test set-up, GSE used, as-run procedures and result analysis
• User Manual, its scope is to provide information and instructions to handle, operate and maintain the e-st@r-II CubeSat after its integration. The document structure goes through the description of verifications at system level to guarantee the correct functionality of the satellite prior the launch, detailing the requirements to be verified, the test facilities, set-up and required GSE. Then, handling procedures, storage life and transport constraints and a description of the inhibits installed on the satellite are provided