Text

Additional Response to NRC Letter Dated August 8, 2007, Regarding the Main Steam and Feedwater Isolation System Controls Modification
	ML072700498
Person / Time
Site:	Wolf Creek
Issue date:	09/20/2007
From:	Garrett T; Wolf Creek
To:	; Document Control Desk, Office of Nuclear Reactor Regulation
References
	ET 07-0041
	Download: ML072700498 (59)
	v • d • e

W*LF CREEK'NUCLEAR OPERATING CORPORATION Terry J. Garrett September 20, 2007 Vice President, Engineering ET 07-0041 U. S. Nuclear Regulatory Commission ATTN: Document Control Desk Washington, DC 20555

Reference:

1) Letter ET 07-0004, dated March 14, 2007, from T. J. Garrett, WCNOC, to USNRC

2) Letter ET 07-0022, dated June 15, 2007, from T. J. Garrett, WCNOC, to USNRC

3) Letter dated August 8, 2007, from J. W. Lubinski, USNRC, to R. A. Muench, WCNOC

4) Letter ET 07-0039, dated August 31, 2007, from T. J. Garrett, WCNOC, to USNRC

Subject:

Docket No. 50-482: Additional Response to NRC Letter dated August 8, 2007, Regarding the Main Steam and Feedwater Isolation System Controls Modification Gentlemen:

Reference 1 provided a license amendment request that proposed revisions to Technical Specification (TS) 3.3.2, "Engineered Safety Feature Actuation System (ESFAS)

Instrumentation," TS 3.7.2, "Main Steam Isolation Valves (MSIVs)," and .TS 3.7.3, "Main Feedwater Isolation Valves (MFIVs)." Reference 1 proposed changes to these specifications based on a planned modification to replace the MSIVs and associated actuators, MFIVs and associated actuators, and replacement of the Main Steam and Feedwater Isolation System (MSFIS) controls. On August 2, 2007, Wolf Creek Nuclear Operating Corporation (WCNOC) personnel met with the Nuclear Regulatory Commission (NRC) to discuss five issues identified by the NRC staff associated with the review of the MSFIS controls modification. Subsequently, Reference 3 provided the results of the meeting and requested WCNOC to respond to the five issues. As discussed at the August 2, 2007 meeting, and documented in Reference 3, the first issue was to provide by September 20, 2007, a detailed mapping of RTCA DO-254/EUROCAE ED 80, "Design Assurance Guidance for Airborne Electronic Hardware," to Institute of Electrical P.O. Box 411 / Burlington, KS 66839 / Phone: (620) 364-8831 An Equal Opportunity Employer M/F/HCNVET

ET 07-0041 Page 2 of 3 and Electronics Engineers (IEEE) Std 7-4.3.2-2003, "IEEE Standard Criteria for Digital Computers in Safety Systems of Nuclear Power Generating Stations." The Attachment provides WCNOC's response to issue 1.

Reference 2 provided supplemental information on the MSFIS controls modification. In the response to item 22, WCNOC made a commitment that the Operations and Maintenance Manual would be developed by September 14, 2007 with acceptance of the manual by September 28, 2007. A review of information and schedules associated with this commitment determined that WCNOC had provided an incorrect date for completing the Operations and Maintenance Manual. The correct date for completion of the manual is November 30, 2007 with WCNOC acceptance of the manual by December 14, 2007. This information was provided to the NRC Project Manager by electronic mail on September 14, 2007.

The additional information provided in the Attachment and Enclosure do not impact the conclusions of the No Significant Hazards Consideration provided in Reference 1. In accordance with 10 CFR 50.91, a copy of this submittal (without the Enclosure) is being provided to the designated Kansas State official.

Attachment II provides a list of commitments made in this letter. If you have any questions concerning this matter, please contact me at (620) 364-4084, or Mr. Kevin Moles at (620) 364-4126.

Sincerely, Terry J. Garrett TJG/rlt Attachments I) Response to NRC Letter Regarding the Main Steam and Feedwater Isolation System (MSFIS) Controls Modification II) List of Commitments Enclosure cc: E. E. Collins (NRC), w/a, w/e T. A. Conley (KDHE), w/a, J. N. Donohew (NRC), w/a, w/e V. G. Gaddy (NRC), w/a, w/e Senior Resident Inspector (NRC), w/a, w/e

ET 07-0041 Page 3 of 3 STATE OF KANSAS )

SS COUNTY OF COFFEY )

Terry J. Garrett, of lawful age, being first duly sworn upon oath says that he is Vice President Engineering of Wolf Creek Nuclear Operating Corporation; that he has read the foregoing document and knows the contents thereof; that he has executed the same for and on behalf of said Corporation with full power and authority to do so; and that the facts therein stated are true and correct to the best of his knowledge, information and belief.

Terry Garrett Vice President Engineering SUBSCRIBED and sworn to before me this/jb1ay offlp4,, 2007.

RHONDA L.TIEMEYER A*COFF*CA.MY COMMISSION EXPIRES otary Public 6

%/;.. .... ~January 11, 2010 Expiration Date 00,L12JL172i1 11J60 /

Attachment I to ET 07-0041 Page 1 of 2 Response to NRC Letter Regarding the Main Steam and Feedwater Isolation System (MSFIS) Controls Modification On August 2, 2007, Wolf Creek Nuclear Operating Corporation (WCNOC) personnel met with the Nuclear Regulatory Commission (NRC) staff to discuss five issues identified by the NRC associated with the review of the MSFIS controls modification. Subsequently, the NRC issued a letter dated August 8, 2007, in which the NRC staff accepted the MSFIS controls modification license amendment request for review. This letter identified 5 issues requiring a response from WCNOC. WCNOC letter ET 07-0039, dated August 31, 2007, provided responses to the 5 issues. With regard to issue 1, WCNOC indicated that a more detailed comparison of RTCA DO-254/EUROCAE ED-80, "Design Assurance Guidance for Airborne Electronic Hardware," to Institute of Electrical and Electronics Engineers (IEEE) Std 7-4.3.2-2003, "IEEE Standard Criteria for Digital Computers in Safety Systems of Nuclear Power Generating Stations," would be provided by September 20, 2007. Issue 1 and supplemental response is provided below.

1. The standard which the licensee chose to use to develop this system, RTCA DO-254/EUROCAE ED-80, "Design Assurance Guidance for Airborne Electronic Hardware," has not been reviewed or approved for nuclear safety-related use at nuclear power plants by the NRC staff At this point, the licensee should provide a detailed mapping of this standard to an NRC-approved standard such as the Institute of Electrical and Electronic Engineers (IEEE)

Standard 7-4.3.2, and show on a paragraph-by-paragraphbasis what portion of standardRTCA DO-2541EUROCAE ED-80 has similar requirements, and why meeting that portion of RTCA DO-2541EUROCAE ED-80 will satisfy the corresponding section of the approved IEEE standard. There may be sections of the approved standard which are not applicable to an FPGA design, and these should be pointed out and justified. The NRC staff should receive the results of this task by September 20, 2007, as the licensee agreed to in the August 2, 2007, meeting. If this date is not met or the quality of the information is not sufficient, our acceptance of the review of the proposed replacement MSFIS will be retracted.

Response: WCNOC contracted with HighRely, Inc. to perform a difference analysis between RTCA DO-254 and IEEE 7-4.3.2. WCNOC chose HighRely to perform this analysis based on their familiarity and experience with DO-254 and knowledge of IEEE 7-4.3.2. The IEEE 7-4.3.2

- DO-254 Difference Analysis is provided in Enclosure I. WCNOC has indicated in letter ET 07-0039 that the MSFIS controls is a software-based digital system from the standpoint that there is high quality software utilized in the Field Programmable Gate Array (FPGA) logic development process and therefore, will meet the applicable criteria of IEEE 7-4.3.2-2003.

WCNOC is available for a meeting with the technical branch reviewer the week of October 15 to discuss Enclosure I, if necessary. We believe that a meeting would be beneficial in explaining the difference analysis and the applicability of IEEE 7-4.3.2 to the WCGS design.

The difference analysis performed by HighRely, Inc. has identified several key aspects of the relationship between the aviation industry and nuclear industry standards for complex digital systems. The difference analysis was specifically scoped to compare IEEE 7-4.3.2 and DO-254, however during the analysis there were several interviews with the HighRely engineers, and it became apparent that this is not an easy comparison to make. The expectation had initially been a paragraph-by-paragraph comparison, but once the details of the analysis began to formulate, WCNOC realized this would not be possible. Given this difficulty of the paragraph-by-paragraph comparison, a written comparison was made to highlight the differences between the two standards.

Attachment I to ET 07-0041 Page 2 of 2 The difference analysis identifies the fact that IEEE 7-4.3.2 is more heavily focused on the system level while DO-254 is focused on the low level steps of the development process. As the analysis progresses it becomes further apparent that IEEE 7-4.3.2 and DO-254 have many similarities but are basically at a different level within the overall set of standards for the respective industries, Aviation and Nuclear. In other words, DO-254 relies on system level aspects being provided by standards above it, such as SAE ARP 4754, "Certification Consideration for Highly-Integrated or Complex Aircraft Systems," and SAE ARP 4761, "Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment." This is similar in the way that IEEE 603-1998, "IEEE Standard Criteria for Safety Systems for Nuclear Power Generating Stations," provides higher-level aspects, which drive down to IEEE 7-4.3.2.

WCNOC believes that DO-254 provides useful design guidance for complex digital electronics, particularly since the standard is focused on Programmable Logic Devices (PLDs), Application Specific Integrated Circuits (ASICs), and FPGAs based designs. However, WCNOC does not believe that DO-254 is a substitute for IEEE 7-4.3.2, rather; it is a complement to IEEE 7-4.3.2.

WCNOC concludes that IEEE 7-4.3.2 is an appropriate standard for complex digital electronics particularly since the focus of this standard is at the system level. WCNOC does not discourage the use of DO-254 as design guidance since the DO-254 standard contains many aspects that compliment IEEE 7-4.3.2. As indicated in letter ET 07-0039, the MSFIS controls will meet the applicable criteria of IEEE 7-4.3.2-2003.

Attachment II to ET 07-0041 Page 1 of 1 LIST OF COMMITMENTS The following table identifies those actions committed to by Wolf Creek Nuclear Operating Corporation in this document. Any other statements in this letter are provided for information purposes and are not considered regulatory commitments. Please direct questions regarding these commitments to Mr. Kevin Moles, Manager Regulatory Affairs at Wolf Creek Generating Station, (620) 364-4126.

REGULATORY COMMITMENT DUE DATE The Operations and Maintenance Manual will be developed by 11/30/2007 November 30, 2007 with acceptance of the manual by December 12/14/2007 14, 2007

Enclosure I to ET 07-0041 IEEE 7-4.3.2 - DO-254 Difference Analysis

