for more information, contact Kenneth A. LaBel
Michele M. Gates, NASA Goddard Space Flight Center
Since SEE-inducing particles are, in general, not effectively attenuated with shielding, design tolerance requirements are not based upon location on the vehicle. Instead, SEE requirements depend on the functions devices perform. Many SEEs are different for different device types, e.g. memories will exhibit different conditions than power converters, so the function the device performs is critical to the analysis. In addition, SEEs may present functional impacts by propagating through the design and impacting other areas. These two conditions make each single event problem different in terms of failure mode and effect. SEE analysis is most effectively supported by viewing a design or system from the perspective of the function(s) it performs.
In this section, we present some systems engineering tools useful in constructing and assessing an SEE problem. Functional analysis is an effective method for the consideration of a design for single event effects. The concept of criticality lends itself well to the assessment of the impact of a specific effect. Error propagation analysis, discussed in the following chapter, provides the final link. With the use of these tools, SEECA becomes a specialized Failure Modes and Effects Criticality Analysis (FMECA)-type study.
The systems engineering process, presented as one of the Systems Engineering Practices in the MIL-STD-499 Engineering Management Practices, is given in Figure 2.1 [1]. The first box represents the input requirements for the system being considered. With the known performance requirements, one then identifies the required functions to achieve performance, termed "functional analysis". Potential mechanisms to fulfill the functions, or design options, are explored and evaluated. A decision is made, leading to the system description. The process may be applied to many levels in a design, from the large-scale system, or upper-level, to the lower levels of subsystems and circuits.
Considering a design in terms of function facilitates engineering groups in developing plans and requirements and in performing analyses. Specific to SEECA, it provides the foundation for studying the impact of single event effects (SEEs) on system performance. SEE presents a functional impact on both the device and system levels. By analyzing a design or system in terms of the functions it performs, regardless of its given subsystem name or physical location on the vehicle, we may form an SEE problem statement and explore solutions. Considering both the device and system in terms of function sets the framework for defining the problem, analyzing it, and exploring solutions.
Different subsystems on a spacecraft are generally associated with different engineering disciplines. The subsystems are typically found on different physical locations on a space vehicle, such as in separate boxes. The attitude control subsystem, for example, is responsible for attaining and maintaining spacecraft orientation. This subsystem usually has several associated boxes which may include earth sensors, sun sensors, reaction wheels, gyros, and support electronics. The command and data handling subsystem may be responsible for issuing, delivering, and storing all computer commands and data. The propulsion subsystem usually contains the on-board thrusters, fuel, and its own electronics. The separation of subsystem boxes is extremely advantageous during design, integration, and test. However, it is easy to overlook the overlapping of functionality. One specific function will often involve hardware and/or software from more than one different subsystem. For example, a reorientation maneuver, when broken down, involves lower level functions in many subsystems: the attitude control system senses orientation data; the command and data handling subsystem generates the required thruster command; and the propulsion subsystem fires a thruster. A schematic of some designated levels of design is presented in Figure 2.2.
Just as the entire systems engineering process in Figure 2.1 applies at many hierarchical levels in design, the functional analysis portion applies similarly. In functional analysis, a design is viewed from the perspective of the functions it performs. The objective of a conventional functional analysis is to define a comprehensive set of baseline functions and functional performance requirements which must be met in order to accomplish the overall mission objectives. This is achieved through the breakdown of top-level requirements into successively lower-level performance requirements, in a methodical and traceable manner. Functional analysis applied at lower levels involves the breakdown of requirements and functions at the subsystem, card, circuit, and device levels. Top level functional analysis is useful in requirements generation, such as for SEE tolerance. Lower level functional analysis is useful in SEE impact assessment, or failure modes and effects analysis.
Functional analysis may be performed in a clear, methodical way through the use of functional flow block diagrams. This flowchart-like method enables the identification of functions while providing traceability. Figure 2.3 presents a functional flow block diagram created in a mission-level functional analysis effort for the Far Ultraviolet Spectroscopic Explorer mission [2]. Mission operations, specified as function #4, is broken down into the next level, functions 4.1 - 4.7, which include contingency operations, safehold, deployment and initialization, maneuvers, target acquisition & tracking, science data acquisition, and science data processing. Figure 2.4 presents function 4.5, target acquisition & tracking, broken down into its next level, functions 4.5.1 - 4.5.6, which include sun acquisition, inertial attitude determination, inertial attitude processing, sensor configuration, target selection, relative attitude processing, slew specification, and instrument alignment [2]. Science data acquisition, function 4.6, is broken down in Figure 2.5 [2].
For quick studies of design issues, less formal analyses are often useful. Here, many-tiered functional flow block diagrams may not be needed. Quickly drafted notes or even a simple thought experiment may suffice as a short functional analysis on the subsystem or device level.
The systems engineering process is used in many engineering disciplines, including single event effect (SEE) analysis. Some SEE mitigation techniques are system level and are designed directly into the system. For these, system level functional analysis identifies functions that are performed to meet the system requirements. Different system design options mitigating SEE to meet performance requirements may then be considered. Device cost, design complexity, design schedule, system weight and power may be potentially impacted by SEE mitigation, just as with many design selections.
The systems engineering process also applies to device-level SEE analysis. This may be done much later in the design process, after the system baseline has been described. A device has specific requirements associated with it in a design, such as operating current, bit error rate, etc. The device also performs functions to fulfill system level requirements, which may or may not overlap the device requirements. Mitigation schemes at the device level may be considered which ensure that performance requirements are met.
One objective of viewing a design or system in terms of function is to determine the riticality of the function(s) performed on an operational level. Many SEEs present a fu cnctional impact, but do not cause permanent damage to the device. Depending on the criticality of a function, these nondestructive conditions may or may not be acceptable in a design. In assessing criticality, we determine the impact of an SEE in a device on the functions it performs. Device hardness requirements are not considered here, since SEEs may be mitigated through many routes. What is of interest is the operational impact of a specific device SEE propagating through the design or system.
Functions may be categorized into "criticality classes", or categories of differing severity of SEE occurrence. Many times, most or all of the functions performed by a design or system are considered critical to a mission. The operational impact of SEEs in critical functions may be unacceptable. For these designs, usually either no single event effects, or a very small probability of SEE occurrences, are permitted. When considering a subsystem, some components may not be SEE-critical, while others may indeed be crucial. For example, the flight data system program memory is certainly critical, while data storage memories may tolerate SEEs if utilizing error correction schemes. Both of these functions are located in the Data System.
In general, one might consider three criticality groups for Single Event Upset: error-functional, error-vulnerable, and error-critical. Functions in the error-functional groups may be unaffected by SEUs, whether it be due to an implemented error-correction scheme or redundancy, and a large probability of SEU may be acceptable. Functions in the error-vulnerable group might be those for which the risk of a low probability is assumable. Functions in the error-critical group are functions where SEU is unacceptable. Figure 2.6 presents a decision tree for criticality analysis, describing a representative criticality grouping and corresponding risk levels, or SEE tolerance requirements [3]. In this discussion, we are applying the decision tree to SEU analysis. One might use Figure 2.6 or a similar process for other nondestructive SEEs.
This functional criticality concept applies directly at the device level. One may specify the criticality of a device function and determine whether current device tolerance needs and mitigation schemes are adequate to protect the system from impacts. Functional criticality is also a direct lead into SEE requirements generation on any level, including spacecraft, system, and subsystem.
Once the criticality of functions are determined, requirements for design, including hardware and software may be directly obtained. In the criticality analysis presented in Figure 2.6, the requirements for SEU probability for all three criticality groups are directly tied to acceptable risks. The more critical an SEE is to operational performance, the more strict the SEE requirement should be.
In general, the tradeoff in the development of SEE requirements is risk vs. cost and design complexity. The more risk assumed, the higher the allowable probability of an SEE, and potentially the less the cost of the design. There may be cases in which a greater percentage of SEEs may be acceptable for a reduction in cost. Other design concerns also play a role, such as performance, power, weight, and volume.
Requirements are specified for each functional group by specifying the maximum probability of SEE occurrence permitted in each category. The SEE rate requirements may be different for SEU, latchup, gate rupture, and any other SEE of concern. These requirements are specified at the functional level, and are achievable through many avenues, including hardware mitigation, software schemes, redundancy, and device hardness. In contrast to specifying a spacecraft-level requirement, functional SEE requirements may yield areas in the design, or specific functions, with lower necessary tolerance levels. This reduction in requirements usually translates to a reduction in the cost of design. However, common devices across functions might be cost-advantageous under the worst-case radiation specification. The decision tree in Figure 2.6 is again helpful here. For each criticality group, there is a functional requirement. The functional requirement may be fulfilled using a combination of methods. The selection of mitigation tools leads to the device requirement. A functional requirement does not necessarily translate directly to a device requirement. Figure 2.7 presents this requirements flow [3].
This idea of functional and device SEE requirements is useful when working at many levels in design. Some projects perform a complete spacecraft functional analysis as part of the systems engineering responsibility. In this case, functional SEE requirements for the entire design, or any portion of it, may be directly derived by categorizing the functional breakdown by criticality. For specific portions of a design, functional SEE requirements may be developed by detailing the functions performed in that portion. Device SEE requirements flow directly from both of these, as described earlier. If addressing a problem in more detailed design phase, device SEE requirements may be determined by assessing the functional criticality of specific components and assessing mitigation options to meet the specified operational requirements.
This section has presented some discussion on functional analysis and criticality, two systems engineering tools for design assessment. It is hoped that these methods will facilitate SEE analysis, both in forming a problem statement and arriving at solutions. Depending on the application, this methodology may be used in its entirety or in various degrees.
1. MIL-STD-499A, "Engineering Management," May 1974.
2. Smith, Terrence, private communication, NASA Goddard Space Flight Center, May 5, 1994.
3. Gates, Michele and LaBel, Kenneth, "A Systems Engineering Approach to the Design of Survivable Electronics for the Natural Space Ionizing Radiation Environment," AIAA paper 95-0843, Jan. 1995.
4. LaBel, K. and Gates, M., "Single Event Effect Mitigation from a System Perspective," IEEE Transactions on Nuclear Science Special Edition, 1996.
Introduction
1. The SEE Problem
2. Functional Analysis and Criticality
3. Ionizing Radiation Environment Concerns
4. Effects in Electronic Devices and SEE Rates
5. SEU Propagation Analysis: System Level Effects
6. SEE Mitigation: Methods of Reducing SEE Impacts
7. Managing SEEs: System Level Planning
8. SEE Criticality Assessment Case Studies
