System Readiness Level Index

From apppm
Revision as of 21:48, 21 February 2021 by S203227 (Talk | contribs)

Jump to: navigation, search

System Readiness Assessment (SRA) is an innovative methodology that provides a system level metric to help reduce integration issues, one of the leading causes of system development failures. The SRA methodology provides decision-makers a snapshot of a system’s holistic state of maturity and quantifies the level of component-to component integration during system development, using a scale from 1 to 9, with 9 signifying the highest level of readiness, to improve system performance management. Implementation of the SRA methodology aids decision makers in identifying both programmatic and technical risk areas. The SRA methodology is currently being validated through a number of program pilots (M. Austin & D. York, P. 496).


Contents

Background And Purpose

In the 1980’s the National Aeronautics and Space Administration (NASA) instituted a seven level Technology Readiness Level (TRL) metric as a quantification methodology to assess the maturity of a particular technology and a scale to compare technologies (From TRL to SRL: The Concept of Systems Readiness Levels, B. Sauser Et al., 2006, p. 1.).

The TRL was initially pioneered by J.C. Mankins at NASA Goddard Space Flight Center as a method to assess the readiness and risk of space technology (M. Austin & D. York, P. 486-487).

Over time, NASA continued to commonly use readiness levels as part of an overall risk assessment process and by the 1990’s this metric had evolved into the nine levels that exist today (From TRL to SRL: The Concept of Systems Readiness Levels, B. Sauser Et al., 2006, p. 1.).

In 1999, the Department of Defense (DoD) embraced a similar TRL concept in their programs (From TRL to SRL: The Concept of Systems Readiness Levels, B. Sauser Et al., 2006, p. 1.).

The TRL scale is a measure of maturity of an individual technology, with a view towards operational use in a system context. A more comprehensive set of concerns become relevant when this assessment is abstracted from an individual technology to a system context, which may involve interplay between multiple technologies. (From TRL to SRL: The Concept of Systems Readiness Levels, B. Sauser Et al., 2006, p.1.).

As systems and technologies become increasingly complex, it is critical to develop a more comprehensive understanding of the readiness of systems to aid in more informed system-level technical and managerial decisions throughout a project’s or program’s life cycle. In order to discover and develop potential system-level metrics, a greater emphasis must be put on the integration between and among individual components. During large-scale developments, it is also critical to measure the system readiness at multiple points along the life cycle to avoid pitfalls that can occur when readiness is only assessed once or twice. The SRA process provides transparency of the entire system’s development life cycle and interfaces to external entities (M. Austin & D. York, P. 486-487). Unlike the Technology Readiness Assessment (TRA), as used to find the TRL metric, the SRA process provides a broader overview of the whole system. This enables the companies to actively trace components throughout the entire system. The SRA process provides a number of additional benefits not provided by the current TRA process (M. Austin & D. York, P. 486-487). The SRA:

  • Measures the readiness of all system components. Hereby, critically considering all elements equally.
  • Has a focus on the readiness both in terms of internal system integration between components and requires a readiness understanding of other external dependencies.
  • Is performed multiple times over the course of the system life cycle and not just at major milestone decisions.

It is critical to measure the system readiness at multiple points along the life cycle to avoid pitfalls that can occur when readiness is only assessed once or twice. As the system development progresses, the TRLs and IRLs of the components will mature and the SRA is calculated for a second snapshot in time, providing the decision maker with risk assessment information. SRAs can be performed on any size program and at any time during the system development. The potential technology and integration risks will determine the frequency at which SRAs are performed. Typically, for larger programs, a quarterly SRA is recommended while for small programs SRAs may be performed every month. Once the system has been defined, the system mapping completed, and the initial SRA done, subsequent or follow-on SRAs can be performed in a reasonably short time (M. Austin & D. York, P. 495).

However, SRAs should be performed early in the life cycle to enable the Program Manager to understand and scope the system being built. The initial SRA is best performed at the beginning of the system development life cycle but can be performed at any time during the life cycle. By creating a comprehensive systems view, the SRA enables developers and systems engineers to perform design trade-offs and make sound design decisions. The SRA gives the Program Manager an overall system perspective so that resources can be effectively applied in the most applicable areas. The SRA process also supports portfolio management. When applied to systems across the enterprise, the SRA approach can provide a picture of both developmental and operational systems, with insight not only into the readiness of individual system components and functions but into enterprise capability readiness as well (M. Austin & D. York, P. 486-487).

