National Ignition Facility Sub-System Design Requirements

UCRL.-ID-126981Rev 2

National Ignition FacilitySub-System Design Requirements

Supervisory Control SoftwareSSDR 1.5.2

J. WoodruffP. VanArsdall

E. Bliss

August 29,1996

This is an informal report intended primarily for internal or limited ●xternal 1

distribution. The opinions and conclusions stated are those of the ●uthor ●nd7

may or may not be those of the Laboratory.

Work performed under the auspices of the U.S. Department of Energy by the \Lawrence Livermore National Laboratory under Contract W-740S-Eng-4S. \

DIWLAIh4ER

This documentw=_d~m=~t &w*~tibymqy dti Utiti%*ti~ t. Neitherthe UnitedStateaCovernmelltw theuNveraityofcawlllh noranyoftheiremployees,makesanywarranty,e-orimplid or asaume6anylegalliabilityor respomibilityfor theaccuracy,com letenesa,or tmefulneaaof any

#d notinfr@e @V&ltelyOwnedinformati~apparatua,product,or proceaa diacl~ or represmta that ita uae wrights. Refercmce herein to any specific commercial product proceaa, or service by trade name, trademark,mamfachwer, or othewhe, doaanotnamaamd“y Constituteor imply ita endorsement mcommm datiq or fWOX@ bythe unitedStateaGovermnen torthe UnhraityofCdiforrda. ‘Ihe Viewaandopinions ofauthorsexpmsad hereindonot necewmily state or retlect those of the UNted States Government or the University of Califcm@ and shall not beWed for A%4aing or product endorsement pqoaes.

-IlliaXeporthaabaenreproduceddirectly fromthe best avaUable copy.

Available to DOE and DOE contractors tkm theOffice of Scienti6c and Techdcal Information

P.o.Box 62, M Ridge, TN 37831Prices available from (615) 57@3401, FE 626-MOl

Available tothe pUtiiCfromtheNational Technical Information Service

U.S. Department of Commerce5285Port Royal Rd.,

S@ngfiel~ VA 22161

NIF-0000138-02WBS 1.5.2

National Ignition Facility

Sub-System Design Requirements

Supervisory Control Software

SSDR 1.5.2

Revision 229 August 96

Prepared by:

J. Woodruff, Supervisory Software Team Leader

P. VanArsdall, Integrated Computer ControlsLead Engineer

E. Bliss, System Controls System Engineer

Special Equipment Engineering Approval:

R. Sawicki, NW Associate Project Engineer

Engineering Review Board Approval:

S. Kumpan, NIF Projeet Engineer

ApprovalDate

