text:
Reliability engineering
Reliability engineering is engineering that emphasizes dependability in the lifecycle management of a product. Dependability, or reliability, describes the ability of a system or component to function under stated conditions for a specified period of time.[1] Reliability engineering represents a sub-discipline within systems engineering. Reliability is theoretically defined as the probability of failure, as the frequency of failures, or in terms of availability, as a probability derived from reliability and maintainability. Maintainability and maintenance is often defined as a part of "reliability engineering" in Reliability Programs. Reliability plays a key role in the cost-effectiveness of systems.
Although stochastic parameters define and affect reliability, according to P. O'Conner and A. Barnard, reliability is not achieved by mathematics and statistics. "Nearly all teaching and literature on the subject emphasize these aspects, and ignore the reality that the ranges of uncertainty involved largely invalidate quantitative methods for prediction and measurement" [2]
Reliability engineering relates closely to safety engineering and to system safety, in that they use common methods for their analysis and may require input from each other. Reliability engineering focuses on costs of failure caused by system downtime, cost of spares, repair equipment, personnel and cost of warranty claims. Safety engineering normally emphasizes not cost, but preserving life and nature, and therefore deals only with particular dangerous system-failure modes. High reliability (safety factor) levels also result from good engineering, from attention to detail and almost never from only re-active failure management (reliability accounting / statistics).[3] Reliability engineers should concentrate more on "why and how" items / systems may fail or have failed, instead of mostly trying to predict "when". Answers to the first questions will drive improvement in design and processes.
A former United States Secretary of Defense, economist James R. Schlesinger, once stated: "Reliability is, after all, engineering in its most practical form."[2]
- 1 Overview
- 2 Reliability and availability program plan
- 3 Reliability requirements
- 4 Reliability culture / Human Factors
- 5 Design for reliability
- 6 Reliability prediction and improvement
- 7 Reliability theory
- 8 Quantitative system reliability parameters – theory
- 9 Reliability modelling
- 10 Reliability test requirements
- 11 Reliability testing
- 12 Software reliability
- 13 Reliability engineering vs safety engineering
- 14 Reliability versus Quality (Six Sigma)
- 15 Reliability operational assessment
- 16 Reliability organizations
- 17 Certification
- 18 Reliability engineering education
- 19 See also
- 20 References
- 21 Further reading
- 22 External links
Reliability engineering for complex systems requires a different, more elaborate systems approach than for non-complex systems. Reliability engineering may involve:
- Use (load) studies and requirements specification (system level analysis)
- Inherent (system) Design Reliability: Hardware- and Software design, System Diagnostics design
- Functional (Failure) analysis
- Human Factors / Errors
- Manufacturing and Assembly induced failures
- Maintenance induced failures
- Transport induced failures
- Storage induced failures
- Failure / reliability testing
- Spare-parts stocking (Availability control)
- Technical documentation
- Data and information acquisition/organisation
Effective reliability engineering requires understanding of the basics of failure mechanisms for which experience, broad engineering skills and good knowledge from many different special fields of engineering,[4] like:
- Tribology
- Stress (mechanics)
- Fracture mechanics / Fatigue (material)
- Thermal engineering
- Fluid mechanics / shock loading engineering
- Electrical engineering
- Chemical engineering (e.g. Corrosion)
Reliability may be defined in the following ways:
- The idea that an item is fit for a purpose with respect to time
- The capacity of a designed, produced or maintained item to perform as required over time
- The capacity of a population of designed, produced or maintained items to perform as required over specified time
- The resistance to failure of an item over time
- The probability of an item to perform a required function under stated conditions for a specified period of time
- The durability of an object.
Many engineering techniques are used in reliability engineering, such as reliability hazard analysis, failure mode and effects analysis (FMEA), failure modes, mechanisms, and effects analysis (FMMEA),[5] fault tree analysis (FTA), material stress and wear calculations, fatigue and creep analysis, finite element method, reliability prediction, thermal (stress) analysis, corrosion analysis, human error analysis, reliability testing, statistical uncertainty estimations, Monte Carlo simulations, design of experiments, reliability centered maintenance (RCM), failure reporting and corrective actions management. Because of the large number of reliability techniques, their expense, and the varying degrees of reliability required for different situations, most projects develop a reliability program plan to specify the reliability tasks that will be performed for that specific system.
Consistent with the creation of safety cases, for example ARP4761, the goal is to provide a robust set of qualitative and quantitative evidence that use of a component or system will not be associated with unacceptable risk. The basic steps to take[6] are to:
- First thoroughly identify relevant unreliability "hazards", e.g. potential conditions, events, human errors, failure modes, interactions, failure mechanisms and root causes, by specific analysis or tests
- Assess the associated system risk, by specific analysis or testing
- Propose mitigation, e.g. requirements, design changes, detection, maintenance, training, by which the risks may be lowered and controlled for at an acceptable level.
- Determine the best mitigation and get agreement on final, acceptable risk levels, possibly based on cost-benefit analysis
Risk is the combination of probability and severity of the failure incident (scenario) occurring.
In a deminimus definition, severity of failures include the cost of spare parts, man hours, logistics, damage (secondary failures) and downtime of machines which may cause production loss. A more complete definition of failure also can mean injury, dismemberment and death of people within the system (witness mine accidents, industrial accidents, space shuttle failures) and the same to innocent bystanders (witness the citizenry of cities like Bhopal, Love Canal, Chernobyl or Sendai and other victims of the 2011 Tōhoku earthquake and tsunami) - in this case, Reliability Engineering becomes System Safety. What is acceptable is determined by the managing authority or customers or the effected communities. Residual risk is the risk that is left over after all reliability activities have finished and includes the un-identified risk and is therefore not completely quantifiable.
Reliability and availability program plan[edit]
A reliability program plan is used to document exactly what "best practices" (tasks, methods, tools, analysis and tests) are required for a particular (sub)system, as well as clarify customer requirements for reliability assessment. For large scale, complex systems, the reliability program plan should be a separate document. Resource determination for manpower and budgets for testing and other tasks is critical for a successful program. In general, the amount of work required for an effective program for complex systems is large.
A reliability program plan is essential for achieving high levels of reliability, testability, maintainability and the resulting system Availability and is developed early during system development and refined over the systems life-cycle. It specifies not only what the reliability engineer does, but also the tasks performed by other stakeholders. A reliability program plan is approved by top program management, which is responsible for allocation of sufficient resources for its implementation.
A reliability program plan may also be used to evaluate and improve availability of a system by the strategy on focusing on increasing testability & maintainability and not on reliability. Improving maintainability is generally easier than reliability. Maintainability estimates (Repair rates) are also generally more accurate. However, because the uncertainties in the reliability estimates are in most cases very large, it is likely to dominate the availability (prediction uncertainty) problem; even in the case maintainability levels are very high. When reliability is not under control more complicated issues may arise, like manpower (maintainers / customer service capability) shortage, spare part availability, logistic delays, lack of repair facilities, extensive retro-fit and complex configuration management costs and others. The problem of unreliability may be increased also due to the "domino effect" of maintenance induced failures after repairs. Only focusing on maintainability is therefore not enough. If failures are prevented, none of the others are of any importance and therefore reliability is generally regarded as the most important part of availability. Reliability needs to be evaluated and improved related to both availability and the cost of ownership (due to cost of spare parts, maintenance man-hours, transport costs, storage cost, part obsolete risks, etc.). But, as GM and Toyota have belatedly discovered, TCO also includes the down-stream liability costs when reliability calculations do not sufficiently or accurately address customers' personal bodily risks. Often a trade-off is needed between the two. There might be a maximum ratio between availability and cost of ownership. Testability of a system should also be addressed in the plan as this is the link between reliability and maintainability. The maintenance strategy can influence the reliability of a system (e.g. by preventive and/or predictive maintenance), although it can never bring it above the inherent reliability.
The reliability plan should clearly provide a strategy for availability control. Whether only availability or also cost of ownership is more important depends on the use of the system. For example, a system that is a critical link in a production system – e.g. a big oil platform – is normally allowed to have a very high cost of ownership if this translates to even a minor increase in availability, as the unavailability of the platform results in a massive loss of revenue which can easily exceed the high cost of ownership. A proper reliability plan should always address RAMT analysis in its total context. RAMT stands in this case for reliability, availability, maintainability/maintenance and testability in context to the customer needs.
Reliability requirements[edit]
For any system, one of the first tasks of reliability engineering is to adequately specify the reliability and maintainability requirements derived from the overall availability needs and more importantly, from proper failure analysis or preliminary test results. Requirements should constrain the designers from designing particular unreliable systems. Setting only availability (reliability, testability and maintainability) targets (e.g. max. Failure rates)is not appropriate. This is a broad misunderstanding about Reliability Requirements Engineering. Reliability requirements address the system itself, including test and assessment requirements, and associated tasks and documentation. Reliability requirements are included in the appropriate system or subsystem requirements specifications, test plans and contract statements. Creation of proper lower level requirements is critical.
Provision of only quantitative minimum targets (e.g. MTBF values/ Failure rates) is not sufficient for different reasons. One reason is that a full validation (related to correctness and verifiability in time) of an quantitative reliability allocation (requirement spec) on lower levels for complex systems can (often) not be made as a consequence of 1) The fact that the requirements are probabalistic 2) The extremely high level of uncertainties involved for showing compliance with all these probabalistic requirements 3) Reliability is a function of time and accurate estimates of a (probabalistic) reliability number per item are available only very late in the project, sometimes even only many years after in-service use. Compare this problem with the continues (re-)balancing of for example lower level system mass requirements in the development of an aircraft, which is already often a big undertaking. Notice that in this case masses do only differ in terms of only some %, are not a function of time the data is non-probabalistic and available already in CAD models. In case of reliability, the levels of unreliability (failure rates) may change with factors of decades (1000's of %)as result of very minor deviations in design, process or anything else. The information is often not available without huge uncertainties within the development phase. This makes this allocation problem almost impossible to do in a useful, practical, valid manner, wich does not result in massive over- or under specification. A pragmatic approach is therefore needed. For example; the use of general levels / classes of quantitative requirements only depending on severity of failure effects. Also the validation of results is a far more subjective task than for any other type of requirement. (Quantitative) Reliability parameters -in terms of MTBF - are by far the most uncertain design parameters in any design.
Furthermore, reliability design requirements should drive a (system or part) design to incorporate features that prevent failures from occurring or limit consequences from failure in the first place! Not only to make some predictions, this could potentially distract the engineering effort to a kind of accounting work. A design requirement should be so precise enough so that a designer can "design to" it and can also prove -through analysis or testing- that the requirement has been achieved, and if possible within some a stated confidence. Any type of reliability requirement should be detailed and could be derived from failure analysis (Finite Element Stress and Fatigue analysis, Reliability Hazard Analysis, FTA, FMEA, Human Factor analysis, Functional Hazard Analysis, etc.) or any type of reliability testing. Also, requirements are needed for verification tests e.g. required overload loads (or stresses) and test time needed. To derive these requirements in an effective manner, a systems engineering based risk assessment and mitigation logic should be used. These practical design requirements shall drive the design and not only be used for verification purposes. These requirements (often design constraints) are in this way derived from failure analysis or preliminary tests. Understanding of this difference with only pure quantitative (logistic) requirement specification (e.g. Failure Rate / MTBF setting) is paramount in the development of successful (complex) systems.[7]
The maintainability requirements address the costs of repairs as well as repair time. Testability (not to be confused with test requirements) requirements provide the link between reliability and maintainability and should address detectability of failure modes (on a particular system level), isolation levels and the creation of diagnostics (procedures).
As indicated above, reliability engineers should also address requirements for various reliability tasks and documentation during system development, test, production, and operation. These requirements are generally specified in the contract statement of work and depend on how much leeway the customer wishes to provide to the contractor. Reliability tasks include various analyses, planning, and failure reporting. Task selection depends on the criticality of the system as well as cost. A safety critical system may require a formal failure reporting and review process throughout development, whereas a non-critical system may rely on final test reports. The most common reliability program tasks are documented in reliability program standards, such as MIL-STD-785 and IEEE 1332. Failure reporting analysis and corrective action systems are a common approach for product/process reliability monitoring.
Reliability culture / Human Factors[edit]
Practically, most failures can in the end be traced back to a root causes of the type of human errors of any kind. For example, human errors in:
- Use studies
- Requirement analysis / setting
- Configuration control
- Assumptions
- Calculations / simulations / FEM analysis
- Design
- Design drawings
- Testing (incorrect load settings or failure measurement)
- Statistical analysis
- Manufacturing
- Quality control
- Maintenance
- Maintenance manuals
- Incorrect feedback of information
- etc.
However, humans are also very good in detection of (the same) failures, correction of failures and improvising when abnormal situations occur. The policy that human actions should be completely ruled out of any design and production process to improve reliability may not be effective therefore. Some tasks are better performed by humans and some are better performed by machines.[8] Furthermore, human errors in management and the organization of data and information or the misuse or abuse of items may also contribute to unreliability. This is the core reason why high levels of reliability for complex systems can only be achieved by following a robust systems engineering process with proper planning and execution of the validation and verification tasks. This also includes careful organization of data and information sharing and creating a "reliability culture" in the same sense as having a "safety culture" is paramount in the development of safety critical systems.
Design for reliability[edit]
Reliability design begins with the development of a (system) model. Reliability and availability models use block diagrams and fault trees to provide a graphical means of evaluating the relationships between different parts of the system. These models may incorporate predictions based on failure rates taken from historical data. While the (input data) predictions are often not accurate in an absolute sense, they are valuable to assess relative differences in design alternatives. Maintainability parameters, for example MTTR, are other inputs for these models.
The most important fundamental initiating causes and failure mechanisms are to be identified and analyzed with engineering tools. A diverse set of practical guidance and practical performance and reliability requirements should be provided to designers so they can generate low-stressed designs and products that protect or are protected against damage and excessive wear. Proper Validation of input loads (requirements) may be needed and verification for reliability "performance" by testing may be needed.
One of the most important design techniques is redundancy. This means that if one part of the system fails, there is an alternate success path, such as a backup system. The reason why this is the ultimate design choice is related to the fact that high confidence reliability evidence for new parts / items is often not available or extremely expensive to obtain. By creating redundancy, together with a high level of failure monitoring and the avoidance of common cause failures, even a system with relative bad single channel (part) reliability, can be made highly reliable (mission reliability) on system level. No testing of reliability has to be required for this. Furthermore, by using redundancy and the use of dissimilar design and manufacturing processes (different suppliers) for the single independent channels, less sensitivity for quality issues (early childhood failures) is created and very high levels of reliability can be achieved at all moments of the development cycles (early life times and long term). Redundancy can also be applied in systems engineering by double checking requirements, data, designs, calculations, software and tests to overcome systematic failures.
Another design technique to prevent failures is called physics of failure. This technique relies on understanding the physical static and dynamic failure mechanisms. It accounts for variation in load, strength and stress leading to failure at high level of detail, possible with use of modern finite element method (FEM) software programs that may handle complex geometries and mechanisms like creep, stress relaxation, fatigue and probabilistic design (Monte Carlo simulations / DOE). The material or component can be re-designed to reduce the probability of failure and to make it more robust against variation. Another common design technique is component derating: Selecting components whose tolerance significantly exceeds the expected stress, as using a heavier gauge wire that exceeds the normal specification for the expected electrical current.
Another effective way to deal with unreliability issues is to perform analysis to be able to predict degradation and being able to prevent unscheduled down events / failures from occurring. RCM (Reliability Centered Maintenance) programs can be used for this.
Many tasks, techniques and analyses are specific to particular industries and applications. Commonly these include:
- Built-in test (BIT) (testability analysis)
- Failure mode and effects analysis (FMEA)
- Reliability hazard analysis
- Reliability block-diagram analysis
- Dynamic Reliability block-diagram analysis[9]
- Fault tree analysis
- Root cause analysis
- Sneak circuit analysis
- Accelerated testing
- Reliability growth analysis (re-active reliability)
- Weibull analysis (re-active reliability)
- Thermal analysis by finite element analysis (FEA) and / or measurement
- Thermal induced, shock and vibration fatigue analysis by FEA and / or measurement
- Electromagnetic analysis
- Statistical interference
- Avoidance of single point of failure
- Functional analysis and functional failure analysis (e.g., function FMEA, FHA or FFA)
- Predictive and preventive maintenance: reliability centered maintenance (RCM) analysis
- Testability analysis
- Failure diagnostics analysis (normally also incorporated in FMEA)
- Human error analysis
- Operational hazard analysis
- Manual screening
- Integrated logistics support
Results are presented during the system design reviews and logistics reviews. Reliability is just one requirement among many system requirements. Engineering trade studies are used to determine the optimum balance between reliability and other requirements and constraints.
Reliability prediction and improvement[edit]
Reliability prediction is the combination of the creation of a proper reliability model together with estimating (and justifying) the input parameters for this model (like failure rates for a particular failure mode or event and the mean time to repair the system for a particular failure) and finally to provide a system (or part) level estimate for the output reliability parameters (system availability or a particular functional failure frequency).
Some recognized reliability engineering specialists – e.g. Patrick O'Connor, R. Barnard – have argued that too much emphasis is often given to the prediction of reliability parameters and more effort should be devoted to the prevention of failure (reliability improvement).[2] Failures can and should be prevented in the first place for most cases. The emphasis on quantification and target setting in terms of (e.g.) MTBF might provide the idea that there is a limit to the amount of reliability that can be achieved. In theory there is no inherent limit and higher reliability does not need to be more costly in development. Another of their arguments is that prediction of reliability based on historic data can be very misleading, as a comparison is only valid for exactly the same designs, products, manufacturing processes and maintenance under exactly the same loads and environmental context. Even a minor change in detail in any of these could have major effects on reliability. Furthermore, normally the most unreliable and important items (most interesting candidates for a reliability investigation) are most often subjected to many modifications and changes. Engineering designs are in most industries updated frequently. This is the reason why the standard (re-active or pro-active) statistical methods and processes as used in the medical industry or insurance branch are not as effective for engineering. Another surprising but logical argument is that to be able to accurately predict reliability by testing, the exact mechanisms of failure must have been known in most cases and therefore – in most cases – can be prevented! Following the incorrect route by trying to quantify and solving a complex reliability engineering problem in terms of MTBF or Probability and using the re-active approach is referred to by Barnard as "Playing the Numbers Game" and is regarded as bad practise.[3]
For existing systems, it is arguable that responsible programs would directly analyse and try to correct the root cause of discovered failures and thereby may render the initial MTBF estimate fully invalid as new assumptions (subject to high error levels) of the effect of the patch/redesign must be made. Another practical issue concerns a general lack of availability of detailed failure data and not consistent filtering of failure (feedback) data or ignoring statistical errors, which are very high for rare events (like reliability related failures). Very clear guidelines must be present to be able to count and compare failures, related to different type of root-causes (e.g. manufacturing-, maintenance-, transport-, system-induced or inherent design failures, ). Comparing different type of causes may lead to incorrect estimations and incorrect business decisions about the focus of improvement.
To perform a proper quantitative reliability prediction for systems may be difficult and may be very expensive if done by testing. On part level, results can be obtained often with higher confidence as many samples might be used for the available testing financial budget, however unfortunately these tests might lack validity on system level due to the assumptions that had to be made for part level testing. These authors argue that it can not be emphasized enough that testing for reliability should be done to create failures in the first place, learn from them and to improve the system / part. The general conclusion is drawn that an accurate and an absolute prediction – by field data comparison or testing – of reliability is in most cases not possible. An exception might be failures due to wear-out problems like fatigue failures. In the introduction of MIL-STD-785 it is written that reliability prediction should be used with great caution if not only used for comparison in trade-off studies.
See also: Risk Assessment#Quantitative risk assessment – Critics paragraph
Reliability theory[edit]
Reliability is defined as the probability that a device will perform its intended function during a specified period of time under stated conditions. Mathematically, this may be expressed as,
- ,
- where is the failure probability density function and is the length of the period of time (which is assumed to start from time zero).
There are a few key elements of this definition:
- Reliability is predicated on "intended function:" Generally, this is taken to mean operation without failure. However, even if no individual part of the system fails, but the system as a whole does not do what was intended, then it is still charged against the system reliability. The system requirements specification is the criterion against which reliability is measured.
- Reliability applies to a specified period of time. In practical terms, this means that a system has a specified chance that it will operate without failure before time . Reliability engineering ensures that components and materials will meet the requirements during the specified time. Units other than time may sometimes be used.
- Reliability is restricted to operation under stated (or explicitly defined) conditions. This constraint is necessary because it is impossible to design a system for unlimited conditions. A Mars Rover will have different specified conditions than a family car. The operating environment must be addressed during design and testing. That same rover may be required to operate in varying conditions requiring additional scrutiny.
Quantitative system reliability parameters – theory[edit]
Quantitative Requirements are specified using reliability parameters. The most common reliability parameter is the mean time to failure (MTTF), which can also be specified as the failure rate (this is expressed as a frequency or conditional probability density function (PDF)) or the number of failures during a given period. These parameters may be useful for higher system levels and systems that are operated frequently, such as most vehicles, machinery, and electronic equipment. Reliability increases as the MTTF increases. The MTTF is usually specified in hours, but can also be used with other units of measurement, such as miles or cycles. Using MTTF values on lower system levels can be very misleading, specially if the Failures Modes and Mechanisms it concerns (The F in MTTF) are not specified with it.[10]
In other cases, reliability is specified as the probability of mission success. For example, reliability of a scheduled aircraft flight can be specified as a dimensionless probability or a percentage, as in system safety engineering.
A special case of mission success is the single-shot device or system. These are devices or systems that remain relatively dormant and only operate once. Examples include automobile airbags, thermal batteries and missiles. Single-shot reliability is specified as a probability of one-time success, or is subsumed into a related parameter. Single-shot missile reliability may be specified as a requirement for the probability of a hit. For such systems, the probability of failure on demand (PFD) is the reliability measure – which actually is an unavailability number. This PFD is derived from failure rate (a frequency of occurrence) and mission time for non-repairable systems.
For repairable systems, it is obtained from failure rate and mean-time-to-repair (MTTR) and test interval. This measure may not be unique for a given system as this measure depends on the kind of demand. In addition to system level requirements, reliability requirements may be specified for critical subsystems. In most cases, reliability parameters are specified with appropriate statistical confidence intervals.
Reliability modelling[edit]
Reliability modelling is the process of predicting or understanding the reliability of a component or system prior to its implementation. Two types of analysis that are often used to model a complete system availability (including effects from logistics issues like spare part provisioning, transport and manpower) behavior are fault tree analysis and reliability block diagrams. On component level the same type of analysis can be used together with others. The input for the models can come from many sources: Testing, Earlier operational experience field data or data handbooks from the same or mixed industries can be used. In all cases, the data must be used with great caution as predictions are only valid in case the same product in the same context is used. Often predictions are only made to compare alternatives.
For part level predictions, two separate fields of investigation are common:
- The physics of failure approach uses an understanding of physical failure mechanisms involved, such as mechanical crack propagation or chemical corrosion degradation or failure;
- The parts stress modelling approach is an empirical method for prediction based on counting the number and type of components of the system, and the stress they undergo during operation.
Software reliability is a more challenging area that must be considered when it is a considerable component to system functionality.
Reliability test requirements[edit]
Reliability test requirements can follow from any analysis for which the first estimate of failure probability, failure mode or effect needs to be justified. Evidence can be generated with some level of confidence by testing. With software-based systems, the probability is a mix of software and hardware-based failures. Testing reliability requirements is problematic for several reasons. A single test is in most cases insufficient to generate enough statistical data. Multiple tests or long-duration tests are usually very expensive. Some tests are simply impractical, and environmental conditions can be hard to predict over a systems life-cycle.
Reliability engineering is used to design a realistic and affordable test program that provides empirical evidence that the system meets its reliability requirements. Statistical confidence levels are used to address some of these concerns. A certain parameter is expressed along with a corresponding confidence level: for example, an MTBF of 1000 hours at 90% confidence level. From this specification, the reliability engineer can, for example, design a test with explicit criteria for the number of hours and number of failures until the requirement is met or failed. Different sorts of tests are possible.
The combination of required reliability level and required confidence level greatly affects the development cost and the risk to both the customer and producer. Care is needed to select the best combination of requirements – e.g. cost-effectiveness. Reliability testing may be performed at various levels, such as component, subsystem and system. Also, many factors must be addressed during testing and operation, such as extreme temperature and humidity, shock, vibration, or other environmental factors (like loss of signal, cooling or power; or other catastrophes such as fire, floods, excessive heat, physical or security violations or other myriad forms of damage or degradation). For systems that must last many years, accelerated life tests may be needed.
Reliability testing[edit]
The purpose of reliability testing is to discover potential problems with the design as early as possible and, ultimately, provide confidence that the system meets its reliability requirements.
Reliability testing may be performed at several levels and there are different types of testing. Complex systems may be tested at component, circuit board, unit, assembly, subsystem and system levels [11] [1] . (The test level nomenclature varies among applications.) For example, performing environmental stress screening tests at lower levels, such as piece parts or small assemblies, catches problems before they cause failures at higher levels. Testing proceeds during each level of integration through full-up system testing, developmental testing, and operational testing, thereby reducing program risk. However, testing does not mitigate unreliability risk.
With each test both a statistical type 1 and type 2 error could be made and depends on sample size, test time, assumptions and the needed discrimination ratio. There is risk of incorrectly accepting a bad design (type 1 error) and the risk of incorrectly rejecting a good design (type 2 error).
It is not always feasible to test all system requirements. Some systems are prohibitively expensive to test; some failure modes may take years to observe; some complex interactions result in a huge number of possible test cases; and some tests require the use of limited test ranges or other resources. In such cases, different approaches to testing can be used, such as (highly) accelerated life testing, design of experiments, and simulations.
The desired level of statistical confidence also plays an role in reliability testing. Statistical confidence is increased by increasing either the test time or the number of items tested. Reliability test plans are designed to achieve the specified reliability at the specified confidence level with the minimum number of test units and test time. Different test plans result in different levels of risk to the producer and consumer. The desired reliability, statistical confidence, and risk levels for each side influence the ultimate test plan. The customer and developer should agree in advance on how reliability requirements will be tested.
A key aspect of reliability testing is to define "failure". Although this may seem obvious, there are many situations where it is not clear whether a failure is really the fault of the system. Variations in test conditions, operator differences, weather and unexpected situations create differences between the customer and the system developer. One strategy to address this issue is to use a scoring conference process. A scoring conference includes representatives from the customer, the developer, the test organization, the reliability organization, and sometimes independent observers. The scoring conference process is defined in the statement of work. Each test case is considered by the group and "scored" as a success or failure. This scoring is the official result used by the reliability engineer.
As part of the requirements phase, the reliability engineer develops a test strategy with the customer. The test strategy makes trade-offs between the needs of the reliability organization, which wants as much data as possible, and constraints such as cost, schedule and available resources. Test plans and procedures are developed for each reliability test, and results are documented.
Accelerated testing[edit]
The purpose of accelerated life testing (ALT test) is to induce field failure in the laboratory at a much faster rate by providing a harsher, but nonetheless representative, environment. In such a test, the product is expected to fail in the lab just as it would have failed in the field—but in much less time. The main objective of an accelerated test is either of the following:
- To discover failure modes
- To predict the normal field life from the high stress lab life
An Accelerated testing program can be broken down into the following steps:
- Define objective and scope of the test
- Collect required information about the product
- Identify the stress(es)
- Determine level of stress(es)
- Conduct the accelerated test and analyze the collected data.
Common way to determine a life stress relationship are
- Arrhenius model
- Eyring model
- Inverse power law model
- Temperature–humidity model
- Temperature non-thermal model
Software reliability[edit]
Software reliability is a special aspect of reliability engineering. System reliability, by definition, includes all parts of the system, including hardware, software, supporting infrastructure (including critical external interfaces), operators and procedures. Traditionally, reliability engineering focuses on critical hardware parts of the system. Since the widespread use of digital integrated circuit technology, software has become an increasingly critical part of most electronics and, hence, nearly all present day systems.
There are significant differences, however, in how software and hardware behave. Most hardware unreliability is the result of a component or material failure that results in the system not performing its intended function. Repairing or replacing the hardware component restores the system to its original operating state. However, software does not fail in the same sense that hardware fails. Instead, software unreliability is the result of unanticipated results of software operations. Even relatively small software programs can have astronomically large combinations of inputs and states that are infeasible to exhaustively test. Restoring software to its original state only works until the same combination of inputs and states results in the same unintended result. Software reliability engineering must take this into account.
Despite this difference in the source of failure between software and hardware, several software reliability models based on statistics have been proposed to quantify what we experience with software: the longer software is run, the higher the probability that it will eventually be used in an untested manner and exhibit a latent defect that results in a failure (Shooman 1987), (Musa 2005), (Denney 2005).
As with hardware, software reliability depends on good requirements, design and implementation. Software reliability engineering relies heavily on a disciplined software engineering process to anticipate and design against unintended consequences. There is more overlap between software quality engineering and software reliability engineering than between hardware quality and reliability. A good software development plan is a key aspect of the software reliability program. The software development plan describes the design and coding standards, peer reviews, unit tests, configuration management, software metrics and software models to be used during software development.
A common reliability metric is the number of software faults, usually expressed as faults per thousand lines of code. This metric, along with software execution time, is key to most software reliability models and estimates. The theory is that the software reliability increases as the number of faults (or fault density) decreases or goes down. Establishing a direct connection between fault density and mean-time-between-failure is difficult, however, because of the way software faults are distributed in the code, their severity, and the probability of the combination of inputs necessary to encounter the fault. Nevertheless, fault density serves as a useful indicator for the reliability engineer. Other software metrics, such as complexity, are also used. This metric remains controversial, since changes in software development and verification practices can have dramatic impact on overall defect rates.
Testing is even more important for software than hardware. Even the best software development process results in some software faults that are nearly undetectable until tested. As with hardware, software is tested at several levels, starting with individual units, through integration and full-up system testing. Unlike hardware, it is inadvisable to skip levels of software testing. During all phases of testing, software faults are discovered, corrected, and re-tested. Reliability estimates are updated based on the fault density and other metrics. At a system level, mean-time-between-failure data can be collected and used to estimate reliability. Unlike hardware, performing exactly the same test on exactly the same software configuration does not provide increased statistical confidence. Instead, software reliability uses different metrics, such as code coverage.
Eventually, the software is integrated with the hardware in the top-level system, and software reliability is subsumed by system reliability. The Software Engineering Institute's capability maturity model is a common means of assessing the overall software development process for reliability and quality purposes.
Reliability engineering vs safety engineering[edit]
Reliability engineering differs from safety engineering with respect to the kind of hazards that are considered. Reliability engineering is in the end only concerned with cost. It relates to all Reliability hazards that could transform into incidents with a particular level of loss of revenue for the company or the customer. These can be cost due to loss of production due to system unavailability, unexpected high or low demands for spares, repair costs, man hours, (multiple) re-designs, interruptions on normal production (e.g. due to high repair times or due to unexpected demands for non-stocked spares) and many other indirect costs.
Safety engineering, on the other hand, is more specific and regulated. It relates to only very specific and system safety hazards that could potentially lead to severe accidents and is primarily concerned with loss of life, loss of equipment, or environmental damage. The related system functional reliability requirements are sometimes extremely high. It deals with unwanted dangerous events (for life, property, and environment) in the same sense as reliability engineering, but does normally not directly look at cost and is not concerned with repair actions after failure / accidents (on system level). Another difference is the level of impact of failures on society and the control of governments. Safety engineering is often strictly controlled by governments (e.g. nuclear, aerospace, defense, rail and oil industries).
Furthermore, safety engineering and reliability engineering may even have contradicting requirements. This relates to system level architecture choices .[citation needed] For example, in train signal control systems it is common practice to use a fail-safe system design concept. In this concept the Wrong-side failure need to be fully controlled to an extreme low failure rate. These failures are related to possible severe effects, like frontal collisions (2* GREEN lights). Systems are designed in a way that the far majority of failures will simply result in a temporary or total loss of signals or open contacts of relays and generate RED lights for all trains. This is the safe state. All trains are stopped immediately. This fail-safe logic might unfortunately lower the reliability of the system. The reason for this is the higher risk of false tripping as any full or temporary, intermittent failure is quickly latched in a shut-down (safe)state. Different solutions are available for this issue. See chapter Fault Tolerance below.
Fault tolerance[edit]
Reliability can be increased here by using a 2oo2 (2 out of 2) redundancy on part or system level, but this does in turn lower the safety levels (more possibilities for Wrong Side and undetected dangerous Failures). Fault tolerant voting systems (e.g. 2oo3 voting logic) can increase both reliability and safety on a system level. In this case the so-called "operational" or "mission" reliability as well as the safety of a system can be increased. This is also common practice in Aerospace systems that need continued availability and do not have a fail safe mode (e.g. flight computers and related electrical and / or mechanical and / or hydraulic steering functions need always to be working. There are no safe fixed positions for rudder or other steering parts when the aircraft is flying).
Basic reliability and mission (operational) reliability[edit]
The above example of a 2oo3 fault tolerant system increases both mission reliability as well as safety. However, the "basic" reliability of the system will in this case still be lower than a non redundant (1oo1) or 2oo2 system! Basic reliability refers to all failures, including those that might not result in system failure, but do result in maintenance repair actions, logistic cost, use of spares, etc. For example, the replacement or repair of 1 channel in a 2oo3 voting system that is still operating with one failed channel (which in this state actually has become a 1oo2 system) is contributing to basic unreliability but not mission unreliability. Also, for example, the failure of the taillight of an aircraft is not considered as a mission loss failure, but does contribute to the basic unreliability.
Detectability and common cause failures[edit]
When using fault tolerant (redundant architectures) systems or systems that are equipped with protection functions, detectability of failures and avoidance of common cause failures become paramount for safe functioning and/or mission reliability.
Reliability versus Quality (Six Sigma)[edit]
The everyday usage term "quality of a product" is loosely taken to mean its inherent degree of excellence. In industry, this is made more precise by defining quality to be "conformance to requirements at the start of use". Assuming the product specifications adequately capture customer or (rest of system) needs, the quality level can now be precisely measured by the fraction of units shipped that meet the detailed product specifications.[12]
But are requirements and related product specifications validated? Will it later result in worn items, by fatigue or corrosion mechanisms or due to maintenance induced failures? How many of these systems still meet function and fullfill the needs after a week of operation? What performance losses occured? Did full system failure occur? What happens after the end of a one year warranty period? And what after 50 years (typical high lifetime of Aircrafts, Trains, Nuclear Systems, etc...)? That is where "reliability" comes in. Quality is a snapshot at the start of life and mainly related to control of product specifications and reliability is more of a system level motion picture of the day-by-day operation for many years. Time zero defects are manufacturing mistakes that escaped final test (Quality Control). The additional defects that appear over time are "reliability defects" or reliability fallout. These reliability issues may just as well occur due to Inherent design issues, which may have nothing to do with non-conformance product specifications. Items that are produced perfectly - according all product specifications - may fail over time due to any failure mechanism (e.g. mechanical-, electrical-, chemical- or human error related). Theoretically, all items will functionally fail over infinite time.[13] In theory the Quality level might be described by a single fraction defective. To describe reliability fallout a probability model that describes the fraction fallout over time is needed. This is known as the life distribution model.[12]
Quality is therefore related to Manufacturing and Reliability is more related to the validation of sub-system or lower item requirements, (system) design and life cycle solutions. Items that do not conform to (any) product specification in general will do worse in terms of reliability (having a lower MTTF), but this does not always have to be the case. The full Quantification (in statistical models) of this combined relation is in general very difficult or impossible. In case manufacturing variances can be effectively reduced, six sigma tools may be used to find optimal process solutions and may thereby also increase reliability. Other Reliability Solutions are generally found by either simplifying a system, understanding all mechanisms of failure involved, increase robustness (against variation from the manufacturing variances and failure mechanisms) and possibly to use redundancy and fault tolerant systems in case of high availability needs (see chapter Reliability engineering vs Safety engineering above).
Reliability operational assessment[edit]
After a system is produced, reliability engineering monitors, assesses and corrects deficiencies. Monitoring includes electronic and visual surveillance of critical parameters identified during the fault tree analysis design stage. Data collection is highly dependent on the nature of the system. Most large organizations have quality control groups that collect failure data on vehicles, equipment and machinery. Consumer product failures are often tracked by the number of returns. For systems in dormant storage or on standby, it is necessary to establish a formal surveillance program to inspect and test random samples. Any changes to the system, such as field upgrades or recall repairs, require additional reliability testing to ensure the reliability of the modification. Since it is not possible to anticipate all the failure modes of a given system, especially ones with a human element, failures will occur. The reliability program also includes a systematic root cause analysis that identifies the causal relationships involved in the failure such that effective corrective actions may be implemented. When possible, system failures and corrective actions are reported to the reliability engineering organization.
One of the most common methods to apply to a reliability operational assessment are failure reporting, analysis, and corrective action systems (FRACAS). This systematic approach develops a reliability, safety and logistics assessment based on Failure / Incident reporting, management, analysis and corrective/preventive actions. Organizations today are adopting this method and utilize commercial systems such as a Web based FRACAS application enabling an organization to create a failure/incident data repository from which statistics can be derived to view accurate and genuine reliability, safety and quality performances.
It is extremely important to have one common source FRACAS system for all end items. Also, test results should be able to be captured here in a practical way. Failure to adopt one easy to handle (easy data entry for field engineers and repair shop engineers)and maintain integrated system is likely to result in a FRACAS program failure.
Some of the common outputs from a FRACAS system includes: Field MTBF, MTTR, Spares Consumption, Reliability Growth, Failure/Incidents distribution by type, location, part no., serial no, symptom etc.
The use of past data to predict the reliability of new comparable systems/items can be misleading as reliability is a function of the context of use and can be affected by small changes in the designs/manufacturing.
Reliability organizations[edit]
Systems of any significant complexity are developed by organizations of people, such as a commercial company or a government agency. The reliability engineering organization must be consistent with the company's organizational structure. For small, non-critical systems, reliability engineering may be informal. As complexity grows, the need arises for a formal reliability function. Because reliability is important to the customer, the customer may even specify certain aspects of the reliability organization.
There are several common types of reliability organizations. The project manager or chief engineer may employ one or more reliability engineers directly. In larger organizations, there is usually a product assurance or specialty engineering organization, which may include reliability, maintainability, quality, safety, human factors, logistics, etc. In such case, the reliability engineer reports to the product assurance manager or specialty engineering manager.
In some cases, a company may wish to establish an independent reliability organization. This is desirable to ensure that the system reliability, which is often expensive and time consuming, is not unduly slighted due to budget and schedule pressures. In such cases, the reliability engineer works for the project day-to-day, but is actually employed and paid by a separate organization within the company.
Because reliability engineering is critical to early system design, it has become common for reliability engineers, however the organization is structured, to work as part of an integrated product team.
The American Society for Quality has a program to become a Certified Reliability Engineer, CRE. Certification is based on education, experience, and a certification test: periodic re-certification is required. The body of knowledge for the test includes: reliability management, design evaluation, product safety, statistical tools, design and development, modeling, reliability testing, collecting and using data, etc.
Another highly respected certification program is the CRP (Certified Reliability Professional). To achieve certification, candidates must complete a series of courses focused on important Reliability Engineering topics, successfully apply the learned body of knowledge in the workplace and publicly present this expertise in an industry conference or journal.
Reliability engineering education[edit]
Some universities offer graduate degrees in reliability engineering. Other reliability engineers typically have an engineering degree, which can be in any field of engineering, from an accredited university or college program. Many engineering programs offer reliability courses, and some universities have entire reliability engineering programs. A reliability engineer may be registered as a professional engineer by the state, but this is not required by most employers. There are many professional conferences and industry training programs available for reliability engineers. Several professional organizations exist for reliability engineers, including the IEEE Reliability Society, the American Society for Quality (ASQ), and the Society of Reliability Engineers (SRE).
See also[edit]
- Brittle systems
- Burn-in
- Cauchy stress tensor
- Factor of safety
- Failing badly
- Fault-tolerant system
- Fault tree analysis
- Fracture mechanics
- Solid mechanics
- Highly accelerated life test
- Highly accelerated stress test
- Human reliability
- Industrial engineering
- Integrated logistics support
- Logistic engineering
- Performance engineering
- Product qualification
- Professional engineer
- Quality assurance
- Redundancy (engineering)
- Redundancy (total quality management)
- Reliability (disambiguation)
- Reliability, availability and serviceability (computer hardware)
- Reliability theory
- Reliability theory of aging and longevity
- Reliable system design
- Risk assessment
- Safety engineering
- Safety integrity level
- Security engineering
- Single point of failure (SPOF)
- Software engineering
- Software reliability testing
- Spurious trip level
- Structural fracture mechanics
- Strength of materials
- Systems engineering
- Temperature cycling
- ^ Institute of Electrical and Electronics Engineers (1990) IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York, NY ISBN 1-55937-079-3
- ^ a b c O'Connor, Patrick D. T. (2002), Practical Reliability Engineering (Fourth Ed.), John Wiley & Sons, New York. ISBN 978-0-4708-4462-5.
- ^ a b Barnard, R.W.A. (2008). "What is wrong with Reliability Engineering?". Lambda Consulting. Retrieved 30 October 2014.
- ^ "Articles - Where Do Reliability Engineers Come From? - ReliabilityWeb.com: A Culture of Reliability".
- ^ Using Failure Modes, Mechanisms, and Effects Analysis in Medical Device Adverse Event Investigations, S. Cheng, D. Das, and M. Pecht, ICBO: International Conference on Biomedical Ontology, Buffalo, NY, July 26–30, 2011, pp. 340–345
- ^ Federal Aviation Administration (19 March 2013). System Safety Handbook (PDF). U.S. Department of Transportation. Retrieved 2 June 2013.
- ^ System Reliability Theory, second edition, Rausand and Hoyland - 2004
- ^ The Blame Machine, Why Human Error Causes Accidents - Whittingham, 2007
- ^ Salvatore Distefano, Antonio Puliafito: Dependability Evaluation with Dynamic Reliability Block Diagrams and Dynamic Fault Trees. IEEE Trans. Dependable Sec. Comput. 6(1): 4-17 (2009)
- ^ Practical Reliability Engineering, O'Conner, 2001
- ^ Ben-Gal I., Herer Y. and Raz T. (2003). "Self-correcting inspection procedure under inspection errors". IIE Transactions on Quality and Reliability, 34(6), pp. 529–540.
- ^ a b "18.104.22.168. Quality versus reliability".
- ^ "The Second Law of Thermodynamics, Evolution, and Probability".
Further reading[edit]
- Blanchard, Benjamin S. (1992), Logistics Engineering and Management (Fourth Ed.), Prentice-Hall, Inc., Englewood Cliffs, New Jersey.
- Breitler, Alan L. and Sloan, C. (2005), Proceedings of the American Institute of Aeronautics and Astronautics (AIAA) Air Force T&E Days Conference, Nashville, TN, December, 2005: System Reliability Prediction: towards a General Approach Using a Neural Network.
- Ebeling, Charles E., (1997), An Introduction to Reliability and Maintainability Engineering, McGraw-Hill Companies, Inc., Boston.
- Denney, Richard (2005) Succeeding with Use Cases: Working Smart to Deliver Quality. Addison-Wesley Professional Publishing. ISBN . Discusses the use of software reliability engineering in use case driven software development.
- Gano, Dean L. (2007), "Apollo Root Cause Analysis" (Third Edition), Apollonian Publications, LLC., Richland, Washington
- Holmes, Oliver Wendell, Sr. The Deacon's Masterpiece
- Kapur, K.C., and Lamberson, L.R., (1977), Reliability in Engineering Design, John Wiley & Sons, New York.
- Kececioglu, Dimitri, (1991) "Reliability Engineering Handbook", Prentice-Hall, Englewood Cliffs, New Jersey
- Trevor Kletz (1998) Process Plants: A Handbook for Inherently Safer Design CRC ISBN 1-56032-619-0
- Leemis, Lawrence, (1995) Reliability: Probabilistic Models and Statistical Methods, 1995, Prentice-Hall. ISBN 0-13-720517-1
- Frank Lees (2005). Loss Prevention in the Process Industries (3rdEdition ed.). Elsevier. ISBN 978-0-7506-7555-0.
- MacDiarmid, Preston; Morris, Seymour; et al., (1995), Reliability Toolkit: Commercial Practices Edition, Reliability Analysis Center and Rome Laboratory, Rome, New York.
- Modarres, Mohammad; Kaminskiy, Mark; Krivtsov, Vasiliy (1999), "Reliability Engineering and Risk Analysis: A Practical Guide, CRC Press, ISBN 0-8247-2000-8.
- Musa, John (2005) Software Reliability Engineering: More Reliable Software Faster and Cheaper, 2nd. Edition, AuthorHouse. ISBN
- Neubeck, Ken (2004) "Practical Reliability Analysis", Prentice Hall, New Jersey
- Neufelder, Ann Marie, (1993), Ensuring Software Reliability, Marcel Dekker, Inc., New York.
- O'Connor, Patrick D. T. (2002), Practical Reliability Engineering (Fourth Ed.), John Wiley & Sons, New York. ISBN 978-0-4708-4462-5.
- Shooman, Martin, (1987), Software Engineering: Design, Reliability, and Management, McGraw-Hill, New York.
- Tobias, Trindade, (1995), Applied Reliability, Chapman & Hall/CRC, ISBN 0-442-00469-9
- Springer Series in Reliability Engineering
- Nelson, Wayne B., (2004), Accelerated Testing – Statistical Models, Test Plans, and Data Analysis, John Wiley & Sons, New York, ISBN 0-471-69736-2
- Bagdonavicius, V., Nikulin, M., (2002), "Accelerated Life Models. Modeling and Statistical analysis", CHAPMAN&HALL/CRC, Boca Raton, ISBN 1-58488-186-0
US standards, specifications, and handbooks[edit]
- Aerospace Report Number: TOR-2007(8583)-6889 Reliability Program Requirements for Space Systems, The Aerospace Corporation (10 Jul 2007)
- DoD 3235.1-H (3rd Ed) Test and Evaluation of System Reliability, Availability, and Maintainability (A Primer), U.S. Department of Defense (March 1982) .
- NASA GSFC 431-REF-000370 Flight Assurance Procedure: Performing a Failure Mode and Effects Analysis, National Aeronautics and Space Administration Goddard Space Flight Center (10 Aug 1996).
- IEEE 1332–1998 IEEE Standard Reliability Program for the Development and Production of Electronic Systems and Equipment, Institute of Electrical and Electronics Engineers (1998).
- JPL D-5703 Reliability Analysis Handbook, National Aeronautics and Space Administration Jet Propulsion Laboratory (July 1990).
- MIL-STD-785B Reliability Program for Systems and Equipment Development and Production, U.S. Department of Defense (15 Sep 1980). (*Obsolete, superseded by ANSI/GEIA-STD-0009-2008 titled Reliability Program Standard for Systems Design, Development, and Manufacturing, 13 Nov 2008)
- MIL-HDBK-217F Reliability Prediction of Electronic Equipment, U.S. Department of Defense (2 Dec 1991).
- MIL-HDBK-217F (Notice 1) Reliability Prediction of Electronic Equipment, U.S. Department of Defense (10 Jul 1992).
- MIL-HDBK-217F (Notice 2) Reliability Prediction of Electronic Equipment, U.S. Department of Defense (28 Feb 1995).
- MIL-STD-690D Failure Rate Sampling Plans and Procedures, U.S. Department of Defense (10 Jun 2005).
- MIL-HDBK-338B Electronic Reliability Design Handbook, U.S. Department of Defense (1 Oct 1998).
- MIL-HDBK-2173 Reliability-Centered Maintenance (RCM) Requirements for Naval Aircraft, Weapon Systems, and Support Equipment, U.S. Department of Defense (30 JAN 1998); (superseded by NAVAIR 00-25-403).
- MIL-STD-1543B Reliability Program Requirements for Space and Launch Vehicles, U.S. Department of Defense (25 Oct 1988).
- MIL-STD-1629A Procedures for Performing a Failure Mode Effects and Criticality Analysis, U.S. Department of Defense (24 Nov 1980).
- MIL-HDBK-781A Reliability Test Methods, Plans, and Environments for Engineering Development, Qualification, and Production, U.S. Department of Defense (1 Apr 1996).
- NSWC-06 (Part A & B) Handbook of Reliability Prediction Procedures for Mechanical Equipment, Naval Surface Warfare Center (10 Jan 2006).
- SR-332 Reliability Prediction Procedure for Electronic Equipment, Telcordia Technologies (January 2011).
- FD-ARPP-01 Automated Reliability Prediction Procedure, Telcordia Technologies (January 2011).
UK standards[edit]
In the UK, there are more up to date standards maintained under the sponsorship of UK MOD as Defence Standards. The relevant Standards include:
DEF STAN 00-40 Reliability and Maintainability (R&M)
- PART 1: Issue 5: Management Responsibilities and Requirements for Programmes and Plans
- PART 4: (ARMP-4)Issue 2: Guidance for Writing NATO R&M Requirements Documents
- PART 6: Issue 1: IN-SERVICE R & M
- PART 7 (ARMP-7) Issue 1: NATO R&M Terminology Applicable to ARMP's
- PART 1: Issue 1: ONE-SHOT DEVICES/SYSTEMS
- PART 2: Issue 1: SOFTWARE
- PART 3: Issue 2: R&M CASE
- PART 4: Issue 1: Testability
- PART 5: Issue 1: IN-SERVICE RELIABILITY DEMONSTRATIONS
- PART 2: Issue 1: IN-SERVICE MAINTAINABILITY DEMONSTRATIONS
- PART 1: Issue 2: MAINTENANCE DATA & DEFECT REPORTING IN THE ROYAL NAVY, THE ARMY AND THE ROYAL AIR FORCE
- PART 2: Issue 1: DATA CLASSIFICATION AND INCIDENT SENTENCING – GENERAL
- PART 3: Issue 1: INCIDENT SENTENCING – SEA
- PART 4: Issue 1: INCIDENT SENTENCING – LAND
DEF STAN 00-45 Issue 1: RELIABILITY CENTERED MAINTENANCE
DEF STAN 00-49 Issue 1: RELIABILITY AND MAINTAINABILITY MOD GUIDE TO TERMINOLOGY DEFINITIONS
These can be obtained from DSTAN. There are also many commercial standards, produced by many organisations including the SAE, MSG, ARP, and IEE.
French standards[edit]
- FIDES [2]. The FIDES methodology (UTE-C 80-811) is based on the physics of failures and supported by the analysis of test data, field returns and existing modelling.
- UTE-C 80–810 or RDF2000 [3]. The RDF2000 methodology is based on the French telecom experience.
International standards[edit]
External links[edit]
|This article's use of external links may not follow Wikipedia's policies or guidelines. (August 2010)
- Prognostics Journal, an open-access journal, provides an international forum for the electronic publication of original research and industrial experience articles in all areas of systems reliability and prognostics.
- Models and methods regarding reliability analysis
- Structural Safety


text:
SAN DIEGO, CA - Full Swing Golf has partnered with The Tiger Woods Foundation to present the Closest to the Pin Challenge. The contest kicks off in Full Swing Golf simulators across the globe Oct. 14, 2013 and runs though Nov. 17, 2013. All proceeds from the Closest To the Pin Challenge will support the college access programs of the Tiger Woods Foundation, which helps underserved children gain a better education and a clear path to college. "We're proud that the Tiger Woods Foundation chose Full Swing Golf to create this global contest," says Chad Coleman, Vice President of Sales and Marketing at Full Swing Golf. " The game grows by making golf more fun, engaging and accessible. We're excited to use our platform to raise money and awareness, empowering young people to reach their … Continue reading →
Full Swing Golf Simulators And Tiger Woods Foundation Team Up For Global Closest-To-Pin Contest
Full Swing Golf Simulator Featured At Tiger Jam
SAN DIEGO, CA - Full Swing Golf is proud to announce that its golf simulator was in the spotlight recently at Tiger Jam 2013 in Las Vegas. For the past 15 years, this Tiger Woods-hosted spectacle has been one of the city's premier fundraising events. Between the annual celebrity-filled concert, parties and golf tournament, this endeavor has raised millions of dollars for the college-access programs of the Tiger Woods Foundation. This year's concert featured Kid Rock. In addition, Tiger Jam highlights include top-notch epicurean fare, plus exclusive live and silent auctions featuring one-of-a-kind luxury items. "Guests at the 2013 Tiger Jam raved about the Full Swing Golf simulator experience. It was a great addition to our charity fundraising event in Las Vegas," said the Tiger Woods … Continue reading →
Golf program helps kids beyond the green
OCEANSIDE — Ten-year-old Miguel Martinez was a big fan of playing golf as a video game. He demonstrated his technique last week, with a sweep of his arm, holding an imaginary plastic game wand. But ask him what it's like to step outdoors to play for real on a hilly course with sand traps and putting greens, using a real golf club, and he can hardly get the words out fast enough. "Real life is way better," said Miguel, one of about 250 kids enrolled in Pro Kids Oceanside golf academy. The nonprofit — its full name is Pro Kids, The First Tee of San Diego — started in San Diego's City Heights neighborhood in 1994, using the game of golf as a life lesson and an incentive to help kids to do better in school. It offers after-school tutoring, community service activities and educational … Continue reading →
Full Swing Golf showcased at the CONCOURS D'ELEGANCE
The La Jolla Concours d'Elegance features various types of fine automobile gems. Past years have showcased horseless carriages, Italian marques, British marques, Woodies, 50's classics, American … Continue reading →
SANDOW Brands Powered by Innovation Features Full Swing Golf
SAN DIEGO, CA – A global luxury event series connecting affluent consumers to top luxury products and services from the most desired brands. These interactive experiences showcase private jets and … Continue reading →
Full Swing Golf Simulator Shines at 2012 Masters
AUGUSTA, GA: Once again, Full Swing Golf simulators are the resounding choice for corporate hospitality surrounding the Masters. The industry-leading Full Swing Golf Simulator was featured at both the … Continue reading →
Full Swing Golf and Sports Coach Systems Enter Exclusive Agreement
Eric Murray, CEO of Full Swing Golf states, "Our partnership with Sports Coach instantly expands our global network of interconnected sports simulators and allows us to offer an entry level system … Continue reading →
Full Swing Golf Simulator Serves Up Virtual TPC at 2012 Phoenix Open
SAN DIEGO, CALIFORNIA – As Kyle Stanley was busy staging the largest comeback in Phoenix Open history, a Full Swing golf simulator was lighting up the Mercedes Tent in the Albertson's Fan Zone just … Continue reading →
Full Swing Golf Simulator Entertains Crowd at ESPN's Super Bowl Party
SAN DIEGO, CALIFORNIA – One of the biggest Super Bowl parties every year is ESPN The Magazine's NEXT party, where Full Swing Golf felt right at home entertaining guests. Celebrity and athlete … Continue reading →
Full Swing Golf Simulators Signs Exclusive Partnership with Initial Force AS
SAN DIEGO, CA. – Leading golf simulator company, Full Swing Golf, announced today that it has entered into a long term exclusive agreement with Initial Force AS, developers of innovative golf … Continue reading →

subset: commoncrawl


text:
What do Paris France, Paris Texas and Paris Las Vegas have in common?
All three have an Eiffel Tower of course.
However, the Paris in Las Vegas is surrounded by other hotels that happen to be cities of their own. Last Vegas is a magical place. Not the same magic as Disney, but still magical.
This is the view from the Cesar's hotel room from my last trip to Las Vegas. When I stayed at Cesar's, it happened to be the same week that Michael Jackson died and The Hangover was released.
Thanks for reading and happy shooting,
Comment Policy: Your words are your own, so be nice and helpful if you can. Please, only use your real name and limit the amount of links submitted in your comment. Critiques and conversations are encouraged, however negativity will not be tolerated.


text:
Biofuel Production
Corn for Biofuel Production
Corn (Zea Mays) is a popular feedstock for ethanol production in the United States due to its abundance and relative ease of conversion to ethyl alcohol (ethanol). Corn and other high-starch grains have been converted into ethanol for thousands of years, yet only in the past century has its use as fuel greatly expanded. Conversion includes grinding, cooking with enzymes, fermentation with yeast and distillation to remove water. For fuel ethanol, two more steps are included: molecular sieve to remove the last of the water and denaturing to make the ethanol undrinkable.
Current Potential for Use as a Biofuel


text:
The Joyful Foundation changed locations Tuesday, but its goal to provide big comfort in a small blanket is the same. The group that makes blankets and donates them to sick people is now in Old Town Tustin, at 181 El Camino Real, Suite A.
"There's so much love that goes into these blankets," board member Terri Benedict said. "And we always need sewers."
Anyone can volunteer, Benedict said. Don't know how to sew? There's an orientation that shows how they sew the blankets.
For volunteer information, call 714-997-9532.
– Alma Fausto
Contact the writer: email@example.com
Comments are encouraged, but you must follow our User Agreement
Keep it civil and stay on topic. No profanity, vulgarity, racial slurs or personal attacks. People who harass others or joke about tragedies will be blocked. By posting your comment, you agree to allow Orange County Register Communications, Inc. the right to republish your name and comment in additional Register publications without any notification or payment.


text:
Film magic: student creates luminous dress from old slide film
This shiny little black dress is a knockout on its own. But, for those of us who love wearable technology we get a little bit of a surprise when embedded LED backlights come on in the dress. As ambient light dims and the dress lights up we find it is woven out of old film slides so there are hundreds of little snapshots to enjoy.
From where I'm sitting it takes wearable technology one-step further by adding art into the mix. At the least it's a conversation starter.
The creation is the work of Emily Steel, a student at Victoria University of Wellington's School of Design in New Zealand. As part of her Wearable Technology project she created the dress with the old film, LEDs and an Arduino Lilypad.
Certain frames of film in the dress are backed with the LED lights. The lights are controlled by a light sensor connected to the Lilypad. The sensor detects the light level, and is what tells the LEDs to slowly backlight the film frames as ambient light is dimming. The lights can even pulse, highlighting certain images at a time.
Steel's website describes her inspiration behind what she calls "the Little Slide Dress:"
The Dress draws inspiration from classic movies and the 'magic of film' to create a wearable piece of technology and art… light is so important in the creation and viewing of images [in film] and this was one of the driving forces behind the dress's creation. With film [we] only see what [is] really going on once the lights go out. For this to work there needs to be a balance of projected and ambient light, something the Little Slide Dress tries to emulate.
Finally! A new use for that old undeveloped Kodachrome!
Emily Steel's Little Slide Dress, PSFK, Gizmodo


text:
Contact Information:
The New Orleans Jazz & Heritage Festival and Foundation, Inc.
1205 N. Rampart Street
New Orleans, Louisiana 70116
Phone: (504) 558-6100
Toll Free: (888) 652-8751
Fax: (504) 558-6122
Get In Touch:
Need something more specific? Please complete the form below, and send it to us. We'll get back to you as soon as we can.
Staff Directory:
- Don Marshall, Executive Director firstname.lastname@example.com
- Marsha A. Boudy, Chief Administrative Officer email@example.com
- Scott Aiges, Director of Programs, Marketing & Communications firstname.lastname@example.com
- Rachel Lyons, Archivist email@example.com
- Jarrod Remetich, Senior Accounting Clerk
- Shanna E. Hudson-Stowe, Development Associate firstname.lastname@example.com
- Kia Robinson, Programs, Marketing & Communications Coordinator email@example.com
- Dolores Hooper, Associate Archivist


text:
Dictionary » N » N-dodecanoic acid
N-dodecanoic acid
n-dodecanoic acid --> lauric acid
CH3(CH2)10COOH;a fatty acid occurring in spermaceti, in milk, and in laurel, coconut, and palm oils as well as waxes and marine fats.
Synonym: n-dodecanoic acid.
Please contribute to this project, if you have more information about this term feel free to edit this page
Results from our forum
Re: Any ideas for vaccine development or anti-viral drugs???
... infection. Antimicrob Agents Chemother. 2009 Feb 17. [Epub ahead of print]. Phosphorodiamidate morpholino oligomers (PMO) are uncharged nucleic acid-like molecules designed to inactivate specific gene expression via antisense-based steric hindrance of mRNA translation. PMOs have been successful ...
See entire post
Re: The effect of low temperature on Ascorbic Acid
Might enzymes be present in the orange even if none are added experimentally? If enzymes are present, might they affect the chemistry?
See entire post
The effect of low temperature on Ascorbic Acid
Hello I was wondering why the ascorbic Acid content of oranges might decrease if the temperature decreases to just above freezing. Without enzyme interaction. (focus on the chemistry) Any thoughts on the topic?
See entire post
Re: Food to ATP energy?
... entirely for ATP production). - It should be noted that not all molecules of glucose are used in ATP production. Some are used to produce lactic acid, glycogen, glycerol, fat, and I'm sure there are other metabolites that I'm not thinking of. When glucose is consumed in excess (eating more calories ...
See entire post
drink water, orange juice or Cola before eating?
Drinking too much cola is not good for health. Because it contains phosphoric acid which reduces the bone density and also the reason for chronic kidney diseases. Drinking citrus juices is good for health, because it contains lot of vit C. I think if pH increased ...
See entire post
This page was last modified 21:16, 3 October 2005. This page has been accessed 4,550 times.
© Biology-Online.org. All Rights Reserved.
Register | Login
| About Us | Contact Us | Link to Us | Disclaimer & Privacy | Powered by CASPION


text:
Optional Mid-Panel for 47-Inch BuzziScreenPrice: $561.00
These optional Mid-Panels are sold individually and can be used to expand the BuzziScreen system to any number of panel lengths by adding them to a BuzziScreen Start/Stop set (sold separately). The Mid-Panels can be ordered in a variety of matched or complementary BuzziFelt colors and must be paired with a BuzziScreen Start/Stop set.
Product ships flat. Stitching is Off-white for all panel colors except Off-white which has Orange stitching. One BuzziFoot per two screens. Variation in color and density may occur.
Eco Friendly
Material(s): Felt, upcycled plastic bottle waste, recycled wool, recycled polyacrylic, recycled rags
Dimensions: Individual Panels, each: 31.5"W X 47.3"H
Designer: Sas Adriaenssens
Sas Adriaenssens, the creative brain behind BuzziSpace's innovative acoustic designs, graduated with a Masters in Graphic Arts and Illustration. She began her career working in the marketing field and naturally transitioned into product and interior design. Referring to herself as a creative problem solver, Adriaenssens uses her creativity and practical organizational skills in design, company coaching, image building and painting. Her entire design process is greatly influenced by her strong belief in a designer's ability to determine future waste and aid in the preservation of the planet. Recognized for innovation and ecological impact, Adriaenssens' designs for BuzziSpace have garnered many awards. These awards include the OVAM Ecodesign Award PRO in 2009 and the Henry van de Velde Award for most innovative company in 2011.View other products by Sas Adriaenssens
Manufacturer: BuzziSpace
BuzziSpace: Keeping the peace through innovative, eco-friendly designs for home and office
BuzziSpace, established in Antwerp in 2007, offers innovative acoustic solutions for home and office environments. The company's designs focus on multi-functionalism while embodying functionality, lightness, and flexibility. BuzziSpace strives for innovative acoustic solutions executed via unique products with diverse uses. As the movement towards working and living in open, public spaces grows; private and quiet places for a phone call or meeting are diminishing. BuzziSpace seeks to address these diminishing spots of peace and quiet without disrupting the flow of the open environments where they are located.
Distinguished by acoustics, ecology and flexibility, BuzziSpace products contain a core of sound absorbing eco felt created from 100% recycled plastic bottle waste. Designs aim for optimal sound absorption by concentrating on the range of human speech, the sound frequencies of 250 Hz and 2000 Hz, to create the most peaceful spaces possible.
BuzziSpace is committed to preserving the environment by focusing on a "cradle to cradle" philosophy. Products are created from recycled materials and are recyclable. The company closely monitors raw material recycling in order to continually economize and improve this process, reducing the environmental strain to a minimum impact. This goal has resulted in the development of signature materials BuzziFelt, BuzziRough, and BuzziFabric - all created with recycled content to meet the acoustic and environmental benefits which distinguish BuzziSpace products.
BuzziSpace is the recipient of the of the OVAM Ecodesign Award Pro in 2009 and the Henry van de Velde Award for most innovative company in 2011.View other products from BuzziSpace


text:
Commencement Weekend Ceremonies
Where: Westmont College Campus, Russell Carr Field
When: Friday, May 2, 2014 from 6 p.m. to 7:30 p.m.
Baccalaureate is a special time of worship when the Westmont community gives thanks to God and celebrates the accomplishments of the graduates. Graduates will receive two parking passes for family and friends, as Friday afternoon traffic prohibits shuttling guests to campus. Parking passes will be required for all vehicles entering campus. While there is a limit for cars, there is no guest limit for this event. There are no tickets issued for this event, and none are necessary.
Where: Westmont College Campus, Russell Carr Field
When: Saturday, May 3, 2014 from 10 a.m. to 12:30 p.m.
Each graduate will receive one Commencement Parking Pass to be used that day. All cars entering the campus must display a Commencement Parking Pass. Most guests will park at Santa Barbara City College and ride the free shuttle busses to and from the Westmont campus. There are no tickets issued for this event, and none are necessary.
We suggest that you bring water, sunscreen, sunglasses, hats, layers of clothing and wear comfortable shoes for walking. There will be some snacks, water and flowers to purchase on site. A First Aid tent for emergencies and portable restrooms will also be available.
In order to best enjoy the morning, plan ahead and be EARLY. The field opens at 8 a.m. Know that there will be buses, shuttles, and cars all sharing what will be a one-way road on campus that day.
Commencement Speaker
Pastor Rick Warren
Pastor Rick Warren founded Saddleback Church in Lake Forest, Calif., in 1980 with another family. Today it has grown into one of America's most influential churches, with about 20,000 people attending weekend services. Saddleback offers more than 200 community ministries and support groups for parents, families, children, couples, prisoners, addicts, and people living with HIV/AIDS, depression, MS, Parkinson's and autism, to name a few.
His book, "The Purpose Driven Life," is best-selling hardback in American history, with more than 30 million copies purchased worldwide. Pastor Warren built the Purpose Driven Network, a global alliance of pastors from 162 countries and hundreds of denominations who have been trained to be purpose-driven churches. He also founded Pastors.com, an online, interactive community that provides sermons, forums and other practical resources for pastors, including archives of a bi-weekly newsletter sent to more than 100,000 pastors and leaders in ministry.
Pastor Warren and his wife, Kay, are passionate about global missions and what he calls "attacking the five global giants" of poverty, disease, spiritual emptiness, self-serving leadership, and illiteracy. His solution, The Peace Plan, is a massive effort to mobilize Christians around the world into an outreach effort to attack these five global giants of today by promoting reconciliation, equipping servant leaders, assisting the poor, caring for the sick and educating the next generation.
Born in San Jose, Calif., Pastor Warren earned a Bachelor of Arts degree from California Baptist University, a Master of Divinity from Southwestern Theological Seminary and Doctor of Ministry from Fuller Theological Seminary.


text:
Mystery Book Reviews
Book Review: Blotto, Twinks and the Dead Dowager Duchess
By Sandy Amazeen Jan 17, 2012, 7:55 GMT
Hurrah for the return of that intrepid duo: Blotto (handsome, honorable, not the sharpest knife in the drawer), and his sister Twinks (just a bit brainier than a girl should be)! As this is the 1920s, they are of course attending a weekend house party, where - how astonishing! - a murder is announced. One of the guests has the gall to accuse Corky, the siblings\' family chauffeur, so Blotto ...more
The incredibly handsome but not-too-bright Devereux Lyminster who goes by the name of Blotto and his bright, beautiful sister Lady Honoria Lyminster, better known as Twinks have been conscripted by their mother the Dowager Duchess of Tawcester to attend a weekend houseparty. Blotto in particular just knew the weekend was doomed as not only would he be subjected to matchmaking plans but doubtless, there would be a murder at some point and unfortunately, he was correct on both counts. Before he could be caught in a compromising position with the hostesss daughter, the venerable Dowager was discovered murdered. As Blotto and Twinks investigate the body, they could not help but notice the handprint in red paint on the Dowagers back. After the local constabulary finger Corky, the Lyminsters chauffer as the murderer, Blotto and Twinks must get busy solving the case but there is much more at stake then a simple murder or two. To prevent the destruction of Britains ruling class, Blotto and Twinks will need a good friend or two as they face the Crimson Hand.
If you are searching for a bright, funny murder mystery packed with plenty of hip, hip and cheerio then look no further. Set in British countryside during the 1920s, this delivers a fast, sparkling adventure through the upper crust, a sleazy opium den and an ancient castle while including betrayals, unexpected help, narrow escapes and new uses for cricket bats.
Like this article? Please share on Facebook and give Monsters & Critics a "Like" too!
Further Reading on M&C
COMMENTcomments powered by Disqus


text:
TORONTO — There were whispers about Kyle Lowry's personality as he arrived in Toronto this summer. He was rather hastily traded by Houston last season, even after putting up borderline all-star statistics in the first half. Early in his career, the Memphis Grizzlies chose Mike Conley over him. Many observers pointed to Lowry's prickly personality as a reason for that.
Five questions: The Raptors' trade for Rudy Gay
Following the Toronto Raptors' trade for Rudy Gay, there are a few lingering questions that surround the franchise. Here they are, in order of immediacy:
1. What is Andrea Bargnani's trade value?
General manager Bryan Colangelo told NBA TV and reporters Wednesday night in Atlanta that he has contacted Andrea Bargnani's agent, and that Bargnani would be open to a trade. While Colangelo said that he would not just give Bargnani away, you do not publicly mention that you are open to trading a specific player unless you are pretty committed to doing so. Bargnani is having one of his worst seasons, however, and has not played since early December because of an elbow injury. He is expecting back in the lineup soon, however. There is little doubt that this would be an example of Colangelo selling low on Bargnani, as he is owed more than US$22-million over the next two seasons. It is likely we will find out what he can fetch before the Feb. 21 trade deadline.
But give Lowry credit, even if the start of his Toronto Raptors career did not go as he planned: He was always a solid teammate, especially to the man who took his starting job, Jose Calderon.
Calderon started 30 games in a row after Lowry suffered a triceps injury in December. Lowry supported Calderon demonstratively on and off the court. With Calderon traded away on Wednesday, with Rudy Gay coming the to Toronto, Lowry has his starting gig back now.
"Honestly, it was a hump in the road," Lowry said about the start of the year. "Unfortunately, I got hurt. Jose was playing fantastically. We were winning games. We were trying to win games as a team. It's been an up and down-type six weeks, but at the end of the day, I just wanted our team to win and me to stay professional and get better to help our team win games.
"The burden of it being my team [as the point guard] it definitely is the thing I always wanted. I have no problem with this being my team and having that pressure of being a point guard and everyone looking at me to make the team go."
Lowry is averaging 15.9 points, 5.8 rebounds and 5.7 assists in 16 starts this year, although the Raptors are just 2-14 in those games. It is the front office's working theory that there is not a causal relationship between Lowry starting and losses, especially with Gay coming to Toronto.
Lowry and Gay were friends in AAU, teammates in Memphis and close friends. Lowry missed a Raptors' practice this year to attend the funeral of Gay's grandmother.
"It's very exciting for me personally and for the team and the organization because you get pretty much a superstar-type player, a guy who could be a possible all-star for the next five, six years in a row," Lowry said. "Personally I'm happy. It sucks to lose two great guys in Jose and Ed [Davis]. Those guys were great, playing great this year. It sucks to lose them but it's a business before everything else."
With Gay and DeMar DeRozan likely starting on the wing, the Raptors will be at a bit of a defensive deficit. Neither is a shutdown defender, part of the reason why Memphis shooting guard Tony Allen was so valuable to the Grizzlies — his defensive excellence could cover from Gay's shortcomings. Raptors coach Dwane Casey said the Raptors might use more zone defence.
However, the real change will come on offence. The loss of Calderon likely means the Raptors will have to rely less and less on precise set-plays, with Casey giving leeway to Gay and Lowry to create.
Gay will not play on Friday night against the Clippers. He will likely make his Raptors debut on Sunday against the Heat.
There seemed to be an air of genuine sadness among the Raptors, even the day after the trade. On Wednesday, both Calderon and especially Davis were emotional upon getting the news they were dealt.
"It was tough, man," swingman Alan Anderson said. "It's tough because when I came in last year, they just greeted me with open arms and we just got along and hit it off so good, just like that. Unexpectedly. It was just …it was just so quick. It's more hurtful to see the pain I think, especially Ed in particular. He was starting, had a great season, was playing really good, his best year easily as a professional. It's part of the game, but it's tough."
It's more hurtful to see the pain I think, especially Ed in particular. He was starting, had a great season, was playing really good, his best year easily as a professional
Davis's growth is what allowed this deal to happen. There was a distinct lack of interest in Davis this off-season, as he had to prove he was a capable rotation player. He was the most pleasant surprise about the Raptors' first 46 games this year, with a player efficiency rating well above the league average.
"He put himself in position to be a centerpiece, a part of … a trade. My hat is off to Ed," Casey said. "I think it's a beautiful story. He's an example of what you can do if you put the work in. It says a lot about him."
Gay's arrival creates a logjam at the wing. Gay and DeRozan are both playing nearly 37 minutes per game this year. Alan Anderson is averaging 26. Landry Fields is averaging nearly 24. Rookie Terrence Ross is averaging about 18.
Even if the Raptors use small lineups, with just one traditional big man, there are just not enough minutes to go around to keep all five of those players at those current levels.
However, Ross, because of his potential, three-point shooting and defence, remains a franchise priority.
"He's earned his stripes and is doing what we've asked him to do," Casey said. "[Wednesday] night he didn't have a good shooting night, so we had to get somebody else in for him. He's earned his keep. Nothing is going to happen with Terrence, his minutes, or anything like that."


text:
The following policies have been adopted by the Library to assure fair and equitable access by all to library collections and services.
Contact: Chris Nolan, Library Director, 203-438-2282 ext. 1002, email@example.com
Meeting Rooms
Key Numbers
To renew an item
call x2003
For reference questions
call x2004
For Children's Services
call x2002
For Teen Services
call x1005
For Book Club requests
call x1011
For Adult Programs
call x1013
For Homebound Delivery
call x1003
Enter your email address to receive e-news:
Ridgefield Library | 472 Main Street, Ridgefield, Connecticut 06877 | 203-438-2282 | Directions
- Home
- Catalog & Collections
- Using the Library
- Research & Reference
- Children
- Teens
- Reader's Resources
- News & Events
- About the Library
Privacy Policy | Sitemap | Email us with comments and questions | © Ridgefield Library |


text:
Student Enrollment Verfications
Dear Student,
Do you need an enrollment verification for Fall 2013? Good news! You can now obtain one without a trip to the Registrar's office!
With the FREE* Student Self-Service Site from the National Student Clearinghouse, accessed through MyCUInfo, you have access to the following services securely online, 24/7:
- Print enrollment verification certificates to send to health insurers, housing providers or other organizations requiring proof of your enrollment
- Check the deferment forms and electronic notifications sent to your lenders
- Obtain a list of your student loan lenders and link to real-time loan information
- View your enrollment history
- View enrollment verifications provided to student service providers at your request
*NOTE: You must access the National Student Clearinghouse through MyCUInfo to obtain free enrollment verifications.
Visit the Office of the Registrar online for step-by-step instructions and more information.
If the National Student Clearinghouse verification does not meet your needs, you may obtain a specialized verification at the Office of the Registrar in person or via firstname.lastname@example.com.
The Office of the Registrar
University of Colorado Boulder
20 UCB Boulder, CO 80309
Phone: 303- 492-6970
Fax: 303-492-8748
Map: Regent Administrative Center Room 105
Office of the Registrar
University of Colorado Boulder
Boulder, CO 80309
Phone: 303-492-6970
Fax: 303-492-8748
Map: Regent Administrative Center - Room 105
Important Dates
Frequently Asked Questions
Contact Us
- Email us
- 303-492-6970
- In Person
(9 a.m.–5 p.m.)
Regent Admin. Center 101
Boulder, CO 80309
Online Tools
Calendars & Schedules
Contact Us
- Email us
- 303-492-6970
- In Person
(9 a.m.–5 p.m.)
Regent Admin. Center 101
Boulder, CO 80309


text:
Contact: Patrick Regan
Technische Universitaet Muenchen
Caption: An immune response derived from a single T cell can be visualized directly ex vivo: Progeny of a specific single CD8 T cell is characterized by simultaneous expression of CD8 (x axis) and a defined heritable marker (y axis) setting it apart from all endogenous cells. Here every pixel stands for a cell. A color-coded heatmap indicates high (blue) and low cell density (red). The picture displays more than 20,000,000 cells, only a tiny fraction of which (within the black box) are derived from single transferred T cells.
Credit: Photo by Uli Benz, copyright TU Muenchen.
Usage Restrictions: This image may be freely used, with copyright noted, in news coverage of the TU Muenchen.
Related news release: Insights into the immune system, from the fates of individual T cells


text:
Promotion Terms & Conditions
- To participate, add at least $100 of qualifying merchandise to your cart in order to receive Next Day Shipping.
- Orders must be completed by December 23rd, 2014 2:59 PM to qualify.
- Offer is not valid on Jerseys.
- Offer is not applicable to orders placed through Group Sales.
- Offer is not applicable to gift certificates or gift cards.
- Offer only valid on orders shipped to the contiguous U.S.
- This promotional offer may be modified or terminated at any time without notice.
Main Content
- 100% Acrylic
- Design inspired by vintage NHL uniforms
- Made in China
- Natural insulation keeps drink temperatures regulated
- Officially licensed
- Set of 6 knit can coolers
Leafs Customers also liked:
Special event items are produced by manufacturers only after the outcome of a game or event. These are advanced sale items and will ship immediately after they are received in our warehouse.
Manufacturer direct items are shipped directly from the manufacturer. These items are not available for international or expedited shipping.
Customized items can be personalized with options such as your name, your favorite number, and/or designs. Some options may be limited by league rules.


text:
Access the most comprehensive pro-AV resource in the industry to explore audiovisual equipment catalogs, compare prices, locate service providers and review case studies.
Go to AV-iQ
Economic Snapshot Survey July 2009
Type: Market Research
Topics: Business and Management
Date: July 2009
This report measures macro trends in the AV industry by taking a periodic snapshot of the market. The survey examines key economic-based factors including:
- Overall company performance in the past six months
- Expected company performance in the next six months
- Respondents' level of confidence in, and perceptions of, economic conditions
- Company health and operational indicators
The inaugural survey was launched in August 2008, with new reports at measured intervals in 2009, 2010, 2011 and 2012.
The July 2009 version of the survey, the third in this research series, collected data from 308 AV providers and 53 AV end-users spanning 23 countries.