Preliminary Metrics

TRL

Level TRL Definition
9 Actual system proven through succesful mission operations
8 Actual system completed and qualified through test and demonstration
7 System prototype demonstration in relevant environment
6 System/Subsystem model or prototype demonstration in relevant environment
5 Component and/or breadboard validation in relevant environment
4 Component and/or breadboard validation in relevant environment
3 Analytical and experimental critical function and/or characteristic proof-of-concept
2 Technology concept and/or application formulated
1 Basic principals observed and reported



[TRL]_{\text{nx1}}=
\begin{pmatrix}
TRL_1 \\
TRL_2 \\
... \\
TRL_n
\end{pmatrix}

IRL

Level IRL Definition
7 The integration of technologies has been verified and validated with sufficient detail to be actionable
6 The integrating technologies can accept, translate, and structure information for its intended application
5 There is sufficient control between technologies neccesary to establish, manage, and terminate the integration
4 There is sufficient detail in the quality and assuranceof the integration between technologies
3 There is compatibility between technologies to orderly and efficiently integrate and interact
2 There is some level of specificity to characterize the interaction between technolgoies through their interface
1 An interface between technologies has been identified with sufficient detail to allow characterization of the relationship


[IRL]_{\text{nxn}}=
\begin{pmatrix}
IRL_{11} & IRL_{12} & ... & IRL_{1n}  \\
IRL_{21} & IRL_{22} & ... & IRL_{2n}  \\
... & ... & ... & ...  \\
IRL_{n1} & IRL_{n2} & ... & IRL_{nn}  \\
\end{pmatrix}

System Readiness Metrics

Component SRL


Component SRL_i=\frac{SRL_i}{m_i}

Composite SRL


Composite SRL=\frac{(\frac{SRL_1}{m_1})+(\frac{SRL_2}{m_2})+...+(\frac{SRL_i}{m_i})}{n}

SRL

Level SRL Definition
9 System has achieved initial operational capability and can satisfy mission objectives
8 System interoperability should have been demonstrated in an operational environment
7 System threshold capability should have been demonstrated at operational performance level
6 System component integrability shouldhave been validated
5 System high-risk component technology development should have been defined and the vaseline has been allocated
4 System performance specifications and constraints should have been defined and the baseline has been allocated
3 System high-risk immature technologies have been indetified and prototyped
2 System materiel solution should have been considered
1 System alternative materiel solutions should have been considered



[SRL]_{\text{nx1}}=[IRL]_{\text{nxn}}*[TRL]_{\text{nx1}}



\begin{pmatrix}
SRL_1 \\
SRL_2 \\
... \\
SRL_n
\end{pmatrix}
=
\begin{pmatrix}
IRL_{11} & IRL_{12} & ... & IRL_{1j}  \\
IRL_{21} & IRL_{22} & ... & IRL_{2j}  \\
... & ... & ... & ...  \\
IRL_{i1} & IRL_{i2} & ... & IRL_{ij}  \\
\end{pmatrix}
*
\begin{pmatrix}
TRL_1 \\
TRL_2 \\
... \\
TRL_i
\end{pmatrix}


The 3-Step SRA Process

Understand And Bound The System

Decompose And Map System

Perform Iterative Evaluations

TRL IRL Composite SRL_i Mean Composite SRL_i Range SRL
9 9 1.000 0.914 - 1.000 9
8 8 0.828 0.914 0.750 - 0.913 8
7 7 0.672 0.750 0.601 - 0.749 7
6 6 0.530 0.601 0.467 - 0.600 6
5 5 0.404 0.467 0.349 - 0.466 5
4 4 0.293 0.349 0.245 - 0.348 4
3 3 0.197 0.245 0.157 - 0.244 3
2 2 0.116 0.157 0.084 - 0.156 2
1 1 0.051 0.084 0.000 - 0.083 1

Limitations

Annotated References

References

Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox