Subsea system readiness level assessment

Transcription

1 doi: /ut 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 Technical Paper 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 technology 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 readiness 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 proposed 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 readiness 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 components into a seamless unit. This is an integration-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 readiness. 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 maturity before incorporating into a system. address: sirous.yasseri@gmail.com 1. Introduction Technology readiness levels (TRLs) were first used by NASA in the 1980s as part of an overall technology 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 methodology) 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 interaction 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 variety 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 readiness level; human readiness levels; habitation readiness level; and capability readiness levels. Many industries have embraced the concept of TRL as a metric for measuring technology maturity. 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 practice is now written into major petroleum companies procedures as a tool to assess the level of progress of subsea design, fabrication and components qualification. Such policies require contractors 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

2 Yasseri. Subsea system readiness level assessment Undoubtedly, TRL is a useful tool for determining a technology s maturity before inserting it into a system. However, TRL was not intended to assess the integration of technologies and hence the readiness of the complete system comprising them. It was originally 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 system comprising a collection of technologies, which are individually assessed against TRL, is optimistic. If the integration of two pieces of technology follows the same maturation path, just as the technologies 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 components 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 versus imperial) contributed to the loss of the spacecraft (Sauser et al., 2008b). Discovering that different components designed and fabricated by different vendors do not match or were designed for a different 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 component lies on the scale, and integration readiness between modules or the entire system with the environment is only implied or is not assessed. This paper presents the new concept of an integration 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 readiness scale, but also presents a direction for improving integration with other technologies. Obviously, at a given review stage components may not be at the same level of readiness. A methodology is proposed to combine TRL and IRL into one composite index, termed SRL est, which is an estimate of a third scale termed the system readiness level (SRL), a third scale. The resultant SRL est can provide an assessment of overall system development 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 demonstrates how a composite scale can be derived and used in conjunction with the SRL table to determine 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 interchangeably, and it also takes readiness and maturity to be the same entity and uses interchangeably. An effective method of understanding a complex 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 modules), which are easier to understand; and identify the interfaces (i.e. dependencies or relationships) between the components (or modules) that enable the system to function as a single entity (Sharman and Yassine, 2004). Subsea systems are generally modularised for ease of installation and parallel engineering. Modularising 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 78

3 Vol 31, No 2, 2013 suppliers and accommodating future expansion. Good architecture enables each individual module and its interfaces to be changed out without undermining 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 determines the subsea modules and their interfaces. This does not undermine the concept of modularisation, as the linear (sequential) nature of the subsea 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 modules. Interfaces between two components are shown by a double-headed arrow, implying that the readiness of two components to be integrated is interdependent. 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 representation of a system architecture, which captures the relationship between different components. This is also a suitable tool for system modelling and analyses, 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), direction of information flow and dependency. In this paper, a variation of DSM is tailored, for representing the subsea architecture and is used as a visual aid for decomposition and housekeeping when combining TRL and IRL into a single index. However, it has a wider application in grouping together components forming modules for enhancing manufacturing 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 representation 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 column 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. Information about dependency or interface is added by using a marker in the cells to represent relationships (x in Fig 2). An off-diagonal x signifies the A to F IRL=6 A to E E F ENV=5 A TRL=6 C IRL=4 IRL=6 B D TRL=6 D to E D to H IRL=6 G H IRL=4 IRL=4 IRL=4 I TRL=6 J ENV=5 C to J 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

4 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 connected. 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 dependencies. That is, if component A is shown to relate to component F, it is not clear why and how this relationship 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 integration. 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

