doi:10.3723/ut.31.
077 International Journal of the Society for Underwater Technology, Vol 31, No 2, pp 77–92, 2013
Subsea system readiness level assessment
Sirous Yasseri
Safe Sight Technology, London, UK
Abstract
Both the American Petroleum Institute (API) 17N: 2009 and
Det Norske Veritas (DNV) RP-A203 (2011) recommend that
the technologies inserted into subsea installations should
be assessed during design and manufacturing using a tech-
nology readiness level (TRL) scale. This should be used as
a measure of maturity of all the individual technologies, for
qualification and readiness assurance. This paper proposes
the creation of a system-based approach for managing
the development of subsea systems and making effective
decisions to ensure the efficient progress of the project. It
recommends complementing TRL with an integration readi-
ness level (IRL) scale, to address IRL between the inserted
technologies, along with a system readiness level (SRL)
scale to assess the overall project status. It also presents a
method for combining the current TRL scale and the pro-
posed new IRL scale to determine an estimate of SRL at all
stages of a subsea system development. This provides a
composite metric for determining the system readiness level
for project delivery. The application of the new proposed
scales is demonstrated using a case example.
Keywords: system readiness level (SRL), technology readi-
ness level (TRL), integration readiness level (IRL), subsea
technology qualification, subsea production technical risk
Acronym list
BoD basis of design: This is the system’s engineering
requirements.
DP dynamic positioning
DSM design structure matrix
FAT factory acceptance test
IRL integration readiness level
Integration is the combining of separate compo-
nents into a seamless unit. This is an integra-
tion-specific metric, to determine the integration
readiness between two or more components,
and/or subsystems (hardware and/or software).
SRL system readiness level
This is a metric that incorporates the maturity
level of the integrated system, as well as the
interoperability of the entire system.
SRLest system readiness level estimate
This is the SRL estimate at a review stage, which
determines the current state of the system readi-
ness. It is a derived metric, which aggregates TRL
and IRL of all components of a system that may
be at various levels of development at a given time.
TRL technology readiness level
This is a metric for determining technology matu-
rity before incorporating into a system.
E-mail address: sirous.yasseri@gmail.com
Technical Paper
1. Introduction
Technology readiness levels (TRLs) were first used
by NASA in the 1980s as part of an overall technol-
ogy risk management process. By the early 1990s,
TRLs were routinely used within NASA to support
technology maturity assessments and consistent
comparisons of the maturity between different
technologies (Mankins, 2002).
The US Department of Defense (USDOD)
adopted TRL for risk assessments in 1999 (USDOD,
1998). Current USDOD guidance (2008; 2009)
requires the use of TRL (or an equivalent method-
ology) as part of an overall system technical risk
assessment. These TRLs range from 1 to 9, with
9 signifying the highest degree of readiness and
1 the lowest.
In the UK the Ministry of Defence (MOD)
adopted TRL to improve technology management
to reduce the project delay. In 2007, the UK MOD
updated its TRLs’ section to bring more focus to
the importance of project and sub-project inter-
action when conducting a TRL assessment (MOD,
2008). The MOD replaced NASA’s broad generic
terms with definitions aligned to specific milestones
(MOD, 2011). Because of the success of TRL, a vari-
ety of other maturity metrics have been proposed
as decision support tools (Bilbro, 2007), such as
design readiness level; manufacturing readiness
level; software readiness level; operational readi-
ness level; human readiness levels; habitation read-
iness level; and capability readiness levels.
Many industries have embraced the concept of
TRL as a metric for measuring technology matu-
rity. The American Petroleum Institute (API) RP
17N (2009) adopted TRL methodology for subsea
equipment qualification and Det Norske Veritas
(DNV) RP-A203 (2011) followed later. Bureau
Veritas (2010) addresses the same issue using a
risk-based approach. The API recommended prac-
tice is now written into major petroleum compa-
nies’ procedures as a tool to assess the level of
progress of subsea design, fabrication and com-
ponents’ qualification. Such policies require con-
tractors to hold design and manufacturing reviews
using TRL. Examples of TRL application to the
offshore oil and gas can be found in US Mineral
Management Service (MMS, 2010) and Millheim
et al. (2011).
77

Undoubtedly, TRL is a useful tool for determining a
technology’s maturity before inserting it into a sys-
tem. However, TRL was not intended to assess the
integration of technologies and hence the readiness
of the complete system comprising them. It was orig-
inally used by NASA and later by the USDOD as a
tool for tracking contractors’ progress (Gove et al.,
2007; Sauser et al., 2008a). Therefore, expecting that
TRL will be able to monitor the readiness of a sys-
tem comprising a collection of technologies, which
are individually assessed against TRL, is optimistic.
If the integration of two pieces of technology fol-
lows the same maturation path, just as the technol-
ogies do, then TLR can provide an assessment of
integration readiness, which is true towards the
high maturity end of TRL scale. However, TRL is
not always capable of capturing the many small
errors that can occur when two different compo-
nents of software and/or hardware are brought
tighter to exchange data.
The need to explicitly address the integration of
technology is evident from failures of high profile
projects. For example, in NASA’s Mars Climate
Orbiter, the failure of two – independently evaluated
– technologies to use the same units (i.e. metric ver-
sus imperial) contributed to the loss of the space-
craft (Sauser et al., 2008b). Discovering that different
components designed and fabricated by different
vendors do not match or were designed for a differ-
ent set of conditions is not rare. The problem of
integration becomes more acute when there are a
feed-back and feed-forward loops between vendors,
as changes in one part affect the other, and hence
several iterations may be required to resolve the
interdependent design issues, even though each
design, on its own, looks complete. TRL, as used,
determines where the readiness of a module or com-
ponent lies on the scale, and integration readiness
between modules or the entire system with the envi-
ronment is only implied or is not assessed.
This paper presents the new concept of an inte-
gration readiness level (IRL) scale. Just as a TRL
has been used to assess the risk associated with
developing components, an IRL is designed to
assess the risk associated with integrating these
components. The introduction of an IRL to the
assessment process not only provides a check as to
where the technology is on an integration readi-
ness scale, but also presents a direction for improv-
ing integration with other technologies.
Obviously, at a given review stage components
may not be at the same level of readiness. A meth-
odology is proposed to combine TRL and IRL into
one composite index, termed SRLest, which is an
estimate of a third scale termed the system readi-
ness level (SRL), a third scale. The resultant SRLest
78
Yasseri. Subsea system readiness level assessment
can provide an assessment of overall system devel-
opment and identify problem areas that require
management attention.
The following section introduces a methodology
to map a subsea system, and section 3 discusses the
current TRL for the subsea component readiness.
The paper then introduces the new IRL concept in
section 4 and describes the new concept of SRL in
section 5. The case example in section 6 demon-
strates how a composite scale can be derived and
used in conjunction with the SRL table to deter-
mine what has been accomplished to date. Section
7 discusses issues of the subsea system readiness and
section 8 summarises the conclusions of the paper.
2. Mapping the subsea system architecture
The system architecture is a relationship map,
which shows the position of components and/or
modules and their relationship with each other
(Yassine et al., 2003; Yassine and Braha, 2003;
Danilovic and Browning, 2007). Components can
implement one or more functions, and interfaces
between components (i.e. linkages) must be well
defined. A component is a hardware (or a software)
object with clearly defined interfaces, which
embodies specific functionality and interacts with
other components and/or with the environment to
enable the overall system to function. In this paper
technologies and components are used inter-
changeably, and it also takes readiness and maturity
to be the same entity and uses interchangeably.
An effective method of understanding a com-
plex system is to:
•฀ identify the system boundaries, i.e. the terminal
points and where the system integrates with its
environment (or neighbours);
•฀ break it down into components (and/or mod-
ules), which are easier to understand; and
•฀ identify the interfaces (i.e. dependencies or
relationships) between the components (or mod-
ules) that enable the system to function as a sin-
gle entity (Sharman and Yassine, 2004).
Subsea systems are generally modularised for
ease of installation and parallel engineering. Mod-
ularising requires specifying the architecture and
interfaces governing the modules’ interactions. In
a modularised design the system components are
spilt up and assigned to various modules according
to a formal architectural plan (Eppinger, 1991).
Modules are distinct parts of a larger system;
although designed and produced separately they
must function together.
Modularisation enables managing complexity
and parallel work, such as sourcing from different
 Vol 31, No 2, 2013

