Application of systems engineering to subsea development

www.sut.org

Application of systems engineering to subsea development Sirous Yasseri* Safe Sight Technology, Surrey, UK

Technical Paper

doi:10.3723/ut.32.093 Underwater Technology, Vol. 32, No. 2, pp. 93–109, 2014

Received 19 June 2013; Accepted 17 February 2014

Abstract Subsea development managers are faced with tasks of meeting concurrent development schedules, coordinating the work of large numbers of technical personnel, allocating requirements to multiple system elements, acquiring equipment from multiple vendors and adjusting interfaces for compatibility. Systems engineering (SE) is evolving as a key enabler of subsea production system design and acquisition. The present paper applies the SE concept, as well as system thinking, to the design of subsea production systems. SE is a suitable tool for managing complex problems by breaking them into manageable size. It starts with understanding of the desired capability and evolving the solution through various subsystems and components required to meet this capability over the life of the system. With an understanding of SE principles, one can appropriately tailor the SE process to the development of any system or finding solution to any problem. The SE process inputs consist primarily of the field data, the current capabilities/infrastructures, technical limitations, customer’s needs and objectives, and project constraints. Project constraints shape the project and include budget limitations, schedule deadlines and constraints such as a weight limit or the water depth. The scope of SE is to establish the requirements and physical subsea architecture, manage its development into a detailed definition and assess that the required performances are achieved. Keywords: systems engineering, subsea production system, subsea installation, filed development

1. Introduction A system is a collection of elements related in a way that allows the achievement of a common objective (International Council on Systems Engineering (INCOSE), 2010). Any significant subsea production system (SPS) is composed of many different elements that must be completed separately, but all

* E-mail address: [email protected]

of which must work together in harmony. These elements include hardware, software, ancillaries and processes. Such complexity requires a spectrum of engineering expertise and supervisory management systems to coordinate them. Systems engineering (SE) is a discipline concerned with the integration of multiple interrelated subsystems designed by different experts. It is the job of a systems engineer to balance and define the requirements of each subsystem to achieve the best possible final design, considering all constraints and interfaces. The engineers within each subsystem are tasked with optimising their part of the project, subject to the project’s overall constraints. SE is the practical application of scientific, engineering and management skills necessary to transform an operational need into a description of a system configuration that best satisfies that need. The term ‘systems engineering’ can be traced back to the 1940s (INCOSE, 2010). The SE approach was primarily developed by the military industries as a process by which large engineering projects could be designed, implemented and tested prior to deployment (US Department of Defense (DOD), 2006). National Aeronautics and Space Administration (NASA, 2007) adopted the principle of systems thinking to the design of spacecrafts. SE is frequently defined by its context. NASA (2007) gives this definition: Systems engineering is a methodical, disciplined approach for the design, realization, technical management, operations, and retirement of a system. A “system” is a construct or collection of different elements that together produce results not obtainable by the elements alone. SE is the link between all processes – design, technical management and product realisation. The 93

Yasseri. Application of systems engineering to subsea development

now accepted definition of SE is given by the International Organization for Standardization (ISO) 15288 (2008), together with its underpinning methodology. SE deals with the methodology rather than the physics of the problem and considers the customer’s business and the technical needs in shaping the physical system. SE methodologies have been successful in the following areas (NASA, 2007): • Definition of systems, including identification of customer requirements and technological specifications; • Development of system requirements, including conceptual architecture, trade-off of design concepts, configuration management during design development, and integrated product and process development; and • Deployment of system validation and verification, including operational tests and evaluation, maintenance over extended lifecycle and reengineering (renovation). In 1998, the Electronic Industries Alliance (EIA) published their Processes for Engineering a System. This became the American National Standard Institute/ Electronic Industries Alliance (ANSI/EIA) 632 (1999) and is consistent with the approach being taken by the ISO 15288. The Institute of Electrical and Electronics Engineers (IEEE) 1220 (2005) represents an application of ANSI/EIA 632 to the electronics and electrical industry. In 1998 IEEE published IEEESTD-1362-1998 standard, a guide for the application of SE in the information technology industry (IEEE, 2007). The INCOSE (2007) SE process is based on EIA 632. Thus, a consistent SE standard has emerged. This indicates that SE has matured as an engineering discipline. SE has been successfully applied to aeronautic (e.g. Won et al., 2001), automobile (Loureiro et al., 1999), space exploration (NASA, 2007) and software engineering (e.g. Sweeney et al., 2011). There is a great benefit in applying its principles to oil and gas development (Gudmestad et al., 2010). For survey articles see Elm et al. (2008) and Estefan (2007).

2. Systems engineering process SE methodology includes the following major steps: (1) problem statement; (2) identification of objectives and requirements, and their documentation; (3) concept generation; (4) assessment of alternatives and trade-off studies; (5) selection of primary concept; (6) system decomposition (partitioning), design, development, integration, verification and validation; and (7) system operation and lifecycle management. 94

The SE process is an iterative problem-solving approach, applied sequentially top-down by integrated teams to break down a complex system into manageable subsystems, or even down to components. It translates the customer’s needs and requirements into a set of high level system descriptions, which provide input for the next level of decomposition (NASA, 2007). Starting from the top, a complex system is decomposed sequentially, adding detailed definition and performance requirement for each level of the system. This process consists of nested loops (Fig 1) – i.e. requirements loop, design loop, verification loop and the control loop – indicating the recursive nature of the process. It also includes input and output definitions. These loops link requirement analysis, functional analysis and allocation, and synthesis. The inputs consist primarily of the customer’s needs, objectives, requirements and project constraints. The first step of any system design process is understanding of the needs and wants of the customer, as well as the context in which the system will operate (the system boundaries). Prior to driving a system solution, it is necessary to determine which customer’s inputs are requirements and which ones are merely directions. This distinction allows the engineer to evaluate customer’s needs and define the system boundaries based upon requirements rather than directed implementation (Crawley et al., 2004). Requirements analysis is the analysis of the process inputs. It is used to develop functional and performance requirements; namely, customer requirements are translated into a set of requirements that determines what the system must do and how well it must perform. Functional analysis and allocation are used to define successively lower-level functional and performance requirements, thus defining architectures at ever-increasing levels of detail. System requirements are allocated and defined in sufficient detail to provide design and verification criteria to support the integrated system design (INCOSE, 2010). Functional and performance requirements for any level of the system are developed from higher-level requirements. Functional analysis and allocation study result in a better understanding of the requirements and may prompt a revisit to the requirements analysis. This iterative process of revisiting requirements analysis as a result of functional analysis and allocation is referred to as the requirements loop. Synthesis is the process of defining the subsystems in terms of hardware and software elements, which together make up and define the subsystem. The result is the physical architecture. Each part must meet at least one functional requirement, but any part may support many functions.

