Network Integration Dec 5 1900 - rev F - Ocean...

Network Integration

Systems Engineering TeamSystems Engineer, Ocean Observing Activities

Consortium for Ocean Leadership

OOI Preliminary Design ReviewDecember 4-7, 2007

Arlington, VA

Network Integration

• Integrated Team• Systems Engineering• Configuration Management• QA/QC• System Testing, Acceptance,

Commissioning

Network Integration Support• Ocean Leadership – Integration• University of California San Diego - Cyberinfrastructure• Woods Hole Oceanographic Institution and partners -

Coastal and Global Scale Nodes• University of Washington - Regional Scale Nodes

• Systems Engineer(s)• Project Scientists• Contracting Officer’s Technical Representatives (COTR) • Subject Matter Experts (SME)

– science community– engineering contract support

Systems Engineering (SE)• Development and organization of complex systems• Integrates other disciplines and SME groups• Structured development process

– Systematic design-build process– Iterative analysis and design process

• System Lifecycle, concept through decommissioning• Quality product that meets the user needs, satisfies

system/user requirements

• OOI additional focus:• Interoperability• Analysis of range of technology solutions• Cost effective design solutions• Validation of product design and build to the science

Systems Engineering• OOI• Plans, Processes, Schedules, Tools

– CMP, SEMP, CEP, WBS, IMS, DOORS, Basecamp, WebEx…• Requirements

– SR, SUR, IRA, Sub-System• Design Documents, Technical Data Packages• Cross IO design integration• Incremental Design Reviews• Incremental Testing• Design workshops, integration sessions, meetings

Requirements• Focus on scope of task• Each project contributor clear understanding on role /

deliverables• Accountability• Traceability

• Functional Requirements– System Behavior– Verbs– E.g. “The system shall measure quantity x with accuracy ε every time t”

• Non-Functional Requirements– Overall Characteristics– Adjectives– E.g. “The system shall withstand a Category 4 storm”

• Client – Server Architecture– A single server contains all project data– Keeps multiple sites in sync at all times

• Deals Effectively with Change– Requirements change during development

• Change tracking of linked objects shows what lower level requirements are affected

– Risks become issues / Tests fail• Links find the affected system parameters• Revise system performance predictions when subsystems do not

meet their goals

• Hierarchical database structure– Database structure matches project WBS

Requirements Management in DOORS

Requirements Management

Requirements Flowdown: Links

Req ID CI System RequirementsPD-01 The CI is in service to scientific investigation,

discovery and innovationPD-02 Development of the CI shall be science-drivenPD-03 The CI shall support distributed resources and

actorsPD-04 The CI architecture shall be based on standard

service-to-service protocols to the maximum possible extent

PD-05 The CI shall be based on open standards and software to the maximum possible extent

CI-U-1 The CI shall support distributed resources and actors. A resource is any entity associated with an observatory that provides capability, and includes instruments, data, workflows, networks and more. An actor is an entity external to an observatory

CI-U-2 CI source code developed by the CIIO shall be publicly available. The CI will be based on open software and standards to the maximum extent

CI-U-3 The CI shall support real time, guaranteed delivery, pull mode, streaming and register to receive communication capabilities. Real time means minimum delay commensurate with latency on the channel. Guaranteed delivery means storage of a message until an acknowledgement receipt is received. Pull mode means storage of a message pending receipt of an explicit request for it. Streaming means an asynchronous, continuous

OOI Science User Requirements

CI System Requirements

A single requirement is an “object” (row)Links are a many to many relationship

• Work Breakdown Structure breaks the work down• work products (packages) and the tasks

• Control Accounts (CA), Work Packages (WP)• 581 Work Packages• ~1,000 Tasks at preliminary level

• Each Work Package defined in the WBS dictionary• Work captured at a low level and short time period

• Enable program management of activities• Enable the Earned Value Management System (EVMS)

• Tasks to be developed further as the design matures and the work is planned in finer detail

Work Breakdown Structure (WBS)

Work Breakdown Structure

Configuration Management• Established a methodology/process for change management CMP• Configuration Management Process

– Drawing Standards, File Formats and Applications, Naming Conventions– Document Change Control / Change Request Process– Tools

• Technical Engineering Design Reviews– Engineering Final Technical Design Review– Baselines– Engineering Change Classes

• Change Control Reviews– IO Change Control Board– System Level Change Control Board– OOI Change Control Board

Integration of Cost, Resources and Schedule

Class I ECR

Class II ECR

OOI Change Control Process

