Final Report Summary - QB50 (An international network of 50 CubeSats for multi-point, in-situ measurements in the lower thermosphere and re-entry research)
Executive Summary:
The QB50 Project demonstrated the possibility of launching a network of 36 CubeSats built by CubeSat teams from all over the world to perform first-class science and in-orbit demonstration in the largely unexplored middle and lower thermosphere. Space agencies are currently not pursuing a multi-spacecraft network for in-situ measurements in the middle and lower thermosphere because the cost of a network of a number of satellites built to industrial standards would be very high and not justifiable in view of the limited orbital lifetime. No atmospheric network mission for in-situ measurements has been carried out in the past or is planned for the future. A network of satellites for in-situ measurements in the middle and lower thermosphere can only be realised by using very low-cost satellites, and CubeSats are the only realistic option. The Project demonstrated the sustained availability of low-cost launch opportunities, for launching small payloads into low-Earth orbit; these could be microsatellites or networks of CubeSats or nanosats or many individual small satellites for scientific or technological research. The Project included the development of a deployment system for the deployment into orbit of a large number of single, double or triple CubeSats. The system can be easily adapted to other missions. QB50 provided also a launch opportunity for key technology demonstration on IOD CubeSats such as propulsion systems and aerobrakes. Up to 36 CubeSats have been launched together to low earth orbit. Due to atmospheric drag, the orbits of the CubeSats will decay and progressively lower and lower layers of the thermosphere will be explored without the need for on-board propulsion. QB50 is the first University built CubeSat networks in orbit
Project Context and Objectives:
Since its start, the QB50 project has been focusing on the following four main objectives:
• Facilitating access to space
• Scientific research
• Education
• In-orbit demonstration
1 Facilitating access to space
One of the main purposes of the QB50 project was to achieve a sustained and affordable access to space for small-scale research space missions and planetary exploration. To this end, the project was conceived around a Russian Shtil 2.1 rocket. This rocket was intended to launch the entire QB50 constellation as a primary customer. As a member of the QB50 Consortium, Innovative Solutions in Space (ISIS) was charged to design a deployment system that would have allowed deploying a constellation of CubeSats from a single rocket. The first multi-satellite dispenser was made of fifty single satellite slots. It was later found to be advantageous, for accommodation purposes, to cluster four dispensers together allowing the independent ejection of four 2-3U satellites, or fewer with larger size. Those modules are now called ISIS QuadPack.
Important novel features include the integration of the door opening mechanism and a standalone control module to better synchronize the door openings. The mechanism ejecting the CubeSat, consisting of the pusher plate and the ejection spring, was designed to allow the accommodation of the QB50 science unit within the centre of the spiral spring. Since its development and the maiden flight with the QB50 precursor launch campaign in 2014, this deployment system has been flown 39 times on 7 different launch vehicles (Antares, VEGA, PSLV, Dnepr, Soyuz and LM-2D) hence proving its reliability and flexibility. The fact that the global CubeSat community, the launch providers, the European industry and in general the small satellites world are benefiting from a technology developed within QB50 with European funds, is a remarkable achievement of the project.
Between 2012 and 2015, the success of the QB50 mission was jeopardized by the end of three main launch programmes: the Russian Shtil, the Brazilian-Ukrainian Cyclone 4 and Russian-Ukrainian Dnepr. These events introduced a number of delays in the schedule and some important changes in the implementation of the project. Other more expensive launch opportunities were available on the market by that time, but no option fitted the budget available or the time constraints. It was then decided to adopt a split launch strategy to decrease both the risks and the costs. As a result, 28 CubeSats have been deployed at 415km altitude 52deg inclination from the ISS from May 16th to May 25th 2017 and 8 CubeSats have been launched in an orbit at 505km altitude 97.1deg inclination by a PSLV rocket on June 23rd 2017. Both launches allowed distributing the constellation between two different orbital planes (higher polar orbit and lower mid latitudes orbit) in order to cover a larger portion of the thermosphere.
The objective ‘Facilitating access to space’ was not solely achieved by procuring an affordable launch for the constellation but also by the unprecedented undertaking in terms of teamwork and the centralized coordination of the administration paperwork.
The QB50 Consortium guided the CubeSat teams by facilitating their efforts to develop and ultimately to launch their satellites. For example, the Consortium provided technical guidance for CubeSat development through the definition of system requirements, advice and recommendations for design and milestone reviews. To facilitate the reviews, templates for the technical documents were provided. They allow for an efficient and effective reporting of the technical design, the development status, and the identification of risks and non-compliances. The review process, conducted mainly by the Consortium itself, helps in mitigating potential flaws in the design and integration of the CubeSats. CubeSats in general are subject to high mortality particularly during their infancy. Hence, a priority for VKI was ensuring high quality engineering work.
The Consortium supported the participant teams also by coordinating all necessary international legal permission for launch. The satellites were registered by VKI with the state of Belgium. In addition, the majority of the CubeSats benefitted from the radio frequency coordination carried out by VKI in collaboration with AMSAT and IARU, the Belgian Institute for Post and Telecom (BIPT) and ITU. This centralized coordination was very efficient and it left the CubeSat teams caring only about their own national laws such as export/import regulations. Despite being registered in Belgium, each satellite remains the property of the organization that has developed it and it is operated by its own ground station.
2 Scientific Research
The scientific objective of the QB50 project is addressed by carrying out an unprecedented measurement campaign in the mid-lower thermosphere, between 300-450km altitude. This region is the least explored layer of the atmosphere because is difficult or risky to be reached. Typically, this region is too high to be reached by ground based instruments. Measurement campaigns using LIght Detection And Ranging (LIDAR) systems or sounding rockets can only probe the composition of the atmosphere for a short period of time below 200km altitude. Sounding rockets are only flying few times per year and LIDAR can only measure on vertical columns. Only incoherent scatter radars (like the EISCAT facility in Norway) can reach higher altitude up to 800 km, but those radars are only able to measure the electron density in the ionosphere and no information is given about the gas composition. On the other hand, large satellites allow for long duration in-situ measurements below 400km but only with a limited spatial resolution. Missions like CHAMP, GOCE and SWARM were flown below 450km in the thermosphere and the instruments on board of the spacecraft (S/C) continued the measurement acquisition during their orbital decay until the loss of the satellite. To increment the lifetime of the mission, other atmospheric explorers were flown in the past in highly elliptical orbits (typically below 250 km perigee, and above 1000 km apogee); they carried experiments for single-point, in-situ measurements but the time spent in the lower thermosphere was only a few tens of minutes. The NASA Explorer Series of S/C are among the most known atmospheric explorers.
The multi-point, in-situ measurements of QB50 will be complementary to the ground based instruments and satellite in-situ measurements. The developers of the atmospheric models will benefit from the measurements obtained by QB50 in the lower thermosphere. This will lead to tools that are more precise and more robust in modelling the upper atmosphere. Ultimately, the users of these models will obtain more accurate results in terms of drag in the thermosphere, debris trajectory analysis and debris mitigation.
The majority of the CubeSats of the QB50 constellation carry one of the 34 atmospheric sensors. These atmospheric sensors, called hereinafter sensor units, are developed and manufactured by the Consortium and they serve as the primary payload for the CubeSats participating in the project. This swarm of 34 sensor units is constituted by three set of instruments:
• 10 Ion and Neutral Mass Spectrometers (INMS) provided by the Mullard Space Science Laboratory (MSSL). This instrument can measure the most prominent heavy particles in the thermosphere such as O, O2, NO and N2. By changing its operating mode, the instrument can either measure neutral or ionized species.
• 14 Flux Probe EXperiment (FIPEX) sensors units supplied by the Technical University of Dresden (TUD). The instrument measures atomic and molecular partial pressures by means of two separate solid electrolyte sensors.
• 10 multi Needle Langmuir Probe (mNLP) supplied by the University of Oslo (UiO). The instrument can probe the electron density and possibly the electron temperature of the thermosphere.
3 Education
QB50 invited universities worldwide to join the project and send a satellite to space. Numerous proposals have then been received and the CubeSats been selected through a competitive process. As a result, the QB50 CubeSats have been designed and assembled by a great number of young engineers, supervised by experienced staff at their universities and guided by the QB50 Consortium through reviews and feedbacks. More than 300 students and more than 50 professional from 24 different countries participated in the largest international collaboration in the space sector. Those young engineers did not only learn about the challenges of space engineering but they will leave their universities with hands-on experience in an international project.
4 In-orbit demonstration
The fourth objective of the QB50 project is to serve as a platform for technology demonstration. A handful of QB50 CubeSats are also carrying proprietary payloads on board. These payloads are mainly technologies to be qualified in space. Here few examples of the technologies tested:
• InflateSail is a 3U CubeSat built by the Surrey Space Centre (SSC) whose primary objective is the flight demonstration of an inflatable sail structure. InflateSail consists of a 1 m long inflatable cylindrical boom, which supports approximately a 3m x 3m tape-spring supported sail. The technology has been proven to be very successful. After an orbital injection at 505km altitude on June 23rd 2017, the CubeSat has de-orbited successfully on September 3rd 2017 (72 days after the sail deployment).
• LituanicaSAT-2 is a 3U CubeSat built by the University of Vilnius and its spin-off company. The CubeSat validated successfully on July 5th 2017 a small chemical propulsion system based on a green monopropellant. The propulsion system is currently commercialized.
Project Results:
This section is a collection of all the lessons learned accumulated by the authors during the last 6 years. Due to the broad overview of the project, the lessons learned contained in this document are not only a synthesis of the heritage on CubeSat design, testing and assembly but also a summary of the experience built up during the coordination of the first constellation of University CubeSats. These lessons can be used not only as a reference for the implementation of future CubeSat constellations but also as a simple collection of guidelines for the design, testing and review of future CubeSat projects. All lessons collected hereinafter are divided in different engineering topics for easy usability. In order to better summarize the lessons learned, they are presented as a list of items.
1 Management
• When starting a CubeSat project (or any project) it is good practice to assign well-defined roles and responsibilities in the team.
• Use only one reference system for the design of the complete satellite. Define it at the beginning of the project and share it to all the members of the team.
• Perform regular/weekly meetings to keep the team updated on subsystems, interfaces and general design. Keep a configuration control document.
• Start looking into export/import laws of your country from the beginning. In general, start applying for an export license at day one. The export license is a lengthily process and it could require some paperwork.
• Often times, developers underestimate the efforts for ITU filing and frequencies coordination.
• If the environmental test facilities (TVAC chamber, shaker, etc) are not in house, remember to plan in the budget the costs for the test campaign at external facilities. A reasonable estimate is around 10k euro (including the travel costs).
• In the academia the manpower turnover rate is high, thus, students come and go during the project. In order to pass along the work to the new members, all work must be documented. Without documentation, it will be difficult to bring the new members up to speed. It is suggested to start writing a document for each subsystem at the beginning of the development. Each document shall be updated monthly by the responsible of the subsystem.
• In the University, the time spend by master students in the project is in general between 3-6 months. PhD students can be enrolled for much longer and they could help in keeping continuity in the project and help mentoring new students.
• If costs are the driver, then a detailed cost breakdown should be prepared: design, assembly, procurements, integration, testing, launch, early orbit, on-orbit operations, data analysis, and any additional science analyses that may be required.
• Again, do not forget planning in the budget the funds for in-orbit operations. Taking the project to the launch pad is only part of the journey. Carefully planned operations and their execution requires considerable funds. It is very difficult to achieve the mission objectives without a consolidated operation plan.
• Define clear mission objectives since the beginning of the project. This will keep the focus of students, professors and managers on the objectives to achieve.
• Ensure that the objectives and requirements have achievable targets and that they can provide exact values or conditions. This will help to keep track of the progresses. Every objective can be expressed by a target value/status and a threshold value/status, e.g. the target is the more challenging value/status to achieve, the threshold is the minimum acceptable to declare an objective partially reached.
• Every CubeSat should have a user manual with it. This document should be clear and concise in order to be understood by anyone, especially by people that are not part of the developing team (such as by an external launch service company). The document shall include at least the handling procedure, the charging procedure and the deployer integration procedure. All procedures shall be documented step-by-step with clear pictures and a reference system.
• All procedures described in the user manual shall be clear and unique, without any ambiguity on the actions to be performed.
• The final version of the user manual shall include detailed and clear pictures showing the equipment, interfaces, connectors, etc. The purpose of the pictures is to provide a visual reference of the nominal appearance of a certain item: this is useful to immediately detect damages, shape changes, unexpected modifications that may have occurred accidentally during transportation.
2 On-Board Computer
• Always include a bootloader in the OBC. In case of corrupted software, it is still possible to recover the S/C by loading a backup or a simplified version of the operating system and establish communication with the ground.
• Always include an umbilical connector to the OBC that is accessible when the CubeSat is fully integrated. This connector will be useful to run verification tests and download logs or data from the CubeSat at any time and without the use of a (portable) ground station.
• Make sure that the processor and the memory implemented in the OBC are compatible or they provide enough resources to run the software that it is going to be used. A good practice is to involve the software engineer in the early discussions and preliminary design of the OBC hardware.
3 Software Development
• Kick-off the software development soon after the start of the CubeSat project.
• The software shall include a software upgrade/patch capability.
• Software upgrades or patches shall only contain the necessary piece of the codes to be upgraded/patched. Never design a software where the entire software needs to be uploaded because this could be too demanding in terms of uplink.
• Design a software with a code and a parameter area to simplify patching.
• The software team should have frequent interaction with the system engineer and the rest of the team. This will help to design a software in harmony with the hardware and the mission.
• Use revision control software to archive and track changes on test and flight-software.
• Always implement a way to reset the counters in the CubeSat in case of an accidental release of the switches during the integration into the deployer or the fit-check activities.
• Allow software updates to be done through the umbilical connector.
• Always include a safe mode in the software in case of problems during in-orbit operations. The safe mode shall stop all unnecessary subsystems and it shall charge the batteries until a comfortable charge level is reached in order to establish a stable link with ground.
• Safe mode shall support software patching.
• Software implementation is a perfect example of the 80/20 rule. 80% of the work is done in 20% of the time and the remaining 20% of the work consumes the last 80% of the time.
4 Electrical Power Subsystem
• Solar cells are perhaps the most critical component in terms of delivery time, the most expensive and the most affected by market fluctuations. Try to order the solar cells much in advance and get multiple quotations. Spare cells should be procured (if they can be afforded) because they are extremely brittle.
• The consequences of an abrupt interruption of the current while charging the batteries (e.g. removing the charger before the batteries are completely charged) should always be investigated.
• Many batteries are provided without any physical protection circuitry and this protection is sometimes implemented via software. A hardware protection is always preferred over a software protection. Moreover, the software protection is usually not accepted by the safety control board if you are planning to launch from the ISS.
• The batteries with hazardous chemicals are not allowed to fly on the ISS. The list of hazardous chemicals shall be read before procuring the batteries.
• The power budget should be evaluated for the worst case and always account for 20% margins (or more). The nodal precession/recession of the orbit could (and it will) dramatically impact the power generation after few months in the mission.
• It is good practice to build the EPS compatible with the ISS requirements: 3 inhibits (including one between batteries and ground), ISS-version of COTS boards, tested batteries. This approach will save many problems when choosing the launch provider.
• Check the maximum depth-of-discharge and verify sufficient battery charging in case of frequent mode-switching with typical operational profiles.
• Use conservative values for efficiencies from datasheets or better measure the EPS/system performance.
• The use of battery heaters is always encouraged. Very often, the batteries are operating in too cold conditions in orbit. Consequently, their performances are decreased.
• The Safe mode shall be power positive in any event and ensure power and communication with all attitudes.
• Do not require attitude control or other functionalities (e.g. successful deployment of panels) for the power budget calculation of the safe-mode.
• It is good practice to procure extra Li-ion batteries. Some of them can prematurely die or they are defective.
5 Attitude Determination and Control Subsystem
• Test your GPS on ground until you get a proper fix. Always verify if the GPS software can cope with the large Doppler shift in orbit.
• Verify that the GPS board has the proper firmware to work in space. Usually the GPS hardware is delivered with a ground enabled firmware and not with a space enabled firmware. GPS hardware with ground-enabled firmware does not work in space.
• A GPS space firmware might require a COCOM license valid both for the country where the CubeSat is integrated and for the country where the CubeSat is launched. Check with the authorities or the GPS hardware provider.
• Remember that the GPS firmware for space is a dual-use or ITAR restricted item.
• When sizing the attitude control system take into account all disturbances that can generate an applied moment to the CubeSat. Magnetorquers are enough for general purposes if used in orbits higher that 400km altitude. Lower that 400km altitude a combination of magnetorquers and reaction wheels is preferred. Do not forget that moment generated by atmosphere drag between 200-350km altitude is not negligible and it could be much higher that other forcing perturbations.
• Residual magnetic dipoles in the CubeSat can generate unwanted magnetic moments in space. Degauss the satellite before the launch.
• To avoid static magnetic moments, use non-magnetic metal parts (e.g. A4 steel nuts & bolts) and try to screen magnetic components (e.g. permanent magnets, brushless DC motors, solenoid valves) with Mu-Metal plates.
• Always check if there is any electro-magnetic coupling between magnetorquer and magnetometer(s). It is a good practice to place the magnetometer as far as possible from any electric components, usually the best option is to place it on a boom.
• To avoid dynamic magnetic moments, limit the enclosed area between supply (power) and return (GND) currents on PCBs, solar panels and harnesses.
• Use twisted wires with return and no soldering, no screwing and no wire-stripping.
• Long wires on the solar panels can generate current loops and consequently high dynamic magnetic moments, which can spin-up the CubeSat very quickly. These forces are difficult to control and to dump in space.
• When detumbling from high rates, the problem is that normal detumbling controllers can be sample-time limited and therefore not sufficient for detumbling the S/C. It is good practice to use an active magnetic damping controller with fast sampling period. Select the largest B-field component axis and choose an orthogonal axis magnetorquer with the largest ΔB-field measurement to produce a damping torque to reduce the satellite’s spin rate.
• Select low power and low cost 3-axis magnetometers that allow continuous measurement capability.
• Ensure a good measurement resolution of the magnetometer, 3.5milli-Gauss (350nT) is about 1deg attitude error.
• Ensure that the magnetometer has low noise and good sensitivity in the measurement range between 0.2 to 0.6 Gauss.
• The magnetometer calibration curve is temperature dependent. If you are planning to mount your magnetometer on a boom, take care of performing a calibration also as a function of temperature. Because the magnetometer is outside the shell of a CubeSat, it will experience some extreme temperature variations.
• Due to a latency between the magnetometer measurement and the torquer activation, your ADCS could not behave as expected. Make sure you are considering latency times in your ADCS routines.
6 Communication Subsystem
• The antenna pattern(s) shall always be characterized.
• Include as many available sub-system telemetry parameters in the beacon as possible.
• Having a beacon can facilitate early orbit discrimination in case of a cluster launch (which can easily involve a hundred of CubeSats nowadays).
• Some COTS transceiver cannot be fine-tuned to all frequencies (e.g. only at 25 kHz steps). Make sure you can reach the frequency coordinated by IARU or make IARU aware of the limitation when requesting the coordination.
• The implementation of the ESA Packet Utilization Standard (PUS) in the on-board software is encouraged. Nevertheless, the time and resources needed for the deployment of PUS must not be underestimated.
• The CubeSat shall transmit the beacon automatically 30 mins after deployment (i.e. activation). The beacon activation shall be automated and it should not require any activation from ground. In case the CubeSat is malfunctioning during the early orbit operations (LEOP), the data contained in the beacon are essential for the debugging.
• It is good practice to simulate a real communication scenario with the S/C and the ground station in the loop. A not properly tested ground station or a wrong link budget cause most of the problems affecting the LEOP.
• A conservative link budget is crucial for the success of the mission. Ensure that both the uplink and downlink can be close even in the worst conditions (i.e. CubeSat tumbling with high rates, partial deployment of the antennas).
7 Manufacturing, Assembly, Integration, Verification and Testing
• A QM/FM approach is recommended against a PFM approach. It is a good practice (if budget allows) to have a QM (or an EM) for troubleshooting problems when the FM is in space.
• Having a QM in the lab is also a very useful because the components can serve as spares for the FM final integration. In our experience few ADCS, EPS and OBC stop working (because of mistreatment) only few days before the launch preparation activities.
• If possible, include all digital communication lines (UART, I2C, SPI, CAN) on the umbilical connector to monitor and/or inject packets to different sub-systems. This is especially useful for the radio to OBC connection to debug communication problems.
• Do not be afraid of testing your CubeSat on the shaker. Follow the standards (e.g. NASA GEVS) and do not over test it.
• When receiving a component/subsystem, test it! When assembling a component, test it! When assembling a CubeSat, test it! And then re-test everything again! The majority of premature CubeSat death in space is caused by shortcuts during the testing phase.
• Never trust the datasheet or a manual for a component or a subsystem. Test the performances in a real environment instead. Most of the times the values in the datasheet are obtained in a lab under controlled environment and they cannot be replicated in the real usage.
• Running full end-to-end mission test on the hardware is an excellent way to learn and troubleshoot the entire system, even if the full test takes several days. The suggesting is to simulate the deployment, the booms and antennas, the de-tumbling (perhaps using some ad-hoc routines to simulate it) and the first ground contact using your ground station in the loop.
• In case you do not have a shaker and/or a TVAC chamber easily accessible, make sure you reserve a slot for the environmental tests in a proper test facility well in advance. These facilities tend to be extremely crowded sometimes, and any delay can dramatically affect your schedule.
• Keep an integration logbook and pictures for each step of the integration activities. Any deviation and non-conformance shall be tracked, documented and reported. In other words, a rigorous PA/QA procedure shall be in place.
• Keep the amount of additional harness to a minimum.
• Verify the correct connection of TX/RX lines for communication protocols like UART.
• When you are preparing for the environmental tests, make sure there is a list of items/tools that are need to perform the tests. Very often, those tests are one-shot and performed in a remote location and there will be no time to go back in the lab if a tool has been forgotten.
• An assembled CubeSat could look very different from the original CAD model. It is good practice to measure all dimensions with great care. It is known that 60% of the failures during the integration in the deployer is caused by a CubeSat with dimensions out of specs.
• Perform all kind of functional test and deployment test during TVAC. Sometime the hardware (and the software) can behave differently when not at room temperature.
• Prepare a test plan and procedures to make sure ALL functions/subsystems are tested. Avoid testing each function/subsystem one by one but prefer testing them together or in combinations. Unexpected electric or software coupling between two or more components (e.g. RF coupling between two transceivers that are working at the same time can lead to undesired damages) are a cause of failures on CubeSats.
• Account at least 2 weeks for the environmental tests.
• Before leaving the lab for the testing or integration activities, perform a dry run of the expected tasks to troubleshoot the step-by-step procedure.
• Create clear test-procedures and documentation of activities and results to allow for repeatability.
• From a management point of view, the Test Readiness Review (TRR) shall be an important milestone. It represents the point when you CubeSat is fully assembled and ready to be qualified for launch.
• The shock test is indeed a very severe test, which may damage partially the sub-components and the most delicate interfaces. Consequently, this test is very often avoided among CubeSat manufacturers (i.e. because the deployer is damping the shock loads to the CubeSat). Some launch providers are now requiring the shock test as a mandatory test. It is good practice to use an Engineering Structural Model for the shock test and avoid overstressing the flight hardware. The shock test will prove to the launch provider that the CubeSat structure is not breaking into pieces inside the deployer.
• The assembly order can induce stresses on the structure of CubeSat. As a result, the structure can twist or warp causing unwanted non-conformances.
• The failure in respecting the rail tolerances is a surprisingly common issue among CubeSats.
• Tape antennas that wrap around the CubeSat have a tendency to result in envelope violations inside the deployer (i.e. some part of the CubeSat are touching the deployer walls).
• Many envelope violations are caused by solar arrays 'loosely' constrained or constrained in a single point.
• At times, many of the faults in the CubeSat industry can be attributed to poor workmanship.
• The duration of the thermal cycling tests is often underestimated. Reaching vacuum conditions or very low temperature range inside the TVAC chamber can be time consuming (e.g. several hours). The facility manager should give sound advice.
• During the TVAC test, the Temperature Reference Point (TRP) shall be located on the satellite and not on the shroud nor on the table of the TVAC chamber. The suggestion is to use at least three different TRPs on the satellite.
• Always perform a thermal analysis in order to correlate the TVAC test with the results of the thermal model.
• Li-ion cells could be very sensitive to thermal cycling and vibe tests, especially cells that are not space qualified. In general, defected cells do not survive the first thermal cycle. If cells survive the first cycle, then they will survive several other cycles.
• If radio-communications are envisioned during the TVAC tests, the potential issues should be carefully investigated. The reverberation on the TVAC chamber and the impedance mismatch, due to modified environment for example, could lead to damages to the COMM system amplifiers. To avoid any danger, it is suggested to communicate with the CubeSat only via the umbilical connector or to connect the transceiver of the CubeSat to an antenna that sits outside the TVAC chamber.
• During TVAC, a special attention should be paid to the batteries since they usually have the most restrictive temperature range. Constant monitoring of their temperature is needed to avoid charging/discharging above/under defined temperatures.
• The use of thermocouples shall be foreseen during the TVAC tests. On-board sensors cannot be used for temperature monitoring because those are the items under test (the temperature readings of internal sensors cannot be used for the validation of the sensors themselves). The thermocouples can be external (i.e. applied on external surfaces of the CubeSat) or internal. In the latter case, the thermocouples should be integrated while assembling the satellite. For FM or PFM, it is not allowed to re-open the CubeSat to remove the internal thermocouples, so their wires should be cut and secured (isolated and fastened).
• Once the FM (or PFM) has undergone acceptance (or protoflight) testing, it cannot be modified anymore in any way. Any modification to the qualified FM or PFM will void the flight qualification status and the launch authority will require re-testing the hardware. This implies that no antenna (or other deployable) can be deployed after the acceptance vibration campaign is concluded.
• Always prepare a contingency plan for the assembly and testing activities. Some failure/problems could occur. And they will in our experience.
• Never use the transceiver with the antenna stowed. The RF coupling generated during transmission can easily damage the signal amplifier.
• The resistor for a burn wire can be easily undersized by mistake. Test it multiple times to verify the correct deployment of solar panels and antennas (also in vacuum). This is a mission critical item.
• The switch travel on many deployment switches or kill swiches is often insufficient to accommodate tolerances built into the dispenser design.
• The switches must not have the ability to 'chatter' inside the deployer.
• When preparing the CAD model always take into account the volume for the glue and the cables. Solid glue can have a non-negligible thickness and it can affect the final assembly.
• Many satellites are put at risk by not having a fault-tolerant design of the kill switch in order to avoid an accidental activation of the CubeSat inside the deployer. Normal spacecraft are required to have a double barrier for the inhibits and sometimes one of these barriers can be implemented via software.
• Remove Before Flight (RBF) items shall be used instead of Apply Before Flight (ABF) ones.
• Keep the system design simple and do not be overambitious by embarking too many payloads and developments (Keep it simple - KISS). Rather split those payloads over multiple missions.
• A high fidelity quality assurance program must be in place during the execution of the whole project. The ECSS standards (e.g. tailored for CubeSat by ESA) shall be used to ensure a high reliability of the design/testing/verification processes.
• The execution of End-To-End Hardware-In-the-Loop tests shall be a priority.
8 COTS Procurement
• When buying COTS components, make sure to also buy the customer service. A piece of hardware without the proper documentation or support is of no use and can drag the project in a huge waste of time.
• When buying COTS, make sure that the last hardware revision is delivered. In the market there are several hardware revisions of the same board around, and those boards are not all properly tracked by companies. In addition, do not forget asking for serial number.
• When buying COTS, make sure the hardware uses the latest firmware available to date. There are always bugs to fix.
• If COTS components are used, proceed with ordering the components very soon. The delivery time of COTS can be very large (even several months). It is better to have a component sitting in a lab and waiting to be used than having engineers sitting around a table and waiting for the delivery.
9 Ground Station
• It is good practice to build/procure a ground station with the help from a radio amateur or a professional. This can avoid a waste of resources, time and patience.
• Perform monthly checks and inspections of the ground station equipment (antenna included) to discover potential issues as early as possible.
• Have spare parts (e.g. replacement RF cables) available.
• Validate the ground station with real transponders in space (e.g. FunCube transponder, ISS APRS).
• Contact the local AMSAT community to receive help in setting up to ground station and obtaining the radio ham license.
• Experience comes with practice. A lot of frustration in the early operation phases comes from not being able to communicate with your satellite. It is good practice to start listening to other satellites in space and get familiar with the hardware beforehand.
• Having a data warehouse on ground can be extremely handy in order to receive and store data packets coming from the numerous radio hams spread around the globe. The radio ham community can really help in boosting up the number of data received on ground by using their own antennas.
• To facilitate the job of the radio hams, prepare a simple and effective software to decode and display the data (e.g. current, temperature, power, etc.) contained in the packets sent by your CubeSat. This software can also be connected with the data warehouse in order to upload the data in real time.
• When using your ground station to communicate with your CubeSat use only the minimum required power for transmission. If radio amateurs’ frequencies are used, remember that those frequencies are shared with the community and a high power transmission can disturb someone else communications.
• In case of emergency (e.g. the satellite becomes deaf, the link budget is not correct), having access to a more powerful ground station can save the mission. Remember not to exceed the peak envelope power (PEP) given by the radio ham community, a dedicated licence is required otherwise for operating the ground station.
10 Early Operations
• The on-board clock in space can be affected by very high time drifts (e.g. 154 sec in 4 weeks). This behaviour can be overlooked on ground because the on-board clock is automatically updated via the umbilical connector. The suggestion is to keep the CubeSat running unplugged from the computer for few days to verify the drift.
• The verification of a successful deployment (e.g. an antenna or a boom) can be very uncertain in space. It is good practice to implement at least two ways for detecting a deployment (e.g. a press switch and a camera, or gyros).
• The number of people (and resources) assigned to the ground operations can really make the difference during LEOP. Do not under estimate the workload in this early phase.
• Teams with flight experience or with a lot of practice with their ground station-CubeSat chain are progressing much faster during the commissioning phase.
• The threshold upper limit on the battery heaters can be a mission killer. If this value is set too high (e.g. 19degC) the CubeSat could be stuck in a loop where the EPS is always trying to heat up the batteries more than the upper limit and the CubeSat is constantly in a power negative safe mode.
• After the deployment from the ISS, the TLE were published the day after and kept being refined for about 5 days. Complete discrimination with accurate TLEs was completed within 10 days from deployment.
• Most of the failures preventing the CubeSats to reach their objectives are originated by unreliable link budgets and poorly designed ADCS.
11 Launch Procurement
• Reserve or start the negotiation with the launch service provider early on in the project. Having a launch date or even a launch contract will give a touch of reality to the project. The students will be motivated and managers will believe on the project.
• One of the major lessons learned from QB50 is that launching more than one CubeSat at the same time can be a difficult business. It is good practice to have a backup launcher (in the event the main launch is suspended/cancelled) and it is important to have good budget margins allocated.
• Typically, Universities are first assembling the CubeSat and only then they look for a launch opportunity. This is a risky approach because it is too late to modify the design of a CubeSat in order to accommodate for the requirements of different launch provider.
• If it is not possible to choose a launch provider early on in the project, it is good practice to design the CubeSat against the most demanding launcher in terms of launch requirements.
• The test requirements given by the launch provider are not easily waived. It is recommended to find the way meeting those requirements instead of finding the way avoiding them.
• If you wish to attend the launch at the launch site, be flexible with your schedule.
12 Conclusion
It is commonly agreed that the reliability and the technical quality of University CubeSats are very pressing issues. It has been observed that the majority of CubeSats having problems in orbit are affected by issues or flaws that could have been avoided through a more careful testing phase. Frequently most CubeSat projects suffer from setbacks during the design and assembly phases, resulting in less time for testing and verification. The testing phase is extremely important and it deserves appropriate allocated resources. The system requirements and the end-to-end tests set up by the QB50 project gave only a high-level overview on the design of the different CubeSats. Consequently, all the low level testing was left to the responsibility of each CubeSat team.
A clear standard is needed to uniform the design/integration/testing/verification activities and increase the overall technical quality of the CubeSats. When the QB50 project was conceived, the proposal was stating that for cost reasons the CubeSats would have not been built to industrial standards. During the execution of the project a clear diversification of the CubeSat market has been observed. Commercial companies have pushed the development of CubeSats to a higher standard. They have reached the reliability level necessary to exploit the CubeSat format and use it in the most different applications, from data relay to security and Earth observation. It is not known to the authors, if commercial companies are applying the standards to deliver a reliability product or their product are simply based on their heritage in space. On the other hand, some Universities and Research Institutes are struggling to have a fully operational CubeSat in-orbit or even to complete the manufacturing and testing on ground. In this scenario, it appears clear that the available resources and the use of standards are key factors when building a successful CubeSat project.
Comply with standards means having to comply with a large number of requirement. As an example, only the ECSS standard for verification (ECSS-E-ST-10-02C) has more than 120 requirements alone. In this context, the European Space Agency started an effort to tailor the ECSS standards for CubeSat and the result is the document ‘Tailored ECSS Engineering Standards for In-Orbit Demonstration CubeSat Projects Issue 1’. This document is an efficient summary of which standards are applicable or shall be use as guidelines during the execution of a CubeSat project. As a result of the tailoring, there are still more than 230 different requirements applicable to a CubeSat project. This is more than three times the number of requirements needed compared to a project like QB50. It has been observed during the QB50 project that the teams involved had troubles in understanding and complying with the requirements. Sometimes the teams did not provide adequate documents on their designs and ignored some requirements marking them as compliant. During the integration phase in the deployers or when the CubeSat was already in space, we found out that some requirements were not met.
By ESA standards, the compliancy to each requirement shall be supported by a clear evidence of the compatibility. In general, the proof of evidence is given with an exhaustive summary and with a reference to a more detailed description to be found in the design documents. This methodology was not required in QB50. The amount of work necessary for the teams to give evidence of the compatibility of the CubeSat with the standards can be very demanding (and expensive). In general, the students working on the CubeSat do not have the necessary experience to fill in a compliancy table with a satisfactory level of clarity and detail. The University shall then have access to an experienced technical support and they shall have reasonable resources to perform the tasks. By experience, if the CubeSat project is supported only by University funds, the available budget covers mainly the cost of the hardware to build the CubeSat and partially the cost of manpower. In this situation, it is extremely difficult to setup a project that complies with highly demanding standards and that requires high work loads.
As a conclusion, it is recommended to Universities to follow standards and in particular to follow ESA tailored ECSS standards for testing because of their completeness. Such recommendation can be applicable on the following conditions:
• Each CubeSat project shall have a budget reserved to prepare the documents and comply with the standards (e.g. ESA funded CubeSats have an overall budget of more than 1M euro each).
• Universities/Research Institutes shall have a senior engineer (or research fellow with experience) assigned to the PA/QA activities. The responsible shall prepare all review documents and be sure that the CubeSat complies with the standards.
• The funding agency shall be prepared to review the large amount of documents at each milestone review.
Potential Impact:
The Project have demonstrated that access to space can be eased by the use of the CubeSat concept and innovative satellite-launcher interfaces. The QuadPack deployer, developed within the Project, has found to be useful in other activities in provided low-cost access to space and several other FP7 projects with a CubeSat launch included in their scope have the QuadPack as a baseline for launching the CubeSat into space. Moreover, an unprecedented multi-point measurement of the thermosphere will have been achieved.
In addition, Europe has now a leading role in the development of CubeSats for scientific and educational purposes with even stronger SMEs in the new space business. During the Project at least 3 new start-up companies were born. Increasing space competence among European students will improve the innovation of the future European society.
List of Websites:
Website: www.qb50.eu
Contact: masutti@vki.ac.be
The QB50 Project demonstrated the possibility of launching a network of 36 CubeSats built by CubeSat teams from all over the world to perform first-class science and in-orbit demonstration in the largely unexplored middle and lower thermosphere. Space agencies are currently not pursuing a multi-spacecraft network for in-situ measurements in the middle and lower thermosphere because the cost of a network of a number of satellites built to industrial standards would be very high and not justifiable in view of the limited orbital lifetime. No atmospheric network mission for in-situ measurements has been carried out in the past or is planned for the future. A network of satellites for in-situ measurements in the middle and lower thermosphere can only be realised by using very low-cost satellites, and CubeSats are the only realistic option. The Project demonstrated the sustained availability of low-cost launch opportunities, for launching small payloads into low-Earth orbit; these could be microsatellites or networks of CubeSats or nanosats or many individual small satellites for scientific or technological research. The Project included the development of a deployment system for the deployment into orbit of a large number of single, double or triple CubeSats. The system can be easily adapted to other missions. QB50 provided also a launch opportunity for key technology demonstration on IOD CubeSats such as propulsion systems and aerobrakes. Up to 36 CubeSats have been launched together to low earth orbit. Due to atmospheric drag, the orbits of the CubeSats will decay and progressively lower and lower layers of the thermosphere will be explored without the need for on-board propulsion. QB50 is the first University built CubeSat networks in orbit
Project Context and Objectives:
Since its start, the QB50 project has been focusing on the following four main objectives:
• Facilitating access to space
• Scientific research
• Education
• In-orbit demonstration
1 Facilitating access to space
One of the main purposes of the QB50 project was to achieve a sustained and affordable access to space for small-scale research space missions and planetary exploration. To this end, the project was conceived around a Russian Shtil 2.1 rocket. This rocket was intended to launch the entire QB50 constellation as a primary customer. As a member of the QB50 Consortium, Innovative Solutions in Space (ISIS) was charged to design a deployment system that would have allowed deploying a constellation of CubeSats from a single rocket. The first multi-satellite dispenser was made of fifty single satellite slots. It was later found to be advantageous, for accommodation purposes, to cluster four dispensers together allowing the independent ejection of four 2-3U satellites, or fewer with larger size. Those modules are now called ISIS QuadPack.
Important novel features include the integration of the door opening mechanism and a standalone control module to better synchronize the door openings. The mechanism ejecting the CubeSat, consisting of the pusher plate and the ejection spring, was designed to allow the accommodation of the QB50 science unit within the centre of the spiral spring. Since its development and the maiden flight with the QB50 precursor launch campaign in 2014, this deployment system has been flown 39 times on 7 different launch vehicles (Antares, VEGA, PSLV, Dnepr, Soyuz and LM-2D) hence proving its reliability and flexibility. The fact that the global CubeSat community, the launch providers, the European industry and in general the small satellites world are benefiting from a technology developed within QB50 with European funds, is a remarkable achievement of the project.
Between 2012 and 2015, the success of the QB50 mission was jeopardized by the end of three main launch programmes: the Russian Shtil, the Brazilian-Ukrainian Cyclone 4 and Russian-Ukrainian Dnepr. These events introduced a number of delays in the schedule and some important changes in the implementation of the project. Other more expensive launch opportunities were available on the market by that time, but no option fitted the budget available or the time constraints. It was then decided to adopt a split launch strategy to decrease both the risks and the costs. As a result, 28 CubeSats have been deployed at 415km altitude 52deg inclination from the ISS from May 16th to May 25th 2017 and 8 CubeSats have been launched in an orbit at 505km altitude 97.1deg inclination by a PSLV rocket on June 23rd 2017. Both launches allowed distributing the constellation between two different orbital planes (higher polar orbit and lower mid latitudes orbit) in order to cover a larger portion of the thermosphere.
The objective ‘Facilitating access to space’ was not solely achieved by procuring an affordable launch for the constellation but also by the unprecedented undertaking in terms of teamwork and the centralized coordination of the administration paperwork.
The QB50 Consortium guided the CubeSat teams by facilitating their efforts to develop and ultimately to launch their satellites. For example, the Consortium provided technical guidance for CubeSat development through the definition of system requirements, advice and recommendations for design and milestone reviews. To facilitate the reviews, templates for the technical documents were provided. They allow for an efficient and effective reporting of the technical design, the development status, and the identification of risks and non-compliances. The review process, conducted mainly by the Consortium itself, helps in mitigating potential flaws in the design and integration of the CubeSats. CubeSats in general are subject to high mortality particularly during their infancy. Hence, a priority for VKI was ensuring high quality engineering work.
The Consortium supported the participant teams also by coordinating all necessary international legal permission for launch. The satellites were registered by VKI with the state of Belgium. In addition, the majority of the CubeSats benefitted from the radio frequency coordination carried out by VKI in collaboration with AMSAT and IARU, the Belgian Institute for Post and Telecom (BIPT) and ITU. This centralized coordination was very efficient and it left the CubeSat teams caring only about their own national laws such as export/import regulations. Despite being registered in Belgium, each satellite remains the property of the organization that has developed it and it is operated by its own ground station.
2 Scientific Research
The scientific objective of the QB50 project is addressed by carrying out an unprecedented measurement campaign in the mid-lower thermosphere, between 300-450km altitude. This region is the least explored layer of the atmosphere because is difficult or risky to be reached. Typically, this region is too high to be reached by ground based instruments. Measurement campaigns using LIght Detection And Ranging (LIDAR) systems or sounding rockets can only probe the composition of the atmosphere for a short period of time below 200km altitude. Sounding rockets are only flying few times per year and LIDAR can only measure on vertical columns. Only incoherent scatter radars (like the EISCAT facility in Norway) can reach higher altitude up to 800 km, but those radars are only able to measure the electron density in the ionosphere and no information is given about the gas composition. On the other hand, large satellites allow for long duration in-situ measurements below 400km but only with a limited spatial resolution. Missions like CHAMP, GOCE and SWARM were flown below 450km in the thermosphere and the instruments on board of the spacecraft (S/C) continued the measurement acquisition during their orbital decay until the loss of the satellite. To increment the lifetime of the mission, other atmospheric explorers were flown in the past in highly elliptical orbits (typically below 250 km perigee, and above 1000 km apogee); they carried experiments for single-point, in-situ measurements but the time spent in the lower thermosphere was only a few tens of minutes. The NASA Explorer Series of S/C are among the most known atmospheric explorers.
The multi-point, in-situ measurements of QB50 will be complementary to the ground based instruments and satellite in-situ measurements. The developers of the atmospheric models will benefit from the measurements obtained by QB50 in the lower thermosphere. This will lead to tools that are more precise and more robust in modelling the upper atmosphere. Ultimately, the users of these models will obtain more accurate results in terms of drag in the thermosphere, debris trajectory analysis and debris mitigation.
The majority of the CubeSats of the QB50 constellation carry one of the 34 atmospheric sensors. These atmospheric sensors, called hereinafter sensor units, are developed and manufactured by the Consortium and they serve as the primary payload for the CubeSats participating in the project. This swarm of 34 sensor units is constituted by three set of instruments:
• 10 Ion and Neutral Mass Spectrometers (INMS) provided by the Mullard Space Science Laboratory (MSSL). This instrument can measure the most prominent heavy particles in the thermosphere such as O, O2, NO and N2. By changing its operating mode, the instrument can either measure neutral or ionized species.
• 14 Flux Probe EXperiment (FIPEX) sensors units supplied by the Technical University of Dresden (TUD). The instrument measures atomic and molecular partial pressures by means of two separate solid electrolyte sensors.
• 10 multi Needle Langmuir Probe (mNLP) supplied by the University of Oslo (UiO). The instrument can probe the electron density and possibly the electron temperature of the thermosphere.
3 Education
QB50 invited universities worldwide to join the project and send a satellite to space. Numerous proposals have then been received and the CubeSats been selected through a competitive process. As a result, the QB50 CubeSats have been designed and assembled by a great number of young engineers, supervised by experienced staff at their universities and guided by the QB50 Consortium through reviews and feedbacks. More than 300 students and more than 50 professional from 24 different countries participated in the largest international collaboration in the space sector. Those young engineers did not only learn about the challenges of space engineering but they will leave their universities with hands-on experience in an international project.
4 In-orbit demonstration
The fourth objective of the QB50 project is to serve as a platform for technology demonstration. A handful of QB50 CubeSats are also carrying proprietary payloads on board. These payloads are mainly technologies to be qualified in space. Here few examples of the technologies tested:
• InflateSail is a 3U CubeSat built by the Surrey Space Centre (SSC) whose primary objective is the flight demonstration of an inflatable sail structure. InflateSail consists of a 1 m long inflatable cylindrical boom, which supports approximately a 3m x 3m tape-spring supported sail. The technology has been proven to be very successful. After an orbital injection at 505km altitude on June 23rd 2017, the CubeSat has de-orbited successfully on September 3rd 2017 (72 days after the sail deployment).
• LituanicaSAT-2 is a 3U CubeSat built by the University of Vilnius and its spin-off company. The CubeSat validated successfully on July 5th 2017 a small chemical propulsion system based on a green monopropellant. The propulsion system is currently commercialized.
Project Results:
This section is a collection of all the lessons learned accumulated by the authors during the last 6 years. Due to the broad overview of the project, the lessons learned contained in this document are not only a synthesis of the heritage on CubeSat design, testing and assembly but also a summary of the experience built up during the coordination of the first constellation of University CubeSats. These lessons can be used not only as a reference for the implementation of future CubeSat constellations but also as a simple collection of guidelines for the design, testing and review of future CubeSat projects. All lessons collected hereinafter are divided in different engineering topics for easy usability. In order to better summarize the lessons learned, they are presented as a list of items.
1 Management
• When starting a CubeSat project (or any project) it is good practice to assign well-defined roles and responsibilities in the team.
• Use only one reference system for the design of the complete satellite. Define it at the beginning of the project and share it to all the members of the team.
• Perform regular/weekly meetings to keep the team updated on subsystems, interfaces and general design. Keep a configuration control document.
• Start looking into export/import laws of your country from the beginning. In general, start applying for an export license at day one. The export license is a lengthily process and it could require some paperwork.
• Often times, developers underestimate the efforts for ITU filing and frequencies coordination.
• If the environmental test facilities (TVAC chamber, shaker, etc) are not in house, remember to plan in the budget the costs for the test campaign at external facilities. A reasonable estimate is around 10k euro (including the travel costs).
• In the academia the manpower turnover rate is high, thus, students come and go during the project. In order to pass along the work to the new members, all work must be documented. Without documentation, it will be difficult to bring the new members up to speed. It is suggested to start writing a document for each subsystem at the beginning of the development. Each document shall be updated monthly by the responsible of the subsystem.
• In the University, the time spend by master students in the project is in general between 3-6 months. PhD students can be enrolled for much longer and they could help in keeping continuity in the project and help mentoring new students.
• If costs are the driver, then a detailed cost breakdown should be prepared: design, assembly, procurements, integration, testing, launch, early orbit, on-orbit operations, data analysis, and any additional science analyses that may be required.
• Again, do not forget planning in the budget the funds for in-orbit operations. Taking the project to the launch pad is only part of the journey. Carefully planned operations and their execution requires considerable funds. It is very difficult to achieve the mission objectives without a consolidated operation plan.
• Define clear mission objectives since the beginning of the project. This will keep the focus of students, professors and managers on the objectives to achieve.
• Ensure that the objectives and requirements have achievable targets and that they can provide exact values or conditions. This will help to keep track of the progresses. Every objective can be expressed by a target value/status and a threshold value/status, e.g. the target is the more challenging value/status to achieve, the threshold is the minimum acceptable to declare an objective partially reached.
• Every CubeSat should have a user manual with it. This document should be clear and concise in order to be understood by anyone, especially by people that are not part of the developing team (such as by an external launch service company). The document shall include at least the handling procedure, the charging procedure and the deployer integration procedure. All procedures shall be documented step-by-step with clear pictures and a reference system.
• All procedures described in the user manual shall be clear and unique, without any ambiguity on the actions to be performed.
• The final version of the user manual shall include detailed and clear pictures showing the equipment, interfaces, connectors, etc. The purpose of the pictures is to provide a visual reference of the nominal appearance of a certain item: this is useful to immediately detect damages, shape changes, unexpected modifications that may have occurred accidentally during transportation.
2 On-Board Computer
• Always include a bootloader in the OBC. In case of corrupted software, it is still possible to recover the S/C by loading a backup or a simplified version of the operating system and establish communication with the ground.
• Always include an umbilical connector to the OBC that is accessible when the CubeSat is fully integrated. This connector will be useful to run verification tests and download logs or data from the CubeSat at any time and without the use of a (portable) ground station.
• Make sure that the processor and the memory implemented in the OBC are compatible or they provide enough resources to run the software that it is going to be used. A good practice is to involve the software engineer in the early discussions and preliminary design of the OBC hardware.
3 Software Development
• Kick-off the software development soon after the start of the CubeSat project.
• The software shall include a software upgrade/patch capability.
• Software upgrades or patches shall only contain the necessary piece of the codes to be upgraded/patched. Never design a software where the entire software needs to be uploaded because this could be too demanding in terms of uplink.
• Design a software with a code and a parameter area to simplify patching.
• The software team should have frequent interaction with the system engineer and the rest of the team. This will help to design a software in harmony with the hardware and the mission.
• Use revision control software to archive and track changes on test and flight-software.
• Always implement a way to reset the counters in the CubeSat in case of an accidental release of the switches during the integration into the deployer or the fit-check activities.
• Allow software updates to be done through the umbilical connector.
• Always include a safe mode in the software in case of problems during in-orbit operations. The safe mode shall stop all unnecessary subsystems and it shall charge the batteries until a comfortable charge level is reached in order to establish a stable link with ground.
• Safe mode shall support software patching.
• Software implementation is a perfect example of the 80/20 rule. 80% of the work is done in 20% of the time and the remaining 20% of the work consumes the last 80% of the time.
4 Electrical Power Subsystem
• Solar cells are perhaps the most critical component in terms of delivery time, the most expensive and the most affected by market fluctuations. Try to order the solar cells much in advance and get multiple quotations. Spare cells should be procured (if they can be afforded) because they are extremely brittle.
• The consequences of an abrupt interruption of the current while charging the batteries (e.g. removing the charger before the batteries are completely charged) should always be investigated.
• Many batteries are provided without any physical protection circuitry and this protection is sometimes implemented via software. A hardware protection is always preferred over a software protection. Moreover, the software protection is usually not accepted by the safety control board if you are planning to launch from the ISS.
• The batteries with hazardous chemicals are not allowed to fly on the ISS. The list of hazardous chemicals shall be read before procuring the batteries.
• The power budget should be evaluated for the worst case and always account for 20% margins (or more). The nodal precession/recession of the orbit could (and it will) dramatically impact the power generation after few months in the mission.
• It is good practice to build the EPS compatible with the ISS requirements: 3 inhibits (including one between batteries and ground), ISS-version of COTS boards, tested batteries. This approach will save many problems when choosing the launch provider.
• Check the maximum depth-of-discharge and verify sufficient battery charging in case of frequent mode-switching with typical operational profiles.
• Use conservative values for efficiencies from datasheets or better measure the EPS/system performance.
• The use of battery heaters is always encouraged. Very often, the batteries are operating in too cold conditions in orbit. Consequently, their performances are decreased.
• The Safe mode shall be power positive in any event and ensure power and communication with all attitudes.
• Do not require attitude control or other functionalities (e.g. successful deployment of panels) for the power budget calculation of the safe-mode.
• It is good practice to procure extra Li-ion batteries. Some of them can prematurely die or they are defective.
5 Attitude Determination and Control Subsystem
• Test your GPS on ground until you get a proper fix. Always verify if the GPS software can cope with the large Doppler shift in orbit.
• Verify that the GPS board has the proper firmware to work in space. Usually the GPS hardware is delivered with a ground enabled firmware and not with a space enabled firmware. GPS hardware with ground-enabled firmware does not work in space.
• A GPS space firmware might require a COCOM license valid both for the country where the CubeSat is integrated and for the country where the CubeSat is launched. Check with the authorities or the GPS hardware provider.
• Remember that the GPS firmware for space is a dual-use or ITAR restricted item.
• When sizing the attitude control system take into account all disturbances that can generate an applied moment to the CubeSat. Magnetorquers are enough for general purposes if used in orbits higher that 400km altitude. Lower that 400km altitude a combination of magnetorquers and reaction wheels is preferred. Do not forget that moment generated by atmosphere drag between 200-350km altitude is not negligible and it could be much higher that other forcing perturbations.
• Residual magnetic dipoles in the CubeSat can generate unwanted magnetic moments in space. Degauss the satellite before the launch.
• To avoid static magnetic moments, use non-magnetic metal parts (e.g. A4 steel nuts & bolts) and try to screen magnetic components (e.g. permanent magnets, brushless DC motors, solenoid valves) with Mu-Metal plates.
• Always check if there is any electro-magnetic coupling between magnetorquer and magnetometer(s). It is a good practice to place the magnetometer as far as possible from any electric components, usually the best option is to place it on a boom.
• To avoid dynamic magnetic moments, limit the enclosed area between supply (power) and return (GND) currents on PCBs, solar panels and harnesses.
• Use twisted wires with return and no soldering, no screwing and no wire-stripping.
• Long wires on the solar panels can generate current loops and consequently high dynamic magnetic moments, which can spin-up the CubeSat very quickly. These forces are difficult to control and to dump in space.
• When detumbling from high rates, the problem is that normal detumbling controllers can be sample-time limited and therefore not sufficient for detumbling the S/C. It is good practice to use an active magnetic damping controller with fast sampling period. Select the largest B-field component axis and choose an orthogonal axis magnetorquer with the largest ΔB-field measurement to produce a damping torque to reduce the satellite’s spin rate.
• Select low power and low cost 3-axis magnetometers that allow continuous measurement capability.
• Ensure a good measurement resolution of the magnetometer, 3.5milli-Gauss (350nT) is about 1deg attitude error.
• Ensure that the magnetometer has low noise and good sensitivity in the measurement range between 0.2 to 0.6 Gauss.
• The magnetometer calibration curve is temperature dependent. If you are planning to mount your magnetometer on a boom, take care of performing a calibration also as a function of temperature. Because the magnetometer is outside the shell of a CubeSat, it will experience some extreme temperature variations.
• Due to a latency between the magnetometer measurement and the torquer activation, your ADCS could not behave as expected. Make sure you are considering latency times in your ADCS routines.
6 Communication Subsystem
• The antenna pattern(s) shall always be characterized.
• Include as many available sub-system telemetry parameters in the beacon as possible.
• Having a beacon can facilitate early orbit discrimination in case of a cluster launch (which can easily involve a hundred of CubeSats nowadays).
• Some COTS transceiver cannot be fine-tuned to all frequencies (e.g. only at 25 kHz steps). Make sure you can reach the frequency coordinated by IARU or make IARU aware of the limitation when requesting the coordination.
• The implementation of the ESA Packet Utilization Standard (PUS) in the on-board software is encouraged. Nevertheless, the time and resources needed for the deployment of PUS must not be underestimated.
• The CubeSat shall transmit the beacon automatically 30 mins after deployment (i.e. activation). The beacon activation shall be automated and it should not require any activation from ground. In case the CubeSat is malfunctioning during the early orbit operations (LEOP), the data contained in the beacon are essential for the debugging.
• It is good practice to simulate a real communication scenario with the S/C and the ground station in the loop. A not properly tested ground station or a wrong link budget cause most of the problems affecting the LEOP.
• A conservative link budget is crucial for the success of the mission. Ensure that both the uplink and downlink can be close even in the worst conditions (i.e. CubeSat tumbling with high rates, partial deployment of the antennas).
7 Manufacturing, Assembly, Integration, Verification and Testing
• A QM/FM approach is recommended against a PFM approach. It is a good practice (if budget allows) to have a QM (or an EM) for troubleshooting problems when the FM is in space.
• Having a QM in the lab is also a very useful because the components can serve as spares for the FM final integration. In our experience few ADCS, EPS and OBC stop working (because of mistreatment) only few days before the launch preparation activities.
• If possible, include all digital communication lines (UART, I2C, SPI, CAN) on the umbilical connector to monitor and/or inject packets to different sub-systems. This is especially useful for the radio to OBC connection to debug communication problems.
• Do not be afraid of testing your CubeSat on the shaker. Follow the standards (e.g. NASA GEVS) and do not over test it.
• When receiving a component/subsystem, test it! When assembling a component, test it! When assembling a CubeSat, test it! And then re-test everything again! The majority of premature CubeSat death in space is caused by shortcuts during the testing phase.
• Never trust the datasheet or a manual for a component or a subsystem. Test the performances in a real environment instead. Most of the times the values in the datasheet are obtained in a lab under controlled environment and they cannot be replicated in the real usage.
• Running full end-to-end mission test on the hardware is an excellent way to learn and troubleshoot the entire system, even if the full test takes several days. The suggesting is to simulate the deployment, the booms and antennas, the de-tumbling (perhaps using some ad-hoc routines to simulate it) and the first ground contact using your ground station in the loop.
• In case you do not have a shaker and/or a TVAC chamber easily accessible, make sure you reserve a slot for the environmental tests in a proper test facility well in advance. These facilities tend to be extremely crowded sometimes, and any delay can dramatically affect your schedule.
• Keep an integration logbook and pictures for each step of the integration activities. Any deviation and non-conformance shall be tracked, documented and reported. In other words, a rigorous PA/QA procedure shall be in place.
• Keep the amount of additional harness to a minimum.
• Verify the correct connection of TX/RX lines for communication protocols like UART.
• When you are preparing for the environmental tests, make sure there is a list of items/tools that are need to perform the tests. Very often, those tests are one-shot and performed in a remote location and there will be no time to go back in the lab if a tool has been forgotten.
• An assembled CubeSat could look very different from the original CAD model. It is good practice to measure all dimensions with great care. It is known that 60% of the failures during the integration in the deployer is caused by a CubeSat with dimensions out of specs.
• Perform all kind of functional test and deployment test during TVAC. Sometime the hardware (and the software) can behave differently when not at room temperature.
• Prepare a test plan and procedures to make sure ALL functions/subsystems are tested. Avoid testing each function/subsystem one by one but prefer testing them together or in combinations. Unexpected electric or software coupling between two or more components (e.g. RF coupling between two transceivers that are working at the same time can lead to undesired damages) are a cause of failures on CubeSats.
• Account at least 2 weeks for the environmental tests.
• Before leaving the lab for the testing or integration activities, perform a dry run of the expected tasks to troubleshoot the step-by-step procedure.
• Create clear test-procedures and documentation of activities and results to allow for repeatability.
• From a management point of view, the Test Readiness Review (TRR) shall be an important milestone. It represents the point when you CubeSat is fully assembled and ready to be qualified for launch.
• The shock test is indeed a very severe test, which may damage partially the sub-components and the most delicate interfaces. Consequently, this test is very often avoided among CubeSat manufacturers (i.e. because the deployer is damping the shock loads to the CubeSat). Some launch providers are now requiring the shock test as a mandatory test. It is good practice to use an Engineering Structural Model for the shock test and avoid overstressing the flight hardware. The shock test will prove to the launch provider that the CubeSat structure is not breaking into pieces inside the deployer.
• The assembly order can induce stresses on the structure of CubeSat. As a result, the structure can twist or warp causing unwanted non-conformances.
• The failure in respecting the rail tolerances is a surprisingly common issue among CubeSats.
• Tape antennas that wrap around the CubeSat have a tendency to result in envelope violations inside the deployer (i.e. some part of the CubeSat are touching the deployer walls).
• Many envelope violations are caused by solar arrays 'loosely' constrained or constrained in a single point.
• At times, many of the faults in the CubeSat industry can be attributed to poor workmanship.
• The duration of the thermal cycling tests is often underestimated. Reaching vacuum conditions or very low temperature range inside the TVAC chamber can be time consuming (e.g. several hours). The facility manager should give sound advice.
• During the TVAC test, the Temperature Reference Point (TRP) shall be located on the satellite and not on the shroud nor on the table of the TVAC chamber. The suggestion is to use at least three different TRPs on the satellite.
• Always perform a thermal analysis in order to correlate the TVAC test with the results of the thermal model.
• Li-ion cells could be very sensitive to thermal cycling and vibe tests, especially cells that are not space qualified. In general, defected cells do not survive the first thermal cycle. If cells survive the first cycle, then they will survive several other cycles.
• If radio-communications are envisioned during the TVAC tests, the potential issues should be carefully investigated. The reverberation on the TVAC chamber and the impedance mismatch, due to modified environment for example, could lead to damages to the COMM system amplifiers. To avoid any danger, it is suggested to communicate with the CubeSat only via the umbilical connector or to connect the transceiver of the CubeSat to an antenna that sits outside the TVAC chamber.
• During TVAC, a special attention should be paid to the batteries since they usually have the most restrictive temperature range. Constant monitoring of their temperature is needed to avoid charging/discharging above/under defined temperatures.
• The use of thermocouples shall be foreseen during the TVAC tests. On-board sensors cannot be used for temperature monitoring because those are the items under test (the temperature readings of internal sensors cannot be used for the validation of the sensors themselves). The thermocouples can be external (i.e. applied on external surfaces of the CubeSat) or internal. In the latter case, the thermocouples should be integrated while assembling the satellite. For FM or PFM, it is not allowed to re-open the CubeSat to remove the internal thermocouples, so their wires should be cut and secured (isolated and fastened).
• Once the FM (or PFM) has undergone acceptance (or protoflight) testing, it cannot be modified anymore in any way. Any modification to the qualified FM or PFM will void the flight qualification status and the launch authority will require re-testing the hardware. This implies that no antenna (or other deployable) can be deployed after the acceptance vibration campaign is concluded.
• Always prepare a contingency plan for the assembly and testing activities. Some failure/problems could occur. And they will in our experience.
• Never use the transceiver with the antenna stowed. The RF coupling generated during transmission can easily damage the signal amplifier.
• The resistor for a burn wire can be easily undersized by mistake. Test it multiple times to verify the correct deployment of solar panels and antennas (also in vacuum). This is a mission critical item.
• The switch travel on many deployment switches or kill swiches is often insufficient to accommodate tolerances built into the dispenser design.
• The switches must not have the ability to 'chatter' inside the deployer.
• When preparing the CAD model always take into account the volume for the glue and the cables. Solid glue can have a non-negligible thickness and it can affect the final assembly.
• Many satellites are put at risk by not having a fault-tolerant design of the kill switch in order to avoid an accidental activation of the CubeSat inside the deployer. Normal spacecraft are required to have a double barrier for the inhibits and sometimes one of these barriers can be implemented via software.
• Remove Before Flight (RBF) items shall be used instead of Apply Before Flight (ABF) ones.
• Keep the system design simple and do not be overambitious by embarking too many payloads and developments (Keep it simple - KISS). Rather split those payloads over multiple missions.
• A high fidelity quality assurance program must be in place during the execution of the whole project. The ECSS standards (e.g. tailored for CubeSat by ESA) shall be used to ensure a high reliability of the design/testing/verification processes.
• The execution of End-To-End Hardware-In-the-Loop tests shall be a priority.
8 COTS Procurement
• When buying COTS components, make sure to also buy the customer service. A piece of hardware without the proper documentation or support is of no use and can drag the project in a huge waste of time.
• When buying COTS, make sure that the last hardware revision is delivered. In the market there are several hardware revisions of the same board around, and those boards are not all properly tracked by companies. In addition, do not forget asking for serial number.
• When buying COTS, make sure the hardware uses the latest firmware available to date. There are always bugs to fix.
• If COTS components are used, proceed with ordering the components very soon. The delivery time of COTS can be very large (even several months). It is better to have a component sitting in a lab and waiting to be used than having engineers sitting around a table and waiting for the delivery.
9 Ground Station
• It is good practice to build/procure a ground station with the help from a radio amateur or a professional. This can avoid a waste of resources, time and patience.
• Perform monthly checks and inspections of the ground station equipment (antenna included) to discover potential issues as early as possible.
• Have spare parts (e.g. replacement RF cables) available.
• Validate the ground station with real transponders in space (e.g. FunCube transponder, ISS APRS).
• Contact the local AMSAT community to receive help in setting up to ground station and obtaining the radio ham license.
• Experience comes with practice. A lot of frustration in the early operation phases comes from not being able to communicate with your satellite. It is good practice to start listening to other satellites in space and get familiar with the hardware beforehand.
• Having a data warehouse on ground can be extremely handy in order to receive and store data packets coming from the numerous radio hams spread around the globe. The radio ham community can really help in boosting up the number of data received on ground by using their own antennas.
• To facilitate the job of the radio hams, prepare a simple and effective software to decode and display the data (e.g. current, temperature, power, etc.) contained in the packets sent by your CubeSat. This software can also be connected with the data warehouse in order to upload the data in real time.
• When using your ground station to communicate with your CubeSat use only the minimum required power for transmission. If radio amateurs’ frequencies are used, remember that those frequencies are shared with the community and a high power transmission can disturb someone else communications.
• In case of emergency (e.g. the satellite becomes deaf, the link budget is not correct), having access to a more powerful ground station can save the mission. Remember not to exceed the peak envelope power (PEP) given by the radio ham community, a dedicated licence is required otherwise for operating the ground station.
10 Early Operations
• The on-board clock in space can be affected by very high time drifts (e.g. 154 sec in 4 weeks). This behaviour can be overlooked on ground because the on-board clock is automatically updated via the umbilical connector. The suggestion is to keep the CubeSat running unplugged from the computer for few days to verify the drift.
• The verification of a successful deployment (e.g. an antenna or a boom) can be very uncertain in space. It is good practice to implement at least two ways for detecting a deployment (e.g. a press switch and a camera, or gyros).
• The number of people (and resources) assigned to the ground operations can really make the difference during LEOP. Do not under estimate the workload in this early phase.
• Teams with flight experience or with a lot of practice with their ground station-CubeSat chain are progressing much faster during the commissioning phase.
• The threshold upper limit on the battery heaters can be a mission killer. If this value is set too high (e.g. 19degC) the CubeSat could be stuck in a loop where the EPS is always trying to heat up the batteries more than the upper limit and the CubeSat is constantly in a power negative safe mode.
• After the deployment from the ISS, the TLE were published the day after and kept being refined for about 5 days. Complete discrimination with accurate TLEs was completed within 10 days from deployment.
• Most of the failures preventing the CubeSats to reach their objectives are originated by unreliable link budgets and poorly designed ADCS.
11 Launch Procurement
• Reserve or start the negotiation with the launch service provider early on in the project. Having a launch date or even a launch contract will give a touch of reality to the project. The students will be motivated and managers will believe on the project.
• One of the major lessons learned from QB50 is that launching more than one CubeSat at the same time can be a difficult business. It is good practice to have a backup launcher (in the event the main launch is suspended/cancelled) and it is important to have good budget margins allocated.
• Typically, Universities are first assembling the CubeSat and only then they look for a launch opportunity. This is a risky approach because it is too late to modify the design of a CubeSat in order to accommodate for the requirements of different launch provider.
• If it is not possible to choose a launch provider early on in the project, it is good practice to design the CubeSat against the most demanding launcher in terms of launch requirements.
• The test requirements given by the launch provider are not easily waived. It is recommended to find the way meeting those requirements instead of finding the way avoiding them.
• If you wish to attend the launch at the launch site, be flexible with your schedule.
12 Conclusion
It is commonly agreed that the reliability and the technical quality of University CubeSats are very pressing issues. It has been observed that the majority of CubeSats having problems in orbit are affected by issues or flaws that could have been avoided through a more careful testing phase. Frequently most CubeSat projects suffer from setbacks during the design and assembly phases, resulting in less time for testing and verification. The testing phase is extremely important and it deserves appropriate allocated resources. The system requirements and the end-to-end tests set up by the QB50 project gave only a high-level overview on the design of the different CubeSats. Consequently, all the low level testing was left to the responsibility of each CubeSat team.
A clear standard is needed to uniform the design/integration/testing/verification activities and increase the overall technical quality of the CubeSats. When the QB50 project was conceived, the proposal was stating that for cost reasons the CubeSats would have not been built to industrial standards. During the execution of the project a clear diversification of the CubeSat market has been observed. Commercial companies have pushed the development of CubeSats to a higher standard. They have reached the reliability level necessary to exploit the CubeSat format and use it in the most different applications, from data relay to security and Earth observation. It is not known to the authors, if commercial companies are applying the standards to deliver a reliability product or their product are simply based on their heritage in space. On the other hand, some Universities and Research Institutes are struggling to have a fully operational CubeSat in-orbit or even to complete the manufacturing and testing on ground. In this scenario, it appears clear that the available resources and the use of standards are key factors when building a successful CubeSat project.
Comply with standards means having to comply with a large number of requirement. As an example, only the ECSS standard for verification (ECSS-E-ST-10-02C) has more than 120 requirements alone. In this context, the European Space Agency started an effort to tailor the ECSS standards for CubeSat and the result is the document ‘Tailored ECSS Engineering Standards for In-Orbit Demonstration CubeSat Projects Issue 1’. This document is an efficient summary of which standards are applicable or shall be use as guidelines during the execution of a CubeSat project. As a result of the tailoring, there are still more than 230 different requirements applicable to a CubeSat project. This is more than three times the number of requirements needed compared to a project like QB50. It has been observed during the QB50 project that the teams involved had troubles in understanding and complying with the requirements. Sometimes the teams did not provide adequate documents on their designs and ignored some requirements marking them as compliant. During the integration phase in the deployers or when the CubeSat was already in space, we found out that some requirements were not met.
By ESA standards, the compliancy to each requirement shall be supported by a clear evidence of the compatibility. In general, the proof of evidence is given with an exhaustive summary and with a reference to a more detailed description to be found in the design documents. This methodology was not required in QB50. The amount of work necessary for the teams to give evidence of the compatibility of the CubeSat with the standards can be very demanding (and expensive). In general, the students working on the CubeSat do not have the necessary experience to fill in a compliancy table with a satisfactory level of clarity and detail. The University shall then have access to an experienced technical support and they shall have reasonable resources to perform the tasks. By experience, if the CubeSat project is supported only by University funds, the available budget covers mainly the cost of the hardware to build the CubeSat and partially the cost of manpower. In this situation, it is extremely difficult to setup a project that complies with highly demanding standards and that requires high work loads.
As a conclusion, it is recommended to Universities to follow standards and in particular to follow ESA tailored ECSS standards for testing because of their completeness. Such recommendation can be applicable on the following conditions:
• Each CubeSat project shall have a budget reserved to prepare the documents and comply with the standards (e.g. ESA funded CubeSats have an overall budget of more than 1M euro each).
• Universities/Research Institutes shall have a senior engineer (or research fellow with experience) assigned to the PA/QA activities. The responsible shall prepare all review documents and be sure that the CubeSat complies with the standards.
• The funding agency shall be prepared to review the large amount of documents at each milestone review.
Potential Impact:
The Project have demonstrated that access to space can be eased by the use of the CubeSat concept and innovative satellite-launcher interfaces. The QuadPack deployer, developed within the Project, has found to be useful in other activities in provided low-cost access to space and several other FP7 projects with a CubeSat launch included in their scope have the QuadPack as a baseline for launching the CubeSat into space. Moreover, an unprecedented multi-point measurement of the thermosphere will have been achieved.
In addition, Europe has now a leading role in the development of CubeSats for scientific and educational purposes with even stronger SMEs in the new space business. During the Project at least 3 new start-up companies were born. Increasing space competence among European students will improve the innovation of the future European society.
List of Websites:
Website: www.qb50.eu
Contact: masutti@vki.ac.be