Underwater Technology Vol. 32, No. 2, 2014

Requirements analysis

System analyses and controls

• Analyse customer requirements • Identify functional requirements • Define/refine performance and design constraints

• Trade-off studies

Control loop

Requirements loop

Input • Customer needs/objectives/ requirements • Technology base • Output requirements • Field data • Regulatory requirements

• Effectiveness analyses • Risk management • Configuration management • Interface management

Functional analysis/allocation

• Verification and validation

• Decompose to lower-level functions • Allocate performance and other limiting requirements to all functional levels

• Performance measurement

• Define/refine functional interface

• Risk management

• Technical review • Verification and validation

• Define/refine/integrate architecture

• Existing infrastructure • Constraints • Other

Design loop Verification loop

Output • An optimal functioning system

Synthesis • • • •

Transform concepts to physical architecture Alternative system concepts, configuration and elements Select preferred solution Define/refine physical interfaces

• Decision database (traceability) • System architecture/configuration • Subsystems and equipment • Specification

Fig 1: SE process

Design loop is the process of revisiting the functional architecture to verify that the synthesised physical design can perform the required functions and deliver the required levels of performance. The design loop permits reconsideration of how the system will perform its function, and thus can be utilised to optimise the synthesised design. Verification loop is the process of comparing the solution with the requirements. Each requirement at each level of decomposition must be verifiable. Baseline documentation developed during the functional analysis and allocation must establish the method of verification for each requirement. For each application of the SE process, the solution is compared to the requirements to confirm that the solution meets them. Integration of each part and component presents a level of the system requiring verification. Verification can be accomplished by inspection, demonstration, simulation/ analysis or testing. It is important to remember that verification plans should be initiated as part of the requirements development process. Validation is accomplished at the system level against the system requirements or performance requirements. The system approach is illustrated by the ‘V’ (Fig 2) model (NASA, 2007), originally from Forsberg et al. (2005). The downward path of the ‘V’ represents functional analysis and the upward path represents physical synthesis. The ‘V’ diagram provides a route

map for the ordered application of systems design processes and identifies the systems engineer as the key coordinating role. The core project development processes that are the focus of the present paper are enclosed in a dashed box at the centre of the ‘V’. The ‘V’ diagram also includes two wings that show the broader project lifecycle – from initial project identification at the beginning, to system retirement or replacement at the end of the lifecycle. On the left side of the diagram in Fig 2, the system definition progresses from a general customer’s view of the system to a detailed specification of the system design. As development progresses, a series of baselines are established that supports the system design. Hardware implemented during construction is shown at the bottom of the diagram. Moving up along the ‘V’, the components of the system are integrated, tested and verified in iterative manner. Ultimately, the completed system is validated by measuring how well it meets the customer’s needs. There is traceability from one step to the next, as well as between steps on both sides of the diagram, since the system definition that is generated on the left is used to verify the system on the right (NASA, 2007). The user needs that are identified in the very first step of the process are used to validate the completed system as part of system validation. 95


Technical management process

Technical planning

Risk management

Requirement management Configuration management

Technical management

Appraise

System validation plan System verification plan (System acceptance)

Gates/ document/approval

Subsystem verification

Unit/component test plan

Unit/component testing

ratio

finitio

d de

n and

Execute construction

System verification and deployment

mpo

n an sitio mpo Deco

Execute design

Subsystem verification plan (Subsystem acceptance)

Decommissioning

System validation

Select

Define

Modifications and upgrades

Operation and maintenance

sition

Exploration

Technical data management

Decision analysis

deco

Concession

Interface management

Technical assessment

n

Integ

Installation

Implementation development process

Time line

Fig 2: SE ‘V’ diagram

The ‘V’ model shows how SE activities cascade from conceptual/system level to a physical design solution as a series of iterative and interrelated tasks. Many factors influence the nature and degree of iteration and concurrency of the process. Such factors include technology selection (Yasseri, 2012), degree of standardisation/commonality, software/ hardware mix, interface needs and architecture. The ‘V’ model provides a hierarchical, functional and physical partitioning of a system into a collection hardware, which can be logically followed and tracked to completion. The model encourages the early use of conceptual models in order to gain

Concession

Exploration

Appraise

understanding of the technical feasibility. The clearer understanding of the customer’s requirements, the greater potential for success in achieving what is requested. The ‘V’ model does not present the actions necessary for the technical management of the SE process. The upper section of Fig 3 shows the management process needed to run the ‘V’ process successfully. Key points of the ‘V’ model are: 1) The left side is the definition and decomposition of the system into components that can be built

Select

Define

AP1

AP2

Execute and procure

Construct and commission

Operate

Review points AP Regulatory approval process

Gate 1

Fig 3: Stages of the field development

96

Gate 2

Gate 3

Gate 4


or procured. The bottom of the ‘V’ is the construction, fabrication and procurement or development of the component items. The right side of the ‘V’ integrates the components into subsystems and finally into the final system. Each level of integration is verified against the left side of the ‘V’ through the verification process. 2) Control gates provide the system owner with formal decision points to proceed to the next step of the process. 3) There is a relationship of the activities performed on the left side of the ‘V’ to the products produced, integrated and verified on the right side of the ‘V’.

3. Phase and stage-gated approval process A field development is a sequential process which is carried out over several years. The commitment to the capital investment in the oil and gas industry is incremental; accordingly the lifecycle of the project is divided into phases, and each phase, in turn, may be divided into several stages. Fig 4 shows typical phases of a field development (Boehm and Lane, 2008). At each stage, adequate information is gathered to decide whether further investment is justified. This is known as the staged-gate process, which facilitates incremental commitment to the project and supports the timely accrual of relevant information. A robust gating system facilitates the early detection of poorly conceived or defined projects.

Scheduling or resource problems are also detected earlier and can be reworked at lower cost, or the project stopped. The criteria for effective gating of a project are (McGee et al., 2000): • Gates should control decisions rather than activities. Each stage should have clearly defined deliverables, decision criteria and decision makers. • Staging should be structured, simple and adaptable. • Gate position must be a logical point in the design progression. The gating process is facilitated by a number of technical reviews (Table 1), which are carried out at designated points (Fig 3). The process provides progressive evaluation of the direction and progress of the design towards meeting the customer’s requirements. Each review is shown on the diagram in Fig 3 as taking place as a single event, but it is better to hold each review as a progressive series of events and examine individual systems or components separately. However, a final system level review should be completed where the reviews are held progressively to ensure that all interfaces and integration issues have been addressed. Lifecycle models vary according to the nature, purpose, use and circumstances of the customer organisation. There is a variety of lifecycle models, but all of them share an essential set of common characteristics which can be used for the SE purposes. Each stage has a distinct purpose and contribution to the whole lifecycle and represents a major period