suppliers and accommodating future expansion.
Good architecture enables each individual module
and its interfaces to be changed out without under-
mining the functionality of the system. A failed
module can be retrieved and repaired or replaced.
Although in theory modules can be organised in
such a way to minimise the number of interfaces,
the manufacturer’s specialisation largely deter-
mines the subsea modules and their interfaces.
This does not undermine the concept of modulari-
sation, as the linear (sequential) nature of the sub-
sea production system determines the line-up of
components into natural modules.
Fig 1 shows the block diagram of a simple system
consisting of ten components grouped into two
modules at an advanced stage of development.
There are interfaces between components of each
module and between components of the two mod-
ules. Interfaces between two components are shown
by a double-headed arrow, implying that the readi-
ness of two components to be integrated is inter-
dependent. The arrow is not intended to indicate
the direction of flow, but to show dependency. This
paper assumes dependency and interface to be the
same entity. The system matrix is a simple represen-
tation of a system architecture, which captures the
relationship between different components. This is
also a suitable tool for system modelling and analy-
ses, especially for the purposes of decomposition
and integration. Matrix-based approaches are used
for managing complex systems and interactions of
their elements (Steward, 1981).
The DSM (Simon, 1962), which is a square
matrix, has been used in modelling of a variety of
products, processes and organisational structures in
the past (Browning, 2001; Browning and Eppinger,
2002). DSM models can incorporate the concepts
of hierarchy (Eppinger and Browning, 2012), direc-
tion of information flow and dependency. In this
paper, a variation of DSM is tailored, for represent-
ing the subsea architecture and is used as a visual
aid for decomposition and housekeeping when
combining TRL and IRL into a single index. How-
ever, it has a wider application in grouping together
components forming modules for enhancing man-
ufacturing flexibility by reducing the number of
interfaces (Eppinger and Browning, 2012).
The block diagram of Fig 1 is mapped into
design structure matrix (DSM) as shown in Fig 2.
The DSM maps the elements of a system to each
other (like a two-way table), enabling concise rep-
resentation and integration analysis. One reads
across a row of the matrix to see where the element
in that row sends its outputs and reads down a col-
umn to see from where the element in that column
receives its inputs (Browning, 2001).
For example, the element E provides an output
to elements A, D, F and J (reading across row 6)
and receives an input from element A, D, F and J
(reading down column 6). Hence a component
location is known by its column and row. Informa-
tion about dependency or interface is added by
using a marker in the cells to represent relation-
ships (x in Fig 2). An off-diagonal x signifies the

A to F IRL=6

A to E IRL=5
E IRL=5 F
TRL=5 TRL=5

IRL=5
IRL=4
A IRL=5 B
TRL=6 TRL=5
D to E IRL=5 IRL=4
G I
ENV=5 TRL=5 TRL=6 ENV=5
IRL=5 IRL=6
IRL=5
IRL=5
C IRL=4 D
TRL=5 TRL=6
H IRL=4 J
TRL=5 TRL=5
D to H IRL=6

C to J IRL=5

Fig 1: The block diagram for a system with two modules and 10 components (A to J). The double arrows indicate
the interfaces between connected components

79
 Yasseri. Subsea system readiness level assessment

A B C D E F G H I J ENV

A A

B B

C C

D D

E E

F F

G G

H H

I I

J J

ENV

Fig 2: DSM for the system shown in Fig 1. Components A to J are mapped along the diagonal
and interfaces are indicated by a maker

dependency (interface) of one component on
another. The numerical values of X in Fig 2 are the
IRL of the interacting components; they may be
different and thus no symmetry is implied.
Fig 2 shows that C and B are going to be con-
nected. The readiness of C to be integrated with B
is noted at the intersection of column 3 and row 4,
and the readiness of B to be integrated with C is
noted at the intersection of column 4 and row 3,
which are not necessarily equal.
Matrix-based tools provide some insight into the
internal relationship of a complex system (i.e. a
dependency map and their complexity); however,
they do not expose the logic behind these depend-
encies. That is, if component A is shown to relate to
component F, it is not clear why and how this rela-
tionship exists and where it originates from. Such
information can be represented on block diagrams.
The value of the relationship maps is to be able
to show/capture that element A is dependent on F
through some characteristic of A. In doing so, the
analyst would understand better the complexity
of a system and, in turn, has more information
to manage dependencies and leverage them to
improve system performance and mange interfaces
between elements (Eppinger and Browning, 2012).
The block diagram of Fig 1 offers an alternative
method to expand the relationship maps.
3. Technology readiness level
Metrics are an integral part of management activities
for performance measurement, risk management,
quality control and assurance, and maturity
level assessment. Most organisations successfully
employ various metrics in project management and
system engineering. The primary purposes of any
metric are:
•฀ identify critical parameters;
•฀ establish milestones to assess progress;
•฀ provide direction for risk management/
mitigation;
•฀ establish a common understanding of progress;
and
•฀ establish entry and exit criteria for major
milestones.
TRL satisfies all the requirements listed above.
Given the pragmatic benefits of TRL concept, API
(2009) adopted a similar scale. API’s TRL has
8 levels, starting at 0 being ‘unproven idea’ and
ending with 7 as the highest level of maturity, which
is proven in the field. Table 1 is an adaptation of
API’s TRL, where 0 to 6 (more or less) follows 1 to
7 the NASA’s TRL, and API’s 7 combines NASA’s
8 and 9. The dependencies between modules and
the dependency of the system to its environment
are not explicitly addressed by API’s TRL. TRL
does not completely capture the risk involved in
the adopting a new technology, since it does not
address the architectural needs related to integra-
tion. Various studies (Mankins, 2002; Shishko et al.,
2003; Valerdi and Kohl, 2004; Dowling and Pardoe,
2005; Smith, 2005) have discussed the inadequacy
of TRL to address the technology integration issues.
They have also stressed the need for metrics and

80
 Vol 31, No 2, 2013
