design of high integrity embedded systems for control and ... · 2/19/2017 · distinguished...

Feb 19,2017 CFDVS, IIT Bombay 1

Design of High Integrity Embedded

Systems for Control and Monitoring: DAE

Perspectives from Safety and Security

Debashis DasDistinguished Scientist, BARC & C&MD, ECIL

Agenda

Computer based I&C System Evolutions in NPPs

Safety Principles

Security Requirements

Gap Areas

Path Ahead


Overview and Evolution of I&C in Indian NPPs

•Reactor Protection

•Reactor Power Regulation

•Important Process Controls

•Channel Out let

Temperature Monitoring

•Controls for on line

Fuelling

•Over All control Room

•Radiation Monitoring

•Smooth Operation of Plant

•Automatic plant Control

•Information display

•Automatic Safe shut down

•Late 70’s: Relay and Analog based controls

•80’s and 90’s: 8 bit/16bit Microprocessor based Digital controls

• AHWR , 700 MWe PHWR and 500 MWe PFBR : Standardization,

Deployment of FPGA , Distributed Architecture with large Screen Displays and

Screen Based Controls, Qualified platform based development, safety and

cyber security

• The Regulatory process has also evolved and matured concurrently

Role of C&I Important Systems

Evolution


NPP C&I Journey


RAPS and MAPS Control Room

Control Room of 540 MWe PHWR

Evolution of Control Rooms Control Room of RAPS 1&2

Control Room of KGS 1

Sensors to HMI

Computerized

Operator Information

Systems

Control panels

Reactor Regulating

Core Temperature

Monitoring

Safety

Interlocks

Fuel Handling

Controls

Process ControlReactor

Protection

Thermo -

couples

RTDs

Pressure

gauges and

transmitters

Flow gauges

and

Transmitter

Potentiometer

LVDT, RVDT &

Synchros

Solenoids

Motors

Valves

SPN

detectors

Ion

chambers

BF3

Counters

Control Rod

Drives

Mechanism

Level

switches

Radiation

monitoring

Electrical

SCADA

Control Equipment

Field Instrumentation and Actuators

Human Machine Interface

High Temp Fission ChamberFeb 19,2017 CFDVS, IIT Bombay 6

Fault Tolerant Systems Computer Control System Fuel Handling Control

system

Temperature Sensors Door Way Monitor

Area Radiation Monitor Radiation Detectors


Reactor Regulating

System for 540 MWe

Pressurized Heavy

Water Reactor

OCN

REACTOR

Control

Panel

Complex

Design


HMI of TAPS 4 PCS



V&V and Regulation

• I&C Designers started moving towards application of Computers

– Qualification Issues

– Lack of Standard Review Process

– DAE Initiated IV&V practices

• Initial Challenges in Verification of Reactor Protection System

Design reviews, Code Inspection

Verification Tool Unavailability

Massive manual efforts

• Need for Safety Classification

– Development of AERB Guides D-1,D-10,D-20

• Identification of Software Process Standards

– Inputs from IEEE, IEC60880, US NRC

– Development of AERB D-25

• Development of In-house Static Analysis Tools (Assembly and C) (1989-95)

• Identified Thrust Areas in Formal Methods, V&V

Software for I&C Systems for

Nuclear Power Plants

safety functions of emergency shutdown, core cooling and containment (IA)

continuous control functions such as reactivity control or primary heat transport system control (IB)

data acquisition, monitoring and display arid information processing functions, and design of nuclear plant systems (IC).


Emphasis on Verification

• Verifiable Requirements.

• Stage wise Development with Lifecycle

Management

• Verification must take place throughout the

development.

• Verification should use techniques

different from the techniques used by the

developers.


Cybersecurity

Architecture

• Network Security

• Identity Authentication and Access Management

• Data Protection & Integrity

• Monitoring Vulnerability and Patch management

• Supply Chain Management

• End Point, Server, Device Security

Cybersecurity Architecture

Data Flow Management


Data Flow to be restricted across

Security zones

Agenda


Safety Principles


Gap Areas

Path Ahead



Software is omnipresent in

embedded Systems

Intelligent

I/O Boards

Intelligent

I/O BoardsCPU

Memory

FPGAIntelligent

Bus

NIB

Switch

Displays

Safety and Functional Safety

• Safety: Freedom from unacceptable risk of physical injury or of damage to the health of people, either directly, or indirectly as a result of damage to property or to the environment.

• Functional safety is the


detection of a potentially dangerous condition

activation of a protective

or corrective device or

mechanism to

prevent hazardous

events


Software System Safety

• Safety-Critical Software Functions are

those software functions failure of which

can directly or indirectly, in consort with

other system component behaviour or

environmental conditions, contribute to the

existence of a hazardous state

Design Principles

Systems important to safety are kept simple

Defence-in-depth and Principles of Diversity are applied.

Fail-safe principle is incorporated into the design of systems. Safety is built into the system, not added on.

High functional reliability and periodic testability commensurate with the safety functions to be performed

Designs are subject to third party assessment and licensing review.



Issues with Computer based I&C

Systems


Software & Hardware Caveats:

Technology & Regulatory Issues

Complex Requirements (SW & HW) How to check Inconsistency of requirements?

Software Software interfaces are conceptual: How to conduct

Effective Reviews?

Difficult to test for Corner case bugs: How to reduce dependency on low level testing ?(Effectiveness depends on Human factor)

Internal States difficult to access : How to design for Effective Monitoring to make systems fail safe?

Trustworthiness of Compiler & Operating System Output of a compiler is put onto the controller running a

RTOS


Generic Requirements of Software

Performing Safety Critical Functions

Upon detecting an anomaly or failures, the

software should remain in or revert to a safe