HIGH RELY IEEE - DO-254 Difference Analysis Report:

CS Innovations IEEE 7-4.3.2 - DO-254 Difference Analysis CS Innovations August 22, 2007 HighRely Avionics & CertificationCenter Phoenix, Arizona HighRely, Inc.

HIGHELY Peli~albe Emnbc~ldad S&,iatio,,s IEEE- DO-254 Difference Analysis Report:

CS Innovations Table of Contents I D O-254 D ifference A nalysis Overview .......................................................................................................... 3 1.1 D O -2 54 S um m ary ............................................................................................................................................ 4 2 Sum m ary: IEEE 7-4.3.2 to DO -254 A nalysis ................................................................................................ 11 2.1 Summary of IEEE 7-4.3.2 and DO-254 Differences ............................................................................... 12 2.2 Sum m ary of IEEE 7-4.3.2 and D O -254 ..................................................................................................... 19 2 .3 C onclusio ns ................................................................................................................................................... 19 3 Complex Electronic Hardware (CEH) Difference Analysis ............................................................................. 21 3.1 Hardware (ASIC/PLD) Planning Process ................................................................................................ 21 3.2 Hardware (ASCIIPLD) Architectural Decisions ...................................................................................... 23 3.3 Hardware (ASIC/PLD) Requirements Capture ......................................................................................... 29 3.4 Hardware (ASIC/PLD) Preliminary Design (behavioral, Conceptual design) ......................................... 31 3.5 Hardware (ASIC/PLD) Detailed Design (synthesis, mask generation, fuse file) ..................................... 32 3.6 Hardware (ASIC/PLD) Fabrication (programming programmable components/Implementation) .......... 33 3.7 Hardware (ASIC/PLD) Production Transition ......................................................................................... 35 3.8 Hardware (ASIC/PLD) Validation and Verification (timing analysis, behavioral simulation, gate level sim u lation and d esign) ............................................................................................................................................... 37 3.9 Hardware (ASIC/PLD) Configuration Management Process ................................................................. 40 3.10 Hardware (ASIC/PLD) Process Assurance ............................................................................................. 42 3.11 Hardware (ASIC/PLD) Certification Liaison Process ............................................................................. 44 3.12 Hardware (ASIC/PLD) Additional Consideration for Levels A&B ........................................................ 45 4 IEEE 7-4.3.2 Deliverables and Aviation Process Equivalent ........................................................................... 45 4.1 DO -254 D eliverables are defined as: ....................................................................................................... 46 4.2 Deliverables of IEEE 7-4.3.2 Vs. Aviation Standards ................................... 50 HighRely, Inc.

HIGHHELY CnbndlodSou ons IEEE - DO-254 Difference Analysis Report:

CS Innovations 1 DO-254 Difference Analysis Overview CS Innovations has requested HighRely Incorporated to perform a Difference Analysis between RTCA DO-254/ED-80, Design Assurance Guidance for Airborne Electronic Hardware (DO-254) and IEEE Std 7-4.3.2 - 2003TM IEEE Standard Criteria for.Digital Computers in Safety Systems of Nuclear Power Generating Stations (IEEE 7-4.3.2). The purpose of this Difference Analysis is to identify the differences, gap and/or or shortcomings pertinent to the complex electronic hardware development under the guidance of DO-254 as compared with those identified in IEEE 7-4.3.2. Specifically, HighRely's Difference Analysis provides for the following activities crucial to DO-254 compliance and certification:

1. Assessment of IEEE 7-4.3.2 and the engineeringapproach contained therein.

2. Detailedanalysis andcross-reference of the IEEE approachas it pertains to DO-254.

3. Explanation of differences using HighRely's DO-254Analysis Checklist; Section 3 of this Report.

4. Onsite explanation by HighRely ofkey DO-254 aspects, common risks and risk-mitigation techniques.

5. High-levelfindings ofDO-254 differences and comments regardingthese differences.

CS Innovations has a history of developing complete electronics systems, specializing in hardware and system development, with expert designers in embedded system architecture, integrated circuits, analog, digital and software. While this exercise does not directly assess them in any detail, CS Innovations' engineering disciplines appear to be well established. Included in these disciplines are configuration management, quality assurance and engineering and manufacturing activities and capabilities that are well suited for safety system development. This assessment is made based on interviews with both CS Innovations and Wolf Creek Generating Station personnel.

HighRely, Inc.

IEEE - DO-254 Difference Analysis ReDort:

CS Innovations 1.1 DO-254 Summary The DO-254 document provides guidance for design assurance of airborne electronic hardware from conception through initial certification and subsequent post certification product improvements to ensure continued airworthiness. DO-254 was released in April 2000 and its intent is to provide developmental assurance for complex electronic hardware including programmable logic devices (PLDs) and application specific integrated circuits (ASICs) and other decision making hardware devices. Following the guidance and procedures outlined in DO-254 assures that the hardware design performs its intended functions in its specified environment, and meets airworthiness requirements. DO-254 does not specify design considerations for system development, but does discuss a relationship to the system development process; which includes the overlapping, iterative feedback nature of system and component development processes, as well as the exchange of information between the system development process and the complex electronic hardware design lifecycle process. As well, DO-254 does not specify the considerations for the software development process, but indicates an exchange of information between the processes.

RTCA/DO-254 distinguishes between complex and simple electronic hardware; recognizes five levels of failure effects ranging from catastrophic to no affect; and provides guidance for each hardware design assurance level. Although the guidance in RTCA/DO-254 is applicable to all categories of hardware items (e.g., Line Replaceable Units (LRUs), Circuit Board Assemblies, etc) guidance is provided for custom micro-coded components (e.g., ASICs, PLDs, and FPGAs).

The following figures depict the scope, contents, and application of DO-254. A subsequent table lists the primary themes of DO-254; all of these DO-254 aspects are evaluated for this project and covered in this difference analysis. Each of these DO-254 Themes is separately assessed and differences analyzed Recommendations for further study are presented A table of IEEE 7-4.3.2 outputs as compared to aviation deliverables is also provided.

HighRely, Inc.

IH RHY:

IEEE - DO-254 Difference Analysis Report:

CS Innovations Ficure 1-1: DO-254/DO-178B Overview - Safety, System. Software & Hardware

Criticality Level

Architectural Inputs SW Rqmts HW Rqmts Tests I a0 -

Tests U

f.ib/ ,fIlbj.ZO FR y~~.

IEEE - DO-254 Difference Analysis Report:

CS Innovations Fiaure 1-2: DO-254 Document Contents Overview DO-254 Contents Deived (las,Requirements reqied).

Development Constraints:.

" ystemn Aspects (Sec. 2) lDesign Process (Sec. 5)

HW Design.life Cyce,. (Se.. 3) .

". Planning~ Process':Sec. 4~) V&V Proces Supporting Processes:

(Sec. 6) 11:I SAdd*itional Considerations (Sec.. 1)1 Design Assurance 1for. ", CM Process (Sec. 7 Levels A & B (Appendix B)< *Process Assura*c* (Sec.**:.

CertificatiornLiaisoni (Sec.,9,)

l.W Diesign LifeCycle Data (Sec. 1i0),

HW Life Cy'leData by Design Assuran"ce L"evel and Control Code (App.

HighRely, Inc.

Rofoabl -jedbd1od &,iolhfjtlsý IEEE - DO-254 Difference Analysis ReDort:

CS Innovations Figure 1-3: DO-254 Hardware Development Lifecycle Overview Hardware Design Life-Cycle HighRely, Inc.

HIGNJELY

4. iiý IEEE - DO-254 Difference Analysis Rejport:

CS Innovations The following table lists the Top Ten common themes of DO-254; all of these DO-254 aspects are evaluated and covered in HighRely's Difference Analysis as presented herein. Each of these DO-254 themes is separately addressed relative to IEEE 7-4.3.2 and separately described herein, complete with HighRely commentary and recommendations.

, 7. . r -;e Hg-ee l Descriptio Safety Assessment Process There are three system safety assessment processes:

functional hazard assessment (FHA), preliminary system safety assessment (PSSA) and SSA. These processes are used to establish the system safety objectives applicable to the system development assurance process, and to determine that the system functions achieve certifiable safety objectives.

Hardware Planning Process The purpose of the hardware planning process is to define the means by which the functional and airworthiness requirements are converted into a hardware item with an acceptable amount of evidence of assurance that the item will safely perform its intended functions. The objectives of the hardware planning process are: the design life-cycle processes are defined, standards are selected and defined, development and verification are selected and defined, and the means of compliance including strategies for safety are proposed and conveyed.

System & Hardware Given the safety, functional and performance Architecture Planning & requirements allocated to the hardware by the system Development process, the hardware safety assessment determines the hardware design assurance level for each function and contributes to determining the appropriate design assurance strategies to be used. Architectural design decisions take into account the system safety, functional and performance requirements.

Hardware Requirements The requirements capture process identifies and records the hardware item requirements. This includes those derived requirements imposed by the proposed hardware item architecture, choice of technology, the basic and optional functionality, environmental, and performance requirements as well as the requirements imposed by the system safety assessment.

HighRely, Inc.

HIGH RELY IEEE - DO-254 Difference Analysis Report:

CS Innovations Hardware Conceptual Design

-aýL*- eer - g. -Levl The conceptual design process produces a high-Level

1i Design concept that may be assessed to determine the potential for the resulting design implementation to meet the requirements. This may be accomplished using such items as functional block diagrams, design and architecture descriptions, circuit card assembly outlines, and chassis sketches.

Hardware Detailed Design The detailed design process produces detailed design data using the hardware item requirements and conceptual design data as the basis for the detailed design.

Hardware Implementation & The implementation process uses the detailed design data Production Transition to produce the hardware item that is an input to the testing activity. In this process, manufacturing data, test facilities and general resources should be examined to ensure availability and suitability for production. The production transition process uses the outputs from the implementation and verification processes to move the product into production.

Hardware Verification & The validation process provides assurances that the Validation hardware item derived requirements are correct and complete with respect to system requirements allocated to the hardware item. The verification process provides assurance that the hardware item implementation meets all of the hardware requirements, including derived requirements.

Hardware Configuration The configuration management process is intended to Management provide the ability to consistently replicate the configuration item, regenerate the information if necessary and modify the configuration item in a controlled fashion if modification is necessary.

Hardware Process Assurance Process assurance ensures that the life cycle process objectives are met and activities have been completed as outlined in plans or that deviations have been addressed.

Unlike software, DO-254 production assurance extends through manufacturing, as building the hardware is equally important to designing it.

MENg MLY IEEE - DO-254 Difference Analysis Report:

CS Innovations "

254h~b .w~n

