How to Design Space Instrumentation
Part 2 in a Series of articles about Why Getting to Space Takes so Long (And Is so Expensive)
By Dr. Diego Casadei, Head of Space R&D at Cosylab
In the first part, we have seen what it takes to demonstrate that our equipment is most likely to be able to survive the launch and operate in space. In this part, we’ll focus on how this is achieved.
Careful design, tremendous attention to QA/PA and failure analysis
The key to success is a careful design, coupled with tremendous attention to quality and project assurance (QA/PA). The development process follows a stage-gate approach in which positive results must be demonstrated in order to get permission (and money) to perform more complex activities. The first big intermediate milestone is typically the Preliminary Design Review (PDR) of the Engineering Model (EM) documentation, including any preliminary tests carried on with subsystems. Once the PDR is approved, most often after having addressed all RIDs (RID = Review Item Discrepancy) issued by the space agency, the construction of the EM can take place. The EM is usually built with commercial components, with the same functional properties as the flight-quality ones, because they are much, much cheaper.
During the design phase, one must assume that failures will happen, and make them as unlikely and unimportant as possible. Typically, once the EM shows that one can achieve the desired functionalities with the initial design using commercial components and materials, a failure analysis is performed. For an electronic board, for example, a simulation is performed by varying independently all parameters (e.g. resistance, capacitance, inductance) according to their tolerances, and the currents and voltages in all input and output lines are computed for all combinations of parameters, to find if any of them will exceed the allowed ranges. Furthermore, single points of failure are searched for, to discover whether any single malfunctioning component may cause a severe or total loss of functionality. If so, the design is reconsidered, to add protections and/or redundancy. But this is not all: a complete failure tree is obtained, to study if and how failures may propagate. A failure causing the loss of a redundant functionality may be tolerated, provided that its probability is low enough during the expected mission, such that it happens at most only once. On the other hand, a failure propagating to the higher level and causing the loss of important functionality (possibly up to the entire mission) is very dangerous and must be avoided by all means (up to deciding not to install the guilty instrument!).
One must assume that failures will happen, and make them as unlikely and unimportant as possible.
The road from design to the flight model
The design of the flight model may go through several cycles until the Critical Design Review (CDR) of the instrument or satellite is successful. At this stage, the permission is given to start manufacturing the Qualification Model (QM), which will then undergo all qualification tests. Once they are successful, the Flight Model (FM) is built and tested at acceptable levels. If the qualification test results spot unforeseen problems, they have to be solved, possibly with some (hopefully very minor) redesign, and the solution must be shown to be appropriate (i.e. the test is performed again).
Of course, all redesign activities are accompanied by revisions of the existing documentation and the creation of additional documents (e.g. test reports). Thus, working on the documentation takes about half of all human resources.
Once the FM is ready, before it is accepted for the actual mission, a number of things need to be done.
- The End Item Data Package (EIDP) need to contain all relevant documents (grouped into about 40 categories for ESA) and is submitted before the FM is delivered, for the final review.
- One of the most important pieces of information in the EIDP is the Verification Control Document (VCD), most often called Verification Control Matrix (VCM) because it is a big (big!) table. The VCD/VCM lists all requirements, tracking where they originate from, which model (EM, QM, FM) should satisfy them, how they are verified (by design, by analysis, by test), whether the system to be delivered is compliant, not compliant (NC), or partially compliant (PC), which document shows the requirement compliance, and which documents track NC or PC requirements.
The latter step is quite tricky indeed. Here I describe what happens with ESA projects. Any requirement to which our system is not fully compliant is first documented by a Non-Conformance Report (NCR), which must be issued not later than 24 hours after the non-compliance has been found (e.g. with a failing test), communicated to the higher level (up to ESA, if it affects a flight unit), and discussed in a NRB (Non-compliance Review Board) in a meeting held within the next two days. When a solution is found acceptable in the NRB, consent is granted to apply the proposed changes and repeat the test. However, the NRB may take a long time to agree on the solution, which means several meetings and a possibly significant delay for the project. The NRB needs also to approve the solution, by validating the last test results in the last meeting in which the later are reviewed and a formal document is signed by all parties. Often a requirement is not satisfied, but the actual test result is not far from it. In this case, a Request For Deviation (RFD) may be issued by the team working on the NC system, which in our example with temperature ranges means that, instead of the original levels, it is requested to accept a smaller temperature range. Given the conservative way in which all uncertainties and margins are applied when defining qualification and acceptance levels, the RFD may be accepted, especially in case of a small deviation from the target limit.
However, sometimes an NC requirement simply cannot be satisfied. In this case, a Request For Waiver (RFW) is issued, which basically asks the higher level to accept a non-compliance. Accepting an RFW is sometimes easy when for example people realize that that particular requirement makes no (more) sense in the current stage. However, in general, an RFW is a big issue because requirements exist to guarantee that different systems do not interfere with each other. Hence the originator of the requirement needs to be identified and interviewed, and all possible implications of the non-compliance on other systems have to be discovered. Sometimes this is a hard task, because the non-compliance may be discovered 10 years after the original requirement was formulated, and the persons behind it may be no more around. This is another reason why the VCD/VCM must be kept up to date and it is typically a living document, revised many times and by different people during the course of the project.
So, it may happen (and it’s not so uncommon) that this fundamental document becomes “something overly complex, detailed or confusing”, fully justifying the common-language meaning of “rocket science” :)
TO BE CONTINUED…
In Part 1 and Part 2, you have seen what it takes to demonstrate that the equipment is most likely to be able to survive the launch and operate in space, and how this is achieved through careful design and tremendous attention to quality and project assurance. In Part 3, you will learn all about how the vast amount of information produced in a lifespan of a space project is organized, and where to find it. Stay tuned!
Don’t miss the next story!
About the author
Diego Casadei has a PhD in Physics and long experience in space instrumentation. He worked on two cosmic-ray detectors, AMS-01 (flown on board the NASA shuttle Discovery in 1998) and AMS-02 (installed on the International Space Station in 2011), and two X-ray telescopes, STIX (on board ESA Solar Orbiter mission, to be launched in 2020) and MiSolFA (a very compact instrument under development). His contributions range from detector R&D to the design of trigger and data acquisition systems, from instrument characterization to space qualification, from simulations to performance studies. He managed tasks of increasing complexity, with recent roles of technical coordinator for STIX and project coordinator for MiSolFA. Currently, he is the Head of Space R&D at Cosylab.
Do you want to learn more about this subject? Please let us know in the comments below!