Form, Fit, and Function, Safety Cost or Schedule to the OOI program in excess of $25,000 cost per control account or in excess of 1 week increase in work package schedule, singular and cumulative for both cost and schedule Technical requirements and specifications that affect reliability, maintainability, availability, form, fit, function or interface characteristics Configuration to the extent that retrofit (replacement of components) action would be taken Interchangeability, substitutability, or replaceability as applied to configuration items and to all subassemblies and parts of repairable configuration items

Minor in nature, such that the cost of processing the change request may equal or exceed the cost of performing the work. Do not exceed any single difference of 10% of the control account baseline budget or $25,000 between a control account estimate to complete versus the baseline budget to complete, whichever is lower. Task level, under the management of a CAM. Correction of typographical errors, dimensions, graphical or pictorial representation.

Board Level Board Membership Level I Authority

Level II Authority

Generate, review and approval all IO internally generated ECRs. Non-Critical Path up to one month. Funding at WP level. No contingency.

Generate, review and approval all IO internally generated ECRs. Non-Critical Path up to one month. Funding at Workpackage level. No contingency.

IO

Chair – IO SE IO PI IO PM Design Engineers CAMs

Forward all Level I ECRs to System Level CCBs that change scope of work, interface or a deliverable. Changes that exceed one month in schedule impact and any on the Critical Path. Funding at a Control Account Level.

Notify System Level CCB of all Level II approvals

Review and approval of all IO approved Level I forwarded over the threshold.

System

Chair – OOI SE OOI Director of Engineering OOI COTR OOI Associate Director (Science) IO PI's IO SE's Design Engineers

Forward all Level I ECRs to System Level CCBs that change scope of work, interface or a deliverable. Changes that exceed one month in schedule impact and any on the Critical Path. Funding at a Control Account Level.

Review and approval of all IO approved Level I forwarded over the threshold.

OOI

Chair OOI PI OOI Director of Engineering OOI Associate Director (Science) IO PI's Science Community Advisor(s)

Forward to NSF for concurrence any change that exceeds the overall program baselines for cost or schedule. Any change to the floor level of the system capability. Any change that reallocates funding at the level 2 WBS in excess of 10% of the 2nd level value.

• Electronic System Group has 35 years experience building and integrating custom data collection systems for Navy Submarines.

• Systems on every submarine in the fleet, supporting different classes of submarines, different sonar systems and different sensor configurations.

• Operations and Maintenance simultaneously supports many generations of data collection systems.

• Following describes existing APL Configuration Control Plan with Navy Sponsor.

Configuration ManagementRSN APL Experience

APL Configuration Control Experience

• Agreed to as part of design contracts with sponsor and ongoing operation and maintenance contracts.

• Sponsor takes very active role in Configuration Control Process.



• Configuration Control Board (CCB)– Sponsor

• Configuration Control Review Board (CCRB)– Sponsor– Design agent (APL) – Consultants designated by sponsor



• Level 1 Change – Impacts funding– Change must be approved by CCB– Printed Circuit Board revisions– System wide changes

• Level 2 Change – No funding impact– Change must be approved by CCRB– Documentation corrections– Replace obsolete parts



• Items Under Configuration Control

• All build documentation including– Engineering Drawing Packages– Software at Source Code Level– System Configuration Documentation– Technical Manuals



• Configuration Control Plan

• Documents entered into CCP after CDR.• First part of First Article Test is physical

configuration audit.– Done by design agent under supervision of sponsor

• Second part is testing to specifications• After passing both, system is ready for

production



• Reasons a Change Request is Initiated

• Part obsolesces• Test failure• Feature request• Documentation discrepancies



• Configuration Control Plan

• Sponsor or Design Agent can submit Engineering Change Proposals.

• Engineering Change Proposals become Engineering Changes after approved.

• CCP Ongoing Process – (not scheduled meeting times)



Example Experience with 3rd Party Design Contract• $6 million (1990) outside development contract

with DataTape to build a 19” format- high data rate custom recording system.

• 20 units purchased at $300K each.• Managed contract, specifications and detailed

ICD.• Extensive environmental and EMI testing

performed.• Physical configuration audits.



• System Quality Assurance (QA)• Hardware QA• Software QA• User QA• Summary

System Quality Assurance (QA)

System Quality Assurance (QA)• Consultant to coordinate QA activities at IOs• Consultant a direct report to Ocean Leadership/JOI Div President• Consultant, SE and COTRs will work with IOs to ensure quality • Consultant and COTRs will ensure QA presence during design,

