ncsx systems engineering management plan peer review bob simmons may 15, 2003

NCSX NCSX Systems Engineering Systems Engineering

Management Plan Peer Management Plan Peer ReviewReview

Bob Simmons

May 15, 2003

May 15, 2003 2

NCSX Data Management Plan NCSX Data Management Plan Peer ReviewPeer Review

Review Committee– Charlie Neumeyer, Chair– Bob Simmons, Cog– Wayne Reiersen, RLM– Judy Malsbury– Mike Williams– Larry Dudek– Brad Nelson

May 15, 2003 3

Review ObjectivesReview Objectives Have the appropriate systems been established for

the implementation of an effective systems engineering management program for NCSX?

Do these systems provide an appropriate level of detail, yet are sufficiently flexible to meet the tailored approach philosophy for NCSX ,including the work being accomplished at ORNL?

What plans are in place to train the NCSX personnel in the various systems engineering programs and systems (e.g., configuration management, interface control, document management, etc.)? Still work in Progress

May 15, 2003 4

Relationships to Other NCSX Relationships to Other NCSX Plans and ProceduresPlans and Procedures

The NCSX NCSX Systems Engineering Management Plan (SEMP) is consistent with the requirements of the Project Execution Plan (PEP) and the Quality Assurance Plan (QAP)

The SEMP is the top-level engineering plan and all other NCSX Engineering Project Plans support and expand the programs and systems outlined in the SEMP

– Configuration Management Plan (CMP)– Interface Control Management Plan (ICMP)– Data Management Plan (DMP)– Document and Records Plan (DOC)– Pro/INTRALINK Users Guide

May 15, 2003 5

Systems Engineering (SE) is Systems Engineering (SE) is Central to the NCSX Central to the NCSX

Engineering ProcessesEngineering Processes

Defines the processes for technical planning and control

Defines the systems engineering processesDefines the engineering specialty integration

processes

May 15, 2003 6

How Does the Systems How Does the Systems Engineering Program Fit?Engineering Program Fit?

ORNL has committed to follow NCSX plans and procedures

Unless specifically modified or supeceded by NCSX-specific plans and procedures, NCSX is committed to following existing DOE and PPPL plans and procedures– In no instances are the NCSX plans and procedures in

conflict or a dilution of the existing PPPL plans and procedures

– Where NCSX is more rigorous, specific note will be made

May 15, 2003 7

Technical Program Planning Technical Program Planning and Controland Control

Work Breakdown Structure (WBS) provides the overall architecture for the systems engineering work– NCSX team structure has been aligned with the WBS

NCSX Engineering Manager has overall responsibility for implementing the SE program on NCSX– Systems Engineering Support Manager and Design

Integration Manager provide staff support to the Engineering Manager

May 15, 2003 8


Four Project Engineers report directly to the Engineering Manager in the line organization– Stellarator Core (WBS 1)– Ancillary Systems (WBS 2-6)– Assembly Operations (WBS 7)– Operations (Testing, Ops and Maintenance

Procedures, Prep for Ops)

May 15, 2003 9


Systems Integration Team (SIT)– Consists of project personnel to facilitate integration of

project work– Provides a forum for discussion of requirements

interpretations, potential areas of risk, system level trade studies, coordination of processes, and resolution of issues

– Intended to facilitate obtaining decisions through line management that are best for the project as a whole

May 15, 2003 10


Work is organized Work is planned and costs and schedules are

estimated and integrated– Use of SEML more rigorous during design process than

existing PPPL procedures (e.g., WP as specified in ENG-032)

– WP will govern any site work

Work is authorized Work is tracked

May 15, 2003 11

Work Authorization ProcessWork Authorization ProcessT h e jo b es tim ate is a b r ie f n ar r a tiv ed es c r ip tio n o f w o r k to b e p er f o r m edan d a jo b p lan id en tif y in g a ll ac tiv it iesin c lu d in g th e ir

lo g ic a l s eq u en c etim e d u r a tio n sr es o u r c e r eq u ir em en tslin k ag es to o th er ac tiv it iesm iles to n es an d d e liv er ab les

R eq u ir esM o d if ic a tio n to an

E x is tin g S y s teman d /o r F ac ility ?

P r ep ar e a J o b E s tim ate( J o b M an ag er )

As s ig n J o b N u m b er & E n terD ata I n to P 3 D atab as e

( N C S X P C M )

G en er a te W AF( N C S X P C M )

W AFAp p r o v ed ?

R ev is eW AF

Yes

G en er a te W o r kP lan n in g D o c u m en t

p er E N G - 0 3 2Yes

S tar t W o r k( J o b M an ag er )

N o

N o

P C M - P r o jec t C o n tr o l M an ag er