5 Vol 31, No 2, 2013 Table 1: TRL for subsea technology readiness level assessment (API, 2009) Phase TRL Development stage Development stage definition System validation 7 Field proven Production system field proven 6 System installed Production system installed and tested Technology validation 5 System tested Production system interface tested 4 Environment tested Preproduction system environment tested 3 Prototype tested System function, performance and reliability tested Concept validation 2 Validated concept Experimental proof of concept using physical model tests 1 Demonstrated concept Proof of concept as desk study or R&D experimentation 0 Unproven concept Basic research and development (R&D) in papers Production unit integrated into intended operating system, installed and operating in the same environment and operating conditions for more than 10% of its design life with acceptable reliability, demonstrating low risk of early life failures. Complies with all requirements of TRL 5. Production unit or full-scale prototype built and integrated 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. Complies with all requirements of TRL 4. Designed and built as production unit or full-scale prototype and integrated into intended operating system with full interface and functional test, but not usually in intended field environment. Complies with all requirements of TRL 3. Designed and built as a production unit or full-scale 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. Prototype built and put through generic functional and performance tests. Reliability tests are performed in relevant laboratory 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. Concept design or novel features of design validated by physical model, system mock-up or dummy, and functionally tested in laboratory environment. No design history. No environmental tests. Materials testing and reliability testing performed on key parts or components in testing laboratory prior to prototype construction. No design history. Essentially desk study not involving physical models but may include R&D experimentation. Technology concept and/or application formulated. Concept and functionality proven by analysis or reference to features common with/to existing technology. Basic scientific/engineering principles observed and reported in papers. No analysis or testing completed available. No design history. 81

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

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

8 Yasseri. Subsea system readiness level assessment technologies. Table 3 defines a SRL scale that incorporates the maturity level of components and the interoperability of the entire subsea system. Sauser et al. (2008a) proposed a method to combine the TRLs and IRLs for a system under development, which involves matrix operation. In the appendix, a simpler methodology is outlined to aggregate TRL and IRL into a single metric, termed SRL est. 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 single composite metric, yielding a numerical value between 0 and 7. The estimated SRL est is used in Table 3 to judge what the system readiness is (compared with what it should be) at the time of assessment. 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 completion of the FAT, which is a strength test (hydrotested 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 module is ready for integration into the marine environment. 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, integration 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 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 interactions 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 (column 4), but do not need to be the same value. The matrix diagonal represents integration of a component with itself, which is left blank, assuming readiness 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, satisfies the concept and technology validation stages of integration. For the system validation, these assemblies must work together when inserted into the marine environment, and hence the interaction and compatibility of the entire system with its environment should be assured. The environmental readiness is somewhat qualified during the design phase by proper choice of material, corrosion protection, installation procedure, 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, environmental readiness remains subjective. This paper does not introduce another scale for the environmental 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 environmental readiness level. In most cases the environment 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 maturity 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 84

9 Vol 31, No 2, 2013 Table 3: SRL for subsea system readiness level assessment Phase SRL Development stage Development stage definition System validation 7 Field proven operational system 6 The system is installed tested and commissioning in progress Technology validation 5 Manufacturing and installation in progress 4 Detail design and final procurement 3 Front end engineering, sourcing long lead items Concept validation 2 Concept selection, where an optimal concept has emerged 1 Concept refinement Two or more competing concept being considered 0 Concept definition, where various ideas are being considered or discounted The subsea system is in production and it is in compliance with all its functionality requirements. The subsea system is operating successfully with sufficient reliability for more than 10% of its service life. Assure the operation support will meet all of its expected functions. The entire subsea system is installed and tested both at component level and at the system level, and it is ready for its intended operation condition. The subsea system is being commissioned with operation support. Any remaining problems being rectified. The Health and Safety Executive (HSE) policy is monitored. The system with all inserted assemblies will meet all requirements of SRL4 and below. Partly assembled/installed system is tested and compliance verified for the full design specifications. Operational support availability is identified and assured. HSE, pre-commissioning and handover policy are established. Operation support needs are established. The chosen concept is detailed. 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. The first choice and the competing option are moved forward to a level that the difference between them becomes obvious. Vendors, installation and commissioning contactors are selected 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. Two or more options which best satisfy all requirements are identified. Technology risk is reduced. Aspect of technologies to be used is clarified. The most promising option is selected. The project schedule is determined. Promising concept is refined to an adequate level of maturity. The concepts are priced and ranked according to their desirability. Technologies that are needed are researched to see if they can 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 influence of the marine environment on the system is studied and written into the basis of design. Reservoir data, geotechnical data, drilling requirements, distances and existing infrastructure information is collected. Concepts are developed. Economically or technically unfeasible concepts are screened out. The schedules are established and checked if they are realistic. Finance is considered. 85

10 Yasseri. Subsea system readiness level assessment Previous Module A TRL=6 A to E E B A to F IRL=6 F ENV=5 IRL=6 C D to E G IRL=4 ENV=5 IRL=4 IRL=4 D TRL=6 H D to H IRL=6 IRL=4 Next Module I TRL=6 C to J J 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 dependency), hence yielding a symmetric matrix. In general, 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. ( )/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 = 33. The square root of column 16 is given in column 17, giving a composite component 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

