www.sut.org

Interface management of subsea field development Sirous Yasseri* Safe-Sight Technology, UK

Technical Paper

doi:10.3723/ut.33.041  Underwater Technology, Vol. 33, No. 1, pp. 41–57, 2015

Received 23 February 2015; Accepted 20 May 2015

Abstract An interface refers to any logical or physical relationship required to integrate the boundaries between subsystems or between subsystems and their environment. The present paper combines a systems engineering (SE) approach and design structure matrix (DSM) for the interface management of the subsea production systems in the design, fabrication and installation phase. Strategies needed to manage interfaces between various subsystems and their execution and integration with the operational environment are discussed. It is suggested that a better way to keep a record of interfaces is by using a DSM, which is an N × N square matrix representing relationships between the system’s components. In this matrix, N is the number of components of the system. This matrix, which is constructed in a spreadsheet, provides a systematic approach to visualise, recognise, define, tabulate, store and analyse interfaces. The method is illustrated using a typical subsea production system. This approach also allows the identification of change propagation paths. Keywords: subsea production systems, interface management, interface control document, interface register, design structure matrix, change management, change propagation, interface control using spreadsheet

1. Introduction A subsea production system (SPS) is composed of many subsystems and sub-subsystems, each developed by a different specialist team but all of which must be integrated to fulfil an operational need. Subsea systems require many different components to function, e.g. power, umbilicals, chemical injection units, data acquisition systems, controls, computer hardware and software. All necessary items are * Contact author. Email address: [email protected]

grouped together into modules for ease of installation. SPS is referred to as the system, and the major units, e.g. the Manifold, are referred to as the subsystems. Subsystems can be further broken down into sub-subsystems, assemblies and elements. The term subsea production systems, or SPS, is used to mean everything that is needed for control and transport of hydrocarbons extracted using subsea (wet) trees. It includes everything from the trees to the computer control systems on the host platform or onshore terminal. It also includes subsea separators and booster pumps if required. However, downhole units, such as lifting systems, may be excluded from this definition. Owing to specialisation, or tight schedules, an SPS is divided between several design contractors dealing with their own part of the system concurrently. In this context one partner, in consultation with others, specifies interfaces in a written document to ensure traceability. Naturally equipment is procured from numerous sources; long lead items are often ordered before the design is adequately matured. Many contractors also contribute to fabrication, installation, integration testing and commissioning. Such division of responsibilities necessitates managing numerous interfaces. An example of complexity of the subsea equipment is the subsea control, monitoring and communication systems, which may arrive at the marine base as a single package but will consist of many separate components, e.g. high speed communication lines, control circuits, system sensors and controls, sand monitoring instrumentation, computer hardware and software, etc. In procuring such items, one contractor acts as the primary contractor and sources elements of the package from the other vendors. 41

Yasseri. Interface management of subsea field development

Change of one element may require rework of some part of the system. An important part of concurrent, and collaborative, design is managing the compatibility between subsystems. Formal documents are used to assure subsystem consistency as the design evolves. In concurrent engineering, a large number of conflicts can arise when integrating systems with incompatible interfaces. Conflict resolution is based on the ‘exception rule’, which requires that deviations from previously agreed levels are communicated through a formal document exchange system for approval. The assumption is that designers are aware of these open access documents, thus must be aware of all approved changes. It is not uncommon for a design to require major rework as a consequence of a mismatch in timing between the receiver and the provider of data (Van Eikema Hommes and Berry, 2003), or even a manufactured part to require modification. Different teams designing different subsystems often have different perceptions of what might be the best solution for interfaces. This makes it necessary to define clearly subsystem boundaries and the interfaces between them. Thus, management of interfaces is a key requirement for on-time delivery. The current practice of interface management operates on the assumption that there is only one solution to any problem and designers of all interfacing components are moving toward that unique solution; compatibility of interfaces are implied not agreed upon. Hence they feel what they need is more information. For this purpose a process known as the request for information (RFI) is used. This is a standard business process whose purpose is to collect written information. The RFI procedure is also used in the construction industry to confirm the interpretation of a detail, specification or note on the construction drawings or to secure a documented directive or clarification from the client. A perfect system should possess three properties: perfect components; correct ordering of them; and, most importantly, perfect relationship (link) between components. An optimal system is a compromise of these three properties. Engineers from multiple domains must compromise on their preferred solutions in order to optimise the overall system performance. The focus of the interface manger is to ensure optimal relationships (interfaces) between components and to let the designers achieve optimal solutions within the constraints imposed by the optimal interfaces.

2. Interface definition The issue of interfaces is at the heart of the multidisciplinary nature of subsea engineering. It is 42

required to define what is necessary to connect the individual components of a system to achieve a working system. Thus, there is a need to specify the relevant properties and behaviour of each part as well as the particular connections between them and the nature of those connections in terms of limitations, protocols and various operational conditions or scenarios. The system’s engineering practices generally rely on three documents to describe interface requirements and control. These three documents are described in the present paper and the implementation, control and tracking of interface issues are explained by mapping the subsea system into a design structure matrix (DSM). A DSM creates the ability to visualise dependencies and the flow of information. When one subsystem provides flow of material, information, energy or physical contact to another subsystem, then an interface exists between them. Blyler (2004) defines an interface as an input-output module linking two subsystems. The interface requirement is defined at the ‘boundary’ (contact points) between the two subsystems and appears identically in both subsystem specifications, but it can have different verification methods for different sides of the interface. The interface requirement is owned by one of the subsystems (typically by the one which originally recognised the need to control the interface) where the owner is understood as the ‘custodian’ of the interface; however, both sides are equal partners. An interface requirement is only valid when both sides of the interface agree on the wording and envelope of interface parameters, and the ways to manage changes. For example, connectors for a spool are attached to the manifold; thus both spool and manifold must be able to tolerate the same loadings. In this case the manifold designer is the custodian of the interface, i.e. the provider of data, and the spool designer is the receiver. The above requirement addresses one interface issue (there are more than one, e.g. pressure, seismic excitation, temperature, lack of fit, etc.) between a spool and a manifold. In order to progress with the design, an envelope for the interface loads is agreed upon at the start which will be revised in the later iteration as a better definition of the subsystems is obtained. Design is an iterative process, and the interface requirements are not set for the convenience of one party.