P r ep ar e S E M L( E n g in eer in g M an ag er )

May 15, 2003 12

Cost Performance ReportingCost Performance Reporting

O R N L L ab o r an dM & S Ac tu a ls /Ac c r u a ls

( AC W P )( O R N L P C M )

P P P L L ab o r( T im es h ee ts )

P P P L M & SAc tu a ls /Ac c r u a ls

( N C S X P C M o r I n v o ic es )

P P P L Ac c o u n tin gS y s tem

J o b C o s t R ep o r ts( AC W P )

M o n th ly S ta tu s M eetin g( 1 ) J o b % C o m p le te b y T as k( 2 ) J o b C h ar g es( 3 ) E s tim ate to C o m p le te( 4 ) P r o b lem Ar eas an d R ec o v er y P lan s

P 3 D atab as e

P P P L AC W PAC W PO R N L AC W P

BC W P ( ear n ed v a lu e) ,BC W S , AC W P

M o n th ly C o s t P er f o r m an c e R ep o r tC o s t Var ian c e ( BC W P - AC W P )S c h ed u le Var ian c e ( BC W P - BC W S )E s tim ate to C o m p le te ( E T C )P er f o r m an c e C u r v esS ta tu s ed S c h ed u le Bar C h ar t

L eg en dP C M - P r o jec t C o n tr o l M an ag erAC W P - Ac tu a l C o s t o f W o r k P er f o r m edBC W P - Bu d g eted C o s t o f W o r k P er f o r m ed ( ear n ed v a lu e)BC W S - Bu d g eted C o s t o f W o r k S c h ed u leP 3 - P r im av er a P r o jec t P lan n in gC P R - C o s t P er f o r m an c e R ep o r t

May 15, 2003 13

NCSX Project CycleNCSX Project Cycle

S ubs ys te m

C o nfig ura tio n Ite m (C I)

D O E C rit ica l D e cis io n s A ppro v e M is s io n Ne e dC D -0

A ppro v e B a s e lin e R a n g eC D -1

A ppro v e Pe rfo rm a n ce B a s e lin eC D -2

A ppro v e S ta rt o f C o n s tru ct io nC D -3

Pre -C o n ce ptu a l D e s ig n C o n ce ptu a l D e s ig n Pre lim in a ry D e s ig n Fin a l D e s ig nFa brica t io n , A s s e m bly ,I n s ta lla t io n , a n d Te s t O pe ra t io n s

C D RPV R O R AD O E R e v ie ws

A ppro v e S ta rt o f O pe ra t io n sC D -4

S y s temS p ec if ic a tio n ( G R D )

M is s io nR eq u ir em en ts

De c om

p o s it io n &

De fin ition

S y s tem C o n c ep t D ef in it io n

S u b s y s tem S p ec if ic a tio n

F u n c tio n al A llo ca tio n

S u b s y s temC o n c ep tD ef in it io nF u n c tio n al Allo c atio n

C I C o n c ep tD ef in it io n

"D es ig n - to " s p ec if ic a tio n sp u t u n d er c h an g e c o n tr o la t C I P D R s

C I "D es ig n - to "S p ec if ic a tio n s

C IP D R

C I "Bu ild - to "D o c u m en ta tio n

C IF D R

C I D eta iledD es ig n

C IF ab /A s s y /T es t

I n teg ra tedS y s tem sT es tin g

Su b s y s t emT es t in g

S u b s y s temT R R

I n teg ra tio n

S y s temT R R

S y s tem v er if ic a tio n p lan sb as e lin ed in P D

Inte

g ra t

ion &

Ver

ifica

tion

I n teg ra tio n

C I v er if ic a tio n p lan sb as e lin ed a t C I P D R

"Bu ild - to " d o c u m en ta tio np u t u n d er c h an g e c o n tr o la t C I F D R s

Ph a s e

C o n ce pt B a s e lin e Fu n ct io n a l B a s e lin e A llo ca te d o r " D e s ig n - to "B a s e lin e

" B u ild- to " B a s e lin e Pro du ct o r " A s -bu ilt"B a s e lin e

L e g e n dPV R - Ph y s ics V a lida t io n R e v ie w, C D R - C o n ce ptu a l D e s ig n R e v ie w, O R A - O pe ra t io n a l R e a din e s s A s s e s s m e n t , TR R - Te s t R e a din e s s R e v ie w,PD R - Pre lim in a ry D e s ig n R e v ie w, FD R - F in a l D e s ig n R e v ie w

S ys te m

May 15, 2003 14

Requirements Documentation Requirements Documentation HierarchyHierarchy

S y s temR eq u ir em en ts

"D es ig n - to "R eq u ir em en ts

