Sep 4, 2008 - management as part of a distributed control system. iPMS ..... Introduction to a Generic Architecture for Process Automation and Reconfiguration . ...... critical. real time and clock-synchronized communications called ..... The problems of mixing SILs and ALARP have been discussed by Shuttleworth [11] who.
Safety Tactics for Reconfigurable Process Control Devices Adrian E Hill
Report on a project submitted in part for the degree of MSc in Safety Critical Systems Engineering in the Department of Computer Science at
THE UNIVERSITY OF YORK 4th September 2008
Number of words = 43655, as counted by MS Word word count command. This includes all the body of the report but does not include the Reference Section or Appendices A and B.
Abstract Control systems are increasingly subject to reconfiguration either because of a failure of a component or a change in the process under control. System reconfiguration typically takes place by shutting down either the whole or part of an operational system and then going through an installation and commissioning programme before bringing the system back on line. This can be expensive, disruptive and inefficient, but with the introduction of intelligent field devices such as sensors and actuators, system reconfiguration can now be managed more efficiently through commercially available asset management software applications without the need to shut down the system. The advantages that the use of intelligent field devices brings to the process control industry are very appealing to the UK Naval Submarine Programme where operations in harsh environments mean that opportunities to shut down critical processes are limited. With the introduction of smart hardware into future Naval Submarine platforms the ability to reconfigure networked field devices in order to maintain levels of service without disrupting the operation of the submarine would be beneficial. However, as operation of a submarine is a safety critical activity, the question arises, “How can the benefits of systems that use intelligent reconfigurable hardware be realised without compromising safety”? This project report has sought to answer this question through the development and evaluation of a solution based on the use of safety tactics. Specific safety tactics have been developed and applied to a hypothetical submarine control system that implements intelligent plug and play functionality in a safety critical operation. The application of a tactical approach has been shown to reduce the hazards posed by intelligent plug and play functionality.
Statement of Ethics I confirm that the basic ethical principles of “do no harm”, “informed consent” and “confidentiality of data” have been considered while undertaking this project. This project is an academic work, has not embarked on experimentation and no user testing or questionnaires have been used.
Adrian E Hill
-2-
04/09/2008
Glossary of Terms and Abbreviations Abbreviations ADC
Analogue Digital Conversion
ALARP
As Low As Reasonably Practicable
ASAAC
Allied Standards Avionics Architecture Council
ASICs
Application Specific Integrated Circuits
CCA
Component Criticality Analysis
CHM
Hardware Component Monitoring
CPLD
Complex Programmable Logic Device
CNNRP
Chairman of Nuclear Naval Regulatory Panel
COTS
Commercial Off The Shelf
CRC
Cyclic Redundancy Check
DAC
Digital Analogue Conversion
DCS
Distributed Control System
DDL
Device Description Language
DIA
Distributed Intelligent Agent
DS
Defence Standard
DTM
Device Type Manager
EDDL
Electronic Device Description language
E/E/PES
Electrical, Electronics and Programmable Electronic Devices
FDT
Field Device Tool
FAST
Failure Avoidance Safety Tactic
FCST
Failure Containment Safety Tactic
FDST
Failure Detection Safety Tactic
FFA
Functional Failure Analysis
FMEA
Failure Modes and Effects Analysis
FPGA
Field Programmable Gate Array
FSK
Frequency Shift Keying
FTA
Fault Tree Analysis
GHM
Global level Health Monitoring
GSN
Goal Structuring Notation
HAZOP
Hazard and Operability
HART
Highway Addressable Remote Transducer
Adrian E Hill
-3-
04/09/2008
HCF
HART Communications Foundation
HCI
Human Computer Interface
HDAL
Hardware Design Assurance Level
HMI
Human Machine Interface
HSE
High Speed Ethernet
IMA
Integrated Modular Avionics
IMS
Integrated Modular System
iPMS
Integrated Platform Management System
IVHM
Integrated Vehicle Health Management
JSP
Joint Services Publication
LRU
Lowest Replaceable Unit
MHM
Module /application level Health Monitoring
MOD
Ministry of Defence
NCAP
Network Capable Application Processor
NII
Nuclear Installations Inspectorate
NIST
National Institute of Standards and Technology
PHM
Partition /application level Health Monitoring
PID
Proportional Integral Derivative (controller)
PLC
Programmable Logic Controller
PLD
Programmable Logic Device
QoS
Quality of Service
RTCA
Radio Technical Commission of Aeronautics
RTBP
Real Time Blue Print
SAL
Safety Assurance Level
SHARD
Software Hazard Analysis and Resolution in Design
SIL
Safety Integrity Level
SIS
Safety Instrumented System
STIM
Smart Transducer Interface Module
TEDS
Transducer Electronic Data Sheet
XDCR
Transducer
Adrian E Hill
-4-
04/09/2008
Glossary of Terms The following list provides a project specific definition of a number of common technical terms that are used throughout this project report. Asset Management
Application software that manages the overall data collected from distributed intelligent networks and field devices. Asset management allows devices to be installed, configured and maintained through the life of the process plant. Manufacturers design field devices to support either a single proprietary asset management system or open systems such as FDT/DTM.
Health Management
An approach for monitoring the operational health of a device or system. Health management can include predictive analysis to enable the system to predict device failures before they occur.
Intelligent Hardware
Intelligent hardware (device) describes a device that provides built in functions that support diagnostic, health and asset management as part of a distributed control system.
iPMS
The integrated platform management system that provides the means by which platform control is maintained from the HMI through to plant machinery.
OPC
OPC is a system of open standards developed and supported by the OPC Foundation for the automation industry. OPC enables devices to communicate and enables access to system wide data.
Smart Instrument
In its broadest sense a smart instrument is a field device that includes some software (firmware) as indicated by the use of a microprocessor or other similar complex logic technology (FPGAs, CPLDs, PLDs, ASICs) and is capable of communicating on a digital network.
Adrian E Hill
-5-
04/09/2008
Acknowledgments I would like to thank all those who have supported my work at The University of York which has cumulated in completion of this project report. Special thanks go to Dr Mark Nicholson who has supervised this project and to BAE Systems Submarine Solutions who has sponsored and supported me throughout. An extra special thank you must go to my wife, Stella and daughter, Esther who have patiently suffered my further educational exploits.
Adrian E Hill
-6-
04/09/2008
Table of Contents ABSTRACT ................................................................................................................................................................ 2 STATEMENT OF ETHICS....................................................................................................................................... 2 GLOSSARY OF TERMS AND ABBREVIATIONS............................................................................................... 3 ACKNOWLEDGMENTS.......................................................................................................................................... 6 TABLE OF CONTENTS ........................................................................................................................................... 7 LIST OF FIGURES.................................................................................................................................................... 9 LIST OF TABLES...................................................................................................................................................... 9 1
INTRODUCTION ............................................................................................................................................ 10
2
LITERATURE SURVEY................................................................................................................................ 12 2.1 INTELLIGENT HARDWARE ............................................................................................................................. 12 2.2 PROCESS INDUSTRY ...................................................................................................................................... 14 2.2.1 Process Control .................................................................................................................................. 14 2.2.2 Current Advances in Process Control ................................................................................................ 15 2.2.3 Health Monitoring and Asset Management ........................................................................................ 16 2.2.4 Networks of Intelligent Hardware ...................................................................................................... 17 2.2.5 Distributed Intelligent Agents ............................................................................................................. 24 2.3 NUCLEAR INDUSTRY ..................................................................................................................................... 25 2.3.1 Safety Concerns .................................................................................................................................. 25 2.3.2 Approach to Intelligent Hardware...................................................................................................... 26 2.4 AEROSPACE INDUSTRY ................................................................................................................................. 27 2.4.1 Integrated Modular Avionics (IMA) ................................................................................................... 27 2.4.2 IMA Reconfiguration and Certification Issues ................................................................................... 28 2.4.3 Blueprints in a wider context .............................................................................................................. 30 2.4.4 IMA Certification Issues ..................................................................................................................... 30 2.4.5 Dynamic Reconfiguration of IMA - Certification Issues..................................................................... 31 2.5 REGULATORY ISSUES .................................................................................................................................... 31 2.5.1 General ............................................................................................................................................... 31 2.5.2 Application to Military Systems .......................................................................................................... 32 2.5.3 Certification and Standards Compliance Issues ................................................................................. 33 2.6 COTS ACQUISITION AND SAFETY ISSUES ..................................................................................................... 33 2.6.1 Justifying the use of COTS Components ............................................................................................. 34 2.7 SAFETY TACTICS ........................................................................................................................................... 35 2.8 LITERATURE SURVEY CONCLUSIONS ............................................................................................................ 36 3 SYSTEM RECONFIGURATION – A TACTICAL APPROACH TO SAFETY ASSURANCE ............ 38 3.1 PROCESS CONTROL IN CONTEXT ................................................................................................................... 38 3.2 A GENERIC ARCHITECTURE FOR PROCESS AUTOMATION AND RECONFIGURATION ...................................... 39 3.2.1 Introduction to a Generic Architecture for Process Automation and Reconfiguration ...................... 39 3.2.2 A Proposed Process Automation Architecture.................................................................................... 40 3.2.3 Benefits of a layered architecture ....................................................................................................... 42 3.3 GENERAL SAFETY ISSUES WITH SYSTEM RECONFIGURATION ........................................................................ 43 3.3.1 Scope of Issues.................................................................................................................................... 43 3.3.2 Plug and Play at the Field Devices layer ........................................................................................... 44 3.3.3 Device Reconfiguration at the Field Devices layer ............................................................................ 45 3.3.4 System Reconfiguration at the Application Layer............................................................................... 46 3.4 A TACTICAL APPROACH TO SAFETY ASSURANCE ......................................................................................... 47 3.4.1 Failure Avoidance .............................................................................................................................. 48 3.4.2 Acquisition Process............................................................................................................................. 48 3.4.3 COTS Acquisition and Safety Contracts ............................................................................................. 52 3.4.4 Failure Detection................................................................................................................................ 56 3.4.5 Failure Containment........................................................................................................................... 59 3.5 SAFETY JUSTIFICATION ................................................................................................................................. 62 3.6 INSTANTIATION OF THE TACTICAL APPROACH .............................................................................................. 62 3.7 CONCLUSION TO PROPOSAL PHASE ............................................................................................................... 63 3.7.1 Overview of Safety Tactics.................................................................................................................. 64 Adrian E Hill
-7-
04/09/2008
4
CASE STUDY – PLUG AND PLAY IN A SUBMARINE INTEGRATED PLATFORM MANAGEMENT SYSTEM ............................................................................................................................ 65 4.1 INTRODUCTION TO CASE STUDY ................................................................................................................... 65 4.2 SUBMARINE HOVER CONTROL ...................................................................................................................... 66 4.2.1 Overview of Hover System.................................................................................................................. 66 4.2.2 Hover Control..................................................................................................................................... 67 4.3 SUBMARINE HAZARDS .................................................................................................................................. 68 4.3.1 Flowmeter Failure Analysis................................................................................................................ 69 4.4 FLOWMETER REQUIREMENTS ........................................................................................................................ 72 4.5 SELECTION AND APPLICATION OF SAFETY TACTICS...................................................................................... 72 4.5.1 High Level Requirements.................................................................................................................... 73 4.5.2 Architecture Level Constraints ........................................................................................................... 73 4.5.3 Behavioural Level Constraints ........................................................................................................... 73 4.5.4 Quantifiable Level Constraints ........................................................................................................... 74 4.5.5 Documenting of Tactics ...................................................................................................................... 74 4.5.6 Application of Safety Tactics and Safety Contracts ............................................................................ 74 4.6 FAILURE AVOIDANCE TACTICS ..................................................................................................................... 74 4.6.1 Reference COTS component ............................................................................................................... 74 4.6.2 Evaluation and Selection Criteria ...................................................................................................... 75 4.6.3 High level Requirements..................................................................................................................... 77 4.7 FAILURE DETECTION TACTICS ...................................................................................................................... 78 4.7.1 Communication Failure Detection Tactics ......................................................................................... 79 4.7.2 Initialisation Failure Detection Tactics.............................................................................................. 80 4.7.3 Diagnostic Failure Detection Tactics ................................................................................................. 83 4.8 FAILURE CONTAINMENT TACTICS ................................................................................................................. 84 4.8.1 General Failure Containment Tactic.................................................................................................. 84 4.8.2 Communication Failure Containment Tactics .................................................................................... 85 4.8.3 Initialisation Failure Containment Tactics......................................................................................... 87 4.8.4 Diagnostics Failure Containment Tactics .......................................................................................... 88 4.9 SUMMARY OF CASE STUDY SAFETY TACTICS ............................................................................................... 89 4.10 SAFETY JUSTIFICATION ............................................................................................................................ 90 4.10.1 Overview of Safety Justification..................................................................................................... 90 4.10.2 Safety Justification Issues .............................................................................................................. 92 4.11 CONCLUSION TO CASE STUDY .................................................................................................................. 92 5 PROJECT CONCLUSION............................................................................................................................ 93 5.1 PROJECT SUMMARY ...................................................................................................................................... 93 5.2 OVERALL CONCLUSION ................................................................................................................................ 93 6 FUTURE WORK............................................................................................................................................. 95 6.1 FURTHER DEVELOPMENT .............................................................................................................................. 95 6.1.1 Development of Patterns..................................................................................................................... 95 6.1.2 Safety Tactics for Increasing Complexity ........................................................................................... 95 6.2 EMERGENT WORK ......................................................................................................................................... 96 6.2.1 Dynamic Reconfiguration at the Field Device Layer.......................................................................... 96 6.2.2 Safety Analysis of Device Description Languages.............................................................................. 96 6.2.3 Autonomous Devices........................................................................................................................... 96 6.2.4 Wireless Devices ................................................................................................................................. 96 6.2.5 Safety Certification ............................................................................................................................. 97 7 REFERENCES ............................................................................................................................................... 98 APPENDIX A - PLUG AND PLAY FAILURE MODES ................................................................................... 101 APPENDIX B – CASE STUDY SAFETY ARGUMENT STRUCTURE .......................................................... 105
Adrian E Hill
-8-
04/09/2008
List of Figures Figure 2-1 Generic Intelligent Sensor Architecture.................................................................................................... 13 Figure 2-2 Generic Process Control [15].................................................................................................................... 15 Figure 2-3 Intelligent System Architecture [37]......................................................................................................... 16 Figure 2-4 Digital on Analogue Signal [24] ............................................................................................................... 18 Figure 2-5 General Use of HART [24]....................................................................................................................... 19 Figure 2-6 Foundation Fieldbus network [34] ............................................................................................................ 20 Figure 2-7 Profi Network with ProfiSafe Layer [36]................................................................................................. 21 Figure 2-8 IEEE 1451 Interface Model [26]............................................................................................................... 23 Figure 2-9 Scope of FDT/DTM [49] .......................................................................................................................... 24 Figure 2-10 IMS Layered Architecture [7]................................................................................................................. 27 Figure 2-11 IMA Blueprints [13] ............................................................................................................................... 29 Figure 2-12 Component Acquisition Process ............................................................................................................. 34 Figure 2-13 Diagrammatic View of COTS Evaluation .............................................................................................. 35 Figure 2-14 Safety Tactics for Software Architecture Design [41] ............................................................................ 36 Figure 3-1 Layered Architecture ................................................................................................................................ 40 Figure 3-2 Expanded Process Automation Architecture............................................................................................. 40 Figure 3-3 Modified Safety Tactics for System Reconfiguration............................................................................... 47 Figure 3-4 “V” Model of the COTS Development/Safety Lifecycle [33] .................................................................. 49 Figure 3-5 COTS Software Acquisition Process ........................................................................................................ 50 Figure 3-6 COTS Component Acquisition ................................................................................................................. 50 Figure 3-7 COTS Component Evaluation, Selection and Acquisition ....................................................................... 52 Figure 3-8 – Failure Detection.................................................................................................................................... 57 Figure 3-9 Masking Based Failure Containment ........................................................................................................ 61 Figure 3-10 Lifecycle of Tactical Approach............................................................................................................... 63 Figure 4-1 Typical Submarine at sea .......................................................................................................................... 65 Figure 4-2 Basic Submarine Hover Control ............................................................................................................... 66 Figure 4-3 Hover Control Layered Architecture ........................................................................................................ 67 Figure 4-4 Submarine Depth, Roll and Pitch.............................................................................................................. 68 Figure 4-5 Segment of Hover Control System ........................................................................................................... 85 Figure 4-6 Overall Safety Argument .......................................................................................................................... 90 Figure 4-7 Failure Avoidance Argument.................................................................................................................... 91 Figure 4-8 Failure Detection and Containment Argument ......................................................................................... 91
List of Tables Table 2-1 HART Protocol Commands [24]................................................................................................................ 19 Table 2-2 Properties of PROFISafe [36] .................................................................................................................... 21 Table 3-1 Example of Safety Contract for COTS Component Acquisition [33] ........................................................ 53 Table 3-2 Example of IMA Behavioural Level Contract [38].................................................................................... 54 Table 3-3 Example of COTS Component Contract.................................................................................................... 55 Table 4-1 Failure Detection Constraints (Communication)........................................................................................ 80 Table 4-2 Failure Detection Constraints (Initialisation) ............................................................................................. 83 Table 4-3 Failure Detection Constraints (Diagnostics).............................................................................................. 84 Table 4-4 Failure Containment Constraints (Communication)................................................................................... 86 Table 4-5 Failure Containment Constraints (Initialisation) ........................................................................................ 88 Table 4-6 Failure Containment Constraints (Diagnostics) ........................................................................................ 88 Table 4-7 List of Safety Tactics used in Case Study .................................................................................................. 89
Adrian E Hill
-9-
04/09/2008
1 Introduction Recent advances in the process control industry have led to the wide availability of what has become known as smart instruments. The degree of intelligence held within this new breed of hardware device can vary from simple microprocessor controlled signal conditioning and data manipulation through in-built diagnostics and asset management to autonomous real time reconfiguration and wireless integration. The most numerous of these smart instruments are typically sensor type devices that are designed to measure one or more process variables as part of a distributed control system. Process actuation devices, typically valve positioners are also available with a growing number of complex functions including closed loop control functions such as proportional integration (PID) etc that were once only available within process control application software packages, but are now built into the device itself. The process automation industry has in recent years taken advantage of the increase in complex functionality at the device level, especially with regard to increased diagnostics as well as health and asset management across distributed systems. More sophisticated asset management systems enable failures to be predicted through the use of trend data supplied by the field device itself and it can be envisaged that such systems may be capable of dynamic reconfiguration so ensuring the continuation of control in the presence of field device failure. Dynamically reconfigurable systems may also facilitate the safe replacement of hardware before it fails rather than after it has done so. Intelligence built into the field device also enables sophisticated plug and play type functions to be implemented so that the replacement of defective or potentially defective hardware may be undertaken more easily by the maintainer. In practice, the ability for systems to automatically configure new hardware in real time without the maintainer having to undertake complex manual activities enables systems to be efficiently maintained with a reduction in the scope for human error. The advantages that the use of intelligent devices brings to the process control industry are very appealing to the UK Naval Submarine Programme. With the introduction of smart hardware into future Naval Submarine platforms the ability to dynamically reconfigure control systems of networked field devices in order to maintain levels of service and improve fault tolerance would be appealing. The latest class of nuclear powered submarines for the British Royal Navy is the Astute Class. The Astute Class is special, not only because it is the largest attack submarine to be built for the British Navy but in the context of this project it is the first British submarine to have a large process automation system that offers both control and monitoring functions. This system is called an integrated Platform Management System (iPMS) that serves a wide range of submarine control systems that now demand a level of intelligent monitoring and control that in previous class submarines was not possible. The current situation is that there are a limited but increasing number of smart sensors/actuators being introduced on the Astute nuclear submarine platform. The current iPMS is the first step in the process of moving toward greater automation of submarine systems and although intelligent control is used, the advantages of being able to access the additional data available from smart hardware has not yet been realised. However, the benefits of implementing commercial off the shelf (COTS) intelligent hardware from the process control industry within the next generation of UK nuclear submarine platforms is appealing due to the overall need to reduce costs and improve performance whilst maintaining the safe operation of what is in effect a mobile nuclear reactor, process plant, hotel and fighting machine.
Adrian E Hill
-10-
04/09/2008
The requirement to maintain the safe operation of the submarine whilst taking advantage of increasingly intelligent hardware is a key driver for this project. Generally speaking, the use of software intensive systems has caused nervousness amongst those in the military who have an interest in such systems. Headlines, such as “Software glitches leave Navy Smart Ship dead in the water” [1] concerning the problems that beset the USS Yorktown when designers used software intensive systems to make savings in “manpower, maintenance and cost” [1] do nothing to increase confidence in complex intelligent systems. Although the problem with the USS Yorktown was not specifically due to failures with intelligent hardware, the headline is not easily forgotten. Likewise, the UK Nuclear Regulator’s risk adverse attitude to smart instrumentation is also a cause of nervousness when contemplating the implementation of intelligent systems when such systems are associated with platforms powered by nuclear power plants. So, the question arises, “how can the benefits of systems that use intelligent reconfigurable hardware be realised without compromising safety”? The motivation behind this project has been to develop a solution that addresses this question. The aims of the project have been to, 1. Determine the extent to which the safety aspects of implementing the dynamic reconfiguration of intelligent hardware have been addressed in industry. 2. Develop a method for arguing that a system based on reconfigurable intelligent field devices has been safety implemented. 3. Evaluate the chosen approach to arguing the safety of reconfigurable intelligent field devices. In order to satisfy the aims of the project an approach was taken that focused on the adaptation of existing, relevant and appropriate techniques. The initial project scope was broad in its approach to the problem area and included the safety issues associated with reconfigurable systems, smart instruments, intelligent hardware and certification/regulatory issues. This scope was reduced through the literature survey and proposal phase to address the specific area of reconfigurable plug and play intelligent hardware at the system level. The overall approach taken to address the project aims has been, 1. To undertake a review of relevant research and information that is currently available including, • Process control systems in the commercial market place and their applicability to reconfigurable systems, intelligent devices, diagnostics and asset management. • The approach to system reconfiguration taken by the avionics industry and the safety work undertaken with regard to the certification of IMA systems. • Nuclear safety and regulatory issues around smart instrumentation. • Regulatory issues and standards that are applicable to the design and implementation of reconfigurable systems. • Methods of justifying the use of COTS components. 2. To develop a tactical approach to safety in reconfigurable systems in the context of layered system architecture that includes system applications, Infrastructure and intelligent field devices. 3. To undertake an evaluation of the method through the application of the proposed tactical approach to a UK naval submarine platform case study.
Adrian E Hill
-11-
04/09/2008
2 Literature Survey The purpose of this literature survey was to review a range of current and past work being undertaken across a wide range of industries in the area of process control and dynamic reconfiguration. The scope of the literature survey was the following,
2.1
•
Gain an understanding of the term Intelligent Hardware in the context of dynamic real time reconfigurable systems.
•
To understand the use of intelligent hardware within the Process Industry and review the current technological developments around intelligent hardware.
•
To review the current issues faced by the Nuclear Industry with regard to intelligent hardware. This is relevant in the context of nuclear powered submarines
•
To review the work that has been undertaken in the Aerospace Industry in the areas of real time configuration and IMA systems.
•
To assess the Regulatory Issues faced by industry when contemplating the use of reconfigurable systems
•
To determine the issues around COTS Acquisition and Safety Issues as many of the components used to build a reconfigurable system are Commercial Off The Shelf (COTS) items
•
Review a method of applying a tactical approach to safety assurance at the architectural level.
Intelligent Hardware In older analogue control systems the method of compensating for inaccuracies within for sensors was by applying bespoke correction factors, calibration curves or additional signal processing to the raw analogue signal by the controlling computerised system. Modern digital systems can now perform these and many additional functions within the sensor itself and transmit via digital media corrected data directly to the control system. Back in the 1990’s Najafi [16], produced a paper on Smart Sensors whose purpose was to provide a review of smart sensor technology available at the time. Najafi [16] provides a definition of a smart sensor that states that “a smart sensor is defined as one that is capable of (i) providing a digital output; (ii) communicating through a bidirectional digital bus; (iii) being accessed through a specific address; and (iv) executing commands and logical functions”. Najafi [16] constructed this definition from information provided by Brignell [18] and Giachino [19]. However, this definition, although described as “broad” by Najafi [16] is in my opinion quite narrow in so far as the specific technology being described. Whilst the definition to execute commands and logical functions is applicable to all smart sensors the requirement to provide a digital output and to be addressable on a network is very limiting. A better and more inclusive definition of a smart sensor is provided by Dubey [17] “Smart sensors are sensors with integrated electronics that can perform one or more of the following… logic functions, two-way communication, make decisions...” This is a particularly useful in that the smart sensor is now defined in terms of integrated electronics, logic functions and decision making functions that strictly speaking do not have to be provided via a digital output. However, the requirement for two way communication is still limiting in that many sensors that might otherwise be defined as “smart” are not networked and only provide an analogue output to a control system. In this case the sensor is smart in terms of internal processing and manipulation of information but is dumb in terms of its connectivity.
Adrian E Hill
-12-
04/09/2008
A longer, but perhaps more inclusive definition is provided by Sellafield Limited, a major player in the British Civil Nuclear Industry whose definition [20] of a smart instrument is; “A Smart Instrument meets the following criteria: •
That the main purpose of the instrument is to measure or directly control a single process variable.
•
That despite using a microprocessor (or similar), it is a proprietary or ‘off the shelf’ instrument in common use.
•
It may (or may not) include some flexibility in its use, due to parameters that are set by the vendor or user.
•
That its life cycle includes the production of some generic embedded firmware by the manufacturer and may include some particular configuration software or settings by the user. This is often called Fixed Programming Language (FPL).”
“Smart hardware should not be restricted to measurement but should also include actuators, valves, motor starters and other control instruments.” The definition given by Sellafield Limited [20] is inclusive of a wider scope of instrumentation to be classified as smart. This includes the most basic requirement that the instrument has to include some software (firmware) as indicated by the use of a microprocessor or other similar technology. From this definition, devices that implement various types of logic such as FPGAs, CPLDs, PLDs, ASICs etc. are also included. It is also interesting that actuators have also been explicitly included in the definition given by Sellafield Limited [20] whereas they are not in other definitions which focus on sensors. From the various definitions reviewed, none really fit the need to describe the level of intelligence required to support real time reconfiguration based on health management/diagnostic type data. For this reason, the term Intelligent Hardware or Device will be used throughout the rest of this project to describe a device that provides functions that support health monitoring and asset management as well as the “smart” functions described by other definitions.
Figure 2-1 Generic Intelligent Sensor Architecture Figure 2-1 provides a generic functional block diagram of a fictional intelligent device that is based on engineering practice and my generic definition. An intelligent device will require as a minimum, •
A sensing element to capture the analogue process variable
•
Some signal conditioning for the analogue input
•
A means of converting the analogue signal to a digital format for further processing
•
A microprocessor or other programmable logic device to handle digital manipulation, health monitoring, diagnostics and other digital processing.
Adrian E Hill
-13-
04/09/2008
2.2
•
A digital to analogue converter for systems that require an analogue output, for example 4 – 20 mA
•
A digital output for systems that require a direct digital connection to the device.
Process Industry
2.2.1 Process Control Process control systems have been widely used across industry for many years, particularly in the automation of factories used for the mass production of consumer items such as automobiles, food stuffs and paper products etc. Automated control is also used in the process intense petrochemical and pharmaceutical industries. All these industries have driven advances in process control technology in order to improve the reliability of factory automation systems and in so doing improve efficiency by reducing the plant down time due to system failures. One significant area of technology advancement has been in the increased intelligence held within low level field devices such as sensors and actuators. One of the drivers for greater intelligence within field devices has been to enable better asset management of such devices through improvements in health monitoring, diagnostics, automatic configuration and reconfiguration and what is become known as “Plug and Play”. Plug and play functionality provides the ability to simply replace a defective unit with a replacement without the need to manually configure it or change the application software to accommodate it. This has huge benefits in terms of the maintenance and upgradeability of process plants, but the question that this work sets out to answer is, how can such benefits be achieved whilst still maintaining the safety risk to as low as reasonably practicable (ALARP)? A review of how the Process industry implements intelligence within smart hardware and reconfigurable systems is very relevant to the submarine industry as it moves away from bespoke military applications and seeks to implement commercial off the shelf (COTS) process control systems. The submarine iPMS is in effect a process control system that is specifically tailored for the military environment. The submarine iPMS is built from components from the process industry including standard components such as Programmable Logic Controllers (PLCs), Single Board Computers, smart and dumb sensors and actuators. A generic process control system on a submarine is used to control various processes including the flow of liquids such as oils and water around the submarine as well as electrical supplies. Typically, actuation devices include valves, pumps and hydraulic systems. Human interaction with the system is typically through a human computer interface (HCI) that is computer controlled and includes touch screens to allow “under glass” control. This provides control to be undertaken without the need for keyboards and pointer devices. A model of a process control system, shown in Figure 2-2 depicts a system in which some physical process is measured using sensors and then manipulated using actuation. Typically, such a process is controlled by an automated controller which controls the physical process within set limits. Human controllers either monitor the control process or directly interact with the control system through the HCI.
Adrian E Hill
-14-
04/09/2008
Figure 2-2 Generic Process Control [15] One pertinent issue for the process industry and for that matter the military, is the extent to which the human supervisor needs to be involved in the control of the process. As computer based systems become more capable in terms of intelligence it must be asked whether the human operator should be taken out of the control loop when fault conditions are detected and should only be involved in system restoration in special circumstances when command override type decisions can be made to continue with degraded systems. Dynamic reconfiguration of systems could be used to take workload off the human operator during high stress fault conditions and enable the operator to focus on more important tasks. However, there would need to be a balance struck between the advantages of dynamic reconfiguration and reduced human interaction so that the probability of human error due to the lack of awareness of the new system status during and following reconfiguration is managed.
2.2.2 Current Advances in Process Control In recognising the current trend in process control, Yalcinkaya, Atherton, Calis and Powner [37] extend the generic process control shown in Figure 2-2 to describe an intelligent system architecture (Figure 2-3) in which smart sensors are used in conjunction with decision making algorithms and plant models to enable very sophisticated fault detection to take place. Although Yalcinkaya et al do not explicitly say so there is scope here for an intelligent system to not only diagnose a fault and provide a prognosis, but to also reconfigure itself to provide continuation of service in the presence of a fault condition. They do however recognise the potential for smart sensors to communicate with other devices and modify their own behaviour accordingly.
Adrian E Hill
-15-
04/09/2008
Human Supervisor (Controller)
Displays
Controls
Decision Taking
Updates
Evaluation Plan Output
Prediction Model Data
Judgement Behaviour Generation
Input
Pre-processing
Plan States
Actuators
Sensors
Controlled variables
Measured variables
Physical Process Process Outputs
Process Inputs Disturbances
Indirect Monitoring Direct Monitoring/Control
Figure 2-3 Intelligent System Architecture [37]
2.2.3 Health Monitoring and Asset Management Bailey [21] presents a case for asset management pushing advanced diagnostics to deliver enhanced process plant performance and significant savings in through life maintenance. As instruments become smarter, basic diagnostic functions, calibration, configuration of user programmable parameters are being replaced by more advanced diagnostics with a focus on being able to predict plant failures and deploy maintenance before failure occurs. Bailey [21] provides an example of a servo valve with advanced diagnostics that has the capability to learn what normal plant parameters should be experienced and therefore is able to raise warnings when abnormal parameter values are experienced. Bailey also points out that conditions such as measurement sensor drift, leaks, losses and instability can be detectable with modern hardware and by detecting potential failures early; larger plant failures can be avoided. This is a significant driver in the process industry where plant shutdown due to failure can be very costly. The prospect of detecting failures earlier is also taken up by Aaseng [22] in his paper on Integrated Vehicle Health Management (IVHM) for space vehicles, who emphasises the need to be able to “…understand the state of the vehicle and its components, to restore the vehicle to nominal system status when malfunctions occur, and to minimize safety risks and mission impacts that results in system failures…”. Aaseng [22] suggests four areas of interest need to be addressed in order to satisfy this emphasis on IVHM,
Adrian E Hill
-16-
04/09/2008
•
Diagnostics - Knowing what system components are not operating correctly, and to what degree they aren’t working
•
Mitigation - Dealing with the failure for as long as necessary, while maximizing mission effectiveness in spite of the failure
•
Repair - Replacing or otherwise restoring the failed components to a nominal state
•
Verification - Making sure that the repairs fixed the problems and that no latent side effects persist.
For the purposes of discussing the part intelligent hardware plays in the health monitoring and reconfiguration of a system, the two most pertinent points drawn out by Aaseng [22] are “diagnostics” and “mitigation”. In terms of diagnostics, Aaseng [22] extends the principle to encompass prognosis, in a similar way that Bailey [21] described the advantage of advanced diagnostics to detect potential failures. This is of great interest to the submarine application as the ability to detect potential failures and intelligently reconfigure the system around that potential failure is appealing, especially as there can be few opportunities to repair or replace components during intense periods of sustained operations, including “fight” situations. Aaseng [22] recognises that repair of space vehicles can be equally challenging when in flight but only considers reconfiguration of a system from a manual perspective following a review of the situation by human operators using fault models. The use of fault models is an interesting idea that could be taken forward and used, in similar fashion as a static configuration list, in a system that is capable of dynamic reconfiguration. Aaseng [22] also highlights an issue with the perceived trustworthiness of software based control systems and the extent to which operators feel comfortable with handing control over to such systems. Aaseng [22] experience with the space industry is apparently that “Turning over some of these decision responsibilities to an automated system will require very high confidence in the accuracy of the system. Reducing the human element involved in the decision processes will be done only cautiously and reluctantly”. This is very similar to the situation with UK Naval personnel who, anecdotally, appear to have a reluctance to take the “man” out of the loop and allow the “computer” to take control. Whilst the process industry push toward ever increasing levels of automation, any argument concerning the use of automated systems in military systems will need to be carefully constructed and move in measured steps towards taking the man out of the loop. To some extent this is already happening with the Astute Submarine currently under construction. This is the first British Nuclear Submarine that has an iPMS with some automated sequences, although the man is still in command for most control operations. As the UK MoD push toward lower manning levels on their naval platforms, this situation is likely to change over the next couple of generations of submarine. To meet this challenge there is an opportunity to work towards automated reconfigurable systems that can be shown to be sufficiently safe to operate.
2.2.4 Networks of Intelligent Hardware Advances in the Process Control industry has seen much of the complexity that used to reside in the automated controller move closer to the physical process, i.e. to the sensors and actuators. In order to facilitate this move toward greater automation and intelligence, modern process control systems now utilise digital networks and are beginning to move toward wireless networks.
Adrian E Hill
-17-
04/09/2008
HART The Hart Communications Foundation [23] is the organisation that controls the development of HART and provided the historical and technical information about the protocol that has been used in this section of the project report. The HART (Highway Addressable Remote Transducer) Protocol was introduced around 1986. It was one of the earliest methods of taking advantage of the intelligent instruments that were appearing on the market and provided a digital interface without the need for an additional network. By superimposing a digital signal on to the analogue measurement signal (4ma – 20ma loop current) a two way digital communication path can be established between an instrument and the control system. The digital signal is superimposed using frequency shift keying (FSK) with 1.2 KHz and 2.2 KHz representing bits 1 and 0, respectively. As a sine wave is used in the implementation the average amplitude is always zero and therefore the analogue measurement signal is not affected by the additional signal. Figure 2-4 shows the general arrangement of how the digital data is superimposed on the analogue signal.
Figure 2-4 Digital on Analogue Signal [24] Within the HART protocol there is the opportunity to include not only measurement data, but also a great amount of diagnostic data about performance of the instrument. The HART Communications Foundation (HCF) [23] is the body responsible for the development of HART and they have published specifications and application notes for the use of the protocol. It is apparent from the HCF application notes [24] that HART can be used to access a number of common and device specific parameters. This can be seen in Table 2-1 which has been taken from the HCF application notes [24]. Universal commands are those that every HART enabled device must recognise whilst common and device specific commands are provided by many manufacturers but not all. As can be seen from Table 2-1, there are a number of commands that could be very useful in determining the value of secondary variables within the device that could contribute to device failure. The control system could then be used to predict plant failure and reconfigure the system such that the failing device could be reset or removed from service for repair whilst maintaining plant integrity.
Adrian E Hill
-18-
04/09/2008
Table 2-1 HART Protocol Commands [24] Figure 2-5 shows a number of HART enabled devices on a typical process control network with a controller and a local input/output device. The handheld device is a special tool designed to be able to configure a HART device.
Figure 2-5 General Use of HART [24] Adler [25] makes a case for the use of HART enabled devices to increase the reliability of process plant and claims that increased reliability can support an argument that a required safety integrity level (SIL) has been achieved. Although Adler [25] provides Adrian E Hill
-19-
04/09/2008
several examples of how diagnostic data can be used to improve the reliability of a process plant, particularly when alternative networked systems such as Fieldbus necessitate the wholesale replacement of older instruments, he fails to substantiate the safety case for the implementation of the HART protocol. Alder’s [25] focus is on the reliability of the measurement and so he fails to consider the safety issues around the implementation of an intelligent digital instrument, i.e. the HART protocol itself and the software and hardware design of the instrument. Whilst the reliability of the measurement and the benefits that advanced diagnostics bring, there are other issues to contend with that have not been considered including common mode failures across instruments that use a common communication protocol such as HART. Digital Control Networks Following on from and building on the principles of the HART protocol, instrument manufacturers have developed intelligent instruments that are capable of being networked together. Of the various types of digital intelligent field devices available the main flavours are, Foundation Fieldbus [34], Profi (ProfiBus, ProfiNet & ProfiSafe [35]) and IEEE 1451 [26]. All these protocols are claimed to support open standards and many manufacturers offer intelligent instruments with options for Foundation Fieldbus, Profi and HART protocols enabled although IEEE 1451 does not appear to have been adopted by the main instrument manufactures in the process industry. Foundation Fieldbus was one of the first digital networks that were developed to interconnect intelligent field devices to process control systems. Foundation Fieldbus is an open standard that has, along with the HART protocol been adopted by all of the major manufacturers of intelligent instrumentation. The Foundation Fieldbus protocol runs on two digital networks, H1 which is at the field instrumentation level. At the higher, control level the protocol runs on High Speed Ethernet (HSE) to share data between the field instrumentation and the PLC control system and the human operator via the HCI [34]. Figure 2-6 shows a Foundation Fieldbus network in diagrammatic form.
Figure 2-6 Foundation Fieldbus network [34] ProfiBus and ProfiNet Networks [35] are typically used to interconnect field devices using open Industrial standards. ProfiNet is typically used to enable existing systems of
Adrian E Hill
-20-
04/09/2008
Profibus and FieldBus devices to be integrated into a single system by providing a common network backbone from which systems can connect and interact. ProfiNet uses common communication protocols such as TCP, IP and UDP. At the application layer, ProfiNet can use protocols such as HTTP (web), FTP (file transfer) and SMTP (email). The designers of ProfiNet have realised the importance of real time applications and have provided protocols for three levels of process criticality, non time critical. real time and clock-synchronized communications called Isochronous Real Time, which enables clock rates of under 1 ms and a jitter precision of