state (Runtime Monitoring?)

Override commands should require multiple

operator actions

The software should notify the controlling

executive during or immediately after transiting

to an unsafe state

Hence Requires a thorough Design Review


Design Assessment

Assessment using a

engineering process

systematic

technically appropriate

carefully controlled

fully documented


System Functional Assessment

Provide Evidence

Correct

Safe Secure

Testable


Why we need Process Standards?

Assessment of software is guided by a regulatory standard. The documentary evidence is recorded as a safety case.

Since dependability cannot be derived concretely from an assessment, we need an assurance on the development process.

“Because we cannot demonstrate how well we have done, we demonstrate how hard we tried” Dr. John Rushby, SRI


IEC 61508 SIL

Safety-integrity : probability of a safety related

system satisfactorily performing the required

safety functions under all the stated conditions

within a stated period of time.

Safety integrity level : discrete level (one out of a

possible four) for specifying the safety integrity

requirements... where SIL 4 has the highest

level of safety integrity and SIL 1 the lowest.


IEC 61508, Risk Analysis and SIL

Risk analysis guides risk reduction.

– By the allocation of development resources.

A Class 1 (Intolerable) risk usually

– requires software designed to SIL3/4 (highest)

level.

A Class 2 (Undesirable) risk might

– Require software designed to SIL2/3 levels.

Higher SILs require more resources…


Verification of Software Performing Safety

Functions

Architecture : Event Triggered/Time Triggered

Control flow, data flow and information flow

Interrupt handling and exceptions handling in embedded systems

Appropriateness of Finite Arithmetic, pointers and Buffer usage

Functional and performance requirements (unit and integration testing)

Communication protocols

Compliance to quality standards and programming guidelines

Absence of malicious programs.

Agenda


Safety Principles


Gap Areas

Path Ahead



Software & Hardware Security Caveats

Hardware Trustworthiness of Processors

Implementation of the Instruction Set Architecture (has it been implemented correctly?)

Issues with pipelines (has it been implemented correctly?)

Robustness from security (Has it been evaluated from perspectives of system security?)

• Supply Chain Issues in Security Sensitive ApplicationsHardware Components

COTS

Maintenance Support

• Programmable Hardware Devices like FPGA Software Issues (Challenges & Issues with Design Process & Tools

are same as in software)

Device Failure : Can we monitor their internal states to predict failure?


Software & Hardware Security Analysis

Security Vulnerabilities & Evaluation of Embedded

Systems

Evaluation of Architecture

Software Hardware

Communication

Agenda


Safety Principles


Gap Areas

Path Ahead


Gaps

• Non Repeatable process

• Enormous Efforts

• Person Specific Interpretation

Human factors in Design &

Verification.

• Reduce Judgmental Errors

• Rigorous and RepeatableTool

driven/aided



Testing

Is Complex

Dependability Assessment should not guided by Testing Alone


Need for Rigorous and Precise Program Analysis

to detect data flow anomalies, RTE

Checking compliance to MisraC is not enough


Need to think beyond Testing

• HL Modelling and Model Checking

Verification of High Level Requirements

(HLR)

• Verification of Code against LLR (Safety +Security)

Verification of Low Level Requirements

(LLR)

• Automated Program Analysis

Verification of Absence of Runtime

Errors (RTE)


Effort Reduction for Better Design

Review Better Review of higher level specification

– Domain Specific Languages

Invest efforts in validating automated code generators

– Verify once and use many

– Reduce Efforts in Programming and Unit Testing

Promote Component based Designs

– Reuse Verified components with due care of environment and rigorous traceabilty.

Can be

reviewed

by domain

experts


DAE Contributions through Extramural

Research

• Setting up of CFDVS at IIT Bombay to

promote research in Formal Verification

Techniques (CFDVS - I Phase)

• Development of Tools and Techniques with

improved precision and scalability at

CFDVS (CFDVS – II Phase)

Contribution from CFDVS-

BARC Collaboration

• MSC, Timing Diagrams

• Uniform Semantics to Specification FormatsRequirement

Analysis

• Disjunctive Decomposition

• Parallel Model Checking

Model Checking for Large State Space

Designs

• Multiple domains for analysis

• User configuration PossibleProgram Analysis for

Runtime Errors

• Training of Manpower to nurture and effective use

Skill Set Development


Agenda


Safety Principles


Gap Areas

Path Ahead


Verification Technology is a

niche area

We have come a long way together

CFDVS, IIT Bombay and BARC

Pioneered Indigenous of Verification Technology


Handled Multiple Projects

Together

Verification of Get U Home (GUH) software for LCA Project of ADA

Flight Diagnostic and Interlock Logic (FDIL) for ISRO

Onboard Processor (OBP) Software for DRDL

Tools developed as part of this collaboration has been used for Verification of I&C Systems in LWR at BARC



Promote Indigenous Design and

Verification Tools

Design Tools:

• Domain Specific Modelling Language and Synthesis,

Automatic code generator (Verify Once)Runtime Monitoring (Near 360o Surveillance)

Analytical Tools:

• Program Analysis and Compliance Analyzer

• Software Safety and Security Analysis


Issues in front of usValidation of Tools with Case Studies

Packaging and Productize

Long Term Sustenance

• Addressing technological obsolescence

• Skilled manpower

Tool Qualification


Tool Driven Verification Engineering

Need for Verification Tools usable by Design Engineers

Indigenous Tools will allow configurability to reduce False Positives

How to convince Certification Authorities

• What should be provided to certification authorities about soundness? “

• Need to have interaction among Regulating, Design and Academic Communities to build confidence.


Thank You

design of high integrity embedded systems for control and ... · 2/19/2017 · distinguished...

Documents