Hydraulic flying lead Production flowline Production well and subsea tree

Subsea separator

Booster pump

Gas injection flowline Production well and subsea tree

Injection well and subsea tree

Manifold Water injection flowline

Jumpers/spool

Hydraulic and electric control umbilical

Fig 4: Schematic of a typical subsea development

97


Table 1: Technical reviews Review name

Project phase

Primary purpose

SRR – System requirement review

Appraise

SDR – System definition review

Select

PDR – Preliminary design review

Define

CDR – Critical design review

Execute design

SVR – System verification review

Execute installation

PCR – Physical configuration audit

Finalisation

Consider all concepts presented and select a preferred concept for further development. The review assesses progress towards converging on a viable, traceable set of system requirements that are balanced with cost, schedule and risk. Ensure that specification requirements are complete and unambiguous, and that the engineering (technical requirements) specification fully satisfies the system requirements for the design task. Verify that preliminary approach is consistent with specified requirements. The review should establish that the set of assigned requirements has been met by the subsystems designs and the subsystem designs are consistent with the design intent of the customer. Verify that detail design can meet design intent. The CDR provides a major input for final acceptance of the design contractor’s work. It should establish that specifications, data sheets and drawings adequately define the subsystems, enabling systems, products and associated processes for the system to be constructed/fabricated and ensuring they are appropriate for use. Verify that all testing and verification actions are complete prior to final commissioning and project acceptance. The SVR does not involve actual testing. This will have taken place beforehand and the results will have been reviewed progressively in advance of the formal SVR. Provide the formal means of ensuring that the physical installation conforms to the approved design and thus the basis for formal acceptance. PCR is carried out progressively and involves a validation of the ‘as-built’ configuration of the new or altered asset with the design documentation.

in the lifecycle of a system. For example, the appraise stage focuses on identifying the customer’s needs, exploring different solution concepts and proposing candidate solutions. The select stage involves refining the system requirements, creating a solution description and building a system. The stages also describe the major progress and achievement milestones of the system through its lifecycle.

4. Subsea field parameters The main drivers of any field development are the size of field and complexity of the reservoir. These parameters will interact with the fluid characteristics to determine the optimal number of wells. The number of wells will increase when the reservoir becomes larger and when it is more fragmented. An SPS is unique to a particular field and reservoir. In some situations, customisation goes down to individual well level (Fig 4). Implementing a complete system might involve contracting with a number of suppliers. But even if each supplier’s equipment performs its task adequately, integration with other suppliers’ equipment is often problematic. 98

SPSs generally require a hub, i.e. a central processing facility, such as a fixed jacket, a floating production, storage and offloading (FPSO) and a technology readiness level (TLP) – a combination of which is known as the mode of production. Water depth and existing infrastructure determine which mode of production is more economical and technically feasible. The typical required inputs are: • Reservoir data, derived from exploratory and appraisal wells, which will give insight to the production rate, pressures, temperatures, etc. (immediate or future water injection or gas lift must be factored in); • Water depth, metocean data, geological, geochemical and geohazards; • Drilling requirements, including timing; number of wells; anticipated depths; type of trees (dry or subsea); anticipated workovers; location of rig; and rig availability; • Operational considerations, such as expected uptime, flexibility needed and requirements for discharge or disposal, and anticipated flow assurance issues; • Flowline information, including distances from the subsea wellheads via umbilicals and risers;


Subsea systems engineering

Equipment application and development

Integrity and risk management development

Flow assurance and operability

Systems integration

• Line sizing and routing • Thermal-hydraulic issues • Fluid behaviour • Artificial lift • Solids prevention and control • Corrosion prevention

• Development concepts and layouts

• Electric flowlines heating

• Reliability assurance

• Project-wide design basis • Piping and instrumentation diagrams (P&IDs)

• Subsea processing

• Technology readiness

• Subsea chemical distribution • Multiphase metering

• RAM analysis

• Production chemicals • Operating envelopes

• Cost and economics • Functional specifications

• Operating strategies • Operating philosophies • Operating manuals • Reservoir interfaces • Processing facilities interfaces • Production simulators

• Process flow diagrams (PFDs)

• Functional interfaces • Factory and site acceptance tests • Design reviews • Integration tests • Verification and validation

• Multiphase pumping/compression • Single phase pumping/compression • Control/service/power buoys • Long distance communications • Subsea power distribution • Subsea power generation

• Integrity management

• Quantitative risk analysis • Hazard identification • Hazard and operability • Spare and SIMOP policy • Intervention maintenance and repair

Fig 5: Delineation of subsea system deliverables

• Export plans considering the existing infrastructure, proximity to hubs and point of sale; • Export line requirements for complying with transport regulations and delivery standards of host countries; • Location of the field for factoring in the impact of governmental and regulatory agencies, and possibly taxation; • Consideration of customer preferences, mandates and specifications; • Specific safety issues, tolerances for risk and corporate guidelines; and • Existing infrastructure. Subsea system architecture is the fundamental organisation of a system embodied in its components, as well as their relationships to each other and to the environment and the system structure defined in terms of system elements, interfaces, processes, constraints and behaviours. The spread of equipment and component on the seabed is the geometry of the system; the system architecture determines connectivity (Crawley et al., 2004). The size of each element is dependent on the field condition. Architecture dictates what possibilities are allowed, while still remaining faithful to the selected concepts that fulfil the objectives. Architecture provides the rationale for requirements, as well as the criteria for allocating requirements and cascading them down from

one level to the next. Fig 5 shows typical areas of subsea SE activities. The function of the system level architecture is not necessarily to make final decisions. The purpose is to make decisions that ‘enable’ the various other engineering disciplines to achieve their engineering performance objectives. Systems need to be configured in a way that enables them to tolerate change and expansion beyond current customers’ needs. The system architecture must be simple, complete, achievable, expandable, flexible, maintainable, repairable and affordable.

5. System architecting There are various ways of developing subsea oil production fields. A major differentiating factor is whether the tree is wet or dry condition. Dry tree tieback concepts require a platform to support the permanently attached production/intervention risers, but provide the efficiency and the convenience of direct well access for remedial activities. Subsea (wet) tieback concepts provide greater flexibility in utilisation of existing infrastructure and well location, but require more costly well interventions/ workovers. Design is a step towards the acquisition of a system as an end product. The field architecture is the 99


Table 2: Subsea system parameters Group