3. Systems engineering approach to interface management Interface management is part of configuration management (CM) which consists of defining and controlling the progress of configuration items

Underwater Technology  Vol. 33, No. 1, 2015

from a defined baseline through the life of the project, hence providing a record of the configuration at any point of time and its changes from the defined baseline (Yasseri, 2014). The interface manager in turn keeps the record of interfaces and their change from the agreed baselines. The objectives of the interface management are (Lali et al., 1997): • assignment of responsibility and authority for interface management in all the interfacing organisations or groups; • specification of the information to be exchanged between the interface groups with reference to interface control documents providing precise technical definitions and requirements of interface data flows and protocols; • identification of the interface requirements including the scope of works, design, development, installation, integration, testing and commissioning of the subsystems; • the technical strategy for developing, testing and deploying the interfaces including specification of the requirements, design and testing documentation required; • configuration management and quality management procedures relevant to interface development including identification of major reviews; • interface design risk and risk management strategies; and • a functional safety management strategy (if applicable) including references to an interface risk analysis. Three documents form the engineering description of an SPS at the highest level. These documents are the client requirements, the SPS architecture and the operational concept. The client requirements document translates the client’s needs into a set of definitive function and performance statements that must be met in order to achieve the project’s goals. The arrangement of subsystems is the SPS architecture which is recorded in a document and agreed with the client. The SPS architecture document defines key architectures and subsystem choices that guide the subsystems design of the SPS. The operational concept document describes how the SPS will be operated and may impose additional requirements by defining an envelope for the operation. The project relies on these top-level documents to guide the overall SPS design. The requirement statements contained within them flow down to the subsystems such as Christmas trees, spools and manifold structures, high integrity pressure protection systems (HIPPS), all valves and their associated control, and the related software systems. The subsystem requirements in turn flow

down to assemblies and components, imposing on them a set of requirements. Requirements engineering ensures that the SPS components are appropriately specified such that when they are assembled the system meets the top-level performance requirements. The requirements which flow down from the highest to lowest level are analysed to identify inconsistencies or missing requirements at the various levels of the system hierarchy. By recording the traceability or links between requirements from the highest to the lowest level, it can be determined whether various levels of requirements are consistent over the entire system. In addition to tracking hundreds of requirements it must also be defined how the subsystems interconnect and interact. Fig 1 shows key stages of an SPS development leading to the integration. Fig 2 shows the systems engineering process which consists of requirements analysis, functional analysis and design verification. As seen from Fig 2 the activities are iterative and are being managed by the systems configuration manager (Yasseri, 2014). The outcome of functional analysis is the functional specifications of each subsystem and the testing methods for the subsequent verification and validation of the system against the client requirements. The suitability of each subsystem for all modes of operation in its life cycle is established at this stage. Once the functional partitioning of a system has been established, the nature of interfaces becomes clear. The result of functional analysis and system decomposition is a description of the SPS in terms of its primitive functions. This description is known as the functional architecture. By grouping highly correlated functions together, a functional area is obtained that can be implemented by a physical subsystem (e.g. manifold). This process is called synthesis and results in the description of the SPS in terms of its subsystems which is its physical architecture. The physical architecture of a system should be established before interface control documents are created. From the physical point of view, the spatial relationships also play a key role in categorising interface. These functional and physical characteristics can be used to define different subsystems that require specialised design teams (Pimmler and Eppinger, 1994). The SPS architecture is established in parallel with the functional analysis. System architecture is an abstraction of the vision of a collection of equipment arranged in a specified way to fulfil the client’s needs (Crawley et al., 2004). Subsystems required to implement each function can be visualised in a two-dimensional form (as shown in Fig 3), which will be used to determine interactions and dependencies between subsystems. This schematic of 43

Yasseri. Interface management of subsea field development

Overall system engineering plan Client’s needs

Acceptance Overall system acceptance plan

Acceptance testing, system performance demos & commissioning

System architecting

Subsystems architecting

Overall subsystem T & V

Functional analysis

Interface & integration management plan

System architecture

Validation

Integration Subsystems acceptance

Subsystem T&V

Subsystems definitions

Subsystems integration and validation

Subsystems definition

Design, fabrication and installation

Integration tests and verification

System T&V

T & V = Testing and verification

Fig 1: Key stages of an SPS project leading to the integration

the system (Fig 3) shows the relationships between subsystems (i.e. interfaces and dependencies) and describes how various subsystems should be designed and connected together. The system architecture is used for specifying interface requirements between subsystems. The connectivity between the selected equipment determines their dependencies and, hence, the interfaces between them.

Input (client’s needs)

Requirement analysis and verification Requirement loop

Functional analysis and allocations

Trade off studies

Design loop

Design and synthesis Verification and validation loop

Control

Output (configuration documents)

Fig 2: A simplified diagram of systems engineering process

44

4. Interface requirements According to Pimmler and Eppinger (1994) interface requirements is a coherent set of specifications between two groups which define a connection, an exchange of energy (pneumatic, electric, hydraulic or mechanic), an exchange of information, or an exchange of material. If the two groups are subsystems, one of these subsystems could be external or the two subsystems could both be internal. By defining the performance requirements of the system and subsystems thoroughly through a set of engineering requirements, the design goals become clear (NASA, 2007). By deciding what tests must be performed to verify that the system meets its functionality requirements, it is ensured that what is installed is actually what the client has asked for. The subsea functionality requirements are achieved by the physical hierarchy of a collection of subsystems. At the highest level the system attributes captures the client’s requirements that relate directly to functionality, field compatibility, regulatory compliance and the client’s corporate objectives (Yasseri, 2014). Examples of subsea system attributes include throughput, performance, safety and dependability. Below the system level there exist subsystems (such as wellhead, manifold and flowlines) and subsubsystems (such as valves, connectors and sensors). In turn, the requirements are cascaded down to subsystems and sub-subsystems. Thus, every requirement in the SPS requirements plan is owned by

Underwater Technology  Vol. 33, No. 1, 2015

HOST PLATFORM Wellhead

Umbilical

Pipeline termination assembly (PTA)

Spool

Umbilical termination unit

Spools

SDU I 4" Gas injection

Flying lead

10" Pipeline

MANIFOLD

SSIV

10" Pipeline

Umbilical termination unit

SDU II

Umbilical termination unit

Umbilical

Fig 3: A simple subsea field architecture in block diagram representation

