Configuration Management for Digital Upgrades Configuration Management Benchmarking Group 2008 Conference

1. Configuration Managementfor Digital UpgradesConfiguration Management Benchmarking Group 2008 Conference Scott Patterson Program Manager for I&C Obsolescence Pacific Gas & Electric Co. Diablo Canyon Power Plant Tuesday June 3rd , 2008

2. Digital vs. Analog • Digital Equipment goes obsolete much faster than analog equipment • In some cases the equipment is obsolete before you install it • Technology is changing very fast and is hard to keep up with it • Digital requires a CM program that can handle a dynamic change process and that is more complex than analog • Digital Equipment is much more capable and flexible • It takes many analog modules to do complex algorithms • Analog is very hard to modify • Not much analog equipment currently made or supported • Digital is more accurate – convert to digital once, then accuracy stays the same • With capability and flexibility comes complexity • Digital Equipment contains significantly more configurable parameters • Hardware • Firmware • Communication Parameters • Software

3. Hardware • Monitors, Workstations, Servers, Printers, …. • Availability of a monitor or workstation is 6 months to 1 year which is shorter than most design processes • We are developing specifications for these devices that list the minimum requirements • Minimizes design changes when equipment is no longer available • Allows flexibility for these less critical components • In most cases the new equipment is faster and more capable • How do you handle this?

4. Hardware (cont) • PLC or Embedded Systems • Lifetime is usually much longer • DCPP has selected two main hardware platforms based on a detailed evaluation to try to minimize obsolescence issues • Key attributes to minimize obsolescence • Customer base • Past history • OEM equipment • Fewer platforms means fewer differences in CM • Can have many revision levels of hardware and firmware • Configuration is documented on plant drawings • How do you document this?

5. Hardware (cont) • Configurable Devices • Paperless Recorders • Single Loop Controllers • Digital Indicators • If the device is simple enough, SQA plans are not required • Configuration is documented in a plant drawing • Available for disaster recovery • Maintenance needs this information if the component is replaced

6. Firmware • How do you maintain configuration or version control of Firmware? • In most cases the vendor maintains the firmware CM for non-safety and safety systems since they wrote or are responsible for it • However tracking is still needed to keep track of what version is installed • Firmware versions are usually flashed and are accessed through a diagnostic utility • Needs to be part of the disaster recovery procedure • Revision levels can change fast when consecutive upgrades are being installed

7. Firmware (cont) • Compatibility of different firmware versions • New hardware and software may require a new firmware version to be functional or to take advantage of new features • Need to know what versions are compatible • This information is usually controlled by the vendor but it is still important to understand this and document it • How do you document what firmware works with what hardware or software?

8. Communication Parameters • Plant Data Network • IP Addresses • Switch, Firewall, and Router Configurations • Cyber Security • How do you document these parameters? • Communications between systems • Safety to Non-Safety Systems • Control Systems to other control systems • Isolated networks • Connection to the LAN

9. Software • PLC or Embedded Software • Usually one file – Tricon = .pt2 file, AB = .acd file • Simple to program – IEC 61131-3 compliant – Function Blocks, Ladders, Structured Text, etc. • Most have version control and security built in • Configuration software has defensive measures built in • Compilers have error checking • Self Documenting • Easier to specify requirements and test, the algorithm is usually well defined

10. Software (cont) • HMI or Display Software • Much harder to V&V and track changes • Limited error checking or defensive measures to prevent you from doing something that will not work • Hundreds of files are generated • Different scripts can be used for every window/object • Very hard to document the configuration due to the number of attributes and variables • Requirements are hard to define • Hard to test for negative requirements • Licensing of the software and tracking where each license is installed can be hard • How do you manage this?

11. Software Lifecycle Phases • Design Phase – Conceptual Design and Specification Development • Implementation Phase – Software Development and V&V Activities • Maintenance Phase – Operation and Maintenance

12. Software Lifecyle

13. IEEE Documents Used as Reference • IEEE 1059‑1993: Guide for Software Verification and Validation Plans. • IEEE 1012‑1998: Standard for Software Verification and Validation. • IEEE 730‑1998: Standard for Software Quality Assurance Plans. • IEEE 830‑1998: Recommended Practice for Software Requirements Specifications. • IEEE 1233‑1998: Guide for Developing System Requirements Specifications. • IEEE 1016‑1987: Recommended Practice for Software Design Descriptions. • IEEE 1016.1‑1993: Guide to Software Design Descriptions.

14. Software Integrity Levels • IEEE-1012-2004 • “Software integrity levels are a range of values that represent software complexity, criticality, risk, safety level, security level, desired performance, reliability, or other project-unique characteristics that define the importance of the software to the user and acquirer.” • High-integrity software requires a larger set of V&V processes and a more rigorous application of V&V tasks.

15. Software Integrity Levels (IEEE-1012-2004) SIL 4 – Software element must execute correctly or grave consequences (loss of life, loss of system, economic or social loss) will occur. No mitigation is possible. SIL 3 – Software element must execute correctly or the intended use (mission) of the system software will not be realized, causing serious consequences (permanent injury, major system degradation, economic or social impact). Partial to complete mitigation is possible. SIL 2 – Software element must execute correctly or an intended function will not be realized, causing minor consequences. Complete mitigation possible. SIL 1 – Software element must execute correctly or intended function will not be realized, causing negligible consequences. Mitigation not required.

16. Software O&M • CF2.ID2 – Configuration Management for Computers and Software Used for Plant Operations and Operations Support • This procedure provides guidance for developing the SQA Plan for a system. • IEEE Std 828‑1998, IEEE Standard for Software Configuration Management Plans

17. Software O&M • The SQA Plan for a system • Describes if this is vendor supplied software or in-house developed software and how it will be controlled • Contains Disaster Recovery Instructions • How to make/document a software change • Media Control (Source Safe, Location of backup disks, etc.) • What modifications require a design change • What approvals are needed to make a change • An O&M software change will go through a similar process to the software development stage for V&V activities

18. Summary • Digital requires a much more rigorous CM program • Take advantage of the IEEE documents as guidance • Start with non-safety systems to develop the processes used to track CM • Develop and refine the process early establish a consistent process • A good CM process will minimize issues with digital equipment

19. Questions? Scott Patterson Pacific Gas & Electric Co. Diablo Canyon Power Plant Program Manager for I&C Obsolescence Project Manager, Supervisor