Sub-group

Reservoir

Pressure Temperature Reserves Depth Drive mechanism Productivity CAPEX OPEX Risk Net present value Local taxes/incentives Resources and taxation Number of flowlines Flow rates Length Service type Number Size Choke Insulation Separation Booster pumps Maintainability Water depth Metocean Geology and soil Management Contracting Integrated risk management Chemical injection Operation procedure Gas lift Water injection Multiphase boosting ESP Process Composition (oil and gas mix) Viscosity Wax content Water salinity Topography Soil Geohazards Current Power Controls Sensors Communication Infrastructure Installation vessel Local input

Economics

Flowlines and risers Umbilical

Subsea processing Environment Project execution

Enhanced recovery

Fluid type

Seabed

Ancillaries

Logistics

outline of such product, which will take shape at the end of the appraise phase. During the field architecting, the field data (see Table 2) together with architectural aspects (capacity, spatial requirements, mode of production, etc.), environmental aspects (site, location, surroundings, environmental conditions, etc.), and technical aspects (construction vessels, codes and standards) are considered. 100

Fig 6 shows the SE process as shown in Fig 1, but with fewer details. The application of SE models is carried out by separating the final product (the production system) from the enabling product (equipment, installation vessels, testing equipment, etc.) and development product (engineering expertise, analyses tools, etc.). The data and the customer’s statement of requirements provide a common basis to evaluate, validate and communicate key information to all engineers who design the physical components. The aim of SE is to determine what is needed, not how to achieve it. In the following section, the SE process described in section 2 is discussed in the context of SPS development.

5.1. Requirement analysis Requirement analysis translates customer objectives into a set of technical requirements that specify what is expected of the system and what the performance requirements are, but does not prescribe solutions. The initial focus of the SE process involves developing a set of complete, consistent and achievable objectives. The result is a description of the system in terms of the required performances. Fig 7 shows the requirement loop of Fig 6 in an expanded form, stressing the option generation in a recursive context. The main task is to translate the field and technical needs into performance parameters, and to add all other performance para meters necessary to characterise a subsea system that is able to fulfil the customer’s needs. The operational and maintenance constraints, the environmental conditions, the reliability, availability and safety aspects, and others factors play an equally important role in setting the requirements. Subsea systems are tightly coupled; they are not only linked together, but are also dependent upon each other. Multiple coupled subsystems share a workload; the entire system usually needs to be shut down to fix a problem, not just the single system with the issue. Among the first decisions that define the system architecture is the system decomposition. It has a crucial impact on how requirements are grouped together and allocated, tasks are organised, and interfaces are conceived. The system decomposition should match as closely as possible to the work breakdown structure of the project. 5.2. Functional analysis Functional analysis answers questions such as: what are the quantities, pressure, temperature and composition; how the product will decline over the years; what is needed to boost production; how the product will be transported to the market; etc. Answers to these questions determine which modes


Inputs are customer’s requirements INPUTS

Requirements analysis Technical management processes

Requirements loop

Verification and validation loop

System analyses and controls

Functional analysis/allocation

Design loop

Design and synthesis

OUTPUTS Outputs are configuration documents

Fig 6: A simplified version of Fig 1 with fewer details, emphasising the three processes and loops

Validation

Verification

Feedback Options generation

Customer’s requirements

Validation

Feedback Check against requirements

•

Customer’s objectives

• • • • • • • •

Economics Field data Technology Regulation Environment/infrastructure Operation Maintenance Others

• Subsystem/modules • Objectives • Documents

• • • • • • • • •

Modular architecture

Options trade-off

Field architecture

Performance CAPEX/OPEX Risks Reliability Constructability/transport Reparable/maintainable Flexibility/expandability Disposability Others

Modularisation

Function allocation

Fig 7: The requirement loop of the SE process (Fig 1) as applied to the subsea development

of production can be used and how they can be organised (Viola et al., 2012). The next step is the requirements allocation, which is accomplished by decomposing higher-level requirements, identified through requirements analysis performed already, into lower-level subsystem requirements and their relationships. As the

analysis/allocation activity matures, requirements flow down to components or elements, when interfaces between them are more clearly understood. The allocation outcome is the identification of the physical components, which are able to perform the basic functions. These components may be equipment (Christmas tree) or subsystems (flowlines). 101


(It should be noted that equipment from its manufacture point of view is a system.) Once the components of the system have been identified, it is possible to determine their size and investigate how they can be best connected to form the system. The requirement loop links requirement analysis and functional analysis and allocation (Figs 1, 2 and 7). The outcome of going through such iteration is the system architecture. Architecture reveals why an SPS is the way it is and how this understanding is to be sustained. The value of architecture is in its stability and attention to fundamentals, and this guides the designers as the project progresses. Once the preliminary system architecture has been defined, it is verified to ascertain whether all the customer’s requirements have been satisfied. Typically for a process of successive refinements, several iterations may be necessary before selecting a few options. Once this phase makes sufficient progress, the specified system performance characteristics undergo a system requirement review (SRR), as shown in Fig 8. The defined system performance characteristics are assessed against the customer’s needs. The SRR is a verification tool used to review whether the SE work has been done correctly, i.e. to check the

Gate 2

Gate 1

APPRAISE

DEFINE

Phase II

SCR

Al

lo

ca

Preliminary design

System validation

System development and construction

n

an

d

de

gn

g rro

n

io

at

si

d an

te

In

ve

Commissioning and deployment

System performance tests System integration tests

Subsystem integration tests

Construct

Fig 8: Passage through gates (phasing, gating and incremental commitment)

Operation and support

n

tio

ca

Component tests (FAT)

Detail design

SOR

Commissioning

Verification

Freeze design

102

PCR

i rif

tio

MAINTAIN

Phase V

SVR

Planning

Concept development

OPERATE

Phase IV/2

CDR

Risk reduction

Performance requirements and specifications

EXECUTE INSTALL

Phase IV/1

PDR

Concept exploration

Customer needs

Gate 4

EXECUTE DESIGN

Phase III

SDR

5.3. Design synthesis In functional allocation, systems engineers specify only the functional requirements of what a subsystem, e.g. the control system, is supposed to do. Then they let control engineers decide how to satisfy the requirements. In this way, both parties can maximise their expertise and yet still cooperate tightly. They interact and negotiate on the requirements, but only where necessary. The second inner loop in Fig 1 (and Fig 6) is the design synthesis, which is the process of defining the physical components in terms of the hardware, software and operation procedures that together define the physical system. During the design synthesis step, the detailed physical design for each subsystem is developed (e.g. manifold, flowlines, etc.); this involves developing the physical architecture, including components design and interfaces.