either an SPS attribute or by a physical subsystem/ sub-subsystem. The quality of each requirement is measured by necessity/priority, verifiability, attainability and, most importantly, traceability. Requirement traceability (US Department of Energy, 2003) is an overarching principle in requirements management which encompasses their definition and implementation. It is used to ensure that each step of the development process is correct, conforms to the needs of the prior and next steps, and conforms to the defined requirements. In this context, requirements tracing is the ability to describe and follow the life of a requirement in both forward and backward directions and through each step of the development. Traceability of requirements ensures that all the client’s needs are addressed and every part can be traced back to a client requirement in two ways: • a requirement is cascaded from the client’s needs. For instance, an attribute requirement is cascaded from the client’s corporation (e.g. safety) or a subsystem requirement is cascaded from the SPS attribute (e.g. a safety attribute may impose a level of protection against dropped objects, or from a specific ‘peer-to-peer’ physical/functional interface, e.g. a 16” flowline requires a 16” termination assembly at the riser base, or something similar); and • interfaces are identified during translation of the client’s need into a configured system which is a

grouping of functional subsystems. Each functional grouping is assigned certain performance requirements. These performance requirements are translated into design requirements. The design requirements are the basis for developing the system specifications. The boundaries between the functional areas as defined in the system specifications become the interfaces. The interfaces could be affected by, and need to be compatible with, components that contribute to its function but may not be physically attached to. For example, some connections must withstand the pressure surge owing to a choke action. Subsea systems consist of a large number of tightly connected subsystems with a large number of dependencies at high impact. Change in one subsystem may propagate throughout the entire system. Keeping track of the impacts of change in one subsystem on another subsystem is the aim of the present paper for managing dependencies. Fig 4 provides an overview of the interface management process. Ensuring that all interfacing subsystems indicated in the requirement agree with the content of the requirement is known as the interface requirements reconciliation. Reconciliation can be difficult since the custodian of the requirement must convince other subsystems about the necessity and attainability of the requirement. However, any un-reconciled interface requirements are 45

Yasseri. Interface management of subsea field development

Speciation(s) for system/component requirements containing higher level interface requirements

System/subsystem/components functional/logical/physical architectural decomposition

Interface identification

Interface requirements specification

Interface definition

Interface approval and control

Interface verification and validation

Fig 4: Interface management process – overview of the main process steps (adopted from ECSS-E-ST-10-24C DIR1; European Space Agency Requirements and Standard Division, 2013)

regarded as ‘unfinished’ and, therefore, an outstanding issue. When a system has complex development and modification processes, agreements between different engineering groups on interfaces cannot be easily achieved. Therefore, some documents are developed that establish the requirements to which the interfaces should be designed and developed. The following documents control the design of the interfaces: 1. Interface definition document (IDD) – A unilateral document controlled by the end item provider which provides the details of the interface for a design solution that is already established. The user must then design the interface of the system to be compatible with the already existing design interface. 2. Interface requirements document (IRD) – The IRD defines the functional, performance, mechanical, hydraulic, electrical, environmental, human, and physical requirements and constraints that exist at a common boundary between two or more functions, system elements, configuration items 46

or systems. Interface requirements include both logical and physical interfaces. Interfaces must ensure the balance of forces, conservation of energy, materials and data (information). 3. Interface control document (ICD) – The ICD identifies the design solution to the interface requirement, and details the physical interface between the elements of two systems including the number and types of connectors, the hydraulic parameters, the mechanical properties and the environmental constraints. The IRD and ICD are related and each has its own specific purpose. IRDs identify the interface requirements between two subsystems, between a subsystem and a ‘user’ or the environment. The requirements in an IRD are often traced to or derived from requirements in a system-level specification or system requirements document. ICDs describe the formal agreement that documents how the interface requirements outlined in the IRD are implemented. ICDs provide design solutions to physical interfaces and act as a concept of operation for the IRD. The design characteristics in an ICD trace to and are derived from the interface requirements in an IRD. When IRDs and ICDs are approved, they become baseline documents and are placed under configuration management change control. A complete system will have many IDDs, IRDs and ICDs. The focus of the present paper is on the ICD and its use in the interface management.

5. Interface control document ICDs contain the functional, physical, performance and design requirements for inter-system interfaces. ICDs are not intended to show the detailed data that would normally appear on design drawings. Instead, they show parameters, characteristics or configurations that are necessary to ensure that the designed subsystem will operate together as intended. Each time a change to the interface definitions occurs a compatibility analysis must be performed to demonstrate the completeness and correctness of interface information. Demonstrating correctness means providing a record that shows interfaces have been examined for having the right form, fit and function for the interacting subsystems. An ICD specifies what is required to connect subsystems in an overall product. Documenting agreements and committing to them is a crucial means of preventing design conflicts correctly. Use of ICDs is particularly helpful when a product is composed of subsystems that are described by

Underwater Technology  Vol. 33, No. 1, 2015

different parts, e.g. mechanical, electrical, hydraulic. In such a situation it is very difficult to have a product representation that includes all such miscellaneous subsystems and defines the interfaces between them. In these cases ICDs can be supplied as separate documents for each part that describes the interfaces among subsystems. Both form and functions of the interface have equal emphasis in subsea systems. The more encapsulated (several items in one bundle) the components are, the more pronounced their interfaces are. ICDs can be pure drawings, textural or combinations of both. Some of the typical information that can be found in an ICD includes the document purpose, the description of the interface, relevant block diagrams, interface functions, performance, configuration and other essential features. There is no consensus on what exactly should be included in ICDs; however, they must include information about the size, format and the type of data needed for the design team to progress. During fabrication it is necessary to check if all requirements are being met, first at the component and subsystem level and then at the integrated system level. This verification exercise consists of a set of tests on the subsystems at various points on the project timeline. The main objectives of ICDs can be summarised as follows (Lalli et al., 1997): • control the design of subsystem interfaces by preventing any changes to a subsystem’s boundary that would affect compatibly of its interfaces with other subsystems; • communicate design decisions that affect a subsystem’s boundary to all collaborating parties; • identify missing interface data (voids) and control the submission of these data; and • identify the subsystems that are associated with an interface. ICD focus is only on subsystem boundaries and highlights how the compatibility of interfaces can be demonstrated during subsystem design, and should not assume any information about the internal structure of the subsystems.