11 Vol 31, No 2, TRL A B C D E F G H I J ENV Ave. TRL*Ave SQRT IRL _IRL (Col16) 3 6 A B C D E F G H I J Fig 4: DSM for the example case The readiness for the first module is calculated as: M1 R = = 5.31 (1) The denominator of 4 is the number of components of the first module. Similarly for the second module, the readiness is calculated as: M 2 R = 6 = 4.95 (2) Therefore, the readiness of each module to be integrated into its environment is judged to be 5 for both modules of the case example using Table 3. Hence, the aggregate system readiness index (SRI) is: SRI = 2 2 (5.31) 5 + (4.95) 5 = (3) The denominator of 7 is the highest IRL in Table 2; this number is used to normalise the environmental integration readiness level, namely 5/7, which is the same for both modules in the example. From a metric point of view, SRL est and SRL are meant to measure the same things on the same scale. However, SRL is defined (Table 3), while SRL est 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 SRL est reduces to SRL. Entering Table 3 with 4.34, the system must be at assembly and installation stage; if the project schedule requires a different level then this must be justified. This index informs the management when and where to intervene if the system readiness is lagging 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 controlled project ensures that TRL, IRL and SRL closely follow each other. The derived system readiness index of 4.34 indicates that some components are not maturing within the desired time frame. In this hypothetical example, components with TRL or IRL lower than 4.34 need to be scrutinised. While this case example is simple, the underlying methodology is important. It demonstrates how to use DSM to combine TRL and IRL into a new metric, which indicates the readiness of the system. In addition to this housekeeping advantage, DSM provides a visual aid to present the system audit results to the senior managers. The advantage becomes more evident when dealing with more than 200 components manufactures in various locations that must mate and work together when assembled. 7. Discussion Measuring technology and system maturity is a multidimensional process that cannot be performed adequately by a one-dimensional metric such as TRL. Although TRL has been employed by many industries, it captures only a part of the information 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

12 Yasseri. Subsea system readiness level assessment This paper has also introduced the concept of environmental 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 performed. 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-tomarine-environment may be judged using the available physical evidences, e.g. tests and compliance with rules, specifications and codes. The root mean square (RMS) method was used for determining SRL est (see for example Bissell and Chapman, 1992). This estimated value incorporates 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, corrosion, 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; 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 markers act as visual aids for installation, by for example, identifying the corner locations for structures. The linear asset (e.g. pipelines, flowlines) follows a similar path, but is not necessarily in sync with the major equipment. Some post installation 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 components. 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 transparency 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 mechanisms 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, fabrication 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 88

13 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 management 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 measurement 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 concepts 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 making 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 effective and timely decisions during all phases of a subsea 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 maturation 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 SRL est. 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 mapping the subsea architecture, namely all components 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 installation; 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 assessment. Presented at: Technology maturity conference: multi-dimensional assessment of technology maturity. Virginia Beach, VA, September. Available at last accessed <10 October 2012>. Bissell C and Chapman D. (1992). Digital Signal Transmission. 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 Engineering Management 48: 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: 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 guidelines. 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: Det Norske Veritas (DNV). (2011). DNV-RP-A203 Recommended 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 managing concurrent engineering. Journal of Engineering Design 2: