Prepara tus exámenes y mejora tus resultados gracias a la gran cantidad de recursos disponibles en Docsity
Gana puntos ayudando a otros estudiantes o consíguelos activando un Plan Premium
Prepara tus exámenes
Prepara tus exámenes y mejora tus resultados gracias a la gran cantidad de recursos disponibles en Docsity
Prepara tus exámenes con los documentos que comparten otros estudiantes como tú en Docsity
Encuentra los documentos específicos para los exámenes de tu universidad
Estudia con lecciones y exámenes resueltos basados en los programas académicos de las mejores universidades
Responde a preguntas de exámenes reales y pon a prueba tu preparación
Consigue puntos base para descargar
Gana puntos ayudando a otros estudiantes o consíguelos activando un Plan Premium
Comunidad
Pide ayuda a la comunidad y resuelve tus dudas de estudio
Ebooks gratuitos
Descarga nuestras guías gratuitas sobre técnicas de estudio, métodos para controlar la ansiedad y consejos para la tesis preparadas por los tutores de Docsity
A guideline to assist those interested in deploying a raspberry pi in a spacecraft build, with a primary emphasis on the radiation reliability issues involved. It covers an overview of raspberry pi usage in space, standard issues for space computers, raspberry pi radiation effects, and considerations for different radiation environments. The document also discusses alternatives to raspberry pi and provides a comparison of raspberry pi models. The description covers the key aspects of the document, including the focus on radiation reliability, the overview of raspberry pi usage in space, the discussion of standard issues for space computers, the analysis of raspberry pi radiation effects, and the comparison of alternative solutions. The description is comprehensive, providing sufficient details to give a good understanding of the document's content.
Tipo: Apuntes
1 / 21
Esta página no es visible en la vista previa
¡No te pierdas las partes importantes!
National Aeronautics and Space Administration
Jet Propulsion Laboratory California Institute of Technology Pasadena, California
ii
National Aeronautics and Space Administration
JPL Project Number: 107590 Task Number: 40.31.55.03.
Jet Propulsion Laboratory 4800 Oak Grove Drive Pasadena, CA 91109
http://nepp.nasa.gov
This guideline is intended only to provide support and background understanding. It does not focus on solving any of the many Raspberry Pi implementation issues. In some cases, alternatives are suggested. In some cases, critical issues related to ensuring reliability will be discussed with the expectation that they will likely involve recommendations that cannot be used.
The final point to make in what is presented here is that the goal is not to show a user how difficult it will be to use their device in a space mission. In practice, the majority of reliability issues that take a Raspberry Pi outside of the normal flow for reliable spacecraft will yield anomaly or system failure rates that are below the limit for the user while being very high compared to a normal risk matrix for a typical NASA mission. That is, users will probably find that Raspberry Pis, provided they make it to space and function at all, will have failure rates well below other components of a spacecraft built in a similar approach. Further, some of the considerations discussed here are for ensuring lower than 1% chance of failure of the mission due to the device – which means many users with much higher acceptable risk will consider some issues relatively minor.
In the event users are considering using Raspberry Pis in a situation similar to a normal classification of a NASA mission, this guideline is not recommended. Users are highly recommended to contact the author, the NEPP program, or similar experts available to them through their program’s contacts (see also Section 11.1).
Raspberry Pi computers can (depending on the system communication architecture) be added to a design for as low as $5 (ignoring software development costs and difficulties in actually bolting it in). Thus,
There are, nevertheless, many examples of consumer electronics that repeatedly have errors, or simply fail, due to space radiation. The worst examples have been units that cannot reliably operate for more than a few hours, when the original plan was that they would “usually” work for a day or so as a worst-case estimate.
Relevant to this discussion are NAND flash memories and SD cards. Note that [7] has reported on SD cards that fail with protons with a cross section so high that their expected failure rate is above 1 event every 3 months in LEO (where 1e10/cm 2 protons equates to roughly 5 years of exposure).
D. Flight Heritage Flight heritage refers to the argument that a system or component is likely to work for a mission because another one was used on another mission and it seems to have worked. In some cases the implementation of the article may have been done with monitoring, so that things like TID-induced increases in current can be monitored. Those situations can improve the heritage argument for a unit being considered for flight. Unfortunately, for Raspberry Pis, the heritage argument has significant limitations. See Section 10 for more information.
A comparison of Raspberry Pi models is provided in Table 1, below. Table 1: Comparison of Raspberry Pi models. Note that OTG is the abbreviation for USB "on the go".
physical peripheral functions.
The original approach was to provide a platform where users could use C++ or Python, in a Linux or similar operating environment, to provide access to simple hardware peripherals. Over time, the models have become either more capable from a computing perspective (such as the 4B), or more focused on providing a lower foot print hardware interface, such as with the Pico and Zero.
Table 2: Typical Raspberry Pi Use Cases
A. Hardware Considerations Flight hardware usually is designed for challenges of transit to, and operation in space. Raspberry Pis are special in that it is not expected that users will modify the printed circuit boards (PCBs), and it is not expected that users will design their own alternate hardware. That leaves for consideration only how the Raspberry Pi is held in the hardware and how connections are made to it. The following hardware considerations may be critical for missions that wish to deploy a Raspberry Pi.
Raspberry Pi thermal control is handled in terrestrial environments through convection. They depend on heating surrounding air and the natural processes by which the hot air escapes and is replaced by colder air. Since this doesn’t happen in space, Raspberry Pis must be conduction cooled. If no conduction path is provided on purpose, then the components on a given Raspberry Pi will heat the base circuit board,
An obvious additional requirement for handling permanent failures is the ability to detect a failed Raspberry Pi and indicate to the flight hardware to disconnect it.
This may be considered a simple part of the recovery scheme for some of the other issues indicated below, because if the system can disconnect the Raspberry Pi, presumably it can reconnect it. This gives a straightforward way to do a temporary disconnection in the event that a Raspberry Pi is in a SEFI state. Unfortunately, some simple-to-fix permanent failures, such as an SD card that needs to be reprogrammed, are likely to be outside of the capabilities of the flight systems.
SEFIs are actually the most likely events to be observed on a Raspberry Pi. The reason is because the software systems typically are not robust to errors and will require to be reset. The primary issue with a SEFI is how the flight systems detect a SEFI. Once detected, the most reliable way to handle a SEFI is to simply turn the unit off for an extended period of time, then turn it back on.
It is, therefore, necessary to consider Raspberry Pis as units and try to understand the limitations of the existing radiation data. Then try to extract general information which will be used in Section 7 to highlight likely issues in various environments.
C. TID Performance Several groups have explored the TID performance of various Raspberry Pis. The NEPP program explored the Raspberry Pi B and showed that it worked (up to functional benchmarks and log in) up to 40- 50 krad[Si] [9]. Decena, as part of work towards the Opal CubeSat by Utah State University showed functionality of Raspberry Pi Zero up to 100 krad[Si] [10]. Similar data was collected by G. Toumbus [11] on a Raspberry Pi compute module 3.
For this guideline, the NEPP program looked at the TID performance of the Raspberry Pi Zero and Raspberry Pi 3B+. The testing required a full boot to nominal operation and monitoring of operational characteristics during characterization tests. As a result, both units showed no degradation of any kind at 10 krad[Si]. At 30 krad[Si], all units showed some degradation, though the 3B+s performed better. Some of the Raspberry Pi Zeros actually hanged or failed to perform some of the tests.
These tests all have a general difficulty in common. That is that there is no good way to ensure that a user application will actually work. The reason this occurs is because the test conditions do not obviously cover all possible use scenarios. However, they do all indicate that there is no obvious issue with any Raspberry Pi up to 10 krad[Si] (some of the tests seem to indicate much higher levels, but appear to have limitations of their approach or are not calling it a failure when a unit has its first reduction in performance). This information is used in the radiation environments section.
A further problem with TID performance is that it generally cannot be guaranteed that just because one test resulted in a given TID level, another test of another Raspberry Pi will give the same results. The issue is that for TID results to carry from one unit to another, a strict parts program is typically required where the wafer lot of all of the components of the test unit has to match that of the flight unit. It is understood that will probably not happen for a Raspberry Pi user, but it is a serious limitation of the predicted TID performance of a Raspberry Pi system.
D. SEE Performance There is essentially no current SEE performance for Raspberry Pis available. A test was conducted as background work for this guideline, but the linear energy transfer coverage was very minimal. This means that the test likely missed what are classified as rare events from space particles with a flux of less than 100/cm 2 -year. The key result for SEFIs was that Raspberry Pi Zero’s appear to have a saturated cross section of about 3e-4. A plot of the results is shown in Figure 1, below. This information is used in the radiation environments section.
Figure 1: SEFI sensitivity of Raspberry Pis - note that above LET 5 the ions are ranging out and the cross section reduces. The onset LET appears to be below 0.6, and saturation is roughly 3e-4cm^2_._
High inclination typically refers to the ISS, which orbits at an inclination of 51.6°. A lot of CubeSats that launch with rockets to the ISS end up in this orbit. At this inclination, a significant amount of time is spent both in the trapped radiation belts and in unprotected space.
In practice, because of various tradeoffs, the TID and SEE levels in this orbit are almost the same as low inclination. So, the results above hold – at least 5 years of TID survivability, and SEFIs on the order of once every 100 days. Note, however, that a fair amount of Raspberry Pi on-orbit knowledge comes from the Astro Pi program. These units are not only inside a ruggedized Al enclosure, but they are also in the astronaut enclosure of the ISS. This is key because the ISS itself adds shielding to bring the natural radiation down from ~1-2krad[Si]/year down to about 30rad[Si]/year – to protect the astronauts. As a result, the radiation environment inside the ISS should be considered very different than that outside.
High-inclination orbits also are more likely to be affected by solar flares. As a rough rule of thumb, a solar flare may be as much TID as a full year of TID accumulation. It also is likely to overwhelm electronics giving a few months of exposure in a few minutes or hours. It is expected that most electronics will have problems during solar flares.
SEE rates in high-inclination orbits for Raspberry Pis are expected to remain in the 1/100 days range. In practice the rates will probably be about 3x below this rate.
Rather than review polar orbits in detail here. We will instead indicate that above about 40° the natural space environment has very little geomagnetic shielding (though it does still get protection from solar events), but it also has very little trapped particles. As with high-inclination, the exposure tends to average out except that the high LET component increases significantly at higher inclinations. This means that the chances for a damaging SEE increase. Unfortunately, we do not have a good estimate of the rate of damaging SEE for Raspberry Pis. If we did, we would have to warn that data from one Raspberry Pi likely does not apply to another – even the same model.
Thus, the predicted TID performance will be at least 5 years. Each flare will likely add a year of TID exposure per year.
SEE rates in polar orbits for Raspberry Pis are expected to remain in the 1/100 days range. In practice the rates will probably be about 3x below this rate. Damaging SEEs may be much more common but we do not have a means to estimate them. This could mean that only a few months of exposure might be sufficient to damage a Raspberry Pi.
B. GEO Orbit/Interplantary Space Generally speaking, the main contributor to SEE risk in this orbit is galactic cosmic rays (GCR). Without the Earth’s trapped particle belts, the SEE rate from GCR for the SEFI sensitivities reported in Section 6. give rates about 5x higher than in LEO. That is, the predicted rate is closer to 1/20 days for a SEFI as the high estimate, and the best guess is about 3x lower, or about 1/60 days.
In GEO orbit spacecraft will still be in the outer trapped particle belts of the Earth, and this is not so good. About 10 krad[Si]/year is the likely dose rate, so Raspberry Pis in GEO orbit may have trouble with TID after the first year.
In interplanetary space, TID is very minimal unless the spacecraft is hit by a flare. Typically TID is below 500 rad[Si]/year, so a Cubesat can survive 20 years in interplanetary space.
C. Lunar Orbit Lunar orbit is actually a special case of the information presented below. We present it here because it appears likely that Cubesats and other low-reliability/classification spacecraft may be likely to head to Lunar orbit in the coming decade.
The moon has no radiation sources of its own that would impact spacecraft. The principal possible source would be a magnetic field with trapped particles. Instead, the moon is actually more benign than interplanetary space (but much more dangerous than non-polar LEO). The primary cause is because the moon blocks radiation from the portion of the sky that it fills (i.e. the solid angle subtended from the spacecraft’s point of view).
Thus both TID and SEE levels range from the full interplanetary amounts given above, to about ½ those values when in close orbit of the moon. The Lunar Reconnaissance Orbiter (LRO) orbits the moon at about 50 km, and sees these levels. Thus for low altitude lunar orbiters, TID can reach 40 years (provided no flares), and SEE rates will be about 1/40-1/120 days for SEFIs.
D. Solar Flares Some of the sections above pointed to solar events. This section provides the same information but in a place that is easy to find. Solar events are particularly bad for electronics because they can deliver months of exposure in only a few minutes or hours of time. As a result, if a spacecraft is in the line of a flare, the typical response is to go into a safe mode of some type and “wait it out”. Because of the event rates in the normal environment for a Raspberry Pi, there is a high likelihood it will have a SEFI during a flare. Typically, some sort of watchdog will observe the system having problems and either shut it down for ~48 hours, or try to reboot it right away – repeat the process a few times – then shut it down for ~ hours.
Solar flares are significantly mitigated by the Earth’s geomagnetic shielding. Some of this extends near the poles, but high inclination systems are still at pretty high risk. Flares tend to energize the trapped particle belts. And they will impact polar orbit spacecraft as well. Typically, Earth orbiters take about a year of exposure from a single flare. In Lunar orbit, or interplanetary space, solar flares can deposit as much as 5 krad[Si], which is easily 10 times the normal exposure for a year. Typical flares can vary considerably.
E. Other Orbits We did not consider Mid-altitude Earth Orbit (MEO), which sits directly in the Earth’s trapped particle belts and easily collects more than 20 krad[Si] per year. We also left out orbits of other planets, because in general they are either a subset of GEO, or their radiation risk is so bad that an program sending a spacecraft there must use a viable parts/radiation approach that would preclude a Raspberry Pi.
Cruise to other bodies in the solar system fall into the interplanetary designation and are generally less stressful than GEO. In practice, GEO has essentially all of the interplanetary radiation risk with added TID risk due to possible extension of the upper trapper particle belts. Without the belt component, GEO and interplanetary space are very similar (up to the level of detail considered in this guideline).
Below is a list of device or system failures and how a user might identify them.
The issue here is absolute knowledge versus hopeful evidence. If all details required to establish carrying information from one use scenario to another are verified, it is possible to come very close to showing that previous heritage
B. Where Similarity Fails There is one class of events where similarity is almost impossible to establish based on heritage, and that is statistically rare events. The most obvious category of these is permanent failure. At best, if there are N missions flying a board that might permanently fail, then N failures might be observed (by contrast, for bit errors in non-critical memory, many events may be observed on a single mission, yielding much higher statistical significance). Worse, permanent failures are unlikely to be properly attributed to the component or mechanism that actually experienced the failure. For example, if 9 one-year missions are conducted using component X, and none of them observed permanent failure, the best-case scenario for the predicted rate is the upper bound 2-sigma rate of 3.7/9 missions, putting the worst case upper bound rate for the next 1-year mission at about 0.41/year. Even if this were somehow acceptable, it is actually likely wrong and underestimates the actual rate. Even if the mission durations are the same, it is not obvious that the usage cases sensitize all of the devices the same.
For example, SEL is worse in devices that run hotter, so if the new application runs hotter than the previous ones, 0.41/year may be an underestimate. Also, some missions may not bias the device at 100% duty cycle. Without details, heritage arguments are simply a guess, except for one key observation – many modern electronics have done very well in LEO missions, typically due to the very weak radiation exposure. That is, many systems have done well simply because the stress is minimal. In these cases, flight heritage argues more towards good overall design, workmanship, surviving launch, reliability, and ease of use.
C. Loose Similarity The biggest problem with hard similarity requirements is that if you don’t meet them, there is still a high likelihood that one unit will have a similar radiation response to another. For example, two LPDDR devices may be from two different manufacturers but have SBU and SEFI rates that are within a factor of
a run of Raspberry Pis with user-selected components. But it is outside the scope of this guideline to provide support or recommend resources in this regard.
Although it will be less than ideal, the recommended test campaign is the following. The user should identify the typical environment, duration, and approach to handling flares (typically either assume one every few years, or ignore them completely). This sets a target TID level (usually at a few krad[Si]/year augmented by 3-5 krad per flare). The user then buys a set of Raspberry Pis that include the intended flight unit(s). From this set, the user constructs a lot acceptance test batch. The test units are then irradiated in a Co-60 TID lab, while operating, with periodic checks for boot and performance, known as characterization. Ideally the lab test TID will be 2- to 3- times the target mission TID.
For the TID testing performed for this guideline, both Raspberry Pi 0 and Raspberry Pi 3 B+ worked with no apparent impact to any operating parameters until after 10 krad exposure. This is consistent with some other tests [refs – NEPP], so it is likely that if the user application requires 10 krad or less, that Raspberry Pis will likely function sufficiently.
C. SD Card It is highly recommended that SD cards be tested for TID along with the target Raspberry Pi units. A set of three or more options, covering multiple sizes, manufacturers, and if possible, feature sizes, should be considered.
Table 3: Generic “radiation tolerant” alternatives to Raspberry Pi use cases by price range
Note: If using Raspberry Pi as a “desktop” computer, there is no viable space computer alternative in the $10-30k range that can provide similar processing performance. The indication in other applications expects that the Raspberry Pi’s computing capabilities are not heavily utilized. Further, it is unclear if a “desktop” computer configuration can be supported in a spacecraft design.
Above $100k, a user can probably get a custom piece of space grade computing hardware for most potential Raspberry Pi applications. In the mid-range, $10k-$30k, things get a little dicey because there are some options but they get expensive fast and may not have the computing power or other performance metrics required. However, above $10k, the list provided in the Military and Aerospace Electronics website article on radiation hardened electronics gives a pretty good list of options [12]. The principal players for “low end” space computers are things like Cubesat Space Computer [13], and AiTech’s SP0-S [14] as just a couple of a fairly long list of examples. The issue is the tradeoff between cost and performance, where the upper bound of performance is unfortunately rather low. In terms of raw performance, the Raspberry Pi 4, with its quad core A72 cluster, easily outperforms pretty much any space grade computer for less than $250k, provided the issue of space survivability can be ignored.
In terms of rad hard microcontrollers (RH Microcontroller), there are a huge number of options. Many of these would have been considered computer processors not that long ago. There are a number of Sparc-, ARM-, and even RISC-V-based space microcontrollers available from many different companies such as Microchip, Vorago, CAES, TI, etc.. It is understood that the convenience of the Raspberry Pi development environment is not duplicated in these RH microcontrollers, and it is not obvious that the price will stay in the range specified because some of these devices carry very expensive software requirements. So, in order to go this direction, some research will be required to ensure that a possible solution will actually meet the working price range.