6. Existing tools for the interface management The most popular method of project control is the work breakdown structure (WBS) which is a hierarchical list of tasks that defines the scope of a project, relating effort, timeline and budget. An important objective in using WBS is the project scheduling. Gantt charts, which are used as general management tools, provide graphical process representation based on work breakdown structure (WBS);

however, they can only follow feedforward correctly and cannot cope very well with feedback and design iteration. Functional block diagrams (Fig 5) are used for abstraction of systems for various type of analyses (e.g. reliability and process flow), which also can be used for representing interface information (Yasseri, 2013). In this representation some information about the content of interfaces can be shown on links between blocks. The arrows, with descriptive tags on them, indicate the information which flows between the system’s boundaries. The direction of the arrows is identical to the direction of flow between the subsystems. Another tool for interface control is known as N2 diagram (NASA, 2007). It is created by first giving each major subsystem a box on a diagonal line in the diagram (Fig 6). These boxes are connected by a network of vertical and horizontal lines. At each position where a vertical line crosses a horizontal line one should consider if there is a need to define an interface between these two subsystems. This would be the case, for example, if the two subsystems must ultimately be bolted together or if highlevel control software will need to communicate with the control software of a subassembly. A node is drawn at that intersection whenever this is the case (Fig 6). The present paper uses the design structure matrix (DSM; Yassine and Braha, 2003; Yasseri, 2013) for the mapping of an SPS to show the connectivity pattern of the subsystems. A spreadsheet is used to plot DSM and store project data for the interface management.

7. Domain mapping DSM is a visual tool that represents the relationships and dependencies between components of a system (Eppinger, 1997). Browning (2001) describes four applications of DSM for addressing different types of problems (Table 1). The component-based DSM, which is used in the present paper, comprises of a list of components in some desirable order whereby upstream components are listed in the upper row. The component interactions are represented by ‘X’ marks in the off-diagonal cells. The marked cells indicate the information exchange between components. One can examine the marked cells in the matrix from two viewpoints. For instance, reading down a column indicates that a component provides information to others in its associated row. On the other hand, a component in the row receives information from the component in the corresponding column when reading across a row in the matrix. 47

Yasseri. Interface management of subsea field development

A – Control panels

E – CCU (Central control unit)

I – MUX cables

Control and monitoring BOP system

Supply electric power to control system

Provide power and communication to subsea control pods

B – Fluid reservoir w/HPU

F – BOP

J – Control pods

Provide fluid to control BOP function

Isolate well

Convert electric signal to hydraulic signal; providing information to control panels

C – Rigid and flexible fluid hoses

G – Control valve

K – Solenoid valve

Transport fluid from supply system to subsea components

Actuate BOP valve

Control BOP valve

D – Surface/subsea actuators

H – Shuttle valve

Supply high pressure fluid pre-charge to BOP functions

Direct fluid from active pod

Fig 5: Functional block diagram of the BOP system

Organising the DSM rows and columns in a new DSM, such that all the information (i.e. dependency marks) in the new DSM flows forward and there is no feedback, i.e. transforming the DSM into a lower triangular form, is known as partitioning (Eppinger and Browning, 2012). For subsea it is unlikely that simple row and column manipulation will result in a lower triangular form. Reordering the DSM of a subsea system will not completely

A B C D E F G H I J K

Fig 6: An N2 diagram for the functional block diagram of the BOP shown in Fig 5

48

eliminate feedbacks but can minimise them and move the rest as close as possible to the diagonal. In doing so fewer system elements will be involved in the iteration cycle resulting in more internal than external interfaces. Ordering of rows and columns represents a flow through time, i.e. upstream activities in a process precede downstream activities, and terms like ‘feedforward’ and ‘feedback’ become meaningful when referring to interfaces. Fig 7 shows the DSM representation of the blowout preventer (BOP) functional block diagram shown in Fig 5. The functional block diagram gives a view of the system’s functions and how they must interface in order to achieve the overall function, i.e. isolate wells. Two representations of BOP are shown in Fig 7: the left-hand matrix (Fig 7a) shows the flow of information while the connectivity is shown on the right-hand side DSM (Fig 7b). The components of BOP are shown as rows and columns in the matrix where the components are listed in the same order along both axes. An off-diagonal mark located within the matrix denotes a coupling between two components. Fig 7a and Fig 6 are similar as both indicate the direction of information flow. Fig 7a shows that components B, C, E and H do not require input from the other components within BOP but C and H receive input from the outside. If these are off the shelf components then

Underwater Technology  Vol. 33, No. 1, 2015

Table 1: Four applications of DSM analysis (adopted from Browning, 2001)

DSM Type

Description

Analysis method

Component-based or architecture DSM Team-based or organisation DSM Activity-based, task-based or schedule Parameter-based or low level schedule

Used for modelling system architecture based on component

Clustering

Interrelationships Used for modelling organisation structure based on information flow, project scheduling, activity sequencing, cycle time reduction Used for modelling low level relationships between design decisions and parameters, systems of equations, subroutine parameter exchange, etc.

Clustering Partitioning, tearing, banding Partitioning, tearing, banding

the receiving components must conform and provide an interface suitable for them since they cannot be changed. This is an example of a one-sided interface. However, Fig 7b shows a two-sided coupling whose interfaces must be designed to suit both interfacing components. The present paper, for simplicity, assumes at the highest level of hierarchy that all dependencies are two-sided; thus, in a raw form, the interface matrix is symmetrical. A number can be used instead of ‘X’ to represent some interface quantity, for example risk or/and the volatility of the interface (see section 9). If the strength of backward and forward dependencies of interfacing components are the same, then DSM is symmetrical, as shown in Fig 8. Fig 7 shows a symmetrical matrix but asymmetrical matrices can be used to show different criticality for forward and backward dependencies. In the present paper, the diagonal of the square matrix is used to create a link to another worksheet which contains information about the interfacing component. Presenting every component of a subsea system in a single matrix obscures its visual usefulness. A subsea system can be organised into a hierarchical structure, e.g. subsystem, sub-subsystems and assemblies. Such hierarchical representation avoids problems related to presenting extremely large a)