Table 1: TRL for subsea technology readiness level assessment (API, 2009)
Phase TRL
System validation
Technology validation
Concept validation
Development stage Development stage definition
7 Field proven •฀ ฀Production฀unit฀integrated฀into฀intended฀operating฀system,฀
Production system installed and operating in the same environment and
field proven operating conditions for more than 10% of its design life
with acceptable reliability, demonstrating low risk of early
life failures.
6 System installed •฀ ฀Complies฀with฀all฀requirements฀of฀TRL฀5.
Production system •฀ ฀Production฀unit฀or฀full-scale฀prototype฀built฀and฀integrated฀
installed and tested into intended operating system.
•฀ ฀Full฀interface฀and฀functional฀test฀programme฀performed
in intended or closely simulated environment and
operated for less than three years.
•฀ ฀New฀technology฀equipment฀may฀require฀additional฀
support for first 12 to 18 months of operation.
5 System tested •฀ ฀Complies฀with฀all฀requirements฀of฀TRL฀4.
Production system •฀ ฀Designed฀and฀built฀as฀production฀unit฀or฀full-scale฀
interface tested prototype and integrated into intended operating system
with full interface and functional test, but not usually in
intended field environment.
4 Environment tested •฀ ฀Complies฀with฀all฀requirements฀of฀TRL฀3.
Preproduction system •฀ ฀Designed฀and฀built฀as฀a฀production฀unit฀or฀full-scale฀
environment tested prototype and put through qualification programme in
simulated environment (e.g. hyperbaric chamber to
simulate pressure) or actual intended environment
(e.g. subsea environment) but not installed
or operating.
•฀ ฀Reliability฀testing฀is฀limited฀to฀demonstrating฀that
prototype function and performance criteria can be
complied within the intended operating condition and
external environment.
3 Prototype tested •฀ ฀Prototype฀built฀and฀put฀through฀generic฀functional฀and฀
System function, performance tests.
performance and •฀ ฀Reliability฀tests฀are฀performed฀in฀relevant฀laboratory฀
reliability tested testing environment, including reliability growth tests,
accelerated life tests and robust design development
test programme.
•฀ ฀Tests฀are฀performed฀without฀integration฀into
broader system.
•฀ ฀The฀extent฀of฀application฀compliance฀requirements฀
are assessed and potential benefits and risks are
demonstrated.
2 Validated concept •฀ ฀Concept฀design฀or฀novel฀features฀of฀design฀validated฀
Experimental proof of by physical model, system mock-up or dummy, and
concept using physical functionally tested in laboratory environment.
model tests •฀ ฀No฀design฀history.฀No฀environmental฀tests.
•฀ ฀Materials฀testing฀and฀reliability฀testing฀performed฀on฀key฀
parts or components in testing laboratory prior to
prototype construction.
1 Demonstrated •฀ ฀No฀design฀history.
concept •฀ ฀Essentially฀desk฀study฀not฀involving฀physical฀models฀but฀
Proof of concept as may include R&D experimentation.
desk study or R&D •฀ ฀Technology฀concept฀and/or฀application฀formulated.
experimentation •฀ ฀Concept฀and฀functionality฀proven฀by฀analysis
or reference to features common with/to
existing technology.
0 Unproven concept •฀ ฀Basic฀scientiic/engineering฀principles฀observed฀and฀
Basic research and reported in papers.
development (R&D) •฀ ฀No฀analysis฀or฀testing฀completed฀available.
in papers •฀ ฀No฀design฀history.
81
 Yasseri. Subsea system readiness level assessment

methodology for the coupling and measuring the For a metric to be useful (Dowling and Pardoe,
maturity of multiple technologies within systems. 2005), it must be:
•฀ unambiguous;
4. Integration readiness level •฀ understood by stakeholders with little effort;
Integration is the process of assembling the system •฀ adequately measure the integration maturity;
from its components (Buede, 2000). This seems to •฀ mirror the TRL for ease of implementation; and
imply that ‘putting together’ a system from its com- •฀ simple to apply.
ponents entails no complication, since components
By drawing upon these studies, this paper
are built from specifications, which are recognisa-
extends the same concept to the subsea technology
ble to any system engineer. However, integration
integration. Table 2 shows the proposed metric to
can be a complex process containing multiple over-
measure the subsea IRL, which moves in parallel
lapping and iterative tasks to create a delivery sys-
with TRL.
tem, built to the user requirements and that will
IRL, as TRL, consists of three stages: (1) concept
function in the marine environment.
validation; (2) technology validation; and (3) sys-
The need for a reliable method becomes more
tem validation (see Table 2). Concept validation is
imperative as a system’s complexity increases and
about deciding if a number of technologies can be
components are sourced from diffident manufac-
brought together to perform a function. Clarity
turers. Water depth and availability of installation
and differentiation are important factors at this
vessel (the deck space for assembling components)
stage. Thus IRL 0–2 are considered fundamental
and crane capacity could demand a specific inter-
to describing the three principles of integration,
face type and hence add to complexity.
namely interface, interaction and compatibility.
A technology can only be successfully inserted
The next stage is technology validation, which
into a system if its functionality, maturity and com-
is defined as a conformance to rules. Thus IRLs
patibility allow it to integrate with the rest of the
3–5 are about assurance that an integration solu-
system. The integration should not pose a problem
tion is in compliance with specifications. The final
if the technology and system evolve along similar
stage is system validation, which relates to practical
maturation paths. However, the core technology
considerations. IRLs 6 and 7 are about the assur-
components of a system receive more attention than
ance afforded by integration testing (in-place test-
the linkages between them. Inadequately conceived
ing and actual performance in service).
linkages can cause the integration of components
There are also three aspects to the readiness
from different suppliers to be problematic.
measure: (1) readiness of components to be inte-
The application of metrics to support integration
grated into a module; (2) readiness of modules to
has been extensively used in the computer industry
be connected together to make an assembly; and
to define coupling of components (Orme et al.,
(3) the readiness of the assembly to be integrated
2006; 2007). Mankins (2002) proposes an inte-
into the marine environment. Both components
grated technology analysis methodology to estimate
and modules are tested at the factory for compli-
an integrated technology index and used it for
ance. The factory acceptance test (FAT) qualifies
a comparative ranking of competing systems.
a module as ready to be transported to the site (i.e.
Mankins highlights the difficulty of using the TRL
IRL exceed 4). The assemblies of a few modules are
index when choosing between alternatives.
leak-tested at the site to assure their interface read-
The USDOD and MOD developed a technology
iness for deployment. IRL must be 5 before it can
insertion metric that includes an integration matu-
be installed.
rity level (Dowling and Pardoe, 2005). Gove et al.
Now that both the technologies and integration
(2007) created an IRL to measure integration
elements can be assessed and mapped along a
maturity on a scale similar to TRL.
numerical scale, the next challenge is to develop a
An IRL metric should be able to:
metric that aggregates TRL and IRL.
•฀ determine the integration maturity between two
or more components and/or modules;
•฀ provide a means to reduce the uncertainty in 5. Systems readiness level
integrating new technology into a system; The application of an IRL in the assessment proc-
•฀ meet the system requirements in terms of deliv- ess provides a check as to where the technology
ery time and functionality; and maturity is on an integration readiness scale. Just as
•฀ provide a common platform for tracking the a TRL has been used to assess the risk associated
system development and maturity assessment with developing technologies, an IRL is designed
(Sauser et al., 2008a). to assess the risk associated with integrating these

82
 Vol 31, No 2, 2013

Table 2: IRL for subsea technology readiness level assessment