"Bu ild - to "R eq u ir em en ts

BUI L D E R S P r o d u c t/S er v ic e

May 15, 2003 15

Specification TypesSpecification TypesSPECIFICATION PURPOSE SYSTEM • Establishes the requirements for the system/project and characteristics of

lower level WBS elements. The GRD will be the system specification. DEVELOPMENT (“Design to”)

• Allocation of development requirements to the subsystem and CI from the GRD specification (e.g., to SRDs and then to lower level CI’s)

• Defines the methods used to verify the requirements have been met PRODUCT (“Build to”)

• Defines product acceptance requirements

PROCESS • Prepared for manufacturing techniques that require a specific procedure in order that a satisfactory result may be achieved.

MATERIALS • Prepared to control the development of a material.

May 15, 2003 16

Systems Engineering Systems Engineering ProcessesProcesses

Design Definition and Integration– Point where a design concept is created to satisfy a given

set of requirements– Includes evaluation of alternatives– Eventually culminates in a final design for the entire

NCSX Risk Management

– Responsibility lies with NCSX line management– SIT will facilitate the identification of areas of risk,

coordinating the development of risk mitigation plans, and the monitoring of performance against those plans

May 15, 2003 17


System Build– Starts with a concept and evolves in detail until the

system is constructed and ready for integrated systems testing

– Naturally an extension of the requirements analysis and design tasks for all components and subsystems

– Intend to utilize construction techniques familiar to PPPL technicians

System Test and Verification– Combination of inspection, demonstration, test, and

analysis techniques

May 15, 2003 18


Configuration Management, Interface Control, and QA already subject of peer reviews

Design Reviews– External design reviews conducted by DOE in

support of Critical Decision milestones– Internal design reviews scheduled and planned

in accordance with ENG-033 – usually at the subsystem level

May 15, 2003 19

Engineering Specialty Engineering Specialty IntegrationIntegration

Reliability, Availability, and Maintainability (RAM) – RAM Plan will be prepared prior to final design

review

Value Engineering/Management (VE/VM)– Will apply to NCSX using a graded approach– Already have implemented several VE/VM

studies

May 15, 2003 20


Parts, Materials, and Process Standardization and Control– Plan to develop a Master Parts List and

Vacuum Materials List – by time of PDR

Manufacturability– Manufacturing, Inspection, and Test Plan

(MITP) shall be produced for each configuration item

May 15, 2003 21


Constructability– Under the leadership of the Assembly Operations

Project Engineer, although all WBS Managers have this responsibility

Space allocations Access for assembly Required assembly sequence Early identification and mitigation of constructability issues Design features to reduce construction costs

Training– Safety and project-specific

May 15, 2003 22


Technical Publications (O&M Manuals, etc.)– Electronic or hard copy data bases available

(depending on material)

ES&H– ISM policies and practices followed– ES&H review of technical documentation

throughout the life of the project

May 15, 2003 23

SEML (PROC-004)SEML (PROC-004)

The Systems Engineering Master Logic is the key planning document during the design phase– Defines the logic for design development and the

necessary activities and deliverables for the Preliminary and Final Design Reviews

– Used as guide when developing the WAFs

Work Planning (WPs) shall be used for planning all field work, including on-site R&D during the design phases

May 15, 2003 24

SEML (PROC-004)SEML (PROC-004)

This procedure lays out the process for– Identifying configuration items (CI) and for

aligning the specifications, design reviews, and acquisition plans with that CI

– Developing the SEML (generic example) for both Preliminary and Final Design Reviews

May 15, 2003 25

Item Requirement Success Criteria Configuration Identification

Identify configuration items (CIs). Include software, support equipment, and tooling. Align specifications, design reviews, and acquisition plans with CI identification. Acquisition plans should address build v. buy issues.

Spec tree, design review schedule, and acquisition plans updated and posted on Web. Project detailed schedule updated by PC Mgr.

Specifications Performance requirements are finalized and documented in approved development ("design-to") specifications , which are under change control. No TBDs allowed.

Approved specification(s).

Design vs. Requirements Document design approach. Demonstrate how the design concept satisfies requirements and design constraints in the relevant development specifications.

Documented in Design Basis Document prior to PDR. Approved by cognizant Project Engineer.

Resolution of Design Recommendations

Document resolution of chits from prior design reviews. Resolution of chits from prior design reviews documented on Web. Action items completed.

Interface Identification Signed scope sheets for all primary interfaces. No TBDs allowed. Approved by Systems Engineering Support Manager

Signed ICDs for all primary interfaces. TBDs allowed with closure plans. Approved by Systems Engineering Support Manager