matrices by shifting the focus to the various levels in the hierarchy at a time which enables the analysis of a system at different levels of detail. The multitiered approach was developed by Grose (1997) at the Boeing Company. The modelling begins (Tripathy et al., 2007) from the highest level subsystems and deliverables in a project called level 1 or the system level. Next, each high-level subsystem is further decomposed into a set of sub-subsystems forming a series of level 2 DSMs. Similarly one can construct a level 3 DSM which decomposes a sub-subsystem into its assemblies or components. Assuming activities related to subsystems and sub-subsystems another are within one organisation then levels 2 and 3 DSMs address both internal and external interfaces, as the supply chain may be two or three layers deep. In general, the DSM analysis only looks at relationships across components (at the same level) and not within components (the next level below). In the example presented in Fig 9 the last task in each matrix is decomposed to provide additional detail through the construction of lower level DSMs. In this structure there are three possible forms of information exchange: • internal interaction, referred to information being exchanged within a single matrix; b)

Fig 7: Two DSM representations of the block diagram from Fig 5: a) the direction of information flow between blocks; as shown in Fig 5, and b) the connectivity between blocks; the interface matrix

49

Yasseri. Interface management of subsea field development

Components Host (connections) 4” spool 10” spools (2 no) Incoming connectors Piping SSIV SSIV structure SSIV foundation Outgoing connectors 4” gas lift 10” pipelines (2 no) 4” FTA 10” FTA (2 no) 4” spool 10” spools (2 no) FTA foundation Multibore connectors Piping Manifold foundation Valves (& HIPPS) Manifold structure Multibore connectors Jumpers Flying leads Wellhead X-trees (3No) Connector Umblicals Termination assembly SDU I& II SDU support & foundations Termination assembly Distributed systems Leak detection systems Materials Integration testing Sensors/data acquisition Controls Installation phase Marin installation contractor System installation contractor Tree functionality testers Third party witnesses

Task 9

Task 8

Task 7

Task 6

Task 5

Task 4

Task 3

Task 2

Task 1

Fig 8: Mapping of subsea architecture in Fig 3 using DSM

Task 1 Task 2 Task 3

Level 1

Task 4 Task 5 Task 6 Task 7 Task 8

Task 11

Task 10

Task 9

Task 8

Task 7

Task 6

Task 5

Task 4

Task 3

Task 2

Task 1

Task 9

Task 1 Task 2 Task 3 Task 4 Task 5 Task 6

Level 2

Task 7 Task 8 Task 9 Task 10 Task 11

To Level 3 Fig 9: A simple multi-level DSM

50

Underwater Technology  Vol. 33, No. 1, 2015

• external interaction, consisting of information being exchanged between two or more matrices; and • boundary interaction, the information exchange which occurs at the boundaries of the model interacting with entities outside the project such as vendors and installation contractors. Various strategies (Pimmler and Eppinger, 1994) have been proposed to improve the design process. The first one involves artificial decoupling (tearing) by removing one or more dependencies from the matrix. This approach requires defining design boundaries for the dependent components (maximum forces and moments, pressure, etc.). An alternative strategy is clustering, where all interdependent components are kept closer to each other; this approach is known as partitioning (Eppinger and Browning, 2012). Subsea systems are historically partitioned into self-contained subsystems based on specialisation of design contractors and manufacturers. However, artificial decoupling is used by assuming suitable interface forces and moments at the interfaces (e.g. between spools and the manifold) to start the first design iteration. Adding connections as individual elements could improve the process. One can add more dependencies by adding artificial boundaries; for example, breaking the pipeline into two or more sections so that different contractors can work concurrently. Another example is using a control pod of one vendor on the X-tree of another; hence, adding an external interface requirement. Such increased coupling will slow down the design but has a higher chance of speeding up the delivery. Interdependency may occur directly as indicated by entries that are symmetrical about the diagonal (Fig 7b). Indirect dependency also could occur through a chain of dependent actions that are in a feedback loop. Design of interdependent systems involves iterations until information at the two sides of the interface converge. There are two types of iteration in a design process, namely sequential and parallel iterations. Sequential iteration involves a set of coupled tasks whereby a task is executed one after another. Tasks are repeated whenever discrepancies are discovered or if the client requests a change. In fact, many tasks are performed simultaneously in parallel iterations which are repeated until convergence is reached. By examining the DSM one can identify where iteration requirements lie. Fig 8 shows a two-dimensional map of the subsea system shown in Fig 3. In this representation simplifications are made for the sake of clarity and page size, i.e. not all subsystems are shown and some are bundled together. Subsystems which are shown are

labelled in Fig 8. Diagonals are used to link to another worksheet which contains further information about interfaces; dependencies are shown down a column. Reading across row 1 tells us that module B provides input to module A. Column 1 in Fig 8 shows that module A depends on module C; the criticality of dependency is shown by a scale factor as discussed in section 9. This matrix shows that modules A and B are coupled whilst the design of modules B and C is parallel. The example shown here has a symmetric structure where each coupling shows interdependency (bi-directional) rather than hierarchical dependency (unidirectional), which is typical in architectures of physical systems. Installation process is a typical example where hierarchical dependency occurs, namely one task must be completed before another task can begin. For this reason, process DSM representations are typically asymmetric.

8. Interface register All identified interfaces as well as the history of their evolution are recorded in a document known as the interface register (IR). The objective of the IR is to record, manage and report to the management the completion status of all identified interfaces on a project-wide basis. Each interface agreement has its own unique number with clearly identified provider and receiver of data. The resulting database can be used to generate ICDs. The interface register includes information about the interfacing components as well as the value and quality of the transferred fluid, forces, etc. Other data can be included to record information such as technology readiness level (TRL), integration readiness level (IRL) and system readiness level (SRL; see Yasseri, 2013). The interfaces between various subsystems are stored in a worksheet and hyperlinked to the system’s DSM using the diagonals. This can also be useful in linking and generating connectivity between the interface and other project data. The worksheet can contain all sorts of information and it also can contain all children of a subsystem linking them to the equipment list using tag numbers, and piping and instrumentation diagrams (P&IDs), their meaning and where they appear. Fig 10 shows how an interface information can be documented as a simple spreadsheet and linked to components in the DSM matrix. By interrogating these, project managers can determine the completion status of all registered interfaces. This register is continually updated while keeping the history; in Microsoft Excel the history can be hidden to avoid clutter. For each higher level interface there may well be several lower-level 51

Yasseri. Interface management of subsea field development

Type

TRL

IRL

TR

Interface description

Location