Phase IRL Development stage Development stage definition
System 7 Integration is field •฀ ฀The฀integrated฀subsea฀system฀is฀in฀production฀and฀is฀in฀compliance฀with฀all฀
validation proven through its functionality requirements.
successful •฀ ฀Inserted฀components฀are฀fully฀integrated฀and฀comply฀with฀all฀performance฀
operations requirements decided at the outset. All components are maturing
to TRL 7.
•฀ ฀The฀integrated฀subsea฀system฀is฀operating฀successfully฀with฀suficient฀
reliability for more than 10% of its service life.
6 Integration is •฀ ฀All฀interfaces฀meet฀and฀exceed฀all฀requirements฀of฀IRL฀5฀and฀below.
completed and •฀ ฀The฀entire฀system฀is฀installed฀and฀tested฀both฀at฀component฀level
qualified through and at system level. The interfaces of assemblies are proven to
sufficient and be reliable.
rigorous testing •฀ ฀Interfaces฀compatibility฀are฀assured฀by฀testing฀in฀the฀marine
in the marine environment.
environment •฀ ฀The฀installed฀system฀is฀being฀commissioned฀and฀its฀functionality
tested.
Technology 5 The integration has •฀ ฀The฀subsea฀system’s฀integration฀meets฀all฀requirements฀of฀IRL
validation been verified and 4฀and฀below.
validated with •฀ ฀Various฀parts฀of฀the฀subsea฀system฀are฀tested฀and฀interactions
sufficient detail for between interfaces are verified through testing in the factory and
the system to be on the site.
deployable •฀ ฀Installation฀contactor’s฀procedures฀and฀tooling฀are฀in฀place฀and฀veriied.฀
Special tools and connectors are on the site and seabed is ready to host.
4 There is sufficient •฀ ฀The฀interfaces฀of฀all฀inserted฀technologies฀meet฀all฀requirements
details to assure of฀IRL฀3.
interoperability •฀ ฀Partly฀assembled฀system฀is฀tested฀on฀the฀site฀and฀the฀compatibility฀of฀
between technologies interfaces is verified for the full design specifications.
necessary to •฀ ฀All฀integration฀issues฀and฀problems฀with฀interactions฀between฀various฀
establish, manage technologies have been teased out.
and assure the •฀ ฀Interface฀requirements฀are฀documented฀and฀interface฀management฀is฀in฀place฀to฀
integration coordinate the flow of information between contactors.
•฀ ฀Quality฀control฀and฀assurance฀are฀in฀place.
3 There is sufficient •฀ ฀All฀requirements฀of฀IRL฀2฀are฀complied฀with.
detail in the control •฀ ฀The฀system฀performance฀requirements฀are฀developed฀and฀translated฀
and assurance of into specifications for interfacing components, modules and assemblies.
the integration •฀ ฀The฀speciications฀include฀performance฀requirements,฀functionality,฀environment฀
between technologies and interface with other systems already in production.
to deliver the required •฀ ฀Technologies฀to฀be฀inserted฀into฀system฀are฀demonstrated฀to฀work
functionality together, either by previous filed proven records or by isolated
factory tests.
Concept 2 There is sufficient •฀ ฀It฀can฀be฀shown฀that฀the฀constituent฀components฀can฀work฀together฀and฀
validation evidence of realistically can perform the required function, but may need future work.
compatibility •฀ ฀An฀interoperability฀check฀is฀made฀on฀the฀components฀of฀the฀system฀to฀
between technologies assure their compatibility.
within the system, •฀ ฀Either฀similar฀assembly฀is฀already฀in฀use,฀or฀proven฀in฀qualifying฀test.
namely they will work •฀ ฀All฀likely฀problems฀can฀be฀solved.฀Special฀tools฀and฀connectors
together and can be are identified.
integrated with ease •฀ ฀Interdependencies฀of฀components฀are฀identiied฀and฀the฀channels฀for฀
two-way flow of information/data are determined. Special needs are known
by now.
1 There is some level of •฀ ฀The฀concept฀has฀taken฀shape฀and฀reined฀to฀a฀point฀where฀the฀basic฀
specificity to the dimension, materials, technology need, interfaces between them etc. have
system functionality been developed.
to allow identification •฀ ฀It฀is฀judged฀that฀all฀needed฀technologies฀can฀be฀made฀into฀a฀seamless฀
of linkage between system. The concept or concepts may not meet all requirements,
technologies but there is a promise to meet all functionality requirements by
additional efforts.
0 The interface, i.e. •฀ ฀The฀linkage฀between฀components฀and฀modules฀have฀been฀characterised฀
the linkage, between and฀are฀judged฀as฀achievable.
technologies can •฀ ฀The฀description฀of฀functionality฀and฀interfaces฀is฀general฀without฀reference฀to฀
be identified/ specific performance.
characterised with •฀ ฀The฀concept฀has฀been฀advanced฀to฀a฀level฀that฀the฀physical฀principles฀can฀
sufficient clarity be communicated though reports and sketches.

83

technologies. Table 3 defines a SRL scale that incor-
porates the maturity level of components and the
interoperability of the entire subsea system.
Sauser et al. (2008a) proposed a method to com-
bine the TRLs and IRLs for a system under devel-
opment, which involves matrix operation. In the
appendix, a simpler methodology is outlined to
aggregate TRL and IRL into a single metric, termed
SRLest. This methodology requires all components
to be assessed using TRL (Table 1), as well as their
readiness for integration with each other and the
environment to be assessed using IRL (Table 2).
The method combines TRLs and IRLs into a sin-
gle composite metric, yielding a numerical value
between 0 and 7. The estimated SRLest is used in
Table 3 to judge what the system readiness is (com-
pared with what it should be) at the time of assess-
ment. Building a spreadsheet (see the case example
in section 6) will enable the user to regularly review
the state of system readiness and track the project’s
progress.
6. Case example
Fig 3 shows a block diagram of a system with ten
components (A to J) arranged in two modules. The
TRL of each component is judged using Table 1
and is noted on its node. The IRL between two
components is shown by a double-headed arrow.
The IRLs of components with dependencies are
judged using Table 2 and are shown on the double
arrows. In this example some components of the
first module have interface with components of the
second module.
Modules are transported to the site after com-
pletion of the FAT, which is a strength test (hydro-
tested at ~1.5 times of the design pressure). Its
primary focus is the weld quality. At the site, a few of
these modules are assembled and hydro-tested at
~1.25 times of the design pressure tested to detect
interface leaks. These two tests determine if a mod-
ule is ready for integration into the marine environ-
ment. Finally, the entire subsea system is hydro-tested
at 1.1 times the design pressure. The intention is to
assure no leakage at the assembly interfaces.
These are the three minimum hydro-tests, with
the relevant load factors as specified in applicable
codes. Some codes, e.g. API 17N or ASME B31.8
(2010), replace the third test with three separate
hydro tests, known as post installation test, inte-
gration test and operational test. In addition,
sometimes a shallow water test is also performed
by immersing a module into the water to ensure
the centres of gravity and of buoyancy are correct.
The components of this system are mapped onto
a DSM as shown in Fig 4. The system matrix is
84
Yasseri. Subsea system readiness level assessment
extended horizontally to show the calculation
details. Columns and rows are numbered for the
ease of referencing. The off-diagonal numerical
entries are IRL, corresponding to an interface
readiness between two components. Not every
component of the system interacts with every
other component, but all of the component inter-
actions that do exist are essential to achieve desired
functionality.
IRLs are taken from Fig 3 and entered into DSM
of Fig 4. For example, ‘6’ at the intersection of
components A (row 3) and F (column 9) is the IRL
of their interface; the same value is entered at the
intersection of components F (row 8) and A (col-
umn 4), but do not need to be the same value. The
matrix diagonal represents integration of a compo-
nent with itself, which is left blank, assuming read-
iness of a component to be integrated with itself
is judged by TRL (column 2).
Assuring correct integration of components into
modules, and then modules into assemblies, satis-
fies the concept and technology validation stages of
integration. For the system validation, these assem-
blies must work together when inserted into the
marine environment, and hence the interaction
and compatibility of the entire system with its envi-
ronment should be assured.
The environmental readiness is somewhat quali-
fied during the design phase by proper choice of
material, corrosion protection, installation proce-
dure, etc. Similarly, it is assured during the first two
stages of interfacing, namely concept validation
and technology validation, by complying with
engineering specifications. However, without the
strength test at the factory and the leak tests, envi-
ronmental readiness remains subjective. This paper
does not introduce another scale for the environ-
mental readiness, but assumes that it matures along
the same timeline as modules and hence can be
measured using the same scale of 0 to 7.
A single value for each module is entered in the
last column of Fig 4 to indicate the module’s envi-
ronmental readiness level. In most cases the envi-
ronment must be prepared (e.g. pre-sweep, seabed
remediation, sand bag markers, foundation) to
host the subsea modules, which is performed just
before installation, when the system reaches matu-
rity level 4.
Note that in Fig 4, the part of the seabed where
a module occupies is not part of the module, but
the module is superimposed on the environment,
and the column 14 represents the environment.
The alternative is to add the associated seabed as a
component to the module.
For this case example, it is assumed that two
interfacing components could be at different
 Vol 31, No 2, 2013