development, manufacturing, deployment, use, maintenance, service and Commissioning of OOI systems

• QA main focus will be on QA systems and integrated system tests– Software Integration and Test– Software Acceptance Test– Hardware inspection, test and acceptance– Hardware, Software and Communications System Acceptance Test– Telecommunications testing– User testing

• Leads to Commissioning

Hardware QA• Systematic

– Integrates QA and QC functions • Requires management commitment• QA actions are documented in Quality plans,

policies, procedures and records of audits and inspections

• QA is customer focused • Starts in the design phase• QA ensures flow down of QA requirements to

partners, subcontractors and suppliers

• QA verifies the Quality of purchased and manufactured components

• Evaluates subcontractors • QA verifies manufactured items to drawings,

documentation, processes and procedures• Evaluates calibration programs• Identifies and segregates materials and equipment

purchased for the OOI• QA assists with planning for design, development,

production, test and installation and use of OOI hardware

Hardware QA

• QA is a member of the Change Control Board (CCB)

• QA focus is on measurement, analysis and improvement

• Customer satisfaction is ultimate concern• QA verifies compliance for OOI property• Performs independent audits of processes and

product• Initiates corrective and preventive action• Controls disposition of nonconforming product• Leads to Commissioning

Hardware QA

Software QA (SQA)• SQA is systematic• Documented with Plans and Procedures• Focus is on defect density, containment and improvement • CI to implement a Quality Performance Index (QPI) “to serve

as a predictive indicator of the program’s final quality”• Four QPI Indicators

– Overall Product Quality status– Development Process Quality status– Customer Satisfaction Ratings– Contract Compliance

• SQA performs audits• SQA monitors defined processes

SQA• SQA emphasis on process and improvement• Requests corrective and preventive action• Focus is on software design, development and testing

– Software Integration and Test– Hardware and Software System Integration and Test– OOI System Acceptance

• Leads to Commissioning

CI Software Experience

CI Software QA• Currenex (Arrott was VP Product Development)• Regression test on a daily basis• QA Team manually tested code as early in a release

cycle as possible (<= 0.5)• Expose code to end users for validation of

functionality and further ID of defects 2 week prior to release

• Defect list maintained on a daily basis• Final testing in production environment for two weeks

Requirements Management


Traceability Matrix

CI-SR385 The OOI CI shall support remote detection of events OOI System Requirements DocumentSRD464Through a unifying Cyberinfrastructure, researchers will control sampling strategies of experiments deployed on one part of the infrastructure in response to remote detection of events by other parts of the infrastructure.

CI-SR386 The OOI CI shall enable researchers to control sampling strategies based on detected events

OOI System Requirements DocumentSRD464Through a unifying Cyberinfrastructure, researchers will control sampling strategies of experiments deployed on one part of the infrastructure in response to remote detection of events by other parts of the infrastructure.

ID ReqID

CI System Requirements Out-links

CI-SR63 PI-07 Availability-the CI shall be available on a 24/7/365 basis with no more than xx downtime

CI-CGSN Interface AgreementCI-CG20The satellite and other wireless links between moorings, ships and shore shall be available xx% of the time. Regardless of link availability the system goal is 0% scientific data loss. CI-RSN Interface AgreementCI-R21The backhaul shall have at least 99.99% availability.

CI-SR104 II-01 The CI shall verify and validate the identity of all resources connected to an OOI observatory

CI User RequirementsCI-UR208The CI shall support distributed resources and actors

<= DOORS Module

<= DOORS Module

<= DOORS Module

<= DOORS Module

<= DOORS Module

CI System Requirements Traceability Report (Out-links to Parent Modules)


OOI will enable powerful new scientific approaches by transitioning the community fromexpedition-based data gathering to persistent, controllable observations from a suite ofinterconnected sensors.

The OOI shall enable persistent, controllable observations from a networked sensor grid

The CI shall support distributed resources and actorsAll resources connected to an OOI observatory shall beidentifiable, authenticatable, authorizable and auditable

COI Identity and Policy Management ServicesAll resources connected to an OOI observatory shall be discoverable by the CI either directly, by content or throughtheir associated metadata

COI Resource Catalog and Repository ServicesDM Data Catalog and Repository Services

The CI shall provide a standard mechanism to manage stateful resources

S&A Instrument Management ServicesS&A Marine Resource Scheduling ServicesCOI Federated Facility ServicesCEI Resource Management Services


Example

Systems Engineering V Model

* Subsystems are:• Regional Observatory• Global Observatory• Coastal Observatory• Cyberinfrastructure