Gate 3

SELECT

Phase I

completeness, correctness, achievability of the system performance characteristics, and the development risks. The purpose of the SRR is to demonstrate that the ‘right’ system characteristics have been specified. Deviations from the original needs are discussed and changes are initiated if the deviations are unacceptable.


This iterative process drives necessary adjustments to the conceived logical design and ensures each functional/logical requirement is addressed by at least one component (redundancy is desirable in SPS) and that each component is justified by a valid system requirement. Fig 5 is a realisation of a simple SPS, which will evolve as more iterations are performed to perfect the system.

5.4. Verification and validation There are four methods for verification: prototyping, testing, inspection and analysis. The first three require a physical system to be developed, while the last is based on a mathematical representation of the system, also known as a model. Analysis is generally used for verification at early stages of design. Because of the use of domain-specific modelling tools, such models usually correspond to a specific point of view of the system, like the flow assurance or mechanical aspects and so on. These separate views cannot capture the overall system behaviour; hence, testing and inspection is the preferred method. An overall progressive assurance strategy is used to ensure the acceptance process. This consists of tests at various stages of fabrication and installation. The major components of progressive assurance are various tests (factory acceptance test (FAT), site test, leak test, shallow water test integration test, etc.) as well as regular reviews of manufacturing progress measured against metrics such as TRL, integration readiness level (IRL) and system readiness level (SRL; Yasseri, 2013). The physical tests start at component level and end with substantial part of the system in place. These tests

provide a complete and evidence-based argument that all hardware complies with the requirements, and appropriate processes have been followed. The assurance arguments and evidence are collected in a hierarchy of technical documents, which reflects the logical breakdown of the SPS. Each technical case comprises arguments supported by evidence that demonstrates an objective had been met and lists the documentations that record the evidence. Validation confirms that the product, as provided, will fulfil its intended use, ensuring that ‘the right system was built’. Validation is defined as the evaluation of a system at the end of the development process to ensure compliance with the customer’s requirements. Validation is, therefore, end-to-end verification. Since validation is a comparative assessment against requirements, it also results in the confirmation that the customer’s needs were correctly identified and ratified (Table 3).

5.5. Control process The control process is a collection of management activities used to ensure that the project progresses according to the plan (Fig 2). It also serves as a feedback system for how well the project is moving forward. It measures performance and results against plans and notes deviations, and takes corrective actions to ensure the conformity of outcomes with plans. The control process asks questions such as: Are there any potential problems that will cause delays in meeting a particular requirement within the budget and schedule? Have any risks turned into problems? Is the design approach still valid? The

Table 3: SPS verification and validation activities Lifecycle phase

SE verification and validation activities

Appraise

• Translation of users’ needs into system performance requirements • System requirement review (SRR) • Requirement validation • Concept exploration and definition • Preliminary design review (PDR) • Requirement allocation to lower level • Preparation of validation plan • Preparation of verification plan • Monitoring and control of verifications • Preparation of integration plan • Monitoring of manufacturing verification activities and product • Change control • Verification status control • Preparation of system acceptance plan • Management of installation, integration and verification process • Change control • Verification status control • Management of system acceptance process • System validation • Change control • Monitoring performance against the customer’s requirements

Define

Execute – Design and manufacturing

Execute – Installation

Operation

103


control process must lead to corrective action, by bringing the status back in line with the plan, changing the plan or abandoning the project. In all phases risk must be identified, eliminated, controlled and mitigated (US DOD, 2006). Risk management is an organised, analytical process to identify, assess, mitigate and continuously track, control and document system/project risks, thus increasing the likelihood of meeting cost, schedule and performance objectives. A collection of methods is used to manage the project risk related to configuration, subsystem and external interfaces. Risk management is included as part of the system control process to accomplish the following objectives (DOD, 2001): • Identify the potential sources of risk and identify risk drivers; • Quantify risks and assess their impacts on cost, schedule and performance; • Determine the sensitivity of these risks to programme, product and process assumptions, and the degree of correlation among the risks; • Determine and evaluate alternative approaches to mitigate moderate and high risks; • Take actions to avoid, control, assume or transfer each risk; and • Ensure that risk is factored into decisions on selection of specification requirements and solution alternatives. Risk management must be forward-looking, structured, informative and continuous. Another control tool is the work breakdown structure (WBS), which is a hierarchical tree-like depiction of the system development activities as they relate to the system architecture (Brunson et al., 2009). The WBS provides a coordinated and complete view of the development and is useful for technical systems engineering and project management purposes. WBS is mainly used to track costs and project progress, but it also is used by SE to aid in: • Identifying products, processes, data and documents and their position in hierarchy; • Organising risk management analysis and tracking; • Implementing configuration management and control of subsystem interfaces; • Organising technical reviews and audits; • Planning workflow and concurrent engineering; and • Identifying needed resources. The WBS defines the limits of individual responsibility for work efforts; thus, it can be used to track both the system performance and the progress of its development. 104

6. Passage through the gates Five different phases, excluding concession, should be adequate to allow enough control (Walkup et al., 2006). The concession and exploration phases are not considered in the present paper. In Fig 7 the ‘V’ diagram is superimposed on the development phases. Criteria for rework, going ahead or abandoning the project are established in phase I. Criterion for abandoning a project is mostly of an economic nature. Technical difficulty tends to lead to the project postponement. Unavailability of suitable installation vessels could require rework and reconfiguration. The conceptualisation of the subsea system takes place in the appraise phase, yielding the field architecture. System engineers choose the solution principles, decomposition, interfaces and design process planning that will guide the other phases and the way in which designers will cooperate. The selection of architecture influences the choice and integration of detailed solutions. After the field architecture has matured to have a satisfactory understanding of the production system, it is decomposed into functional subsystems with proper interfaces, e.g. a subsystem for gathering, and another for transportation and how the two are to work together and to be controlled. Then all subsystems are broken down into their constituent components, and down to manageable parts that can be specified to the last details. Pipelines, flowlines, umbilicals, power cables, Christmas trees, spools and jumpers are considered to be well-defined and manageable subsystems. This is the bottom of the ‘V’, where the construction starts. Turning the corner of the ‘V’, all parts are manufactured to specifications. They are then tested, brought together and assembled into larger and larger subsystems, and finally integrated into the SPS, ready for integration testing and commissioning. The process has returned back at the top of the ‘V’, but this time with a completely defined system; instead of a mere vision of it.

6.1. Appraise phase The appraise phase starts when a discovery proves to be profitable and feasible. Financial commitment, site conditions, regulations of the host country and the customer’s needs together with the design requirements are defined during the appraise phase. Functional analysis has the greatest usefulness at this phase and comprises identifying as many options as possible, while looking for any ideas that may offer significant advantages. The system design starts with the requirements of production systems, which is a set of functional