Table 3: SRL for subsea system readiness level assessment
Phase SRL
System validation
Technology validation
Concept validation
Development stage Development stage definition
7 Field proven •฀ ฀The฀subsea฀system฀is฀in฀production฀and฀it฀is฀in฀compliance฀with฀
operational all its functionality requirements.
system •฀ ฀The฀subsea฀system฀is฀operating฀successfully฀with฀suficient฀
reliability for more than 10% of its service life.
•฀ ฀Assure฀the฀operation฀support฀will฀meet฀all฀of฀its
expected functions.
6 The system is •฀ ฀The฀entire฀subsea฀system฀is฀installed฀and฀tested฀both฀at฀
installed tested and component level and at the system level, and it is ready for
commissioning its intended operation condition.
in progress •฀ ฀The฀subsea฀system฀is฀being฀commissioned฀with
operation support.
•฀ ฀Any฀remaining฀problems฀being฀rectiied.
•฀ ฀The฀Health฀and฀Safety฀Executive฀(HSE)฀policy฀is฀monitored.
5 Manufacturing •฀ ฀The฀system฀with฀all฀inserted฀assemblies฀will฀meet฀all
and installation requirements฀of฀SRL4฀and฀below.
in progress •฀ ฀Partly฀assembled/installed฀system฀is฀tested฀and฀compliance฀
verified for the full design specifications.
•฀ ฀Operational฀support฀availability฀is฀identiied฀and฀assured.
•฀ ฀HSE,฀pre-commissioning฀and฀handover฀policy฀are฀established.
•฀ ฀Operation฀support฀needs฀are฀established.
4 Detail design and •฀ The฀chosen฀concept฀is฀detailed.
final procurement •฀ ฀Procurement฀date฀for฀long฀lead฀items฀is฀assured.
•฀ ฀Installation฀and฀commissioning฀contactors฀are฀ready.
•฀ ฀Integration฀and฀manufacturing฀risk฀are฀reduced.
•฀ ฀Procurement฀is฀advanced.
•฀ ฀Seabed฀is฀being฀prepared฀to฀host฀the฀system.
3 Front end •฀ ฀The฀irst฀choice฀and฀the฀competing฀option฀are฀moved฀forward฀to฀
engineering, a level that the difference between them becomes obvious.
sourcing long •฀ ฀Vendors,฀installation฀and฀commissioning฀contactors฀are฀selected฀
lead items and appointed, and assurance that they can meet the delivery
dates is made.
•฀ ฀Possible฀integration฀problems฀are฀checked.
•฀ ฀Logistics฀are฀considered.
•฀ ฀The฀concept฀is฀in฀compliance฀with฀the฀demands฀by฀the
marine environment.
•฀ ฀Seabed฀is฀being฀surveyed.
2 Concept selection, •฀ ฀Two฀or฀more฀options฀which฀best฀satisfy฀all฀requirements
where an optimal are identified.
concept has •฀ ฀Technology฀risk฀is฀reduced.
emerged •฀ ฀Aspect฀of฀technologies฀to฀be฀used฀is฀clariied.
•฀ ฀The฀most฀promising฀option฀is฀selected.
•฀ ฀The฀project฀schedule฀is฀determined.
1 Concept •฀ ฀Promising฀concept฀is฀reined฀to฀an฀adequate฀level฀of฀maturity.
refinement •฀ ฀The฀concepts฀are฀priced฀and฀ranked฀according฀to
Two or more their desirability.
competing concept •฀ ฀Technologies฀that฀are฀needed฀are฀researched฀to฀see฀if฀they฀can฀
being considered be procured and at what price.
•฀ ฀The฀available฀infrastructure,฀means฀of฀transportation฀and฀
installation contactors availability are studied.
•฀ ฀Operational฀requirements฀are฀considered.
•฀ ฀Fabrication,฀transportation฀and฀installation฀are฀considered.
•฀ ฀The฀inluence฀of฀the฀marine฀environment฀on฀the฀system฀is฀
studied and written into the basis of design.
0 Concept definition, •฀ ฀Reservoir฀data,฀geotechnical฀data,฀drilling฀requirements,฀
where various ideas distances and existing infrastructure information is collected.
are being considered •฀ ฀Concepts฀are฀developed.
or discounted •฀ ฀Economically฀or฀technically฀unfeasible฀concepts฀are฀
screened out.
•฀ ฀The฀schedules฀are฀established฀and฀checked฀if฀they
are realistic.
•฀ ฀Finance฀is฀considered.
85
 Yasseri. Subsea system readiness level assessment

Previous
Module

A to E IRL=5
A E
TRL=6 TRL=5

IRL=5 IRL=5

IRL=5
B F
TRL=5 A to F IRL=6 TRL=5

IRL=5
IRL=6 IRL=5
ENV=5 IRL=4
D to E IRL=5 G
C ENV=5
TRL=5 TRL=5

IRL=4
IRL=4
H
D
TRL=5
TRL=6

D to H IRL=6
IRL=4

I
TRL=6
Next
Module
IRL=5

J
TRL=5
C to J IRL=5

Fig 3: A simple system consisting of 10 components arranged in two modules. Interfaces are shown by double
headed arrow

