View
3
Download
0
Category
Preview:
Citation preview
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.
APL Configuration Control Experience
Configuration ManagementRSN APL Experience
• Configuration Control Board (CCB)– Sponsor
• Configuration Control Review Board (CCRB)– Sponsor– Design agent (APL) – Consultants designated by sponsor
APL Configuration Control Experience
Configuration ManagementRSN APL Experience
• 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
APL Configuration Control Experience
Configuration ManagementRSN APL Experience
• Items Under Configuration Control
• All build documentation including– Engineering Drawing Packages– Software at Source Code Level– System Configuration Documentation– Technical Manuals
APL Configuration Control Experience
Configuration ManagementRSN APL Experience
• 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
APL Configuration Control Experience
Configuration ManagementRSN APL Experience
• Reasons a Change Request is Initiated
• Part obsolesces• Test failure• Feature request• Documentation discrepancies
APL Configuration Control Experience
Configuration ManagementRSN APL Experience
• 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)
APL Configuration Control Experience
Configuration ManagementRSN APL Experience
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.
APL Configuration Control Experience
Configuration ManagementRSN APL Experience
• 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
CI Software Experience
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)
CI Software Experience
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
CI Software Experience
Example
Systems Engineering V Model
* Subsystems are:• Regional Observatory• Global Observatory• Coastal Observatory• Cyberinfrastructure
= Requirements Links (flowdown)
= Verification Links
Science Questions
OOI Science User Requirements
OOI System Requirements
OOI Test Procedures & Cases
Sub-System* Requirements
Sub-System* Requirements
Sub-System* Requirements
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 Test Procedures & Cases
Element Test Procedures & Cases
Element Test Procedures & Cases
Element 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)
CI Software Experience
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)
CI Software Experience
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 Science User Requirements
OOI System Requirements
OOI Test Procedures & Cases
Sub-System* Requirements
Sub-System* Requirements
Sub-System* Requirements
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 Test Procedures & Cases
Element Test Procedures & Cases
Element Test Procedures & Cases
Element Test Procedures & Cases
Element 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
Recommended