requirements – namely how to extract and convey the petroleum product to the point of sale and how such system must perform. At this stage, only the outline of possible modes of production is known. Through functional decomposition, detailed design and physical assembly, engineers can specify the whole, its parts and their interrelations clearly. Layering, i.e. breaking down to subsystems, is crucial for managing complex systems, as it enables the introduction of complex details one step at a time. This process of managing the system’s lifecycle (through concept, design, fabrication, installation, operation and disposal) is similar to executing a series of interconnected engineering projects in a sequence, each building on the results of the previous step until the end result is achieved. When an end subsystem requires further development, it will have its own sub-subsystems; i.e. the subordinate building blocks. Once the descriptions of the production system are completed and preliminary system architecture is defined, the development of the next lower layer can be initiated. If the building block has reached the ‘bottom’, the design of these items requires no further layering, i.e. all enabling product. For example, flanges for that end product already exist and are all compatible with each other and with the total solution. During functional decomposition (i.e. layering the system into hierarchy of subsystems), the functional requirements are documented for the system in its entirety, its parts and their interactions at all decomposition levels. Such requirements include: how the system should be tested at each level, how leak detection and surveillance system should work, which materials to be used and so on. Iterations are common at every stage of the design, thus resulting in continuous trade-offs or refinement of system requirements. The customer’s objectives are the broad goals that the system should achieve. The functional analysis takes into account what the customer would like to achieve and what the budget allows. System requirements are traded throughout the design process, and the customer’s objectives may be modified at any phase. Such changes are controlled through management of change procedures. Towards the end of the appraise phase, the generated options for the system architecture go through the system concept review (SCR) to decide if they are matured enough to exit the second gate.

6.2. Select phase In the first part of this phase, two or more alternatives are established, including the associated operational, maintenance and logistic support concepts. The second part of this phase is related to:

• The allocation of performance requirements to subsystems and other system elements; • The comparison of the alternative system concepts; and • The selection of the optimal system. All subsystems are defined in a series of technical baselines, consisting of the approved documentations used to define the technical requirements and interfaces. Baselines are updated at all stages to reflect the current status of progress. These baselines define the system’s characteristics as it evolves, and the impact of any changes is measured against them. The concepts are detailed to such a level that enables them to undergo the system definition review (SDR). The SDR is like any design review. It is a verification tool that is used to analyse whether the concept selection process was performed correctly, and whether all documentations are produced and properly registered. The preliminary design review (PDR) helps to decide if the project can exit the gate.

6.3. Define phase Two or more concepts that give the most advantage are selected at the end of the previous phase. The selected concepts are detailed further, optimised and validated against the customer’s needs. The concept validation is the last opportunity before the detail design to fine tune the system. Towards the end of the phase, the design goes through PDR. Design reports are prepared to be assessed at the fourth gate, where the customer commits to major capital expenditure. A single concept emerges from this gate. 6.4. Execute When the project emerges from the fourth gate, it means that the customer is convinced that the project is economically viable and all interested technologies (Yasseri, 2013) are feasible and can be made to work successfully. This is the last stage of incremental commitment for major expenditure. 6.4.1. Detail design In most cases, when a project reaches this stage, almost everything is known about it and only a final touch may be required. Closing out of all project documents takes place at this stage. The execute phase starts if the customer has decided to continue with the project and begin the acquisition of the major equipment. However, letters of intent would have already been sent to major vendors with long lead equipment at define phase. The following project management documents have to be prepared very early in this phase: system verification plan, and system validation plan. 105


The system verification plan is used to define and plan the entire verification cycle of the system, and to specify the sequence of compliance demonstrations for each performance characteristic defined in the appraise phase. The system validation plan defines activities that are considered to form part of the system validation at a later stage. An example of such activities and results is the reliability analysis performed during the define phase and updated during the execute phase. Since in most cases the reliability cannot be demonstrated by tests, this system performance characteristic must be validated by analyses. Similarly, this applies to the validation of the capability to withstand environmental loads, installation load, etc. The verification plan influences lower level subsystems verification, hence the corresponding requi rements have to be included in the lower level requirement specifications. Both the validation and the verification plans are important project management documents. They define in detail: • What has to be done; • When to do it (i.e. at which configuration status); • Which method and procedures must be used; • Who is responsible; • What are the expected results; and • How the results must be documented. The creation of the two plans very early in the development process enables the SE to manage and control the complete verification and validation processes from the start to the end. The execute phase ends with the critical design reviews (CDR) of the entire system, including individual subsystems and even lower-level elements. The detailed design is scrutinised with respect to the fulfilment of the specified requirements and the cost efficiency. SE is responsible for arranging and coordinating the individual design reviews. It is also the SE’s responsibility to make sure that the design reviews are executed in a timely and purposeful manner. In other words, it should verify that the design is capable of meeting the specified requirements, including those related to the manufacturing, transportation and installation needs. 6.4.2. Manufacturing/fabrication The manufacturing phase is characterised by the first verification activities and the acceptance processes of the manufactured components or subsystem. All factory testing and other verifications activities (e.g. inspections, calculations) performed in the framework of the component or subsystem acceptance process are evidence of compliance with the performance requirements. 106

The acceptance process starts with the preparation of an acceptance plan by the contractor (internal or external) responsible for the delivery of the particular component or subsystem. It defines in detail the individual acceptance steps and execution sequence, methods, equipment, etc. This is reviewed and officially released for use as basis for the acceptance cycle by SE with respect to the system performance and product assurance. 6.4.3. Installation The degree to which a subsystem is assembled, integrated and verified at the manufacturer site depends on the possibility of transporting the assembled unit, as well as the risk involved if not factory tested. Not all characteristics can be verified at the factory. SE has to evaluate the risk and the related costs, and take them into account during the preparation of both the verification plan and the assembly and integration plan at the site. The sequence of the assembly and integration of the system should follow the onsite assembly and integration plan. This plan has either included the necessary verifications or makes references to the appropriate points in the system verification plan. Close to the end of the acquisition phase when many small delays have summed up to a critical schedule slippage, project managers tend to send insufficiently verified subsystems and components to the site, believing time and money can be saved by reducing the verification activities. During this warranty period, the system is gradually validated. As defined by the ISO 8402 (1994): ‘Validation concerns the process of examining a product to determine the conformity with the users’ needs.’ This means that SE has to demonstrate to the operator of the system that the installed system is really the answer to the initial statement of requirements. SE has to provide ‘the objective evidence that the particular requirements for the specific intended use are fulfilled’ as defined also in ISO 8402 (1994). This objective evidence consists of the analytical compliance demonstrations, for example, reliability analyses, environmental conformity analyses, safety compliance assessments and the functionality validation (not verification) processes. At the end of the commissioning, the ownership of the system is transferred to the operation manager. In general there is a warranty period at the end of which the system is formally accepted. The acceptance of the system is basically a demonstration that the system fulfils the specified functional, safety, operation and maintenance requirements. It also includes a certification of the operator’s participation in the operation and maintenance