TRL, but their IRLs are the same and equal to the
less ready component (because of mutual depend-
ency), hence yielding a symmetric matrix. In gen-
eral, if two components have to come together to
create a connection, there may be different degrees
of integration readiness for each component and
therefore the matrix is not symmetric. Symmetry
assumption is not necessary for the success of
the method and can be dropped, if it is believed
that retaining two different IRL for interfacing
components would yield useful information.
The distance between the furthest off-diagonal
terms to the diagonal is known as the bandwidth of
the matrix. A narrow bandwidth is an indication
of a good system line-up (modularisation). A high
bandwidth, as in this example, signifies that too
many components from different modules are
dependent on each other, which adds to the cost of
managing the interface and will probably lead to
delays. There are algorithms to collect components
into modules in order to reduce the bandwidth
and lower the dependencies.
Each row of column 15 of Fig 4 is the average IRL
for the row, determined by summing up of IRLs of
all interfaces across the row and dividing it by the
number of interfaces – e.g. (5 + 6 + 5 + 6)/4 = 5.5.
Column 16 gives the results of multiplication of the
component’s TRL by the average of its IRLs, e.g. in
row 3, it is 6 × 5.5 = 33. The square root of column
16 is given in column 17, giving a composite compo-
nent readiness index. Column 18 is the square root
of mean of squares noted in column 16, which is
the sum of all squares in column 16 divided by the
number of components in the module.

86
 Vol 31, No 2, 2013

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Ave. TRL*Ave SQRT
2 TRL A B C D E F G H I J ENV
IRL _IRL (Col16)
3 6 A 5 6 5 6 5.50 33.00 5.74
4 5 B 5 5 5.00 25.00 5.00
5.31
5 5 C 5 4 5 4.67 23.33 4.83
6 6 D 6 4 5 6 5 5.25 31.50 5.61
7 5 E 5 5 5 5 5.00 25.00 5.00
8 5 F 6 5 5 4 5.00 25.00 5.00
9 5 G 5 4 4.50 22.50 4.74
4.95
10 5 H 6 4 5.00 25.00 5.00
11 6 I 4 4 5 4.33 26.00 5.10
12 5 J 5 5 4 5 5 4.75 23.75 4.87

13 4.34

Fig 4: DSM for the example case

The readiness for the first module is calculated as: controlled project ensures that TRL, IRL and SRL
closely follow each other. The derived system readi-
33 + 25.00 + 23.33 + 31.50 ness index of 4.34 indicates that some components
M 1R = = 5.31 (1)
4 are not maturing within the desired time frame. In
this hypothetical example, components with TRL
The denominator of 4 is the number of compo- or IRL lower than 4.34 need to be scrutinised.
nents of the first module. Similarly for the second While this case example is simple, the underlying
module, the readiness is calculated as: methodology is important. It demonstrates how to
use DSM to combine TRL and IRL into a new met-
25.00 + 25.00 + 22.50 + 25.00 + 26.0 + 23.75 ric, which indicates the readiness of the system. In
M 2R =
6 addition to this housekeeping advantage, DSM pro-
= 4.95 (2) vides a visual aid to present the system audit results
to the senior managers. The advantage becomes
Therefore, the readiness of each module to be more evident when dealing with more than
integrated into its environment is judged to be 5 for 200 components manufactures in various locations
both modules of the case example using Table 3. that must mate and work together when assembled.
Hence, the aggregate system readiness index (SRI) is:

(5.31)2 × 5 + (4.95)2 × 5 7. Discussion

SRI = = 4.34
7 ×2
The denominator of 7 is the highest IRL in Table
2; this number is used to normalise the environmen-
tal integration readiness level, namely 5/7, which is
the same for both modules in the example. From a
metric point of view, SRLest and SRL are meant to
measure the same things on the same scale. How-
ever, SRL is defined (Table 3), while SRLest is derived
by aggregation of attributes of all components,
which may be at different levels of TRL and IRL. If
all components mature simultaneously along the
same path, then SRLest reduces to SRL.
Entering Table 3 with 4.34, the system must be at
assembly and installation stage; if the project sched-
ule requires a different level then this must be justi-
fied. This index informs the management when
and where to intervene if the system readiness is lag-
ging behind the schedules. The markers in each
row identify which other components must be ready
for the integration to become complete; hence
interfaces must be adequately managed. A tightly
(3) Measuring technology and system maturity is a
multidimensional process that cannot be per-
formed adequately by a one-dimensional metric
such as TRL. Although TRL has been employed by
many industries, it captures only a part of the infor-
mation needed to support stakeholders’ decisions.
TRL was not designed to assess the quality of the
system architecture, design or integration, but only
to measure the readiness of system components
based on what has been accomplished at the time
of assessment.
IRL addresses this shortcoming, but it must be
aggregated with TRL into a single composite index
to be useful. In turn, there is a need for a scale to be
used with this composite index. It is also proposed
to use DSM as a visual aid to bring together all three
elements of system maturation metrics. Readiness
of components to be integrated into a module,
or modules to be connected together, may be
assessed by engineering judgment in formal
reviews, assisted by measurements, specifications,
codes and procedures.

87

This paper has also introduced the concept of envi-
ronmental integration readiness level (i.e. module/
assemblies-to-marine-environment) for assemblies
consisting of several modules that are large/heavy
enough to be installed in a single operation. The
readiness of all components cannot be assured
until the factory acceptance tests, the leak tests at
the site and in-place operational tests are per-
formed. It should be kept in mind that by IRL = 5,
all of the technical integration issues must be
resolved. Once it reaches this level, the focus should
be on confirmations of integration by more testing
and the actual performance. In the context of this
work, the integration readiness of modules-to-
marine-environment may be judged using the avail-
able physical evidences, e.g. tests and compliance
with rules, specifications and codes.
The root mean square (RMS) method was used
for determining SRLest (see for example Bissell
and Chapman, 1992). This estimated value incor-
porates not only the current maturation of all
components, but also the physical properties of
interfaces, integrations requirements, interaction,
compatibility, reliability, quality and performance
when assemblies are brought together to deliver a
specific functionality.
The dependency of the system on the seabed is
generally studied at the concept phase, and the
demand of environment, such as geohazards, cor-
rosion, unstable and uneven seabed are identified
and written into the basis of design (BOD). The
compliance of the design with the BOD is reviewed
at all stages of the system development. Thus, the
manufactured modules are expected to withstand
the demand of its environment when installed.
However, the readiness of environment to host the
system is considered when the subsea system is
ready to be installed.
Early seabed surveys help to identify suitable
positions for the subsea system. However, the major
part of making the seabed ready for receiving the
subsea system takes place before installation, when
the modules and assemblies readiness exceed
level 4. The major activities for the installation
preparation are:
•฀ acquisition of the permit (permission) for the
vessel to enter the area;
•฀ deployment of ship’s transponder on the
seabed;
•฀ deepwater trials to assure redundancy of the
deepwater system and also drift off tests;
•฀ as-found survey looking for anomalies, debris
and variation of the seabed;
•฀ installation of transponders array to obtain a
frame of reference for poisoning;
88
Yasseri. Subsea system readiness level assessment
•฀ seabed corrections and remediation, involving
removal of debris, possibly dredging and shoring
up; and
•฀ accurate positioning/laying down buoyancy
markers ballasted with sand bags. These mark-
ers act as visual aids for installation, by for
example, identifying the corner locations for
structures.
The linear asset (e.g. pipelines, flowlines) fol-
lows a similar path, but is not necessarily in sync
with the major equipment. Some post installa-
tion interventions, e.g. trenching of pipelines and
piling of subsea structures, may be required to
secure the asset.
The subsea architecture is represented by a
component-component (N-square) matrix – the
DSM – which can describe a system structure with
respect to the relationships between its compo-
nents. The DSM is an effective representation tool
for mapping subsea equipment and its linkages.
DSM provides a platform for communicating about
quality and alternative architecture, and managing
interfaces. Its use can improve understanding of
the project progress and communicating this to the
senior managers. Simply building the DSM helps to
increase overall awareness and understanding the
relationship between components in the system.
Integration analysis using a DSM promotes trans-
parency by showing all metrics in one picture.
DSMs can also address the following types of
questions:
•฀ Should the components be organised differently
to improve interface management and delivery?
•฀ How should those modules requiring too many
interfaces be reconfigured?
•฀ Where and which integrative mechanisms might
be prudent?
•฀ Are the current choices of integrative mecha-
nisms well balanced?
•฀ Are the interactions as shown in DSM correct and
sufficient for the interface management?
Interfaces between components of one module
do not require the same level of management time
as interfaces between components of two or more
modules supplied by different vendors. The goal of
DSM is to analyse the components within a system,
and it allows one to re-sequence these in order to
minimise interface between modules.
DSM identifies bottlenecks during design, fabri-
cation and installation. The diagonal entries of the
matrix do not have any interpretation in describing
the system; they are either left blank, or filled in
with the component labels. This is done to separate
the upper and lower triangles of the matrix and to
 Vol 31, No 2, 2013