= Requirements Links (flowdown)

= Verification Links

Science Questions


OOI System Requirements

OOI Test Procedures & Cases

Sub-System* Requirements




Sub-System* Test Procedures & CasesSub-System* Test Procedures & CasesSub-System* Test Procedures & CasesSub-System* Test Procedures & Cases

Acceptance Test Procedures & Cases

Element Test Procedures & Cases






Element RequirementsElement RequirementsElement RequirementsElement RequirementsElement RequirementsElement Requirements

Final Commissioning

Construction

Decom

position /Definition In

tegr

atio

n

Validation

Verification

Verification

(A DOORS module view rather than a process view)


Software Testing, Acceptance, Commissioning

• In the DOORS representation of the Systems Engineering V– Boxes correlate to DOORS modules (and infer processes)– Arrows correlate to DOORS traceability links

• The Systems Engineering “V” Model is an excellent representation of the system life cycle

– Decomposes the system down the left side (requirements & design)– Implementation & construction at the bottom– Integration & testing (I&T) of the components up the right side

• During I&T each layer is verified independently prior to integration into the next higher layer

– Coding & Unit Testing (CUT)– Software Integration and Test (SWIT)– Factory Acceptance Test (FAT)– Formal Qualification Testing (FQT)


System Testing, Acceptance, Commissioning

System Testing• Category I: Dry Test

– initial subsystems components– connections or simulated connections to the OOI– data will be captured and stored– confirmation that there are no remaining design changes– ready for manufacture of the balance of the components

• Category II: Wet Test– subsystem components tested in Stage 1 tested in a wet environment– as similar to the deployment site as practicable– water tanks and/or near shore testing

• Category III: Deployment and Commissioning Test– incorporate all lessons learned from the Stage I and Stage II– represents the primary infrastructure baseline– Full Operational Capability (FOC) is achieved at completion

Requirements Verification Testing

DOORS Database Hierarchy

Traceability Matrix

CI-SR385 The OOI CI shall support remote detection of events OOI System Requirements DocumentSRD464Through a unifying Cyberinfrastructure, researchers will control sampling strategies of experiments deployed on one part of the infrastructure in response to remote detection of events by other parts of the infrastructure.

CI-SR386 The OOI CI shall enable researchers to control sampling strategies based on detected events

OOI System Requirements DocumentSRD464Through a unifying Cyberinfrastructure, researchers will control sampling strategies of experiments deployed on one part of the infrastructure in response to remote detection of events by other parts of the infrastructure.

ID ReqID

CI System Requirements Out-links

CI-SR63 PI-07 Availability-the CI shall be available on a 24/7/365 basis with no more than xx downtime

CI-CGSN Interface AgreementCI-CG20The satellite and other wireless links between moorings, ships and shore shall be available xx% of the time. Regardless of link availability the system goal is 0% scientific data loss. CI-RSN Interface AgreementCI-R21The backhaul shall have at least 99.99% availability.

CI-SR104 II-01 The CI shall verify and validate the identity of all resources connected to an OOI observatory

CI User RequirementsCI-UR208The CI shall support distributed resources and actors

<= DOORS Module

<= DOORS Module

<= DOORS Module

<= DOORS Module

<= DOORS Module

CI System Requirements Traceability Report (Out-links to Parent Modules)

Systems Engineering V Model

* Subsystems are:• Regional Observatory• Global Observatory• Coastal Observatory• Cyberinfrastructure

= Requirements Links (flowdown)

= Verification Links

Science Questions


OOI System Requirements

OOI Test Procedures & Cases





Sub-System* Test Procedures & CasesSub-System* Test Procedures & CasesSub-System* Test Procedures & CasesSub-System* Test Procedures & Cases

Acceptance Test Procedures & Cases







Element RequirementsElement RequirementsElement RequirementsElement RequirementsElement RequirementsElement Requirements

Final Commissioning

Construction

Decom

position /Definition In

tegr

atio

n

Verification

Validation

Verification

(A DOORS module view rather than a process view)

Testing, Acceptance, Commissioning• In the Dynamic Object Oriented Requirements System (DOORS)

representation of the Systems Engineering V– Boxes correlate to DOORS modules (and infer processes)– Arrows correlate to DOORS traceability links

• The Systems Engineering “V” Model is an excellent representation of the system development life cycle

– Decomposes the system down the left side (requirements & design)– Implementation & construction at the bottom– Integration & testing (I&T) of the components up the right side

• During I&T each layer is validated independently prior to integration into the next higher layer