W(ad(fu

1

,

NIP - SSDR 1.5.2- Sumxvisow Control Software Subsystem Design Requirements Revision 2

*

Pa ragraDh1.02.02.12.22.32.42.52.63.03.13.1.13.1.23.1.33.1.3.13.1.3.23.1.43.1.53.2.003.2.013.2.023.2.033.2.043.2.04.13.2.04.23.2.04.33.2.053.2.063.2.073.2.083.2.093.2.103.2.113.2.12

-3.2.133.2.143.2.153.2.15.13.2.15.23.2.15.33.2.15.43.2.15.53.2.163.2.173.43.4.16.0

Table of Contents

TitlescopeApplicableDocumentsApplicableNIP ProjectDocumentsApplicable US Government Orders and StandardsApplicable National Consensus Codes and StandardsApplicable LLNL StandardsSupporting Documentation StandardsReferencesRequirements and Verification v

System DeftitionSystem DescriptionSystem FunctionsSystem DiagramsSupervisory Software Relationship to PEP SoftwareSupervisory Control and PEP Software HierarchySystem InterfacesMajor Subsystems, Supervisory Control Software- WBS 1.5.2Supervisory Control Software, Functional RequirementsSupervisory Control Software, Application SoftwareSupervisory Control Software, Look and FeelSupervisory Control Software, GUI ApplicationSupervisory Control Software, Software LanguagesSuperviso~ Control Software, Standard Software Language, AdaSupervisory Control Software, Secondary Software Language, C/C++Supervisory Control Software, QA Level RequirementsSupervisory Control Software, Machine InterlocksSuperviso~ Control Software, Hardware PlatformSupervisory Control Software, On-line ConfigurationSupervisory Control Software, Diagnostic Suite DeftitionSuperviso~ Control Software, Pre-Shot RequirementsSupervisory Control Software, Shot Time RequirementsSoftware Requirements Specification (SRS)Supervisor Control Software, Access to Distributed Control PointsModes of Operation, Segmented and Concurrent OperationSupervisory Control Software, Documentation and ManualsLifetime, Replaceability, Reliability, Availability, MaintainabilityLifetimeReplaceabilityReliabilityAvailabilityMaintainabilityRecovery From Abnormal EventHuman FactorsLogisticsMaintenanceRevision Record

2

,

NIF - SSDR 1.5.2- Supervisory Control Software Subsystem Design Requirements Revision 2

,

1.0 ScopeThis System DesignRequirement document establishes the performance, design, development, and testrequirements for the Supervisory Control Software, WBS 1.5.2, which is pm of the NJ.Fhtegrated ComputerControl System (ICCS). This document responds direc~y to the requirements detiled in ICCS (w13S 1.5) whichis the document directly above.

2.0 Applicable DocumentsThis section lists DOE orders, codes, and standards which are applicable to the N’lFktegrated Computer ControlSystem. The applicable portions of these dwuments apply. Applicmle LN stid~ds m being consideredcontingent upon the decision of final site selection.

2.1 Applicable NIF Project DocumentsNational IgnitionFacility FunctionalRequirementsandPrimaryCriteria,Revision’1.4, Mar 1996.

2.2 Applicable US Government Orders and StandardsUS. GovernmentDOE General Orders: (fd = flowdownfrom SDRO04, nfd = no flowdown)DOE 5700.6C-Quality Assurance(fd)

US. Government DOE Ordersrelatingto SafeguardsandSecurity:Noneapplyto this document.

2.3 Applicable National Consensus Codes and StandardsGeneralStandards:Noneapplyto this document.

Safety Standards:None apply to this document.

software andElectronic Standards:Ethernet IEEE-802.3 Local AreaNetworkfor Data CommunicationsFDDI Fiber DistributedDataInterface,ANSI StandardX3.139-1987RS-232C EIA Serial interfacestandardRS-485 EIA Multi-dropserialinterfacestandardIEEE-488 StandardDigital Interfacefor ProgrammableInstrumentation,NW/IEEE Std 488.1-1987

andANSVIEEE Std 488.2-1987IEEE-1014

RS-170 EIA VideointerfacestandardAda83 ANSUMIL-STD-1815A-1983, programmingg languageAda95 InternationalStandardANSI/ISO/I.EC-8652:1995, January 1995Xll X Window System, Version 11, windowsgraphicsstandard,MIT X ConsortiumOSF/Motif Motif graphicaluser interface,OpenSystemsFoundationPoos;gpt Text andgraphicsprintinglanguage,AdobeSystems Inc.

IEEE- 1003 portableapplicationprogrammingenvironmentTCPflT Protocol stack for networkcommunicationsOSIASO OpenSystems Interconnectprotocolstack for networkcommunicationsOSF/DCE DistributedComputingEnvironment,OpenSystemsFoundationOSF/DME DistributedManagementEnvironment,OpenSystemsFoundation

2.4 Applicable LLNL StandardsNone apply to this document.

3

--

NIF - SSDR 1.5.2- SupervisoryControlSoftwareSubsystemDesign Requirements Revision 2

d

2.5 Supporting Documentation StandardsInstrumentSociety of America,ISA-55.1, InstrumentationSymbolsandIdentificationInstrumentSociety of America ISA-S5.2, Binary Logic Diagramsfor Process OperationsInstrumentSociety of Arneric%ISA-S5.3, GraphicsSymbols for DistributedControVSharedDisplayInstrumentation,Logic andComputerSystemsInstrumentSociety of flrneric~ ISA-S5.4, InstrumentLoop DiagramsInstrumentSociety of America, ISA-S5.5, GraphicsSymbols for Process DisplaysANSI/IEEEStd 730.1-1989, IEEE Standardfor SoftwareQualityAssurancePlansSoftwareGuidelinesStandards,Practices, andConventions(Final DRAFT), ApplicationsDevelopment

Department,LawrenceLivermoreNationalLaboratory,August10,1992ANSUIEEE Std 830-1984, IEEE Guidefor SoftwareRequirementsSpecificationANSUIEEE Std 1016-1987, IEEE RecommendedPractice for SoftwareDesignDescriptionsANSUIEEE Std 828-1983, IEEE Standardfor Sofhwre ConfigurationManagementPlansANSIIIEEE Std 982.1-1988, IEEE StandardDictioniuyfor Measuresto produceReliable SofhvareANSUIEEE Std 982.2-1988, IEEE Guidefor the Use of IEEE StandardDictionaryof Measuresto Produce

ReliableSoftwareThe SoftwareProductivityConsortium,AdaQualityandStyle Guidelinesfor professionalProgrammersANSI/IEEEStd 1063-1987, IEEE Standardfor SoftwareUser Documentation

2.6 ReferencesNIF-LLNL-95-044/L-15958-2, National Ignition Facility Quality AssuranceprogramPlan, September 1995NIF-LLNL-94-017/L- 15958-5, NIF AncillarySoftwareQualityAssurancePlan, January 12, 1994NIF-LLNL-93058, NationalIgnitionFacility FunctionalRequirementsandPrimaryCriteria

3.0 Requirements and Verification

3.1 System Definition

3.1.1 System DescriptionThis system provides supervisory software for integrated control of the distributed subsystems, manual operatorcontrols, and displays and reports laser and target ama shot data.

Application software is organized as subsystems. Alignment, laser diagnostics, power conditioning, optical pulsegeneration, and target diagnostics are each assigned a primary operator console in the control room. A sixthsubsystem is devoted to experiment configuration and overall integration fimctions. All subsystem controls andstatus are provided with graphic user interfaces suitable to operator action.

3.1.2 System Functions

4

..—

NIF - SSDR 1.5.2- Supervisory Control Software Subsystem Design ReauiremenK Revision 2

.

3.1.3 System Diagrams

3.1.3.1 Supervisory Software Relationship to FEP Software

supervisory%;---!:- 9 Software

RequirementSpecification ,

dProtocols

DSViCS Objeet Control

Functional requh’emente Points

AttributesDynamic characterlatics

5

NIF - SSDR 1.5.2- Supervisory Control Softwsre Subsystem Design Requirements Revision 2

.

3.1.3.2 Supervisory Control and FEP Software Hierarchy

IntegratedComputer ControlSoftware

1. ...- ~~ 1 ““1“ *!!!. ‘“’-’’”””””-1~~~....s... #...,:”.......,,,.’

Q**”. mm..

1—I

.SAR

{L—)

-.

---

I

DW&-w 1.561

A

*

,/,’

. . . . . .

J-.. — k

——

6

.


3.1.4 System InterfacesThe ICCS Supervisory ControlSoftware has interfaces to the following WBS systems:

WBs 1.5.3WBs 1.5.4.1WBS 1.5.4.2WBs 1.5.5WBS 1.5.6.3WBS 1.5.6.1WBS 1.563WBS 1.8.6.3WBS 1.8.3.11WBs 1.7.3WBS 1.7.2WBs 1.7.1WBs 1.3.4WBs 1.3.3WBs 1.3.1WBs 1.3.1WBs 1.3.1.1WBS 1.3.1.5

Integrated Timing System (FEP)Integrated Safety System (FEP)Integrated Safety System, Access Control (FEP)Automatic Alignment @P)Facility Environmental MonitorVideo Distribution (FEP)Environmental Monitor (FEP)Target Auxiliary Systems (FEP)Target Diagnostics Control Room (FEP)Wavefiont Control (FEP)Beam Diagnostics (FEP)Alignment Systems (FEP)Power Conditioning (FEP)Poekels Cell System (FEP)OPG (FEP)OPG Modulator (FEP)OPG/MOR (FEP)OPG/Preamp (FEP)

3.1.5 Major Subsystems, Supervisory Control Software - WBS 1.5.2Consists of WBSs:

1.5.2.1 System IntegrationSoftware1.5.2.2 Alignment Controls Software1.5.2.3 Power Conditioning Software1.5.2.4 Laser Diagnostics Sofhvare1.5.2.5 Target Diagnostics Software1.5.2.6 Master Oscillator and Preamplifier Softwrue1.5.2.7 Shot Direetor Controls and Status Software

7

*


0

3.2.00 Supervisory Control Software, Functional RequirementsThe SupervisoryControl Software

● provides supervisory software for integratedcontrol of the distributed subsystems:‘ power conditioning● laser alignment and wave front controls● laser beam diagnostics● target diagnostics

optical pulse generation● ~rovides manual operator controls for maintenance● displays laser- and target-area configuration schematically“ displays and report laser- and target-area shot data e● provides special motor-slewing operator controls for alignment● configures laser- and target-area sensors and instruments using FEP capabilities, store shot configuration

as part of shot data● coordinates FEP-level machine interlocks to protect against component darnage caused by improper

operation“ retrieves data from distributed FEPs● provides reusable integration software for upper-level systems

● interprocess communication“ distributed shot number“ event logging● alarm processing

“ sequences slower control elements not connected to hardware timing system“ reduees and stores laser diagnostic data in on-line database● analyzes laser performance and models power balances processes seleeted target diagnostics data for rapid assessment of experimental results● coordinates automatic alignment system

3.2.01 Supervisory Control Software, Application SoftwareDetailed requirementsfor eaeh majorelement of the supervisorysoftwareshall be documentedin a separateSoftware RequirementsSpecification (SRS). The SRS shall speci~ requirementsincluding performance,concummcy, persistence, and other dynamic specifications thatmay imply system partitioningor a particularmethod of implementation.Each SRS shall deseribe the functionalrequirementsthatthe subsystem must provide,including:

● services that arerequiredby the respective FrontEnd Processors“ configumtiondatathatcharacterizeequipmentbeing controlled● user interfaces“ dataprocessing and archival● automaticsequencing● statusandalarmprocessing“ datalogging and trending.

3.2.02 Supervisory Control Software, Look and FeelAll applicationGUISshall provide a consistent look andfeel across all subsystemsto amelioratethe potentialofoperatorerrors.The look (presentationof information)andfeel (wayin whichthe operatorinteraetswiththeapplication)shall follow the similarconventionsthroughoutthe controlsystem,includinguse of color, use ofsymbols, andstyle of operatorinput.

3.2.03 Supervisory Control Software, GUI ApplicationThe applicationsGUI shall allow the operatorto control the layout of the workstation, including number, sizingand placement of windows.

8

b

NIF - SSDR 1.5.2- SupervisoryControlSoftware SubsystemDesign Requirements Revision 2

0

ils a goal, ail GUI applicationsshouldattemptto allowrecoveryof an operatordefinedscreenlayoutconfiguration,on a per-operatorbasis. That is, an individualoperatorshouldbe able to definea screen“window”configuration,andretrievethe layout,to effwtively customizetheScmn, md tive at a fdiar operatingpresentationat runtime.

3.2.04 Supervisory Control Software, Software Languages

3.2.04.1 Supervisory Control Software, Standard Software Language, AdaThe standardsoftware language shall be Ada. Exceptions shall be by design review.

3.2.04.2 Supervisory Control Software, Secondary Software Language, C/C++The secondary software language shall be C/C++. Exceptions shall be by design review.

3.2.04.3 Supervisory Control Software, QA Level RequirementsThe SupervisoryControlSoftware shall adhereto the following (@d@ Level specifications. Reference for QALevel is the NW QA Plan as stated in paragraph2.6 of this document.

WBS 1.5.2.1 System IntegrationSoftware $I_#; ;WBS 1.5.2.2 Aiignment ControlsSoftwareWBS 1.5.2.3 Power Conditioning Software Q-Level 3WBS 1.5.2.4 Laser Diagnostics Software Q-Level 2WBS 1.5.2.5 TargetDiagnostics Software Q-Level 3WBS 1.5.2.6 MasterOscillatorandPreamplifierSofbamte Q-Level 3WBS 1.5.2.7 Shot Director Controls and Status Softvwue Q-hvel 3

3.2.05 Supervisory Control Software, Machine InterlocksMachine interlocks, via a configurationdatabase,shall be used to keep the beam pathclear, and assurethatattenuatorsor gain settings areestablishedbefore a shot so thatcomponents cannotbe darnaged.Othermachineinterlockfunctions shall be implemented as needed.

3.2.06 Supervisory Control Software, Hardware PlatformThe Supervisory Software shall operate in the hardware environment specified in ICCS, Computer SystemsSSDR

3.2.07 Supervisory Control Software, On-line ConfigurationSupervisoryControlSoftware shall utilize a conf@urationdatabaseto con@ure ail dynamic control pointoperatingparameters(such as calibrations,I/O channels, etc.).

3.2.08 Supervisory Control Software, Diagnostic Suite DefinitionThe TargetDiagnostic InstrumentsSuite and setup for each instrumentshail be defined via a databaseconilgu.rationfile.

3.2.09 Supervisory Control Software, Pre-Shot Requirements● ICCS shall provide supervisory software for integratedcontrol of five distributedsubsystems:

“ power conditioning● optical pulse generation“ laserbeam control, including alignment andwave frontcontrols“ laser beam diagnostics“ targetdiagnostics

9

*

NIP - SSDR 1.5.2- Supervisory Control Software Subsystem Design Requirements Revision 2

e

● For each subsystem, controls shall be provided to the operator that enable the following functions:●

●

●

●

●

●

●

●

●

●

●

●

provide m-anualoperator controls for installation, maintenance and problem diagno~isexamine the status of each controlled devicecoordinate FEP-level machine interlocks to protect against component dmge caused by improper

operationprovide display of status data from auxiliary systems (gas pressures, coolant fluid flow, vacuum

system, radiation safety monitors)report events to the operatordisplay laser- and target-area equipment configuration schematicallyreport and archive equipment- and safety-interlock statusmaintain an audit trail of operator actions and equipment responses ~assure the orderly coordination of activities performed by diffenmt operatorsarchive beam diagnostic images as nq.dred to support damage inspectionsupport the diagnosis of failures in the software, computer systems, stored data, and networkarchive laser performance data to facilitate performance tuning on later shots

3.2.10 Supervisory Control Software, Shot Time Requirementss ICCS shall coordinateall subsystemactivities to execute a shot underthe directionof the Shot Director:

“ preparethe laser to execute a shot● sequence such slower controlelements as are not connected to the hardwaretiming systems reduce and store laser diagnosticdatain on-line database“ collect, display, and archivedatageneratedin a shot● store shot conilguration as partof shot datas analyze laser performanceandmodel andprovide power balance feedback to the OPGs process selected targetdiagnostics datafor rapidassessment of experimentalresults● analyze wavefrontdata● analyze Laser Diagnostic data

3.2.11 Software Requirements Specification (SRS)Detailed requirementsfor each majorelement of the supervisorysoftwareshall be documentedin a separateSoftwue RequirementsSpecification. The SRS shall include functionalrequirements for user interfaces, dataprocessing and archival, automatic sequencing, control system configuration, status processing, alarm processing,and data logging and trend@g.

The SRS shall also include performance, persistence, concurrency, or other dynamic requirements as well as otherarchitectural requirements that may imply system partitioning or a particular method of implementation.

.3.2.12 Supervisory Control Software, Access to Distributed Control PointsAccess to all distributed control points that are integrated into the control system shall be made by Front EndProcessors that implement the hardware-level interface to the control points. The FEP software shall implementthose functional requirements that are determined by requirements analysis to be allocated to the FEP layer in thecontrols architecture. The requirements analysis shall be guided by the physical properties and performanceconstraints of the control hardware, and by those operational scenarios requiring operation independent of thesupervisory software or local control.

A separate Software Requirements Specification (SRS) shall be provided for each FEP. These SRS documentsshall be used to further define the requirements of the supervisory sofiware.

10


3.2.13 Modes of Operation, Segmented and Concurrent OperationThe Supervisory Control Software shall supportseveral modes of operation including:

Conf@uration SetupPreshot-aligmnentShot CountdownPost-shot data collection and archivalPost-shot data reduction and presentationMaintenancePartial laser system operation

The Supervisory Control Software shall be capable of operating the NE in a segmented mode with the segmentsfunctioning concurrently indifferent configurations. As an example, a portion of the laser maybe undermaintenance or construction and the rest of the laser operational. The Supervisory Control Software shall supportthe area under construction with appropriate test sequenees, chagnostics and construction debugging tools, whilesimultaneously supporting shot sequenees on the operational segment of the laser.

3.2.14 Supervisory Control Software, Documentation and ManualsDocumentationandmanualsshall be providedto:

s Trainand serve as a reference for OperationsStaff. Serve as a refereneefor futuresoftware development staff to facilitate modifications and additionsthat

will be requiredover the life of the project.

The Supervisory Control Software System shall provide sufficient documentation to comply with the NIF QualityAssurance Plan, and DOE Order 5700.6C, QuaMy Assurance, Criterion-4 Documents and Reeords, which states:“Documents shall be prepared, reviewed, approved, issued used and revised to preseribe processes, speci~requirements or establish design. Records shall be speeifkd, prepared, reviewed approved and maintained.”

Examples of documents that should be controlled include drawings, data files, calculations, specifications,computer codes, purchase orders, vendor supplied documents, procedures, work records and data sheets and testreeords. Revisions should be reviewed by the organizations that originally prepared and approved the documents.Controlled documents should be distributed to those doing the work.

3.2.15 Lifetime, Replaceability, Reliability, Availability, Maintainability

3.2.15.1 LifetimeLifetime: The SupervisoryControl Software shall operatefor 30 years.

3.2.15.2 ReplaceabilityReplaceability: Any portionof the SupervisoryControl Softwarewhich cannot reasonablybe designed for 30 yearlifetime shall be designed to be replaced or repairedat reasonablecost in a timely mannerconsistent with theoverall availability of the System.

3.2.15.3 ReliabilityReliability: The SupervisoryControl Software shall have an overall reliability of 99.70%. Reliability is defined asthe probabilityof meeting the minimum requirementsof the experimentper no-yield shot.

3.2.15.4 AvailabilityAvailability: The SupervisoryControl Software shall have a shot availability of at least 97.22%. The SupervisoryControl Sotlware is unavailablewhen it is undergoingunplannedmaintenance.Unplannedmaintenanceincludesfailure deteetion and active repairas well as logistic andadministrativedowntimes.

11

}

NIP - SSDR 1.5.2- Supervisory Control Software Subsystem Design Requirements Revision 2

3.2.15.5 MaintainabilityMaintainability:The SupervisoryControlSoftware shall have a scheduled maintenanceplanthatfits within anoverall annualplantgoal of 69 days. The unplannedmaintenancegoal is 7.5 days peryear. Opportunisticmaintenanceactivities areperformedbetween shots andduringother system downtimes.

3.2.16 Recovery From Abnormal EventThe time requiredfor the SupervisoryControlSoftware to recover from any abnormalevent shall be less thanthemaximum times cited below, as a fimction of the expected yearly frequencyof occurrenceof the event.

Iixp=d Freauencv of Occurren ce Per Year. F Maxi“mum Recovem TimeF>l 24 hours t

l> F>le-2 1 weekle-2>F25e-4 3 months

Probabilities listed in DOE-STD- 1020-94 shall be used for natural phenomena.

For frequent events, the maximum allowed recovery time may be restricted by availability requirements to be lessthan that shown in the table above.

To meet the above Maximum Recovery Time requirements, Supervisory Controls shall maintain an off-site (otherthan the NIP facility) backup storage facility.

3.2.17 Human FactorsThe SupervisoryControlSoftware shall be designed in an ergonometric fashion to ensurethatreliabilityduringoperationandmaintenanceis sustainedat a level consistentwith meeting overall availabilityandreliabilityobjectives. Consistency in displays, warnings, and humaninterfaces should be maintainedthroughouttheSupervisory Control Software and, if possible, throughoutthe NIP facility (i.e., GUI displays, access ports,tooling).

3.4 Logistics

3.4.1 MaintenanceAs a partof the desigrdconstructionproject, the SupervisoryControlSoftwaIEshall provide all equipmentrequiredto inspect, swice, and maintainall subsystems within the Supervisory ControlSoftware to meet themaintainabilityandavailabilityrequirements.Maintenanceequipmentshall include softwaremaintenancetools,software backup tools, etc., and other special tools not otherwise available within the NIF, thatarenecessary toperformany planned(scheduledor unscheduled) maintenanceactivity.

6.0 Revision Record

A 12Mar96 SeverynA 30May96 Severyn2 06Aug96 Severyn

2 20Aug96 Severyn

2 28Aug96 Clasen2 29Aug96 Severyn

Convert to FileMaker, updatePost Mid Title-1 updatepara 2.6, update QA Plan refpara 3.2.04.3, update QA levelspara 2.2, was empty, added ref to QA DOE Order.para 2.2,2.3,2.4, stated that some sections of these paragraphs do not

have standards that apply to this document.Convert to WordCall rev B= rev 2 to match Sherpa.Deleted “Supervisory Control Software” from many para. titles.

12

Technical Inform

ation Departm

ent • Lawrence Liverm

ore National Laboratory

University of C

alifornia • Livermore, C

alifornia 94551