training, as well as the delivery of all documentations. The process is followed; one section of a company provides services for another section. Two major reviews during the execute phase are CDR (critical design review) and SVR (system verification review; see Fig 8 and Table 1). The last review before handing over the installation to the operation is PCR (physical configuration review). All reviews are carried out progressively to ensure the smooth progression of the project and to ensure that the physical installation will conform to the approved design and thus the basis for formal acceptance. The system operation review (SOR) should be performed regularly during the system lifetime to study the need for preventative and corrective actions.

7. Risk management Risk management is the act or practice of controlling risk and determining how risks impact operations, performance, schedule and cost. The risk management concept is based on the principles that risk management must be forward-looking, structured, informative and continuous (US DOD, 2006). The key to successful risk management is early planning and focused execution. It should be looked at as a decision-making tool used to systematically evaluate possible courses of action, identify risks and benefits, and determine the best course of action in any given situation. It is an analytical process that continuously tracks, controls and documents system/ programme risks. The goal of risk management is to increase the likelihood of meeting cost, schedule and performance objectives. The elements of an effective risk management are as follows (US DOD, 2006): • Risk planning – develops and documents organised, comprehensive and interactive strategy and methods for performing risk management. • Risk assessment – identifies and examines each risk, isolating the cause and determining the impact in terms of its probability of occurrence and its consequences. The risk assessment process includes:

Risk handling – identifies, evaluates, selects and implements options in order to set risk at acceptable levels given programme constraints and objectives. It provides the mitigation aspects of risk management. Risk monitoring – systematically tracks and evaluates the performance of risk-handling actions against established indicators and measures.

8. Discussion According to Sharon et al. (2011): Most systems engineering management applications use some subset of traditional project management methods and tools, the actual practice of systems engineering management involves continuous cognitive zigzagging between systems engineering – the product domain – and project management – the project domain. Systems thinking is emerging both as a school of management thought and an academic discipline, as the ability to perform systems thinking is a critical competency for a systems engineer (Kasser and Mackley, 2008). SE has matured into a disciple (Kasser and Hitchins, 2012) and codes of practice covering SE are converging (Table 4) in their recommendations. SE is an interdisciplinary approach encompassing the entire technical effort to evolve and verify an integrated solution that satisfy customer needs (NASA, 2007). It is a process by which all of the important aspects or subsystems of a production system and their interactions can be identified, sized and studied to make sure they all work together harmoniously. The SE approach consists of identification and quantification of system goals, creation of alternative system design concepts, performance requirements, selection and implementation of the best design, verification that the design is properly built and integrated, and post-implementation assessment of how well the system meets the goals. Throughout the design, many studies and analyses are conducted to support decisions regarding

Table 4: Focus of major standards and their convergence (Kasser and Mackley, 2008) Activity

Mil-STD 499C

ANSI/EIA 632

IEEE-1220

ISO-15288

Conceptualising and alternative solutions Purpose definition Requirement engineering System architecting Technical analysis System implementation and management Verification and validation

No No Yes Yes Yes No Yes

No No Yes Yes Yes Yes Yes

No Yes Yes Yes Yes No Yes

No Yes Yes Yes Yes Yes Yes

107


requirements selection and system design. The collection of these reports effectively documents the process of defining the system. These are used to provide traceability to the rationale for the system performance. Specifications cover requirements from the top-level customer’s requirements to increasingly detailed requirements for the subsystems down to components. The specifications are grouped into levels within the context of levels, i.e. system level, subsystem level and component level. Typically, traceability starts from the lowest level of user requirements to an intermediate level in system requirements. SE requires verification to be carried out at every stage to ensure that the intermediate developments meet the requirements and specifications, which have been set at the previous stages. SE defines requirements for all components, but it does not decide how the design, manufacturing and installation should be done. All SE models begin with eliciting customer requirements and ends with acceptance tests where the final system is validated against the original customer requirements. The V-model sets a general flow for the development process. It requires that each stage of the product definition should be used to systematically test the implementation as subsystems are integrated. Different stages of development and testing are defined depending on the purpose, but in general, requirements analysis, architecture, detailed design and the corresponding verification/ validation stages are defined. In the present paper, the ‘V’ diagram is applied to an SPS. A large range of requirements defines a subsea system, and the interrelationship between them may be complex. An optimal design that satisfies all requirements as closely as possible must be obtained. Optimisation is used in trade-off studies where the interrelationship between parameters and results can be specified either mathematically or through simulation. Optimisation is useful for investigating sensitivity to key design parameters in search of an optimal design. The objective of an optimal design is to select design points according to some criteria, generally costs. However, accounting for installation vessel availability, materials and inbuilt flexibility for future expansion in the optimal design is also common. Therefore, trade-off studies comparing an optimal solution with different levels of constraints for large SPSs are essential. The SE approach, as analysis and synthesis, focuses on internal structures along with a set of given functional requirements. It goes one step further to establish what functions are required to design and build the successful system. SPSs are complex adaptive systems requiring many adaptive changes during the design. They 108

characteristically consist of a large number elements with interfaces at all levels. Berryman and Campbell (2010) discuss engineering of large projects that are characterised by a large number of (sub)systems – namely, system of systems (SOS) – where achieving the end goals involve interaction, and where designs and the technology of parts in service undergo many adaptive changes. Integration of a complex system is a major task, as parts that may not necessarily be designed to operate together are subsequently required to do so, hence understanding their interactions may prove to be problematic.