Interface type (Mechanical, electrical, functional, etc.)

Status (close/open)

Compliance traceability to ICD

Type

TRL

IRL

TR

Interface description

Requirements

Location

Interface type (Mechanical, electrical, functional, etc.)

Status (close/open)

Compliance traceability to ICD

ICD reference

Date raised

Target completion date

Tests (verification & validation)

Remarks

Type

TRL

IRL

TR

Interface description

Requirements

Location

Interface type (Mechanical, electrical, functional, etc.)

Status (close/open)

Compliance traceability to ICD

ICD reference

Date raised

Target completion date

Tests (verification & validation)

Remarks

Remarks

Contact details Contact details Contact details

Tests (verification & validation)

ID ID ID

Date raised

Responder Responder Responder

ICD reference

Requester Requester Requester

Requirements

Date Date Date

Target completion date

A

B

C

D

Fig 10: Interface data and history stored in a separate worksheet; the Interface Register

interfaces which will also require recording and managing. These should be listed in a different worksheet and linked to their respective high-level interface while considering their associated subsystems.

9. Interface criticality 9.1. Interface volatility Using simple binary representations in DSM only displays the existence of a dependency between two components without providing additional information on the nature of the interaction. Yassine et al. (2001) proposed a process to assess subjectively the likelihood of re-work. A variation of their approach is used here to assess the criticality of interfaces. In this approach interdependencies are assigned by calculating the interface volatility (IV) first, which is assumed to be a function of information sensitivity (IS) of the interface, and information changeability (IC) of the input. IV is taken as the product of IC and IS. IV describes the volatility of the dependent components (located in the column) with 52

respect to changes in input data which are received from the input providers (located in the rows). IC determines the possibility that information provided by an input subsystem would change after the initial release. Each subsystem has its own IC score, which quantifies the likelihood that the data provided by it would change. In the present paper, for the sake of simplicity, one IC value is assigned to the interfaces on both sides of the subsystem; however, assigning different values is straightforward. ICs are shown along the left-hand side of Fig 8, corresponding to the subsystem in that row. Information sensitivity (IS) accounts for the sensitivity of the dependent subsystem (located in the column) to changes in the design of the subsystem feeding into it (located in rows). ISs are shown at the top of Fig 8 corresponding to the subsystem in that column. The estimated changeability of information originating from a subsystem is categorised in three levels as shown in Table 2. IS depends on the strength of dependency between two particular subsystems; Table 3 describes the three levels of sensitivity.

Table 2: Information changeability (IC) – The likelihood of information provided by a subsystem (in a row) to change Information changeability (IC) Score

Description

1

Design has almost converged, hence no change is expected Some excursion beyond the agreed envelope is likely Unknown

2 3

Table 3: Interface sensitivity (IS) – The sensitivity of the interface to changes in information. Description

1

Insensitive to most of the data changes Interfaces require adjustment of data changes Complete re-work is needed of data changes

2 3

(1)

The olatilities calculated using Equation 1 are noted in Table 4 and compared with the importance score used in quality function deployed (QFD; see Hauser and Clausing, 1988). The intention of the scoring method is to accentuate the relative difference, not to measure IV in absolute terms. Low value of one parameter (IS or IC) moderates the effect of the high value of the other. The IV is also shown in a 3 × 3 risk matrix format in Fig 11 for comparison purposes.

9.2. Technical risk indicator Because an SPS relies, to a certain extent, on advanced technologies in many domains, the identification and management of these technology risks is crucial to the outcome of the project. Thus, IV is multiplied by the technical risk (TR) indicator of the two interfacing components and entered at the intersection of the row of the dependent component and column of the input component. Table 4: Interface volatility (IV) compared with QFD’s importance score Interface volatility (IV)

Description

House of quality scale

1&2

Low risk of re-work Moderate risk of re-work High risk of re-work

1

3&4 6&9

3 9

3

6

9

2

2

4

6

1

1

2

3

1

2

3

Fig 11: Interface volatility (IV) in a risk matrix format

IS describes the physical nature of the interface while IC is related to the variability of input, thus they are not related and they measure two aspects of a design. The IV is defined as: IV = IS × IC

3

Likelihood of input changing (information changeability)

Interface sensitivity (IS) Score

Sensitivity to input change

Underwater Technology  Vol. 33, No. 1, 2015

TR indicates the sources of uncertainties which should reduce as more definition is added to the design. The purpose of TR is to identify potential technical risks by looking at what is different from before. It is an assessment of influence of a number of risk factors that can contribute to the likelihood of failure. Following the American Petroleum Institute Recommended Practice 17N (API-RP-17N; API, 2009) five criteria have been defined (reliability, technology, architecture, environment and organisation) that are assessed against an ordinal scale of one to five based on the perceived risk and deviation from previous experience. The risk levels for each risk factor are defined in Table 5. Annex A of API 17N (API, 2009) gives guidance as to how the decision should be made. The proposed metrics are inspired by the API Technical Readiness Levels (TRLs) but deviate slightly by defining five numeric risk levels for the calculation purposes. Table 6 lists five attributes (subcriteria) for each top-level criteria in Table 5. There are many ways to rank subcriteria, namely by single experts or aggregate opinion of several experts (Yasseri, 2015). A simple way would be to score each attribute using a binary system of zero and one; a demanding attribute is scored one, otherwise is zero. Summing all scores, then dividing it by 5, and rounding it up to the nearest whole number, gives an estimate of TR. An average overall score of less than one is rounded up to one. Table 5 also gives an indication of where TR lies for all TRLs. The TR scale is assigned a value of one for the lowest-risk components (TRL = 7) and a value of five for the highest-risk or unproven components (TRL = 1). Mapping of TR onto TRL is on the subsystem level using the definition of TRLs as given by the API and the implied risk level for each TRL. Individual components may have been in use in a similar field; hence, TRL at the component level 53

Yasseri. Interface management of subsea field development

Table 5: Technical risk indicators TR

Reliability demand

Complexity

System architecture

Operating environment

Contractor organisation

Expected APIs TRL

1

Same as before

In common use

Simple and similar configurations are in use

An extension of the current facility

Same team as before

2

Minor improvement

Company used Minor it in other modifications projects

Similar to recent projects

Minor changes to the team

3

Reliability requires modified design

4

Reliability requires new equipment

Another company is using it Somewhere in the world being used