- --- * -- *eDesripio Hardware Certification Liaison The purpose of the certification liaison process is to establish communication and understanding between the applicant and the certification authority throughout the hardware design life cycle to assist in the certification process. Liaison activities may include design approach presentation for timely approval, negotiations concerning the means of compliance with the certification basis, approval of design approach, means of data approval, and any required certification authority reviews and witnessing of tests. For DO-254, Liaison is performed via DER with a Systems ticket augmented with DO-254 certification.

HighRely, Inc.

HIGH RELY ReLbe~e~

ta SI ,fl IEEE - DO-254 Difference Analysis Report:

CS Innovations 2 Summary: IEEE 7-4.3.2 to DO-254 Analysis This section presents a summary of IEEE 7-4.3.2 and DO-254 similarities and differences and related issues for Complex Electronic Hardware (CEH). As previously mentioned, HighRely's DO-254 Difference Analysis provides an independent, detailed, and accurate assessment of DO-254 related*

activities in comparison to those stated in IEEE 7-4.3.2,, along with recommendations for filling any gaps between the standards. The scope of this report is limited to IEEE 7-4.3.2. IEEE 7-4.3.2 makes reference to multiple IEEE standards, the details of which are considered out of the scope of this analysis, however those additional standards parallel the primary IEEE standard compared herein.

In essence, IEEE 7-4.3.2 and DO-254 have many similarities, with both aiming to improve the measurable quality, repeatability, and auditability of critical complex electronic systems. Many characteristics reflect a typical computer system development process, including conceptual design, requirements development, implementation, requirements-based testing, acceptance testing, production and operation. For these characteristics, IEEE 7-4.3.2 points to IEEE 603-1998 along with other IEEE standards and a comparison between these standards and DO-254 is not within scope of this exercise. IEEE 7-4.3.2 does, however, necessitate requirements necessary to meet the quality criterion of safety systems. These include software development, qualification of COTS, use of software tools, verification and validation, configuration management and risk management. DO-254 also addresses these aspects, but in a fashion where the details are embedded within the design assurance guidance for the appropriate criticality level.

In order to accommodate different cost structures based on the intended use of a system or subsystem, DO-254 provides a unique means for varying criticality levels based on system functionality as integrated into an airborne platform; determined via various safety assessments and hazard analyses integrated into formal system requirements. DO-254 also allows for protection through partitioning of systems and subsystems based on the intended use and safety assessment. Since IEEE 7-4.3.2 is specifically targeted to nuclear power generating stations, this report focuses on DO-254 design assurance for criticality Level A; that is the criticality at the highest level defined, and does not detail aspects of lower criticality levels as described in DO-254.

IEEE 7-4.3.2 is focused more heavily upon system developmentaspects versus the development lifecycle and low-level steps inherent in DO-254. As an example, Annex E of IEEE 7-4.3.2 discusses communication independence in great detail. It is apparent that the discussion in Annex E is appropriate to the development of data communication between a single safety channel, between safety channels and between safety and non-safety computer systems; and the possibility of the loss of a computer's ability to perform its function. This discussion leads to the development of appropriate system level requirements; but does not provide assurance that the refinement of those requirements, the allocation of those requirements, the specification of an adequate complex electronic hardware design, the implementation of that design, and that the verification that the requirements were implemented correctly is accomplished.

The development using DO-254 of communication independent system designs, such as those presented in Annex E, would provide for assurances that the system is specified, designed and implemented completely and correctly.

Z7.1f1,MLRY IEEE - DO-254 Difference Analysis Report:

.CS Innovations Similar to the explanation above regarding Annex E, IEEE 7-4.3.2 presents a section discussing system integrity. This discussion is intended to ensure that the system is designed for integrity, designed for test and calibration and designed for fault detection and self-diagnosis. While presented in a different context, this system integrity parallels DO-254's precursor safety assessment process, whereby the architecture is refined to support the desired safety (criticality) level. When these design considerations are adequately specified (outside the scope of DO-254), developing the system under the guidance of DO-254 will ensure that the system performs its intended function without introducing error and that no unintended function is inadvertently introduced during the development lifecycle.

It is intended that the readerfully review and absorb the detailedfindings as contained in the sections herein; those sections contain the complete HighRely DO-254 Difference Analysis and DO-254 Checklists along with discrete nuances of individualfindings.

2.1 Summary of IEEE 7-4.3.2 and DO-254 Differences IEEE 7-4.3.2 discusses safety systems in general, and delves into the specific aspects of Nuclear Power Generating Stations, but does not directly address the safety system design basis; rather defers to IEEE Std 603-1998. DO-254, refers to SAE ARP 4754 as a source of development guidance for highly integrated or complex systems and SAE ARP 4761 as a source of safety assessment methods to be used in the hardware design assurance process. While these processes may be similar or equivalent, this report does not make that assessment official as it is beyond the scope, however it is the authors' opinions that these process have similar goals and similar implementation practices including hazard assessment, functional hazard assessments, failure modes effect analysis, and safety assessments.

DO-254 also refers to RTCA DO-178/EUROCAE ED-12 for Software Considerations in Airborne Systems and Equipment Certification as well as RTCA DO-160/ EUROCAE ED-14 for Environmental Conditions and Test Procedures for Airborne Equipment. The current version of DO-178 is DO-178B and the current version of DO-160 is DO-160E. The three, DO-254, DO-178B and DO-160E, combined provide for the overall design assurance of airborne equipment. This report does not assess the considerations or conditions described in DO-178B or DO-160E.

IEEE 7-4.3.2 discusses safety system criteria in terms of the quality of the development, equipment qualification, system integrity, independence and identification; whereas DO-254 discusses design assurance for various levels of criticality with an emphasis on process and objective evidence. The quality, independence, integrity and identification considerations are embedded in the lifecycle processes discussed in DO-254.

Both software and hardware are discussed within IEEE 7-4.3.2 (and IEEE Std 603-1998, and IEEE/EIA Std 12207.0-1996), where DO-254 focuses on complex electronic hardware. Complex electronic hardware is loosely defined as hardware that is capable of producing varying results based on decision making aspects contained within the hardware device. A significant difference between IEEE 7-4.3.2 and DO-254 is the use of the term 'firmware'. IEEE 74.3.2 attempts to define firmware as a combination of a hardware device and computer instructions and data that reside as read-only software on that device. In 1747 E. Morten Avenue, Suite 202 HighRely, Inc. Email: infotahiqhrely.com Phoenix, AZ 85020 Page 12 of 52 +1 602 443 RELY T USA HighRely Copyright 2007 +1 480 452 0951 F

HGiZRELY Rhap~b~Embdm Sqfo~

IEEE - DO-254 Difference Analysis Report:

CS Innovations essence, IEEE 7-4.3.2 defines firmware as non-loadable software. IEEE 74.3.2 also briefly discusses allocating functional and performance requirements to hardware and software (Section C.2.2), but does not discuss allocation to firmware.

DO-254 does not attempt to define firmware; rather choosing to force the application to be defined and allocated as either hardware or software; making the DO-254 method less ambiguous and more robust.

That allocation provides the means to apply appropriate design considerations and leaves no room for interpretation. For those applications allocated to software, the governing design considerations are contained within DO-178B. In fact DO-178B and DO-254 are nearly equivalent in terms of development process considerations; however there are unique concerns in DO-254 that deal with the nature of hardware devices.

IEEE 7-4.3.2 contains multiple references to software and firmware, which is technically out of scope of DO-254; however, some of the software discussions can be related to the development of complex electronic hardware and, therefore, are discussed as best as can be determined throughout this report. Note that the nuclear power industry has an advantage in that massive physical redundancy is considered an appropriate and desired fault mitigation technique and such is inherent in the corresponding standards for

'system integrity'. However, DO-254, being an airborne avionics standard may not have those luxuries due to weight and size (physical) constraints.

The remainder of this section discusses IEEE 7-4.3.2 as the primary item, and then comparisons are made to the guidance provided by DO-254.

a. Safety Assessment Process IEEE 7-4.3.2 is not developed around FAA-type practices regarding the System Safety Assurance (SSA) process.

Safety assurance is driven by IEEE Std 603-1998. The DO-254 design assurance process is based on the substantiation that appropriate measures have been followed to assure functions are designed with safety and determinism for the level of assurance required for the intended aircraft function; for this, safety assessment is to be an iterative process throughout the product life cycle, starting with system safety practices at the front end of the development life cycle in order to substantiate the design assurance level for the hardware and provide objective evidence for such. It is outside the scope of this report to determine if IEEE Std 603-1998 provides an iterative safety assessment process.

The safety guidelines and methods listed in SAE ARP 4761 are the traditional precursor to DO-254 complex electronic hardware development and include Functional Hazard Assessment (FHA), Preliminary System Safety Assessment (PSSA), Failure Mode and Effects Analysis (FMEA), Fault Tree Analysis (FTA) and Common Cause Analysis (CCA) among the techniques for system safety. DO-254 does not specify the details of these plans.

IEEE 7-4.3.2 provides a discussion centered on the identification and resolution of hazards as part of Annex D.

Annex D provides detail into the hazard analysis process and also presents a brief discussion on the use of FTA and FMEA and they appear to be closely aligned with those considerations of SAE ARP 4761. A separate detailed analysis would be necessary to confirm similarities and differences between SAE ARP 4761 and IEEE 7-4.3.2 Annex D.