9. Concluding remarks SE has four characteristics: holistic, multidisciplinary, value-driven and lifecycle-oriented. The approach is holistic in that it considers the full technical system, including any number of performance criteria, as well as potentially non-technical concerns related to human factors or societal impacts. SE work is multidisciplinary, involving engineering, natural, computational and even social sciences. It is also integrated and value-driven by considering the needs and interests of all stakeholders. Finally, SE is focused on the long-term or lifecycle of the system and takes every aspect of a development into account (Dykes and Meadows, 2011). Developing and sustaining complex subsea systems requires collaboration of multidisciplinary teams, coordination of processes, methods and tools, allocation of resources and utilisation of facilities within the customer organisation. The classification of a system as complex or simple depends on the observer of the system, as well as the purpose of breaking it down to simpler subsystems. Dealing with complexity means using industry-based knowledge to develop an understanding of the interrelationships among the system components – which is an abstraction of the situation. A subsea system engineer must have wide-ranging knowledge, but knowing the subsea system is a prerequisite. By being exposed to experiences in various related fields one can accumulate the relevant knowledge. Schooling in SE can consolidate on the job learning. However, system thinking is gained through experience. The systems engineer must: • View the system from the customer’s points of view; • Start at the finish line – define the output of the system and the way the system will operate; • Address risks as early as possible – where the cost impacts are lowest; • Define what is to be done before defining how it is to be done;


• Focus on interface between subsystems; and • Verify and validate the physical system against requirement at every stage of progress.

References ANSI/EIA-632. (1998). ANSI/EIA-632 Processes for Engineering a System. New York: ESA-ESTEC (Requirements & Standards Division). Berryman MJ and Campbell P. (2010). Some complex systems engineering principles. In: Australia’s Preeminent Systems Engineering and Test & Evaluation Conference, University of Wollongong, Australia, Research Online. Available at http://ro.uow.edu.au/smartpapers/1, last accessed . Boehm B and Lane JA. (2010). DoD Systems Engineering and Management Implications for Evolutionary Acquisition of Major Defense Systems. System Engineering Research Centre, University of Southern California. Brunson KL, Beach J, Mazzuchi TA and Sarkani SH. (2009). A framework for systems engineering development of complex systems. CrossTalk: the Journal of Defense Software Engineering. Available at www.crosstalkonline.org/storage/ issue-archives/2009/200907/200907-Brunson.pdf, last accessed . Crawley E, De-Weck O, Eppinger S, Magee Ch, Moses J, Seering W, Schindall J, Wallace D and Whitney D. (2004). Engineering systems monograph. The Influence of Architecture in Engineering Systems, The MIT ESD Architecture Committee. Available at http://esd.mit.edu/symposium/ pdfs/monograph/architecture-b.pdf, last accessed . Dykes K and Meadows R. (2011). Applications of systems engineering to the research, design, and development of wind energy systems NREL/TP-5000-52616. Washington, DC: National Renewable Energy Laboratory. Available at www.nrel.gov/docs/fy12osti/52616.pdf, last accessed . Elm JP, Goldenson D, El Emam K, Donatelli N, Neisa A and NDIA SE Effectiveness Committee. (2008). A survey of systems engineering effectiveness – initial results. Paper 299. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University. Available at http:// repository.cmu.edu/sei/299, last accessed . Estefan JA. (2007). Survey of model-based systems engineering (MBSE) methodologies. INCOSE MBSE Focus Group. Available at www.omgsysml.org/MBSE_Methodology_ Survey_RevA.pdf, last accessed . Forsberg K, Mooz H and Cotterman H. (2005). Visualizing Project Management, 3rd edition. New York: John Wiley and Sons. Gudmestad OT, Zolotukhin A and Jarlsby ET. (2010). Development of Petroleum Resources with Emphasis on Offshore Fields. Southampton, UK: WIT Press, 288pp. Institute of Electrical and Electronics Engineers (IEEE). (2007). IEEE-STD-1362-1998 Guide for Information Technology – System Definition – Concept of Operations Document, Available at http://standards.ieee.org/findstds/standard/ 1362-1998.html, last accessed . International Council on Systems Engineering (INCOSE). (2010). Systems Engineering Handbook – A guide for system life cycle processes and activities, vol. 3 no. 2. San Diego, CA: INCOSE.

International Organization for Standardization (ISO). (1994). ISO 8402 Quality management and quality assurance – Vocabulary. Geneva, ISO. ISO (2005). ISO/IEC 26702 (IEEE 1220-2005) Systems engineering – Application and management of the systems engineering process. Geneva: ISO. ISO (2008). ISO/IEC 15288 Systems and software engineering – System life cycle processes. Geneva: ISO. Kasser J and Hitchins D. (2012). Yes systems engineering, you are a discipline. In: 22nd Annual International Symposium of the INCOSE, Rome, Italy, 1–16. Kasser J and Mackley T. (2008). Applying systems thinking and aligning it to systems engineering. In: The 18th INCOSE International Symposium, Utrecht, Holland. Loureiro G, Leaney PG and Hodgson M. (1999). A systems engineering environment for integrated automotive powertrain development. Society for Design and Process Science, vol. 3, no. 4, USA. McGee MD, Defoe PR, Robertson DI and McConnell JD. (2000). Improving asset performance through application of a structured decision process. SPE 60852. SPE Annual Technical Conference and Exhibition, 3–6 October, Houston, Texas. National Aeronautics and Space Administration (NASA). (2007). Systems Engineering Handbook. NASA Technical Report NASA/SP-2007-6105 Rev1. Washington, DC: NASA. Available at http://ntrs.nasa.gov/archive/nasa/casi.ntrs. nasa.gov/20080008301_2008008500.pdf, last accessed . Sharon A, De Weck L and Dori D. (2011). Project management vs. systems engineering management: a practitioners’ view on integrating the project and product domains. Systems Engineering 14: 427–440. Sweeney RL, Hamman JP and Biemer M. (2011). The application of systems engineering to software development: a case study. Johns Hopkins APL Technical Digest 29: 327–337. US Department of Defense (DOD). (2001). Military Handbook: Configuration Management Guidance. MIL-HDBK-61A. US Department of Defense. 7 February 2001. Retrieved 24 March 2012. Available at https://acc.dau.mil/ CommunityBrowser.aspx?id=142238, last accessed . US DOD. (2006). Risk Management Guide for DOD Acquisition, sixth edition, version 1.0. Available at www.acq.osd.mil/se/ docs/2006RMGuide4Aug06finalversion.pdf, last accessed . Viola N, Corpino S, Fioriti M and Stesina F. (2012). Functional analysis in systems engineering: methodology and applications. In: Cogan B (ed.). Systems engineering – practice and theory. Rijeka, Croatia: InTech. Available at www. intechopen.com/download/get/type/pdfs/id/32617, last accessed . Walkup GW and Ligon JR. (2006). The good, the bad and the ugly of the stage-gate project management process in the oil and gas industry. SPE 102926. SPE Annual Technical Conference and Exhibition, 24–27 September, San Antonio, Texas, USA Won CH, Sale D, Schultz RR, Johnson F and Semke H. (2001). Spacecraft systems engineering – the initiation of a multidisciplinary design project at the university of North Dakota. In: Proceedings of ASEEACE, 8951–8963. 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.

109