– Coding & Unit Testing (CUT)– Software Integration and Test (SWIT)– Factory Acceptance Test (FAT)– Formal Qualification Testing (FQT)

• Defined + Verified = Complete

• Reduce risk: verify all at the lowest level (earliest time) possible

• Eliminate redundant testing– Track requirements verified at lower levels – No need to repeat at higher levels

Testing, Acceptance, Commissioning

CGSN Electrical Subsystem Verification Testing to Requirements

• Power Systems – Tested under load for energy production specification – Verification of "reduced" and "minimal" power configurations – Load and Thermal cycled to simulate use

• Communications System – Verification of throughput and power efficiency of each satellite

link – Thermal Cycling

• Controllers – Design qualification of COTS– Thermal cycling– Burn in

C/GSN Testing Experience

CGSN Integration & Testing• Wet Subsystem Verification Tests

– Mooring component pull tests– Wire shot laser length measurement– Electrical leakage testing in seawater – all wet components– Pressure tests of 1 atmosphere housings

• Burn-in, Pre-Installation Integration Test– Complete mooring assembled and run in water off WHOI dock– Buoy and instrumentation run outdoors for several weeks, using

telemetry links• Test Deployment

– Southern Ocean 55 S mooring group to be deployed in North Atlantic for minimum of 3 winter months

• Installation Test– All systems and instruments queried for functionality using acoustic and

R/F telemetry links. Nonfunctional systems recovered, repaired, and re-deployed

C/GSN Testing Experience

ScheduleL e g en d

D esign /D eve lopm ent

B u ild /M anufactu reIm plem enta tionTest/Deploy/Com m iss ion

Q1 Q2 Q 3 Q4 Q 1 Q2 Q3 Q 4 Q1 Q2 Q3 Q4 Q 1 Q2 Q3 Q4 Q1 Q 2 Q3 Q4 Q 1 Q2 Q 3 Q4

C y ber infra stru ctu re R-1 Data M g m t, D is t an d C o ntrolR -2 M anag ed Data Acq uis itio n

R-3 In teg ra ted D ata An alyticsR-4 In teg ra ted M o d eling Netw o rk

R -5 Interact ive Ob servato ry S ys

C I M arine In tegrationC I / C oas ta l In tegra tion CI / RS N In teg rat ionC I / G loba l In teg ra tion

Exter nal Ob servator y Integ ra tio n - Nep tu ne-C an ad a , IO OS, W M O/IOC

C o as ta l S c a le O b serva to ry Deve lo p m ent CS NDetail Des ign & S E - Endurance A rray, Cen tra l O regon L ineDetail Des ign & S ystem s Eng - P ioneer Ar ray - M idd le Atlan t ic Bigh t

Im p lem en ta tion CS NEndurance A rray - C en tra l O regon L ine

P ioneer Ar ray - M idd le A tlan t ic Bigh t / Ou te r Con tinen ta l S he lf

R e g io n a l S cale O b se rva to ry Deve lo p m ent RS NBackbone C ables

W arre n ton Sh ore S ta

P acific C ity Sh ore S ta

Detail Des ign , Low V oltage Node / J B oxPrim ary / Secondary N odes

M oor ing D esignS econdary Cab le

S ensor D esignIm p lem en ta tio n RS NBu ild -ou t W arren ton SS In sta ll B B C bl Bu ild LV Node / J B ox Insta ll / C om m iss ion LV Nodes / J BoxBu ild -ou t P ac if ic C ity S S Bu ild Pr i / S ec N odes Insta ll / C om m iss ion Pr i / Sec Nodes

M ooring M anufactu re M ooring Install

S enso r Im p lem en ta tion

G lo ba l S c a le O bs e rva to ry Deve lo p m ent GS NDetail Des ign & S ys E ngSta tion PapaIrm inge r SeaSou the rn Ocean 55 ºS

Im p lem en ta t io n G S NSta tion PapaIrm inge r Sea

S outhe rn Oc ean 55 ºS

Secondary C able A ssem b le / TestSensor In teg ra t ion / T est

S ystem Accep t Test

Jul 1

1S

ep 1

1

Jul 1

3S

ep 1

3

Jul 1

2Se

p 12

Jul 1

0Se

p 10

Jul 0

9S

ep 0

9

FY 2012 FY 2013FY 2008 FY 2009 FY 2010 FY 2011

Jul 0

8S

ep 0

8

Network Integration Dec 5 1900 - rev F - Ocean...

Documents

Transcript of Network Integration Dec 5 1900 - rev F - Ocean...