IEEE 7-4.3.2 provides a discussion centered on computer reliability and quantifiable reliability goals as part of Annex F. Included is a very general discussion describing that an evaluation of the development process can minimize the 1747 E. Morten Avenue, Suite 202 HighRely, Inc. Email: info(ohiqhrely.com Phoenix, AZ 85020 Page 13 of 52 +1 602 443 RELY T USA HighRely Copyright 2007 +1 60 4452 0951 F

X IEEE - DO-254 Difference Analysis Report:

CS Innovations existence of computer failures. The details of these aspects, including the use of anomaly reporting are at the essence of the design assurance guidance of DO-254, but not specifically related to reliability as is discussed in IEEE 7-4.3.2.

DO-254 discusses reliability as associated with safety requirements addressed from a system perspective, to determine the required level of reliability and the level of assurance necessary to satisfy reliability requirements. The system perspective is iteratively assessed as hardware and software requirements are refined and derived throughout the development lifecycle, In addition to fault tree analysis, common mode analysis, and failure modes and effects analysis, statistical reliability analysis methods are referenced for applicable quantitative assessment of random faults, however the techniques for these statistical reliability analyses are not described in DO-254. It is implied that these analyses and assessments occur iteratively throughout the product development life cycle.

b. HardwarePlans IEEE 7-4.3.2 does not directly identify enumerated hardware planning data to substantiate deterministic development that is consistent and repeatable for each facet of the design life-cycle process as detailed in DO-254. IEEE 7-4.3.2 does, however, reference plans such as a quality assurance plan and a configuration management plan. Additionally, IEEE 7-4.3.2 identifies a risk management plan, where DO-254 discusses the mitigation of risk as an iterative process through the development lifecycle based on the design assurance level. Product life cycle development standards are not described in IEEE 7-4.3.2. While IEEE 7-4.3.2 is considered a standard, it is an industry standard and not developed specifically to the unique development project. DO-254 requires the.description and documentation of standards to be uniquely applied to the specific project The complete set of DO-254 Hardware Planning data includes the Plan for Hardware Aspects of Certification (PHAC), the Hardware Design Plan (HDP), the Hardware Process Assurance Plan (HPAP), the Hardware Configuration Management Plan (HCMP), and the*Hardware Verification and Validation Plan (HVVP), along with the project specific standards, including Hardware Requirement Standards, Hardware Design Standards, Hardware Implementation Standards, Hardware Validation and Verification Standards, and Hardware Archive Standards.

Customers regularly use the basic HighRely hardware planning data templates as the basis for their hardware planning and DO-254 compliance; tailoring these templates to their unique projects.

Planning for the use of Commercial off the Shelf (COTS) items is discussed in IEEE 7-4.3.2. DO-254 discusses the planned use of COTS in the PHAC, as "additional considerations". These additional considerations assure that COTS components will be verified through the overall design process, including the supporting processes. The use of an electronic component management process, in conjunction with the design process, provides the basis for COTS components usage. Often, the supporting processes are glanced over by the non-experienced reader. The supporting processes effort is not trivial. COTS components must meet the intent of DO-254.

DO-254 also provides great detail describing the technique of analyzing functional failure paths (FFP) and fail-safe aspects as part of the highest design assurance levels. Functional failure path analysis is often considered the 'cousin' to software structural coverage for complex electronic hardware. When used, FFP analysis provides the means to analyze every functional path throughout a hardware component and the combination of hardware components within the defined system. Each path possible in delivering any particular result based on any input combinations is individually analyzed to assure correct functional operation.

The relationship between the aviation certification authority, the Federal Aviation Administration (FAA) or designee, is not the same for nuclear power generating stations. In this capacity, the system developer liaises with the specific nuclear power generating station, who then liaises with the Nuclear Regulatory Commission (NRC). To draw a parallel, the planning provided by the PHAC could be used as an adequate medium between the developer and the nuclear power generating station. The nuclear power generating station in turn could use the 'PHAC-equivalent' plan 1747 E. Morten Avenue, Suite 202 HighRely, Inc. Email: infol.hiqhrelv.com Phoenix, AZ 85020 Page 14 of 52 +1 602 443 RELY T USA HighRely Copyright 2007 +1 480 452 0951 F

VILIJILY ~

IEEE - DO-254 Difference Analysis Report:

CS Innovations as a medium, similar to the FAA 'cert liaison' process, for explanation and discussion with the NRC regarding the plans for development of complex electronic hardware components destined to implement the requirements specified in the system design and specification data. Ultimately the results presented in Hardware Accomplishment Summary (HAS) provided at the completion of the development project could similarly communicate the accomplishments of the overall project and any variations from those plans presented in the PHAC.

c. HardwareConceptualData IEEE 7-4.3.2 does not detail the process of the conceptual data developed for complex electronic hardware, rather refers, to the creation of the conceptual design of the system in the discussion of quality. It is presumed that either IEEE standards similar to IEEE 12207.0-1996 or IEEE 603-1998 provide detail with respect to hardware, but an in-depth difference analysis is outside the scope of this study. IEEE 7-4.3.2 describes software quality metrics to be considered throughout the software development life cycle, including correctness/completeness during the requirements phase, but does not discuss the means by which correctness and completeness is measured or determined. This is an example where the allocation of requirements to either hardware or software (i.e. not firmware) provides significant value. The development of decision making aspects (logic) of complex electronic hardware (PLDs, FPGAs, ASICs, etc...), while similar to software, is intended to be controlled under the auspices of DO-254; not DO-178B. Indeed, the guidance provided by both DO-254 and DO-178B are very similar; however there are aspects that are unique to DO-254 for the development of complex electronic hardware. It appears that the' IEEE standards do not make that distinction; at least notwithin IEEE 7-4.3.2.

The concepts behind the product and its complex electronic hardware are elucidated and documented under the guidance of DO-254. The hardware conceptual data described in DO-254 includes architectural constraints related to safety, including those necessary to address designerrors and functional, component over-stress, reliability and robustness defects and identifies implementation constraints on system components. Major components are identified. The way the major components contribute to the hardware safety requirements are determined, including the impact of unused functions. Derived and refined requirements, including the interface definition, are related and iteratively included in the system and hardware/software requirements. Requirement omissions and errors are fed back within the development life cycle for appropriate resolution based on their source. The development life cycle is prescribed so as to ensure that these errors and omissions are found. The reliability, maintenance, and test features to be provided are identified.

DO-254 guidance for high design assurance levels includes conceptual data and associated standards for representation of design data, and suggests that these are incorporated into development practices. HighRely finds this practice also to be a very cost-effective process improvement on all programs; even those without high design assurance level requirements.

d. HardwareDetailedDesign Data IEEE 7-4.3.2 does not describe the detailed design data that describes the functions of the code blocks within the FPGA designs, however it does discuss software development under the guidance of IEEE 12207.0-1996. IEEE 7-4.3.2 discusses the use of the requirements to develop a detailed system design as part of the quality discussion.

Further, IEEE 7-4.3.2 describes software quality metrics to be considered throughout the software development life cycle, including compliance with requirements at the design phase and it is presumed that these are applicable to FPGA designs. Since Annex.D of IEEE 7-4.3.2 discusses the identification and evaluation of hazards during the detailed design phase, it is presumed that the detailed design phase is adequately specified in other IEEE standards.

DO-254 is less concerned with such metrics than the IEEE standard, leaving the metric collection definition and collection process to the Production (Quality) Assurance organization.

- HIGHrRLY Fbo* *bcdde* Soi eons IEEE - DO-254 Difference Analysis Report:

CS Innovations The ability to modify the implementation can be severely hampered by the lack of detailed design data providing the why, what and the how of the design. DO-254 provides great detail into the detailed design aspects, including the detailed design objectives and the detailed design process activities, as well as the objective evidence to be developed, configured, and assured according to project plans and standards.

e. HardwareImplementation (specific to FPGA)

IEEE 7-4.3.2 does not directly address complex electronic hardware implementation. The standard is oriented toward system level considerations, with general discussions about software implementation as a function of system quality.

As such, the software quality metrics references life cycle phase characteristics and demands that the implementation be compliant with the design. In this respect DO-254 and IEEE 7-4.3.2 are very similar.

DO-254 provides that a hardware item should be produced using the design data and, where practical, also using the resources intended for the production product, including procurement, kitting, build, inspection and test. Derived requirements generated by the implementation process are part of the overall, iterative life cycle process provided by DO-254. These requirements may have impact to the detailed design process, the requirements process or other appropriate processes. As well, errors and omissions discovered during the implementation process are identified, analyzed and provided to the appropriate process for resolution and continuation of the development process.

In addition, DO-254 discusses the production transition process needed to provide consistent, regular replication of the hardware item. As digital systems intended for use in nuclear power generating systems are not anticipated to be developed in a production line style, production transition may not completely apply; nonetheless, developers would do well to consider these aspects as part of installation and operation of these systems.

f Validation and Verification Process IEEE 7-4.3.2 does not provide great detail into the verification and validation processes for complex electronic hardware, but does reference IEEE Std 1012-1998, the IEEE Standard for Software Verification and Validation. In addition, IEEE 7-4.3.2 discusses verification and validation as a function of quality and as an extension of the program management and system engineering team activities used to identify objective data and draw conclusions about quality, performance and development process compliance. While no verification or validation planning is directly mentioned in IEEE 7-4.3.2, the mention of development process compliance from a quality perspective implies the development of plans for verification and validation and adherence to those plans.

Validation, from the perspective of DO-254, provides assurances that the hardware item derived requirements are correct and complete with respect to system requirements allocated to the hardware item. Verification, from the DO-254 perspective, provides assurance that the hardware item implementation meets all of the hardware requirements, including derived requirements. At the system level, then we can extrapolate that verification ensures that the system is correctly and completely developed to the specified requirements. Validation at the system level ensures that the requirements specified were, indeed the correct requirements for the system.

DO-254 specifically lays out the objectives, process and activities for both verification and validation, and these objectives, processes and activities support the definitions above.

IEEE 7-4.3.2 references IEEE Std 1012-1198 and mentions the 'highest integrity level (level4)'. It is presumed that the level 4 integrity equates to Level A criticality discussed within the aviation community and specifically within DO-254.

The organizational independence criteria identified in IEEE 7-4.3.2, specifically that "development and tests shall be verified and validated by individuals or groups... other than those who developed the original design", is directly 1747 E. Morten Avenue, Suite 202 HighRely, Inc. Email: info(c.highrelv.com Phoenix, AZ 85020 Page 16 of 52 +1 602 443 RELY T USA HighRely Copyright 2007 +1 480 452 0951 F*

M3,KEL Y IEEE - DO-254 Difference Analysis Report:

CS Innovations proportional to the guidance provided by DO-254 for level A critical systems. IEEE 7-4.3.2 specifically calls out the need for independently selecting the verification and validation techniques.

DO-254 also provides for advanced verification methods, including elemental analysis, safety-specific analysis, and formal methods. DO-254 suggests these analyses are applied and occur iteratively throughout the development life cycle and details are provided for each analysis or method. The Functional Failure Path Analysis is used to support these advanced verification methods and analyses and is well suited to ensure correct operation, without introduction of error or unintended function. Data from the analysis is used as a means of design assurance applicable to the hardware circuits, components, and elements, their internal functions, and their interconnectivity in the completed system.

g. Configuration ManagementPractices IEEE 7-4.3.2 identifies good practices for CM as part of the quality discussion. The discussion is targeted specifically at software configuration management. For the purposes of this report, we will extrapolate that to include the development of complex electronic hardware. It is presumed that the IEEE Std 1042-1987 and IEEE Std 828 provides guidance for well defined release structure, naming conventions, baseline control, release practices, and use of rudimentary tools to provide baselines of release. What is not evident is whether these practices are applied for "in-process" CM control baselines and whether they apply to development data. This is implied by the statement that software baselines are established at "appropriate points" in the software life cycle process, but "appropriate points" is a nebulous term. We can presume that the appropriate points would be more clearly refined in the software configuration management plan developed under the guidance of IEEE Std 1042- 1987 (R1993) and 828 - 1998, but cannot ensure that the rigorous of the design guidance of DO-254, including configuration management methods, baselines, problem reporting and resolution, change control, storage and retrieval, environmental control and configuration management tools are included in such a plan; or that they would be applied to development data.

IEEE 7-4.3.2 also refers to baseline control in that 'approved changes' that are created shallbe added to the baseline, but does not specify the approval authority for those changes. It is presumed that the software configuration management plan developed under guidance of IEEE Std 828 - 1998 will establish the change control authority and the multiple release strategy.

The software configuration management discussion in IEEE 7-4.3.2 describes a minimum set of activities, starting with identification and control of all software designs and code. What is not evident is the identification and control of requirements on which the designs and implementation are based; that is, the system, software, and hardware requirements. Apparent is the control of user, operating and maintenance documentation and that fulfills the some needs described in DO-254 for production transition to in-use operation. Also apparent in IEEE 7-4.3.2 is the control of vendor development activities for supplied safety system software. It is presumed that this includes ensuring equivalent processes from vendors, as is indicated in DO-254 discussions regarding compliance substantiation of both supplier development and COTS.

IEEE 7-4.3.2 describes equipment qualification and this is not unfamiliar to developers who use the guidance of DO-254. In fact, qualification is achieved using the vehicles of the Hardware Configuration Index (HCI) to identify those components (and their internal configuration) which are intended for use in actual operation, as well as the Hardware Environment Configuration Index (HECI) to identify those components and tools used in the development and testing of the HCI. The intent is to be able to repeat results consistently by insuring the overall configuration is identified and does not change.

Configuration audits and configuration status accounting are identified as important objectives in both IEEE 7-4.3.2 and DO-254; however the auditing function is discussed in DO-254 as a function of the process assurance practices.

IEEE - DO-254 Difference Analysis Report:

CS Innovations

h. ProcessAssurance Practices IEEE 7-4.3.2 does not directly address process assurance, but does identify quality assurance as a principal theme.

For all intents and purposes, DO-254 process assurance objectives are quality assurance exercises. IEEE 7-4.3.2 recognizes the need for a quality assurance plan, but refers to IEEE Std 730 - 1998 and IEC 60880 (1986-09) [B4]

for the details of that plan. IEEE 7-4.3.2 suggests an approved quality assurance plan compatible with the requirements of IEEE/EIA 12207.0-1996. Approval authority is not specified.

IEEE 7-4.3.2 provides assurance that the required computer system hardware and software are installed in the appropriate system configuration; that firmware and software identification is used to assure correct installation in the correct hardware component, that the software identification can be retrieved from the firmware, and that physical identification requirements meet the identification requirements of IEEE Std 603-1998. There is little doubt that these criteria are, if not completely, nearly compliant with the guidance of DO-254, but further analysis outside the scope of this report would be required to confirm this.

In addition, IEEE 7-4.3.2 presents a need for quality assurance surrounding the diversity requirements of safety systems and the need for diversity to mitigate the risk of common mode failures; although this is more of a safety system specification exercise than a development process exercise. The independent nature of quality (process) assurance is addressed in both IEEE 7-4.3.2 and DO-254 design assurance for the highest (Level A) criticality.

Transition criteria, methods and strategies for assurance that life-cycle processes are not directly addressed as part of the IEEE 7-4.3.2 criteria. The process assurance process presented in DO-254 presents processes checks, transition criteria, when and where they are conducted relative to the complex electronic hardware design, implementation, and testing stages; and identifies process assurance records to be retained as objective evidence of compliance. The same applies to audits: all of the DO-254 related processes and artifacts described are to be audited; the audit points, frequency, depth, and record keeping (checklists) are identified as part of the Hardware Process Assurance Plan (HPAP).

The quality of the hazard analysis is addressed within IEEE 7-4.3.2 and the assurance that the design is enveloped within the identified system constraints is presented along with assurances that non-safety software modules do not adversely affect safety system modules. This is commonly referred to as partitioning of criticality level within aviation systems which are subject to the guidance of DO-254 and DO-178B and can be achieved through architectural mitigation. Architectural mitigation also includes dissimilar implementation, redundancy, monitors, isolation, and cormmand/authority limits specifically employed to mitigate or contain the adverse effects of hardware design and implementation errors. These techniques are employed throughout the development life cycle, but are most cost effective when presented during system design and allocation. Note that DO-254's Production Assurance is basically a Quality Assurance process, applied through development and manufacturing.

i. CertificationLiaison IEEE 7-4.3.2 does not identify a Cert Liaison activity. The relationship of the Nuclear Regulatory Commission (NRC) to the individual nuclear power generating stations and the suppliers of system equipment integrated into those stations is tightly coupled due to the severe nature of potential system failures and the limited number of nuclear power generating stations operating throughout the country. In contrast, there are many aviation systems deployed on a great number of airborne platforms. The individual nuclear power generating station is closely engaged and, in effect performs the cert liaison function that a Designated Engineering Representative (DER) and/or 1747 E. Morten Avenue, Suite 202 HighRely, Inc. Email: infol*hiohrelv.com Phoenix. AZ 65020 Page 18 of 52 +1 602 443 RELY T USA HighRely Copyright 2007 +1 480 452 0951 F

HIGf 7 L Y H~t~t LnOodVO~Solutions IEEE - DO-254 Difference Analysis Report:

CS Innovations Designated Airworthiness Representative (DAR) perform for aviation systems development under the auspices of the Federal Aviation Administration (FAA).

Under the guidance of DO-254, the Cert Liaison activity is identified to assure that the development project is well planned; objective evidence starts with the PHAC as the proposed means of compliance. The cert liaison activity assures that the development project is developed and controlled according to plan, and that the compliance is substantiated; objective evidence of substantiation is presented in the Hardware Accomplishment Summary (HAS).

In effect, the PHAC and the HAS become 'book-ends' that surround the development project and force rigid communication to the cert authority of compliance with regulatory and project objectives. These methods have served the aviation industry well.

The tightly coupled and controlled communication between the NRC, individual power generating stations and the developer of station sub-system has served the nuclear power industry equally as well, it seems, but the addition of these plans could serve to increase awareness and communication for development projects associated with complex digital systems throughout the development life cycle.

2.2 Summary of IEEE 7-4.3.2 and DO-254 The principal difference between IEEE 7-4.3.2 and DO-254 relates to the scope of each document. IEEE 7-4.3.2 serves to amplify criteria established in multiple other IEEE standards as a means of addressing safety systems in nuclear power generating stations; the emphasis being on the system level. The criteria of IEEE 7-4.3.2 principally addresses functional and design requirements for computers used as components of these safety systems and does not specifically address the in-process design considerations of such systems; rather leaving those details to the other IEEE standards.

DO-254 addresses the specific design considerations and provides design guidance for each phase of the development life cycle; the emphasis being on the development processes once the system requirements are specified to ensure that the complex electronic hardware performs its intended function correctly and does not introduce errors or unintended function, while providing a vehicle to identify incorrect or incomplete system specification along with other ambiguities that may only be discovered once the development process has proceeded. In other words, DO-254 prescribes feedback within the scope of the development life cycle to the system aspects used as a basis for that development. An in-depth difference analysis could identify clearly the in-process, development life cycle differences between DO-254 and the other IEEE standards mentioned in IEEE 74.3.2.

2.3 Conclusion It is apparent that IEEE 7-4.3.2 provides excellent engineering guidance and when coupled with the other referenced documents provides for the definition and development of safety systems while mitigating risk of failure throughout the development life cycle. There is little question that the guidance of these standards is sound. DO-254 also provides quite similar guidance, but does not provide the detail in the area of risk management and risk mitigation in a concise section, as does IEEE 7-4.3.2. Risk mitigation and management under DO-254 is integral to the entire development life cycle and is apparent given the iterative nature of the development processes. The secret for all projects is in achieving compliance efficiently and cost-effectively. This analysis has highlighted the differences between IEEE 7-4.3.2 and DO-254 and pointed also to their similarities. Details for each section of DO-254 are provided in the tables which follow.

HIGHRELY.

5)0C

-ebdded So ,benws IEEE - DO-254 Difference Analysis Report:

CS Innovations HighRely Avionics & Certification Center Phoenix, Arizona HighRely, Inc.

"I.14 ky IEEE - DO-254 Difference Analysis ReDort:

CS Innovations 3 Complex Electronic Hardware (CEH) Difference Analysis 3.1 Hardware(ASICIPLD) Planning Process (Section 3)

D0254 Objective Output Data Applicable Difference Analysis Findings Comments Reference Description Level 4.1(1) The hardware PHAC (10.1.1) All IEEE 7-4.3.2 does not define life cycle processes in Life cycle processes are design life cycle HDP (10.1.2) detail, but discusses them generally as part of quality referenced, but the processes are discussions. definition is contained in HVP (10.1.3) defined. other IEEE Standards HVVP (10.1.4) 4.1 (2) Standards are All IEEE 7-4.3.2 does not identify standards. Program-level standards are selected and HCMP (10.1.5) not identified; whether the defined. HPAP (10.1.6) standards referenced would HW Req.Std. (10.2.1) satisfy program-level HW Des.Std. (10.2.2) objectives is out of scope of HWV&V Std. (10.2.3) this study.

4.1 (3) The hardware HW Arch.Std. (10.2.4) All IEEE 7-4.3.2 does not define development development environments but discusses a project environment and verification suitable for effective communications between environments individuals and groups for the resolution of software are selected or project risks as part of the quality discussions.

defined. Development environments are also discussed as a potential source of origination of hazards.

HighRely, Inc.

)HoTELY IEEE - DO-254 Difference Analysis Report:

CS Innovations D0254 Objective Output Data Applicable Difference Analysis Findings Comments Reference Description Level 4.1 (4) The means of All IEEE 7-4.3.2 does not propose means of compliance This practice helps ensure compliance of such as PHAC and HAS. end-to-end success and the hardware communication with design assurance certification authorities.

objectives, including strategies identified using guidance in Section 2.3.4, are proposed to the certification authority.

HighRely, Inc.

HiGURELY A- c- ýv.aow Solutions IEEE - DO-254 Difference Analysis Report:

CS Innovations 3.2 Hardware(ASCI/PLD) ArchitecturalDecisions (Section 2.3)

D0254 Objective Output Data Applicable Difference Analysis Findings Comments Reference Description Level 2.3.1(1) Iterative Requirements All IEEE 7-4.3.2 has safety systems as its principal hardware safety Standards focus, but does not address the iterative nature of the assessment and safety assessments throughout the development life design should cycle.

Trace Data determine derived hardware High-Level Design safety requirements HPA standards.

and ensure that system safety requirements allocated to the hardware are satisfied and ensure that derived requirements are satisfied.

1747 E. Morten Avenue, Suite 202 HighRely, Inc.

H~aohaffony IEEE - DO-254 Difference Analysis ReDort:

CS Innovations D0254 Objective Output Data Applicable Difference Analysis Findings Comments Reference Description Level 2.3.1(2) These derived All IEEE 7-4.3.2 has safety systems as its principal Derived requirements requirements focus, but does not specifically address derived ensuring that safety, should include requirements throughout the development life cycle. reliability and functional safety aspects should be mitigated requirements for through architectural means hardware and established as defined, architecture, traceable items throughout circuits and the development life cycle.