show the interfaces more clearly. The number of
markers in a row determines dependencies, as well
as the level of demand on the interface manage-
ment and the criticality of the component. DSM
can become the foundation for the optimal
resource allocation, monitoring and evaluation
tool. It can also be a basis for common measure-
ment and language for delivery managers to
improve the system development and acquisition
process.
The complexity of the interfaces is not shown on
the Fig 4, but it can be indicated by colour coding
of the relevant cell using a five level designation:
none, minor, moderate, high and very high. No
colour implies that there is no specific interface
requirement or, if there is one, that its complexity
is negligible. An alternative is to use a scale of 1 to
5 with 5 being the highest.
The methodology that is described here is simple
enough to be usable in practice, and yet adequately
captures all relevant data and gives a clear picture
of the entire system. It provides, with little effort
from the user, a view of the system that is valuable
especially during ongoing development. The con-
cepts described here complement the practice of
TRL and offers a vision of the system readiness
that is compatible with the intuition of practicing
engineers.
8. Concluding remarks
This paper presents a system-based approach for
managing subsea system development and mak-
ing effective and efficient decisions for hardware
and software, acquisition and their integration.
This provides system engineers, delivery managers,
quality control managers and project managers a
common metric that can aid them in making effec-
tive and timely decisions during all phases of a sub-
sea system development. This should help reduce
both a project’s technical risk and schedule risk.
The new IRL scale, which parallels the current
TRL scale, is necessary because when components
are procured from different sources, integration
could pose a problem if not properly managed.
The proposed IRL mimics the value of the TRL by
being simple to understand and use. A new SRL is
also introduced as a scale for measuring the matu-
ration of the entire subsea system. To tie up these
three matrices, a methodology is described that
combines TRLs and IRLs at the time of evaluation,
into a single composite index termed SRLest. This
composite index is an estimate of the system
readiness level. By applying Table 3 and this index,
the stage of advancement of the project can be
determined.
This paper also introduces the DSM for map-
ping the subsea architecture, namely all compo-
nents and their linkages, into a single table (matrix)
as a visual aid. DSM shows interdependencies
between components and the need for information
flow for the interface management. Consequently,
DSM shows TRL and IRL in a single table. These
metrics can identify critical parameters, establish
milestones to assess progress, offer direction for
risk management/mitigation and identify hot spots
requiring management intervention.
In summary, this paper provides a basis for:
•฀ collective evaluation of component integration
and system readiness to reduce schedule and
technical risks;
•฀ a dynamic assessment tool for tracking the
progress of design, manufacturing and installa-
tion; and
•฀ developing contingency, multiple-sourcing and
sparing policy through the comparative analysis
of multiple technologies.
References
American Petroleum Institute (API). (2009). AP RP 17N
Recommended practice for subsea production system reliability
and technical risk management. Washington DC: API.
Bilbro JW. (2007). A suite of tools for technology assess-
ment. Presented at: Technology maturity conference:
multi-dimensional assessment of technology maturity.
Virginia Beach, VA, 11–13 September. Available at
www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA507181 last
accessed <10 October 2012>.
Bissell C and Chapman D. (1992). Digital Signal Transmis-
sion. Cambridge University Press. UK.
Browning TR. (2001). Applying the Design Structure Matrix
to System Decomposition and Integration Problems:
A Review and New Directions. IEEE Transactions on Engi-
neering Management 48: 292–306.
Browning TR and Eppinger S. (2002). Modelling Impacts
of Process Architecture on Cost and Schedule Risk in
Product Development. IEEE Transactions on Engineering
Management 49: 428–442.
Buede DM. (2000). The engineering design of systems: Models
and methods. New York: Wiley.
Bureau Veritas (BV). (2010). BV NI525:2010 Risk based
qualification of new technology methodological guide-
lines. Neuilly-sur-Seine, France: BV, 20pp.
Danilovic M and Browning RT. (2007). Managing complex
product development projects with design structure
matrices and domain mapping matrices. International
Journal of Project Management 25: 300–314.
Det Norske Veritas (DNV). (2011). DNV-RP-A203 Recom-
mended practice: Qualification of new technology. Oslo,
Norway.
Dowling T and Pardoe T. (2005). TIMPA – Technology
insertion metrics, volume 1. London: Ministry of Defence,
QinetiQ.
Eppinger SD. (1991). Model-based approaches to manag-
ing concurrent engineering. Journal of Engineering Design
2: 283–290.
89

