System Readiness Level Index

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 .

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 .

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 .

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 .

In 1999, the Department of Defense (DoD) embraced a similar TRL concept in their programs .

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 .

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 .

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. 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 .

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 .

Preliminary Metrics

This section describes the two metrics, the Technology Readiness Level (TRL) and Integration Readiness Level (IRL).

TRL

The TRL is a method for estimating the maturity of technologies during the acquisition phase of a program. The use of TRLs enables consistent discussions of technical maturity across different types of technology. A technology's TRL is determined during a Technology Readiness Assessment (TRA) that examines program concepts, technology requirements, and demonstrated technology capabilities. TRLs are based on a scale from 1 to 9, with 9 being the most mature technology .

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

The TRL is defined as a vector with n components where TRL_i is the TRL of component i:

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

IRL

Integration readiness level (IRL) is a systematic measurement of the interfacing of compatible interactions for various technologies and the consistent comparison of the maturity between integration points (TRLs). IRL can be used to describe the integration maturity of a developing technology with another technology. The IRLs check to what degree a technology is ready on a 7-level integration readiness scale. Moreover, the methodology can help discover a direction for improving integration with other technologies .

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

As TRA has been used to assess the risk associated with developing technologies, IRL is designed to assess the risk of integration .

The IRLs assists the systems engineer in identifying development areas that require additional engineering. IRLs also provide a means to reduce the risk involved in maturing and integrating components into a system. Therefore, IRLs can give a combined systems measure for both new system development and technology insertion .

The TRL metric does not accurately capture the risk involved in the adopting of a technology .

Furthermore, technologies can have an architectural inequality related to their integration . As systems’ complexity increases there must be a reliable method for integration that allows TRLs to collectively combine for develop these complex systems

The IRL matrix represents the integration of different components with each other from a system perspective. The integration between components i and j is represented by IRL_ij in the IRL matrix. The theoretical integration of a component i to itself is denoted by IRL_ii and is assumed to be a maximum .