components, and protection against anomalous behaviors, including incorporating specific hardware architectural and functional safety attributes, HighRely, Inc.

HGi& L Y Raeiable C'nbaddod Soluttonsý

-t; IEEE - DO-254 Difference Analysis Report:

CS Innovations D0254 Objective Output Data Applicable Difference Analysis Findings Comments Reference Description Level 2.3.1(3) The hardware IEEE 7-4.3.2 does not discuss design assurance Digital Computers in Safety design assurance levels. Systems of Nuclear Power process and the Generating Stations are of hardware safety the highest criticality.

assessment should jointly determine the specific means of compliance and design assurance level for each finction and should determine that an acceptable level of design assurance has been achieved.

2.3.2 Quantitative IEEE 7-4.3.2 Annex D discusses random faults as an "Either quantitative or Assessment of aspect of identification and resolution of hazards. qualitative judgment of the Random probability of occurrence Hardware Faults should be sufficient to determine if further action is required" HighRely, Inc.

IEEE - DO-254 Difference Analysis Report:

CS lnnnvatinns D0254 Objective Output Data Applicable Difference Analysis Findings Comments Reference Description Level 2.3.3 Qualitative Safety Assessment All IEEE 7-4.3.2 Annex D discusses hardware design Example: "undesired Assessment of Hardware Design Data errors as an aspect of identification and resolution of consequence may in turn Hardware hazards. be used as the top event Design Errors in a FTA, which would and Upsets then be decomposed to lower-level intermediate events and terminated in the lowest level of design for which qualitative or quantitative probabilities could be assessed" 2.3.4(1) For Level A or Safety Assessment, A/B IEEE 7-4.3.2 Annex D discusses hardware design "Anomalous behaviors" is B functions Hardware Design Data errors as an aspect of identification and resolution of not directly mentioned.

implemented in hazards. Annex F discusses computer reliability and hardware, the directly discusses unanticipated behavior, design assurance failure/error handling, or timing and processor considerations loading should address potential anomalous behaviors and potential design errors of the hardware functions.

HighRely, Inc.

Refiable Cmbodded Sqhtlo,,s IEEE - DO-254 Difference Analysis Report:

CS Innovations D0254 Objective Output Data Applicable Difference Analysis Findings Comments Reference Description Level 2.3.4(2) The decision Design Assurance All IEEE 7-4.3.2 is related to systems of the highest The equivalent decision is making process Data criticality and as such does not provide a decision level A and design outlined in making process for determining varying levels of assurance strategies would Figure 2-3 design assurance strategies. IEEE 7-4.3.2 does refer fall under that category, at a should be used to interaction with non-safety systems as part of minimum.

when Annex D discussion on the potential introduction of developing hazards design assurance strategies for each hardware function being implemented.

2.3.4(3) The strategies Safety Assessment, A/B IEEE 7-4.3.2 does not directly address functional described in HW Design Data, failure path analysis, architectural mitigation, Appendix B product service experience, or advanced verification should be ate methods such as elemental analysis, safety-specific applied for analysis, and formal methods related to functional Level A and B failure paths.

functions in addition to the guidance provided in Section 3 through Section 11.

HighRely, Inc.

A, ýwddqwo IEEE - DO-254 Difference Analysis Report:

CS Innovations D0254 Objective Output Data Applicable Difference Analysis Findings Comments Reference Description Level 2.3.4(4) The design Standards, All IEEE 7-4.3.2 discusses hardware architecture in the assurance HW design data, section on safety system criteria and in Annex F strategy should Plans section on computer reliability be selected as a function of the hardware architecture and usage, and of the hardware implementation technology that has been chosen.

HighRely, Inc.

HIrRIA R A, l mbdo IEEE - DO-254 Difference Analysis Report:

CS Innovations 3.3 Hardware(ASICIPLD) Requirements Capture (Section 5. 1)

D0254 Objective Output Data - Applicable Difference Analysis Findings Comments Reference Description Level "_"

5.1.1(1) Requirements Hardware All IEEE 7.4.3.2 does not directly address the methods In this case, we presume are identified, Requirements associated with the development of hardware that software requirements defined and (10.3.1 ), Problem requirements; nor the source of them. Software are equivalent to complex documented. Reports (10.6) requirements steps are identified in section 5.4.2 electronic hardware This includes Qualification of existing commercial computers. requirements, so in essence allocated Annex D discusses the relationship of software the activity is performed.

requirements requirements to hazards.

from the PSSA and derived requirements from the hardware safety assessment.

I t 5.1.1(2) Derived All Derived requirements are not mentioned in IEEE 7-requirements 4.3.2.

produced are fed back to the appropriate process.

HighRely, Inc.

i fbi able Cnibeddod Soblutions i

IEEE - DO-254 Difference Analysis Report:

CS Innovations D0254 Objective Output Data Applicable Difference Analysis Findings Comments Reference Description Level 5.1.1(3) Requirement All Errors and omissions are discussed as part of IEEE Process discussions are omissions and 7-4.3.2 Annex D (Identification and resolution of contained within other errors are Hazards). It does not detail the process, but IEEE standards.

provided to the discusses it as a function of V&V under the general appropriate quality discussions and as an extension of program process for management and system engineering team activities.

resolution.

HighRely, Inc.

HIGHREL Y IEEE - DO-254 Difference Analysis Renort:

CS Innovations 3.4 Hardware(ASICIPLD) PreliminaryDesign (behavioral,Conceptual design)

(Section 5.2)

D0254 Objective Output Data Applicable Difference Analysis Findings Comments Reference Description Level 5.2.1(1) The hardware Conceptual Design IEEE 7-4.3.2 refers to the creation of the conceptual The quality discussion in item conceptual Data (10.3.2.1), All design of the system in the discussion of quality and IEEE 7-4.3.2 provides high-design is Hardware the quality assurance plan. It does not detail the level discussions regarding developed Requirements process of the conceptual data. life cycle processes, but consistent with (10.3.1), does not discuss its requirements. Problem Reports consistency, process (10.6) feedback, tracing, etc...

5.2.1(2) Derived IEEE 7-4.3.2 does not discuss derived requirements, Do other IEEE standards requirements but does discuss software quality and the quality address derived produced are fed assurance plan. It does not detail the process of requirements?

back to the requirements feedback, but discusses it as a function requirements of V&V.

capture or other appropriate processes.

5.2.1(3) Requirement IEEE 7-4.3.2 refers to problem resolution in the omissions and discussion of quality and the quality assurance plan.

errors are It does not detail the process, but discusses it as a provided to the function of V&V.

appropriate processes for resolution.

HighRely, Inc.

IEEE - DO-254 Difference Analysis Report:

CS Innovations 3.5 Hardware(ASICIPLD) DetailedDesign (synthesis, mask generation, fuse file)

(Section 5.3)

D0254 Objective Output Data Applicable Difference Analysis Findings Comments Reference Description Level 5.3.1(1) The detailed Detailed Design Data IEEE 7-4.3.2 discusses detailed design as a function It is presumed that these design is (10.3.2.2) All of quality and the quality assurance plan. IEEE 7- processes are included in developed from Top-Level Drawing 4.3.2 does not specifically define the links or trace other IEEE standards.

the hardware (10.3.2.2.1) process, but discusses process feedback as part of itemnteVV xrie requirements Assembly Drawing the V&V exercise.

and conceptual (10.32.2.2) design data. Hardware/Software Interface Data 5.3.1(2) Derived (10.3.2.2.4) All IEEE 7-4.3.2 does not address derived requirements Do other IEEE standards requirements are Problem Reports directly, but discusses the requirements, design and address derived fed back to the (10.6) implementation processes as a function of quality requirements?

conceptual and the quality assurance plan.

design process or other appropriate processes.

5.3.1(3) Requirement IEEE 7-4.3.2 addresses errors and omissions as a It is presumed that these omissions or function of introduced hazards. Process feedback is process details are included errors are discussed as a function of V&V. in other IEEE standards.

provided to the appropriate processes for resolution.

HighRely, Inc.

Ht~LY IEEE - DO-254 Difference Analysis Report:

CS Innovations 3.6 Hardware(ASIC/PLD) Fabrication(programmingprogrammablecomponents/Implementation)

(Section 5.4)

D0254 Objective Output Data Applicable Difference Analysis Findings Comments Reference Description Level _

5.4.1(1) A hardware item Installation Control All IEEE 7-4.3.2 does not directly address the Digital systems for nuclear is produced Drawings (10.3.2.2.3), representative manufacturing process. power generation do not use which Problem Reports mass-production implements the (10.6) manufacturing processes hardware and are scrutinized closely detailed design on an individual bases.

using representative manufacturing processes.

5.4.1(2) The hardware All IEEE 7-4.3.2 discusses implementation and item assembly compliance with requirements (Installation implementation, and Checkout phase) as part of the quality assembly and discussion, within the discussion of commercial installation data computers and within the discussion of functional is complete. hazards.

5.4.1(3) Derived All IEEE 7-4.3.2 does not directly address derived Do other IEEE standards requirements are requirements. address derived fed back to the requirements?

detailed design process or other appropriate processes.

HighRely, Inc.

Hi~GH LY IEEE - DO-254 Difference Analysis Report:

CS Innovations D0254 Objective Output Data. Applicable Difference Analysis Findings Comments Reference Description Level 5.4.1(4) Requirement All IEEE 7-4.3.2 addresses errors and omissions as a It is presumed that these omissions and function of introduced hazards. Process feedback is process details are included errors are discussed as a function of V&V. in other IEEE standards.

provided to the appropriate processes for resolution.

HighRely, Inc.

HiGHREL Reliabip rýbeddedSohmbns, IEEE - DO-254 Difference Analysis Renort:

CS Innovations 3.7 Hardware(ASIC/PLD) Production Transition (Section 5.5)

D0254 Objective Output Data Applicable Difference Analysis Findings Comments Reference Description Level 5.5.1(1) A baseline is Hardware All IEEE 7-4.3.2 addresses baselines as part of its Identification, control, established that Requirements (10.3.1) discussion about software configuration audits and status accounting includes all Top-Level Drawing management plans in an effort to synchronize are all mentioned.

design and (10.3.2.2.1) engineering and documentation activities at manufacturing 'appropriate points'. It does not directly reference Assembly Drawing data needed to all design and manufacturing data or consistent (10.3.2.2.2) support the replication.

consistent Installation Control replication of Drawing (10.3.2.2.3) the hardware HW/SW Interface item. Data (10.3.2.2.4)