Models and Drawings Sufficient drawings to support developmental design and analytical evaluation of the inherent ability of the design to attain the required performance. The drawings shall be sufficient to develop manufacturing approaches and cost estimates. All models and drawings promoted to Preliminary Design Release. Drawings shall be provided which define where the equipment will be located in the facility. Preliminary Design Release models and drawings should form a self-consistent package and provide the basis for cost and schedule estimates.

Models and drawings approved for promotion by the cognizant Project Engineer

Develop a drawing tree with at least enough detail to identify all components necessary to support final design and production planning.

Approved by the cognizant Project Engineer

May 15, 2003 26

Item Requirement Success Criteria Analysis Design criteria to establish limits for acceptability are in place. Sufficient analysis shall

be provided to establish that the proposed design is feasible and meets established design criteria. Analyses must be documented in an auditable way – in analysis reports, not viewgraph presentations. The following analyses shall be accomplished as appropriate: structural, thermal, seismic, eddy current, radiation, and circuit analyses. Other analyses shall be included as appropriate.

Design criteria documented. Material properties characterized and documented. Analysis reports reviewed by cognizant Project Engineer, summarized in Design Basis Document.

Manufacturability Provide evidence (if necessary) from R&D activities that the design is manufacturable and has been optimized for manufacturability.

Manufacturing studies conducted as appropriate and results documented in Design Basis Document.

Qualification and Acceptance Testing

Qualification and acceptance test plans consistent with verification requirements in the development specifications. Identify when these tests would be performed. These plans provide the basis for subsequently developing test procedures.

Qualification and acceptance test plans documented and approved.

Constructability Document plans for assembly, installation, and test. Provide evidence that risk-related issues have been satisfactorily addressed. These plans provide the basis for subsequently developing assembly, installation, and test procedures.

Assembly, installation, and test plans documented and approved.

Value Engineering Determine what design areas would likely benefit from additional value engineering at the beginning of Preliminary Design. Conduct and document results of value engineering studies (if any).

Results of value engineering studies (if any) documented in Design Basis Document.

RAM Provide FMECA per ENG-008 identifying potential failure modes and recovery provisions. Explain how design has been optimized for reliability, maintainability, and safety through systematic evaluation of design options and application of proven design approaches.

FMECA documented. Summary of findings and design recommendations provided in Design Basis Document.

May 15, 2003 27

Item Requirement Success Criteria ES&H Provide a hazard analysis that address the following:

1. Descriptions of the environment, safety and health (ES&H) features of structures, systems and components, as applicable. 2. Identification of hazards associated with anticipated operation of the structure, system or component and methods employed for their mitigation. 3. Some description of the ES&H aspects of operations, e.g., access controls, setting of hardwired interlocks, operator actions, etc. The depth of the discussions of these topics should be commensurate with the potential severity of the specific hazards, and with the maturity of the designs. The hazard analysis report should address ES&H issues identified in the FMECA. Review existing NEPA documentation. Submit new NEPA Planning Form if new hazards are identified.

Report documenting hazard analysis. Approved by NCSX ES&H Manager.

COTS and Legacy Equipment

Identify use of COTS commercial, off-the-shelf (COTS) or legacy equipment. Describe plan for testing the performance of legacy equipment.

Documented in Design Basis Document.

Human Engineering Demonstrate that sound human engineering principles have been followed in the design. Documented in Design Basis Document.

Standardization Considerations

Identify how design has been optimized for standardization, including a list of standardized components


Software and Firmware Identify and describe all planned software and firmware, including the functional requirements allocated to them, how they will be validated and verified. (May be part of a MITP).


Preliminary Weight and Size Data

Demonstrate that weight and sizes are compatible with structural supports and size constraints


Risk Management Identify areas of significant risk and mitigation plans Documented in Design Basis Document.

Baseline Maintenance Update cost and schedule estimates in P3 database consistent with proposed technical baseline as defined by Preliminary Design Release Level models and drawings and other documentation. Cost and schedule updates should generally be of a higher quality than the prior estimate with increased input from industry.

Approved by the cognizant Project Engineer. Coordinated with Engineering Manager. Incorporated in P3 database by Project Control Manager.

Provide input to omnibus ECP to reflect proposed changes to the technical, cost, and schedule baselines. ECP will be processed after chits that have significant design, cost, or schedule impacts have been addressed. New baselines will be established upon approval of ECP and implementation of approved changes.

Approved by the cognizant Project Engineer. Coordinated with the Engineering Manager.

May 15, 2003 28

Questions?Questions?

ncsx systems engineering management plan peer review bob simmons may 15, 2003

Documents

ncsx engineering processes

ncsx plans

systems engineering

systems engineering

wbs ncsx engineering

ncsx personnel

engineering manager

ncsxspecific plans