Another company has asset close by New to the company

Moderate change to the team Significant change to the team

5

Reliability requires significant technology change

TRL7 Actual system is proven through successful operations TRL6 Actual system completed and qualified through test and demonstration TRL4-5 Validate system, components tested TRL2-3 Validated concept; System function, performance and reliability tested TRL1 Proof of concept as desk study or R&D experimentation

Not used anywhere in the world

Some level of novelty

Significant departure from familiar architecture Complex and not Totally unknown tried before

New team in place

TR = technical risk; API TRL = American Petroleum Institute Technical Readiness Level

is high, implying low risk. However, if these components have not yet been integrated and shown to fulfil the required functions in the required environment at the next hierarchical level, the risk at this higher level could be high. Thus, as subsystems and assemblies take shape the technology readiness may differ from one hierarchical level to the higher level. This means an assembly composed of components with high TRL could have a lower TRL than its components. This may cause some difficulty in deciding on TR. An alternative way to define TR is using the standard risk matrix concept as shown in Table 7. Subsystem data are reviewed and each component is assigned a TR based on the criteria given in Table 5; compare TRLs at the bottom of Fig 8 with their associated TR as noted in Table 5. IRLs and TRLs are related (Yasseri, 2013); once the TR values are entered into the spreadsheet for each component in DSM (Fig 8), the spreadsheet automatically calculates an overall interface criticality for each interface. The interface criticalities are calculated based on the following formula (Eppinger and Browning, 2012):

 riticality of interface between A & B = C (TR of A) × (TR of B) × (IC) × (IS)(2) The interface criticality is intended to provide an overall view of the interface technical and design risks as well as to identify the patterns of system level risks and their evolution. Cells with high value (in Fig 8) indicate a higher risk for the interface reconciliation. These numbers are not absolute values but are designed to differentiate problem areas.

10. Management of change Change can occur at any stage after approval of the design baseline. Subsea systems are highly dependent on each other so any change may propagate through the system. Change is a deviation from the approved baseline. Since most changes affect interfaces, the system interface manager should be a member of the change control committee, but not necessarily the approval authority. Baselining refers to the act of placing an approved item under formal change control. A working product, design or

Table 6: Subcriteria of the five top-level criteria listed in Table 5

54

Reliability demand

Complexity

System architecture

Operating environment

Contractor organisation

1. Failure modes 2. QA/QC needs 3. Maintainability 4. Design life 5. Operation team

1. Dimensional control 2. T  emperature and pressure 3. Materials 4. C  orrosion and erosion control 5. Complexity mix

1. Layout 2. Instability 3. Tooling requirements 4. Interfaces 5. Intervention needs

1. Field location 2. Seabed 3. Reservoir complexity 4. Metocean 5. Transportation and storage

1. Location difficulties 2. Supply chain 3. Manufacturing controls 4. Installation 5. Sub-contractors

Underwater Technology  Vol. 33, No. 1, 2015

Table 7: An alternative description of technical risk (TR) indicator TR 1 2 3 4 5

Occurrence Linguistic description

Likelihood

Not likely Low likelihood Likely Highly likely Near certainty

≈ 10% ≈ 30% ≈ 50% ≈ 70% ≈ 90%

document, is referred to as a ‘baseline’ when it has been formally reviewed and agreed upon and can only be changed through formal change control procedures and with the approval of the designated approval authority. In project management the baseline can also include the original scope, total cost and schedule. For the interface designers the baseline is the agreed upon parameters. The objective of a baseline is to reduce a project’s vulnerability to uncontrolled change by fixing and formally change-controlling various key deliverables (configuration items) at critical points in the development life cycle. Baselines are also used to identify the aggregate of hardware components that make up a specific release of a system. System baselines capture the entire current system description and are updated at the project review stages (Yasseri, 2014). Before the execution of the project the baseline must be properly defined, agreed upon and documented. A baselined working product may form the basis for further work activity(s). For example, hardware requirement specification (e.g. a data sheet) creates a baseline for the development of a design. Once baselined, the specification cannot change randomly thus providing a stable reference for the design effort. It is important to have managed baselines, requirements and configurations so that the entire team is working with the same assumptions of what the current system is and what it must do. Systems engineering management is responsible for creating and updating the system baseline, managing changes and dissemination of all accepted changes. The severity of a change is dependent upon how much work has already been completed. Some changes remain local; for example, changes to the pipeline material grade from X60 to X65. Most changes of a point on the system propagate both ways. Owing to high dependency, re-work requires iteration involving feed forward and feedback. The DSM can be used to determine the propagation of changes through the system and their paths. Engineering change requests (ECRs), coupled with the impact assessment and review, are the means for

making changes. The change control authority reviews and assesses the impacts of ECRs; alternatively, change control committees are established to assume this responsibility. A project need not to have this exact structure but there must be a process for approval, based on assessment of the change propagation and its impact on the schedule and costs. When a change request is submitted it is necessary to identify both the re-work requirement of the original task and the current state of the system. Fig 12 shows a flow chart for the management of change; it is suggested to run all potential changes through this process, including problems, suggested enhancements and identified/client changes. The approval authority decides if and when the change will be implemented. A timeline for various phases of the interface development, and how they fit into various stages of the development, is shown in Fig 13. This figure also shows the deliverable to be produced for each stage.

11. Conclusion A spreadsheet-based approach is outlined for managing the interface between subsea subsystems in concurrent and collaborative engineering. The subsea system is mapped into a two-dimensional DSM matrix in a spreadsheet. The off-diagonal cells are used to record the criticality of interfaces as a function of the sensitivity to changes and the likelihood of changes in the input data, as well as the technical risk. The diagonal of the matrix is used to link every subsystem to another worksheet where details and history of the interfaces are recorded (the interface register). This can also be used in linking and generating connectivity between the interface model and other project data. All information needed to effectively manage interfaces can be kept in single spreadsheets, or linked spreadsheets for larger projects. This spreadsheet-based interface management contains all information needed to assure the system integration and compatibility of interfaces. It supports the configuration management effort by ensuring that configuration decisions are made with full understanding of their impact outside the area of the change. It also contributes to the interface requirements reconciliation, namely all interfacing subsystems comply with the content of the requirement. The spreadsheet document can store graphical data for interfaces as well as the properties of the components. The interface matrix is updated whenever a new piece of information becomes available in order to reflect changes in the project status. 55