Problem Reports 5.5.1(2) Manufacturing (10.6) All IEEE 7-4.3.2 does not directly address the Digital systems for nuclear requirements HW Configuration representative manufacturing process. power generation do not use related to safety Management Records mass-production are identified (10.7) manufacturing processes and documented and are scrutinized closely and on an individual bases.

manufacturing controls are established.

HlghRely, Inc.

HGaik L Y:

R-oIab Cbdo Soahdons IEEE - DO-254 Difference Analysis ReDort:

CS Innovations D0254 Objective Output Data Applicable Difference Analysis Findings Comments Reference Description Level 5.5.1(3) Derived All IEEE 7-4.3.2 addresses general process feedback as requirements are a part of the V&V discussion, but does not directly fed back to the reference derived requirements.

implementation process or other appropriate processes.

5.5.1(4) Errors and All IEEE 7-4.3.2 addresses errors and omissions as omissions are potentially introduced hazards. Process feedback is provided to the part of the V&V discussion.

appropriate processes for resolution.

HighRely, Inc.

iG7SEL Y Re teCbdo ,A,d/,,sW~

IEEE - DO-254 Difference Analysis Report:

CS Innovations 3.8 Hardware(ASICIPLD) Validation and Verification (timing analysis, behavioralsimulation, gate level simulation and design)

(Section 6)

D0254 Objective Output Data Applicable Difference Analysis Findings Comments Reference Description Level 6.1.1(1) Derived Hardware Trace Data All IEEE 7-4.3.2 does not directly address derived It is presumed that tracing hardware (10.4.1) requirements or trace data development. through life cycle data is a requirements Hardware Review and part of other IEEE against which Analysis Procedures standards.

the hardware (10.4.2) item is to be Hardware Review and verified are Analysis Results correct and (10.4.3) complete.

Hardware Test 6.1.1(2) Derived Procedures (10.4.4)

All IEEE 74.3.2 does not directly address derived requirements are Hardware Test Results requirements, but discuss impact of requirements evaluated for (10.4.5) and evaluation as part of the hazards discussions of impact on safety Hardware Acceptance Annex D Test Criteria (10.5) 6.1.1(3) Omissions and Problem Reports All IEEE 7-4.3.2 addresses feedback as part of V&V Details are likely presented errors are fed (10.6) section under the general quality discussions and as in other IEEE standards.

back to the an extension of program management and system appropriate engineering team activities.

processes for resolution.

HighRely, Inc.

HMi. ýJ:g imIE IEEE - DO-254 Difference Analysis Report:

CS Innovations D0254 Objective Output Data Applicable Difference Analysis Findings Comments Reference Description Level 6.2.1(1) Evidence is All IEEE 7-4.3.2 discusses acceptance based.upon provided that the evidence that the digital system or component, hardware including hardware, software, firmware, and implementation interfaces, can perform its required functions.

meets the requirements.

6.2.1(2) Traceability is All IEEE 7-4.3.2 does not directly address traceability. It is presumed that other established except as related to COTS (section 5.4), but does IEEE standards detail the between infer that requirements, design and implementation traceability process hardware must be verified.

requirements, the implementation, and the verification procedures and results.

HighRely, Inc.

HGibe.. m#"R L IEEE - DO-254 Difference Analysis ReDort:

CS Innovations D0254 Objective . Output Data Applicable Difference Analysis Findings Comments Reference Description Level 6.2.1(3) Acceptance test Hardware Acceptance All IEEE 7-4.3.2 addresses acceptance testing as part of Always the highest design criteria are Test Criteria (10.5) the quality discussions, but does not address assurance is presumed with identified, can consistency with design assurance levels. digital systems for nuclear be implemented power generating stations.

and are consistent with the hardware design assurance levels of the hardware functions.

6.2.1(4) Omissions and IEEE 7-4.3.2 addresses errors and omissions and errors are fed feedback as part of the V&V section under the back to the general quality discussions and as an extension of appropriate program management and system engineering team processes for activities.

resolution.

HighRely, Inc.

%IG/REL IEEE - DO-254 Difference Analysis ReDort:

CS Innovations 3.9 Hardware (ASIC/PLD) ConfigurationManagement Process (Section 7)

D0254 Objective Output Data Applicable Difference Analysis Findings Comments Reference Description Level 7.2(1) Configuration Problem Reports All IEEE 7-4.3.2 provides a section on configuration items should be (10.6) management under the auspices of quality, but also uniquely Hardware refers to IEEE Std 828 and IEEE Std 1042 as the identified, Configuration primary sources.

documented and Management Records controlled. This (10.8) may include, but is not limited to, hardware, design representations of hardware, tools or other data items used for certification credit and baselines

+ 4 7.2(2) Baselines should All IEEE 7-4.3.2 addresses baselines be established.

HighRely, Inc.

HIO3afukEL Y

'ýRO~ab)- CmVcded o)d&fon~

IEEE - DO-254 Difference Analysis Renort:

CS Innovations D0254 Objective Output Data Applicable Difference Analysis Findings Comments Reference Description Level 7.2(3) Problems should All IEEE 7-4.3.2 addresses approval of changes to This is inferred to include be uniquely baselines. problem reporting and identified, tracking.

tracked and reported.

7.2(4) Change control All IEEE 7-4.3.2 addresses approval of changes to This is inferred to include and tracing of baselines. problem reporting and changes should tracking.

be maintained.

This requires that life cycle data identified in the plans should be secure and retrievable.

7.2(5) Archiving, All IEEE 7-4.3.2 does not specifically addresses It is presumed this data is retrieval and archiving, discussed in IEEE Std 828 release of and IEEE Std 1042 configuration items should be controlled.

1747 E. Morten Avenue, Suite 202 HlghRely, Inc.

Email: infoahiqhrely.com Phoenix, AZ 85020 Page 41 of 52

+14804520951 F

HIH R Y kL Ro~beOCbdded1Saoutk,,s IEEE - DO-254 Difference Analysis ReDort:

CS Innovations 3.10 Hardware(ASICIPLD) Process Assurance (Section 8)

D0254 Objective Output Data Applicable Difference Analysis Findings Comments Reference Description Level 8.1(1) Life cycle Hardware Process All IEEE 7-4.3.2 does not provide guidance, other than processes Assurance Records program management as to the compliance to comply with the (10.8) approved plans.

approved plans.

8.1(2) Hardware All The closest that can be seen is IEEE 7-4.3.2 design life cycle addresses through the discussion of software quality data produced metrics:

complies with Correctness/Completeness (Requirements phase) the approved Compliance with requirements (Design phase) plans. Compliance with design (Implementation phase)

Functional compliance with requirements (Test and Integration phase)

On-site functional compliance with requirements (Installation and Checkout phase)

Perfonnance history (Operation and Maintenance phase)

HighRely, Inc.

HOIGable Ymolo IEEE - DO-254 Difference Analysis Report:

CS Innovations D0254 Objective Output Data Applicable Difference Analysis Findings Comments Reference Description Level 8.1(3) The hardware All The closest that can be seen is IEEE 7-4.3.2 item used for addresses through the discussion of software quality conformance metrics:

assessment is Correctness/Completeness (Requirements phase) built to comply Compliance with requirements (Design phase) with the Compliance with design (Implementation phase) associated life Functional compliance with requirements (Test and cycle data. Integration phase)

On-site functional compliance with requirements (Installation and Checkout phase)

Performance history (Operation and Maintenance phase)

HighRely, Inc.

MIGM aY ROI,able rmbevd~dedS~~

IEEE - DO-254 Difference Analysis Report:

CS Innovations 3.11 Hardware(ASICIPLD) CertificationLiaison Process (Section 9)

D0254 Objective Output Data Applicable Difference Analysis Findings. Comments Reference Description Level 9.1 The applicant Hardware All IEEE 7-4.3.2 does not include a means for proposes a Accomplishment compliance.

means of Summary (HAS) compliance for (10.9) hardware.

9.2 The applicant All IEEE 7-4.3.2 does not include discuss the evidence provides of satisfaction to approved plans outside the program evidence that the management and V&V practices.

hardware design life cycle processes have satisfied the hardware plans.

1747 E. Morten Avenue, Suite 202 HighRely, Inc.

HIG;7RELY:

Fe a, 10 OCmbedded Salut ions IEEE - DO-254 Difference Analysis m Report:

m CS Innovations 3.12 Hardware(ASIC/PLD) Additional Considerationfor Levels A&B (Appendix B)

D0254 Objective Output Data Applicable Difference Analysis Findings Comments Reference Description Level 3.0 Design Analysis, Test Data A/B IEEE 7-4.3.2 does not specifically addresses the use Assurance of the design assurance methods based on functional Methods For failure path analysis listed in Appendix B of DO-254 Level A and B Functions.

4 IEEE 7-4.3.2 Deliverables and Aviation Process Equivalent The information in this section presents the deliverables from the Nuclear Standards on the left, followed by the Aviation Deliverable equivalent. The final right-most column discusses either the Objective Evidence or Process Equivalent within the Aviation processes, DO-254 and the system engineering information flow from processes such as ARP 4754 and ARP 4761. The DO-254 guidelines call for an iterative development with multiple re-entry points to assess the system and safety aspects. In addition DO-254 calls for a Hardware Accomplishment Summary and standards that are not listed in the IEEE 7-4.3.2 output provided. It is presumed that the PHAC and the Software Management Plan are reasonably equivalent and this report discusses that IEEE 7-4.3.2 does not call for a cert liaison process which includes a stated means of compliance.

HighRely, Inc.

IEEE - DO-254 Difference Analysis Report:

CS Innovations 4.1 DO-254 Deliverables are defined as:

Hardware Life Cycle Data by Hardware Design Assurance Level and Configuration Control Code{TC "Table A-I Hardware Life Cycle Data by Hardware Design Assurance Level and Configuration Control Code" \f t}

D0254 Data Hardware Life Cycle Data Objectives jSubmit Level A Level B Level C Level D Section 10.1 Hardware Plans 10.1.1 Plan for Hardware Aspects of Certification 4.1(1,2,3,4) S HCI HCI HCI HCI 10.1.2 Hardware Design Plan 4.1(1,2,3,4) HC2 HC2 HC2 NA 10.1.3 Hardware Validation Plan 4. 6.1(1,2,3,4)

______ ~~~6.1.1(1) H2 H2 H2 N 10.1.4 Hardware Verification Plan 4.1(1,2,3,4); S HC2 HC2 HC2 HC2 6.2.1(1) 10.1.5 Hardware Configuration Management Plan 4.1(1,2,3,4); 7.1(3) HCI HCI HC2 HC2 10.1.6 Hardware Process Assurance Plan 4.1(1,2,4);

8.101,2,3) HC2 HC2 NA NA 10.2 Hardware Design Standards *i: * "