$[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

There are three system readiness metrics that are computed in the SRA process. These are the Component SRL, Composite SRL, and SRL. System readiness incorporates TRL and IRL metrics. The TRL metric provides component knowledge, while the IRL is a metric that provides a description of architectural knowledge. System readiness provides a snapshot in time of the readiness of the entire system.

Component SRL

A Component SRL is the System Readiness Level of an individual component of the system and its integration links . Component SRLs are used to identify system components variations, both in terms of being behind and too far ahead in regard to their readiness and thus require Program Management and/or engineering attention .

The SRL_i for each component i is divided by m_i to obtain its Component SRL value. The m_i term is the number of integrations of component i with every other component as defined by the system architecture .

$Component SRL_i=\frac{SRL_i}{m_i}$

Composite SRL

The Composite SRL measures the SRL of the whole system or all the components of the system integrated together. The SRA approach calculates the Composite SRL by averaging the Component SRLs and rendering the value in a decimal format.

The Composite SRL for the system is the average of the Component SRL values where n is the number of components :

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

Composite SRLs are defined on a scale from 0 to 1 with a value carried out to three decimal places.

SRL

The SRL is obtained by converting the Composite SRL to an 1 to 9 integer scale, with 9 being the most ready.

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

To calculate a value of the SRL from the TRL and IRL values, an SRL matrix is generated by obtaining the product of the IRL and TRL matrices .

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

The SRL matrix consists of one element for each of the represented components and quantifies the readiness level, of a specific component, with respect to every other component in the system while also accounting for the development state of each.

Mathematically, TRL_i represent the individual TRLs and the IRL_ij are the individual IRLs between the components. SRL_i represents the readiness level of Component i, reflecting the readiness of all of its connections .

$\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

This section describes in detail the System Readiness Assessment process. The approach for conducting an SRA is broken down into the following three core steps :

1. Understand and Bound the System
2. Decompose and Map System
3. Perform Iterative Evaluations

Understand and Bound The System

The team performing the SRA gathers any program information that can help support the understanding of the system, I.e., capabilities statements, requirements documents, architecture products, context diagrams, test plans, and any other documents that support understanding the system. Product vendor documentation and relevant published reports may also provide additional information to fill in any gaps to develop a complete understanding of the system. For this step, there is close interaction of the team with the program Lead Systems Engineer (LSE) and Subject Matter Experts .

Decompose and Map System

This step consists of mapping the system that provides a relational understanding between the different layers of architecture. At the highest level, this mapping originates with operational requirements and activities. Functions which trace to these operational activities are then generated. System components which perform these functions are identified. The individual components are comprised of technologies. The SRA method is scalable to large systems in case of an increase of new data gathering, assessments and calculations. The system mapping and component interface diagrams together serve as the foundation on which a SRA analysis is performed. Developing system mappings identifies the linkages and traceability between system components and allows systems to be assessed consistently. All hardware and software components that represent the system are identified. Technologies are mapped to specific components when evaluating TRLs. Mappings are based on what is known as-is and are updated as the design, architecture, or other information changes. The same mapping process can be implemented when doing design or system trade-offs, providing significant benefits and insight into analysis of alternatives .

Perform Iterative Evaluations

The third step in the process evaluates the system to determine its readiness. The evaluation is conducted iteratively through the development cycle and can be continued throughout the system life cycle. All component and integration links must be evaluated for technology and integration readiness. TRLs and IRLs are determined using detailed decision criteria and assigned accordingly. Components may be comprised of more than one technology each with its own TRL. The TRL of a component is determined by assigning to it the minimum TRL of the component’s system technologies. Hence, the TRL is assessed at the technology level and the SRL is calculated at the component level. This approach for determining a component’s TRL is a recommended approach, not a required one. Assessment may be performed at a different level as long as consistency is maintained . The following procedure for calculating the SRL Index is given:

1. SRL Matrix. In order to calculate a value of the SRL from the TRL and IRL values, an SRL matrix is generated by obtaining the product of the IRL and TRL matrices.
2. Component SRL. The corresponding SRL_i for each component i is then divided by m_i to obtain its normalized value.
3. Composite SRL. The Composite SRL for the system is the average of the Component SRL values, where n is the number of components.
4. SRL Translation Model. Composite SRL values are translated to whole numbers consistent with TRL and IRL scaling for ease of interpretation. To translate the 0 to 1 scale to a 1 to 9 scale, the SRL Translation Model is used to map the decimal values to whole number values. Because the SRA is dependent on the system architecture configuration, a SRL Translation Model is generated for each architecture configuration when performing the SRA.

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

The limitations of the SRA are tied to the mathematical biases related to the interpretations of the procedure. The conversion to an integer scale facilitates reporting and interpretation of the results.

The SRA approach calculates the Composite SRL by averaging the Component SRLs and rendering the value in a decimal format. As with any calculation involving an average, the user needs to be aware of the potential risk of masking a Component SRL that may be significantly lagging or leading the average. Furthermore, it could potentially be difficult to understand the difference between system readiness values that are very similar when converting decimals to integer levels via the SRL Translation Model .

Finally, the SRA methodology is currently being validated through a number of program pilots, and the method is therefore not tried and tested. Further validation of the method will be achieved through broader application across multiple enterprises. Future research areas include mathematically sound weighting techniques and leveraging the principles of the SRA framework to model system availability and for other Risk Management techniques .

Annotated bibliography

The following topics would be of interest to further study in relation to the SRA:

Project risk response strategies

The strategies developed to deal with risks at the project level consist of activities guided by the risk management plan, budgeted accordingly, and funded by the project’s contingency reserve. Risk responses consist of additional activities or work packages to update the project’s baselines or remove activities from these same baselines. Whenever the project is part of a program or is managed as part of a portfolio, escalation of risks to a higher governance level is always one of the responses. Escalation increases the effectiveness or efficiency of dealing with specific risks that impact the program or portfolio or with risks that require funding in excess of the contingency reserves.

Qualitative and Quantitative project risk analyses

The evaluation of risks at the project level is performed by taking into account the degree of impact on the project objectives and probability of occurrence. The purpose of these analyses is to evaluate whether or not the impact can be contained within the limits of the project budget and the boundary of accountability of the project manager. Risks that have an impact evaluated as containable within the limits of accountability of the project manager and team are dealt with in the project risk management plan and strategy. Every risk impact that exceeds the limits of accountability is escalated to the appropriate governance level. When the impact of the risk is determined to be containable within the limit of the project budget and accountability of the project manager and team, it is addressed at the project level. If the risk impacts the ability of the organization to obtain or sustain the expected benefits, then the risk and its treatment are escalated to the appropriate governance level.

A Quantitative Analysis of System Readiness Level Plus (SRL+): Development of Readiness Level Measurement

A quantitative combination of levels of readiness can be made and open the potential for expanding the other sizes of readiness levels, such as the Manufacturing Readiness Level (MRL). A measurement tool to measure the development of readiness level by involving MRL is called System Readiness Level Plus (SRL+). This research paper focuses on quantitative analysis of SRL+ model. It consists of the mathematical properties method and readiness reversal method to be conducted to design the SRL+ model .