Yasseri. Interface management of subsea field development

Service engineering management

Change control management

Sources of change Filter and prioritise Client’s request

Enhancements

Problems and identified changes Evaluate engineering change request

Assess the impact Engineering discipline

Yes

No Approved?

Incorporate change

Engineering change request

Archive ECR

Systems engineering

Verify change

Feedback to the originator

Review and monitor

Close

Fig 12: A flow chart for managing changes

Many decision-making methods involve the use of scoring methods in which the importance of each factor is rated on an ordinal scale. The resulting values are then combined by addition or by

Select

FEED

Detail design

multiplication of some weighting factor to compute an aggregate measure. Some of such methodologies go even further by employing procedures to determine the ranking of influencing factors

Execute

Integration testing

Interface identification Installation

Interface design

Draft interface matrix Draft interface register

Draft interface DSM, IRD and ICD

Management of change Validation Finalised interface DSM, IRD and ICD

Interface test procedure

Fig 13: Interface timeline for various activities

56

Finalised interface test procedures

Interface test reports

Commissioning

Underwater Technology  Vol. 33, No. 1, 2015

(Yasseri, 2012). Ordinal scales are used in the present paper for scoring the interface volatility and technical risk. Interface verification (Fig 1) is performed at many stages during the system development and realisation. It is carried out to demonstrate that the design and implementation conform to the ICD and procedures for doing this are described in formal documents. Validation of the interface requirements will take place at the factory and again at the marine base. Each lead party is responsible for their assigned interface test. At the marine base the respective interface will go through integration tests to validate the complete system compliance against the system design specification. The overall system integration plan will elaborate what and how system integration tests must be performed. For a successful interface solution all parties must be regarded with equal degree of responsibility. It is not uncommon for the stronger party to force its view on others leading to none optimal solution. The project director is responsible for the scope of responsibilities. The lead party will ensure that resolutions are documented and any conflict is reconciled.

References American Petroleum Institute (API). (2009). API RP 17N Recommended Practice subsea production system reliability and technical risk management. Washington DC, USA: American Petroleum Institute, 99pp. Blyler J. (2004). Interface management: Managing complexity at the system interface. IEEE Instrumentation and Measurement Magazine 7: 32–37. Browning T. (2001). Applying the design structure matrix to system decomposition and integration problems: a review and new directions. IEEE Transactions on Engineering Management 48: 292–306. Crawley E, de Weck O, Eppinger S, Magee C, Moses J, Seering W, Schindall J, Wallace D and Whitney D. (2004). The influence of architecture in engineering systems, Engineering systems monograph. MITesd, 29–31 March, Cambridge, USA. Available at http://esd.mit.edu/ symposium/pdfs/monograph/architecture-b.pdf, last accessed . Eppinger SD. (1997). A planning method for integration of large-scale engineering systems. International Conference on Engineering Design (ICED) ’97. Tampere, USA, 19–21 August. Available at http://web.mit.edu/eppinger/ www/pdf/Eppinger_ICED1997.pdf, last accessed . Eppinger SD and Browning TR. (2012). Design Structure Matrix Methods and Applications. Cambridge, USA: MIT Press, 280pp. European Space Agency Requirements and Standard Division. (2013). ECSS-E-ST-10-24C DIR1, Space engineering

interface management. Noordwijk, The Netherlands: ECSS Secretariat, 50pp. Grose LD. (1997). Lean Aircraft Initiative – Product Development Focus Group. Lean Aircraft Initiative Plenary Workshop, 8 October, Cambridge, USA. Available at http://dspace.mit.edu/bitstream/handle/1721.1/83415/ PLN_1097_Grose_DesStructMatrix.pdf?sequence=1, last accessed . Hauser JR and Clausing D. (1988). The house of quality. Harvard Business Review, May–June, 63–73. Lalli VR, Kastner RE and Hartt HN. (1997). Training Manual for Elements of Interface Definition and Control. National Aeronautics and Space Administration Reference Publication 1370, Lewis Research Center, Cleveland, Ohio: National Aeronautics and Space Administration, 60pp. Available at www.hq.nasa.gov/office/codeq/rp1370.pdf, last accessed . National Aeronautics and Space Administration (NASA). (2007). Systems Engineering Handbook. NASA/SP-2007-6105 Rev1. Washington DC, USA: National Aeronautics and Space Administration, 360pp. Available at http://ntrs. nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20080008301. pdf, last accessed . Pimmler TU and Eppinger SD. (1994). Integration analysis of product decompositions. ASME Design Theory and Methodology Conference, Minneapolis, USA, 10pp. Available at http://web.mit.edu/eppinger/www/pdf/Pimmler_ DTM1994.pdf, last accessed . Tripathy A and Eppinger SD. (2007). A System Architecture Approach to Global Product Development. Massachusetts Institute of Technology Sloan School of Management Working Paper Number 4645-07, 46pp. Available at http://mitsloan.mit.edu/pdf/global-product.pdf, last accessed . Van Eikema Hommes QD and Berry PW. (2003). Managing system interface requirements reconciliation using design structure matrix method. Proceedings of INCOSE International Symposium 13: 607–618. Yasseri S. (2012). Subsea technologies selection using analytic hierarchy process. Underwater Technology 30: 151–164. Yasseri S. (2013). Subsea system readiness level assessment. Underwater Technology 31: 77–92. Yasseri S. (2014). Application of system engineering to subsea development Underwater Technology 32: 93–109. Yasseri S. (2015). Evidence-based subsea engineering. Underwater Technology 32: 231–244. Yassine A and Braha D. (2003). Complex concurrent engineering and the design structure matrix method. Journal of Concurrent Engineering: Research and Applications 11: 165–176. Yassine AA, Whitney DE and Zambito T. (2001). Assessment of rework probabilities for simulating product development processes using the Design Structure Matrix (DSM). Proceedings of DETC ’01. ASME 2001 International Design Engineering Technical Conferences, Pittsburgh, USA, 9pp. Available at http://dspace.mit.edu/bitstream/handle/ 1721.1/1673/Yassine-DTM21693.pdf, last accessed . US Department of Energy. (2003). System engineering and interface management. Office of Management, Budget and Evaluation, Project Management Practices, Rev E, June 2003, 23pp. Available at www.cesames.net/fichier. php?id=71, last accessed .

57