10.2.1 Requirements Standards 4.1(2) HC2 HC2 NA NA 10.2.2 Hardware Design Standards 4.1(2) HC2 HC2 NA NA 10.2.3 Validation and Verification Standards D 4.1(2) HC2 HC2 NA NA 10.2.4 Hardware Archive Standards 4.1(2)55.(1) HC2 HC2 NA NA 10.3 Hardware Design Data ?i * .

_.___

5.1.1(1,2); 5.2.1(2);

10.3.1 Hardware Requirements 5.3.1(2); 5.4.1(3); HC1 HCl HC1 HCl 5.5.1(1,2,3);

________ ________________________________6.1.1(1,2); 6.2.1 (1) ______ ______ __

1747 E. Morten Avenue, Suite 202 HighRely, Inc.

HZ~y RoiGab~ mbvd A

IEEE - DO-254 Difference Analysis ReDort:

CS Innnv3tinn~

D0254 Data Hardware Life Cycle Data Objectives ( Submit Level A Level B Level C Level D Section 10.3.2 Hardware Design Representation Data - '". __"_

10.3.2.2.1 Top-Level Drawing 5.3.1(1); 5.4.1(2); S HCI HCI HCI HCI 5.5.1(1) 10.3.2.2.2 Assembly Drawings 5.3.1(1); 5.4.1(2); HCI HCI HCI HCI 5.5.1(1) 10.3.2.2.3 Installation Control Drawings 5.4.1(2); 5.5.1(1) HCI HCI HCI HCI 10.3.2.2.4 Hardware/Software Interface Data 5.3.1(1); 5.5.1(1) HCI HCI HCI HCI 10.4 Validation And Verification Data . .. .. ._. *. ** __, _ _. .,..

10.4.1 Hardware Traceability Data 6.1.1(1); 6.2.1(1,2) HC2 HC2 HC2@ HC2c 10.4.2. Hardware Review and Analysis Procedures . 6.1.1(1,2); 6.2.1(1) HCI HCI NA NA 10.4.3 Hardware Review and Analysis Results

6.1.1(1,2); 6.2.1(1) HC2 HC2 HC2 HC2 10.4.4 Hardware Test Procedures . 6.1.1(1,2);6.2.1(1) HCI HCI HC2 HC2(

10.4.5 Hardware Test Results

6.1.1(1,2); 6.2.1(1) HC2 HC2 HC2 HC2 (

10.5 Hardware Acceptance Test Criteria 5.5.1(3),6.2.1(3) HC2 HC2 HC2 HC2 5.1.1(3); 5.2.1(3);

10.6 Problem Reports 5.3.1(3); 5.4.1(4); HC2 HC2 HC2 HC2 5.5.1(4); 6.1.1(3);

6.2.1(4); 7.1(3) 10.7 Hardware Configuration Management Records 5.5.1(1); 7.1(1,2,3) HC2 HC2 HC2 HC2 10.8 Hardware Process Assurance Records 7.1(2); 8.1(1.2,3) HC2 HC2 HC2 NA 10.9 Hardware.Accomplishment Summary 8.1(1,2,3) S HCI HCI HCI HC1 HighRely, Inc.

IEEE - DO-254 Difference Analysis Renort:

CS Innovations

@*Data that should be submitted is indicated by an S in the Submit column. HC 1 and HC2 data used for certification that need not be submitted should be available.

The objectives listed here are for reference only. Not all objectives may be applicable to all assurance levels.

(D If this data is used for certification, then its availability is shown in the table. This data is not always used for certification and may not be required.

This can be accomplished informally through the certification liaison process for Levels C and D. Documentation can be in the form of meeting minutes and and/or presentation material.

If the applicant references this data item in required data items, it should be available.

Only the traceability data from requirements to test is needed.

Q) Test coverage of derived or lower hierarchical requirements is not required.

HighRely, Inc.

mijGff'Ey Ro >býFmeddS~fos J IEEE - DO-254 Difference Analysis Report:

CS Innovations Required Certification

1. Plan for Hardware Aspects of Certification Documentation (PHAC) 16. Installation Control Drawings

2. Hardware Design Plan 17. Hardware/Software Interface Data

3. Hardware Validation Plan 18. Hardware Traceability Data

4. Hardware Verification Plan (HVP) 19. Hardware Review and Analysis

5. Hardware Configuration Management Plan Procedures

6. Hardware Process Assurance Plan 20. Hardware Review and Analysis Results

7. Hardware Design Standards 21. Hardware Test Procedures

8. Requirements Standards 22. Hardware Test Results

9. Validation and Verification Standards 23. Hardware Acceptance Test Criteria

10. Hardware Archive Standards 24. Problem Reports

11. Hardware Requirements 25. Hardware Configuration Management

12. Conceptual Design Data Records

13. Detailed Design Data 26. Hardware Process Assurance Records

14. Top-Level Drawing 27. Hardware Accomplishment Summary (HAS)

15. Assembly Drawings Copyright HighRely 2005 Slide 215 HighRely, Inc.

H.I7E;'

fotjaatEmbdded sofalons IEEE - DO-254 Difference Analysis Report:

CS Innovations 4.2 Deliverables of IEEE 7-4.3.2 Vs. Aviation Standards Nuclear Deliverable Aviation Deliverable Objective Evidence or Process Equivalent SAE SAE RTCA ARP 4754 ARP 4761 DO-254 Planning Documentation:

Software Management Plan PHAC Plan for Hardware Aspects of Certification Software Development Plan HDP Hardware Design Plan Software Test Plan HVP Hardware Verification Plan Software QA Plan HPAP Hardware Process Assurance Plan Integration Plan HDP Hardware Design Plan Installation Plan HDP Hardware Design Plan Maintenance plan Production Transition Process Training plan Production Transition Process Operations Plan Production Transition Process Software Safety Plan PSSA Preliminary System Safety Assessment Software V&V Plan HWP Hardware Verification and Validation Plan Software CM Plan HCMP Hardware Configuration Management Plan HRqtS Hardware Requirement Standards HDesS Hardware Design Standards HImpS Hardware Implementation Standards HArchS Hardware Archival Standards Design Specific Documentation:

Requirements Specifications SSS HRD System Subsystem Specification Requirement Traceability Matrix I System Information Flow Process/Traceability Data HighRely, Inc.

RoaikCmbdde&AS~,

- DO-254 Difference Analysis Report:

CS Innovations Nuclear Deliverable Aviation*Deliverable Objective Evidence or Process Equivalent SAE SAE RTCA ARP 4754 ARP 4761 DO-254 Design Specifications System Information Flow Process Major hardware component description and qualification System Information Flow Process.

Hardware & Software Architecture HRD/HDD Hardware Requirements or Design Data Software Requirements Specification .. _HRD Hardware Requirements Data Software Design Description HDD Hardware Design Data (Conceptual and Detail)

Code Listings HCI Hardware Configuration Index/Top Level Drawing/

Assembly Drawings System Build Documentation HECI Hardware Environment Configuration Index Top Level Drawing/Assembly Drawings Test Plans and Documentation HVVP Hardware Verification and Validation Procedures Environmental test plans, procedures, and results HWP/HWD Environmental Configuration Hardware Verification and Validation Plan/Data/Results Unit test plans, procedures, and results HWP/HVVD Hardware Verification and Validation Plan/Data/Results Integration test plans, procedures, and results HWP/HVVD Hardware Verification and Validation Plan/Data/Results Factory acceptance test plans, procedures, and results Production Transition process Site acceptance test plans, procedures, and results Production Transition process Installation test plans,. procedures, and results HWP/HWD Hardware Verification and Validation Plan/Data/Results Analysis Documentation:

Requirements Safety Analysis PSSA Preliminary System Safety Assessment Design Safety Analysis PSSA Preliminary System Safety Assessment.

Code Safety Analysis PSSA Preliminary System Safety Assessment Integration Safety Analysis PSSA Preliminary System Safety Assessment Validation Safety Analysis PSSA Preliminary System Safety Assessment HighRely, Inc.

H1G~RL Y Foat,- '-C--,-wdSc.1utions%

IEEE - DO-254 Difference Analysis Report:

CS Innovations Nuclear Deliverable Aviation Deliverable Objective Evidence or Process Equivalent SAE SAE RTCA ARP 4754 ARP 4761 DO-254 Installation Safety Analysis SSA System Safety Assessment Change Safety Analysis SSA System Safety Assessment Failure Modes and Effects Analysis (FMEA) FMEA Failure Mode and Effects Analysis

__"_HAS Hardware Accomplishment Summary Verification and Validation (V&V) Reports:

V&V Requirements Analysis Report HVVR Hardware Verification and Validation Results V&V Design Analysis Report HVVR Hardware Verification and Validation Results V&V Implementation Analysis & Test Report HVVR Hardware Verification and Validation Results V&V Integration Analysis & Test Report HVVR Hardware Verification and Validation Results V&V Validation & Test Report HWR Hardware Verification and Validation Results V&V Validation & Test Report _ HWR Hardware Verification and Validation Results V&V Change Report *HVVR Hardware Verification and Validation Results Installation, Operations and Maintenance Documentation:

Operations Manuals System Process Maintenance Manuals System Process Training Manuals System Process Installation Configuration Tables System Process Spare Parts list System Process Repair Planning System Process System Retirements Plan System Process HighRely, Inc.

v t e Letter Sequence Request
TAC:MD4839, Removal of Main Steam and Main Feedwater Valve Isolation Times from Technical Specifications (Approved, Closed)
Initiation Request, Request, Request, Request, Request, Request, Request, Request, Request, Request, Request, Request, Request Acceptance, Acceptance Administration Withholding Request Acceptance, Withholding Request Acceptance, Withholding Request Acceptance, Withholding Request Acceptance, Withholding Request Acceptance, Withholding Request Acceptance, Withholding Request Acceptance, Withholding Request Acceptance, Withholding Request Acceptance, Withholding Request Acceptance Meeting, Meeting, Meeting, Meeting, Meeting, Meeting, Meeting Questions 7 December 2007 27 November 2007 27 November 2007 Answers 9 May 2007 16 January 2009 Results Approval, Approval Other: ET 09-0008, Additional Information Regarding Main Steam and Feedwater Isolation System (Msfis) Controls Modification, ET 09-0011, Additional Information Regarding Main Steam and Feedwater Isolation System (Msfis) Controls Modification, ML072970028, ML080980134
MONTHYEAR2007-08-08 [Table View]

ET 07-0041, Additional Response to NRC Letter Dated August 8, 2007, Regarding the Main Steam and Feedwater Isolation System Controls Modification

Text

Reference:

Subject:

Navigation menu

ET 07-0041, Additional Response to NRC Letter Dated August 8, 2007, Regarding the Main Steam and Feedwater Isolation System Controls Modification

Text

Reference:

Subject:

Navigation menu

Search