Configuration Management for Digital Upgrades Configuration Management Benchmarking Group 2008...

Configuration Managementfor Digital Upgrades

Configuration Management Benchmarking Group 2008 Conference

Scott PattersonProgram Manager for I&C Obsolescence

Pacific Gas & Electric Co.Diablo Canyon Power Plant

Tuesday June 3rd , 2008

Configuration Management for Digital Upgrades

Digital vs. Analog

1. 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

2. 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

3. Digital Equipment contains significantly more configurable parameters• Hardware• Firmware• Communication Parameters• Software


Hardware

1.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?


Hardware (cont)

1. 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?


Hardware (cont)

1. Configurable Devices• Paperless Recorders• Single Loop Controllers•Digital Indicators

2. If the device is simple enough, SQA plans are not required

3. Configuration is documented in a plant drawing• Available for disaster recovery•Maintenance needs this information if the component is replaced


Firmware

1. 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


Firmware (cont)

1. 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?


Communication Parameters

1. Plant Data Network• IP Addresses• Switch, Firewall, and Router Configurations•Cyber Security•How do you document these parameters?

2. Communications between systems• Safety to Non-Safety Systems•Control Systems to other control systems• Isolated networks•Connection to the LAN


Software

1.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


Software (cont)

1. 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?


Software Lifecycle Phases

1. Design Phase – Conceptual Design and Specification Development

2. Implementation Phase – Software Development and V&V Activities

3. Maintenance Phase – Operation and Maintenance


Software Lifecyle

C oncep tua lD es ign

Design Phase

Implementation Phase

Maintenance Phase

ApplicationDevelopm ent

(Coding) Installation

Design DocumentSystem FunctionalitySystem RequirementsDesired O ptions, FeaturesConstra ints& etc.(IEEE 1233)

(D esign Engineering)

FunctionalRequirem entsSpecification

SoftwareRequirem entsSpecification Software Design

Description

SoftwareVerification &

Validation Report

Installation Tests(PMT, STP)

SQA P lan(Volum e 10)

(D ig ita l System s Engineering)

(D ig ita l System s Engineering)

Disaster RecoveryRevisions

Req. T race MatrixAcceptance TestingDoc. of O verall ReviewProblem Reporting

System Level TestingInsta lla tion TestingO perability Tests

(IEEE 1012)

(IEEE 830)

(IEEE 1016)

V&VActivity

V&VActivity

V&VActivity

(IEEE 1012)

.


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.


Software Integrity Levels

1. 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.”

2. High-integrity software requires a larger set of V&V processes and a more rigorous application of V&V tasks.


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.


Software O&M

1. CF2.ID2 – Configuration Management for Computers and Software Used for Plant Operations and Operations Support

2. This procedure provides guidance for developing the SQA Plan for a system.

3. IEEE Std 828‑1998, IEEE Standard for Software Configuration Management Plans


Software O&M

1. 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


Summary

1. Digital requires a much more rigorous CM program

2. Take advantage of the IEEE documents as guidance

3. Start with non-safety systems to develop the processes used to track CM

4. Develop and refine the process early establish a consistent process

5. A good CM process will minimize issues with digital equipment


Questions?

Scott PattersonPacific Gas & Electric Co.

Diablo Canyon Power PlantProgram Manager for I&C Obsolescence

Project Manager, Supervisor

Configuration Management for Digital Upgrades Configuration Management Benchmarking Group 2008...

Documents

Transcript of Configuration Management for Digital Upgrades Configuration Management Benchmarking Group 2008...