Eppinger SD and Browning TR. (2012). Design structure
matrix methods and applications (engineering systems).
Cambridge, MA: MIT Press, 280pp.
Gove R, Sauser B and Ramirez-Marquez J. (2007). Integra-
tion maturity metrics: development of an integration readiness
level. Hoboken, NJ: Stevens Institute of Technology,
School of Systems and Enterprises.
Mankins JC. (2002). Approaches to strategic research and
technology (r&t) analysis and road mapping. Acta Astro-
nautica 51: 3–21.
Millheim K, Williams TE and Yemington CR. (2011). Evalu-
ation of well testing systems for three deepwater gulf of mexico
(GOM) reservoir types, SPE 145682. Richardson, TX: Soci-
ety of Petroleum Engineers.
Mineral Management Service (MMS). (2010). US MMS –
Enhance Recovery Study, Document and Revision
Number: KRNACRI090620-020FR, total number of
pages 81.
Ministry of Defence (MOD). (2008). System Readiness
Levels (SRLs). AOF Technology Management Policy,
Information and Guidance on the Technology Manage-
ment aspects of Defence Acquisition version 1.0.1.
London: MOD.
MOD. (2011). Defence Technology Strategy for the
Demands of the 21st Century. London: MOD.
Orme AM, Yao H and Etzkorn LH. (2006). Coupling Metrics
for Ontology-Based Systems. IEEE Software 23: 102–108.
Orme AM, Yao H and Etzkorn LH. (2007). Indicating
ontology data quality, stability, and completeness
throughout ontology evolution. Journal of Software Main-
tenance and Evolution 19: 49–75.
Sauser BJ, Ramirez-Marquez JE, Henry D and DiMarzio D.
(2008a). A system maturity index for the systems engi-
neering life cycle. International Journal of Industrial and
Systems Engineering 3: 673–691.
Sauser B, Ramirez-Marquez JE, Magnaye R and Tan W.
(2008b). A systems approach to expanding the technol-
ogy readiness level within defense acquisition. Interna-
tional Journal of Defense Acquisition Management 1: 39–58.
Sharman D and Yassine AA. (2004). Characterizing
Complex Product Architectures. Systems engineering 7:
35–60. DOI: 10.1002/sys.10056.
90
Yasseri. Subsea system readiness level assessment
Shishko R, Ebbeler DH and Fox G. (2003). NASA Technol-
ogy Assessment Using Real Options Valuation. Systems
Engineering 7: 1–12.
Simon HA. (1962). The architecture of complexity. Proceed-
ings of the American Philosophical Society 106: 467–482.
Smith JD. (2005). An alternative to technology readiness
levels for non-developmental item (NDI) software. Paper
read at 38th Hawaii International Conference on System
Sciences.
Steward DV. (1981). The design structure system: a method
for managing the design of complex systems. IEEE Trans-
actions on Engineering Management 28: 71–74.
US Department of Defense (USDOD). (1998). Levels of
Information Systems Interoperability, the US Depart-
ment of Defense. Available at www.eng.auburn.edu/
~hamilton/security/DODAF/LISI.pdf last accessed
<13 January 2013>.
USDOD. (2008). DOD Directive 5000.2 – Instruction:
Operation of the Defence Acquisition System: US
Department of Defense. Available at www.dtic.mil/
whs/directives/corres/pdf/500002p.pdf last accessed
<13 January 2013>.
USDOD. (2009). Technology Readiness Assessment (TRA) Desk-
book, Research Directorate, Office of the Director,
Defence Research and Engineering (DDR&E), US Depart-
ment of Defence. Available at www.acq.osd.mil/ddre/
publications/docs/TRA2011.pdf last accessed <13 January
2013>.
Valerdi R and Kohl RJ. (2004). An approach to technology risk
management. Paper read at engineering systems division
symposium, 29–31 March, Cambridge, MA. Available at
http://web.mit.edu/rvalerdi/www/TRL%20paper%20
ESD%20Valerdi%20Kohl.pdf last accessed <13 January
2013>.
Yassine A and Braha D. (2003). Complex Concurrent Engi-
neering and the Design Structure Matrix Method. Vol-
ume 11 Number 3. Concurrent Engineering: Research
and Applications. Sage Publications.
Yassine A, Whitney D, Daleiden S and Lavine J. (2003). Con-
nectivity maps: modelling and analysing relationships in
product development processes. Journal of Engineering
Design 14: 377–394.
 Vol 31, No 2, 2013

Appendix

Suppose there are J independent components, (X j interfaces with Nj components, and the IRLS are
j = 1, 2, . . . , J ), partitioned into M independent given by IRLjn , for a given n = 1, 2, …, Nj .
modules as shown in Fig 5. TRL of Xi (TRLi) is The average of the integration readiness of Xj
noted next to row Xi. The readiness level of compo- is given by:
nent Xi to be integrated with the component Xk is
shown by an x at the intersection of column Xi with Nj
row Xk. Similarly, the readiness level for Xk to be (X jIRL )Ave =
∑ n =1 IRL jn ,
integrated with Xi is shown in column Xk and row Nj
Xi. It is assumed the mutual readiness levels are the for j = 1,..., j , and for a given j, n =1, ..., N j (A1)
same, hence yielding a symmetric matrix. The
bandwidth of this matrix indicates the success of
modularisation. where Nj is the number of interfaces of Xj
Let TRLj , j = 1, 2, . . ., J to be at the TRL level (e.g. component A of the example has Nj = 4
of Xj j = 1, 2, . . ., J. Component Xj (row Xj) has interfaces);

J components

X1 X2 X3 X4 . . Xi Xj Xk Xl . . . . . . . XJ ENV

X1 TRL1
N1 dependencies for X1
X2 TRL2
Module 1
X3 TRL3

X4 TRL4

Xi
Ni dependencies for X i
Xj

Xk
Module m
Xl

Module M

XJ TRLJ NJ dependencies for XJ

ENV

Fig 5: A typical DSM consisting of J components and M modules. Interfaces are shown by x.
TRL of each component are noted in the second column. The last column shows the integration
readiness for each module with the marine environment

91
 Yasseri. Subsea system readiness level assessment

J is the number of components (e.g. for the
case study, J = 10 components, which are labelled
using the alphabet); and
IRLjn, (for a given j, n = 1, …, N) is the interface
readiness as entered in row j.
If there are M modules with different readiness
to be integrated with its environment, then the
system’s composite readiness index is given by:
(IRL ENV )1 ×(M 1 )2 + ...
CR

For the component A of the case example:

+ (IRL ENV )m ×(M m )2 + ...
CR

5+6+5+6 + (IRL ENV )M ×(M M )2

(AIRL )Ave = = 5.5 (A2) (SRL )estimate = CR
(A6)
4 7 ×M
The composite readiness of component Xj is
given by: where (IRLENV)m is the readiness of module m to be
integrated with the environment and m = 1,2, …, M.
X j = TRL j ×(X j )Ave , for j = 1, ..., J (A3) The number 7 in the denominator is the highest
CR IRL
readiness level, which a system can achieve on IRL
scale, and it is used to normalise the readiness of
In this paper, Xj = A,B,C, … J. For the aggregate
each module to be integrated with the marine envi-
readiness, i.e. weighted mean, of component A
ronment (IRLENV). Thus, at the highest level of
of the case example is:
readiness, a value of 1.0 (100%) can be obtained
ACR = 6 × 5.5 = 5.74 (A4) for IRLENV / 7.
For the case example, this is calculated as:
The composite readiness of the module Mi (i =
1, 2, ..., M ) is given by: 5 ×(5.31)2 + 5 ×(4.95)2
(SRL )estimate = = 4.34 (A7)
7 ×2
K
∑ K =1,(X K CR
)2 This paper assumes that the system is dependent
Mi = (A5) on the seabed, but not vice versa. If it is desirable to
CR
K
assume that the system and the seabed are inter-
where K is the number of components in Mi. dependent, then the seabed portion of each mod-
This is the RMS (root mean-of-squares), which ule must be added as another component within
gives an estimate the ‘typical’ mean. RMS, also known each module. For example, Fig 4 becomes a 12 ×
as the quadratic mean, is a statistical measure of 12 matrix; 5 elements for module 1 and 7 elements
the magnitude of a variable (Bissell and Chapman, for module 2; the extra element being the seabed.
1992). This is calculated for the first and the second Then, there is no need for the column and row 14.
modules as shown in equation (1) and (2) in the The formulae in this appendix should also be
main text. modified to accommodate such addition.

92