This chapter provides a brief overview, including the important terms, naming conventions, and relevant standards.

1         Functional Design Specifications (FDS)

In this chapter a brief overview of control system FDS is given. The important industrial terms and naming conventions are discussed and the standards are highlighted.

Learning objectives

You will learn about:

  •     Overview of control system FDS
  •     Essential industry terms and abbreviations used in the FDS
  •     Naming conventions and standards
  •     Control philosophy needed in guiding the FDS

Any Supervisory Control and Data Acquisition (SCADA) project will be successful if, and only if, the creating, understanding and execution of the functional specifications are executed perfectly. These technical specifications are important in the overall development and designing of control systems which contain the technical details that lead to the success of the project. These functions are as important as that of the mechanical sections.

For example, consider piping. The complete description of the valves, pumps, chillers, piping specialties and other components used to construct the piping system are given in piping specifications. Designers will not submit a project without this important information for the piping system. In general, this kind of thorough information is not included for control systems. The lack of proper technical specifications for control systems may lead to difficulty in meeting the project’s design objectives. The design process is said to be successful if it contains descriptions of maintenance, operation and commissioning requirements. This leads to efficient building, and ensures the operation runs smoothly.

A functional specification defines what the system should do and what functions and facilities are to be provided. It provides a list of design objectives for the system.

A standard specification of the project should consider what is generally available in the market and what can reasonably be called upon for options. It is of no use to specify aspects which suppliers cannot provide at a reasonable cost and within a sensible time frame. The aim is to match what the manufacturer can offer, within their standard range of equipment. An efficient approach, by the purchaser, is to select standard equipment which is suitable for the manufacturer and then design the power system around the equipment to be purchased. In general, this approach will reduce the amount of time needed to design the power system.

Functional aspects of the specification should be considered carefully. The function of basic equipment such as generators, motors and switchgear will be understood easily. But, in order to gain an understanding of what is required, it is essential to pay attention to the design and performance details. Functionality implies a more interrelated type of existence, as is the case with systems of equipment rather than individual items of equipment.

Functional specifications in the area of process control systems cover the following:

  •     SCADA systems
  •     Power management control system
  •     System computer
  •     Measuring devices
  •     Controller set points
  •     Switchgear
  •     Rotating machines.

The entire system should be defined functionally and all the elements should be compatible from the conceptual stage of the specification.

Control System Engineers analyze the following, to develop the design and functional specifications of automation systems:

  •     User requirements
  •     Procedures
  •     Design process
  •     Mechanical equipment
  •     Problems to identify the system components.

The automation system helps the equipment to function in a required manner. The interface between the hardware and software development, for the automation system, is the responsibility of Control System Engineers.

A FDS is the most important stage in the design of any control system. It provides details of the solution to be implemented, to meet user requirements. It should be accepted by the user and should form the basis of the design for both hardware and software. An excellent FDS clearly specifies the following which are associated with the system:

  •      Functions
  •     Operator interactions control
  •     Sequencing.

Therefore, before the system is developed, the user must confirm whether the proposed solution fully meets the specified requirements or not. A FDS is considered as the basis for the design of the system. It is used during testing to verify and validate the system, to ensure whether all the required functions are present and that they operate correctly.

A FDS has all the information associated with the control system including:

  •     Details of how each area of the plant operates under automatic control (control philosophy)
  •     Details of the SCADA system i.e. screen layouts, navigation charts, alarm handling, trending and reporting
  •     Details of the Network architecture
  •     Details of any local operator interfaces.

EIT Stock Image

Figure 1.1

Control system design

The FDS should cover:

  • Control Modules such as PID Loops, indicators etc
  • HMI Graphic displays
  • Equipment Basic Control
  • Phase Logic
  • Operations
  • Unit Procedures
  • SCADA Recipes
  • The Inputs and Outputs of the systems with cards and channels assigned to them.

1.1.1    Benefits of using a FDS

There are numerous benefits provided by a complete and coherent FDS which include time savings of approximately 50% of total time and a saving of resources and money of approximately 25%. These benefits are achieved only after everyone is involved in designing, developing, testing, approving of an application, signing the document containing an ordered list of all design and functional requirements.

By using a FDS (Functional Design Specification):

  • The manufacturer knows exactly what to develop & deliver
  • The system integrators know exactly what they are working with
  • Quality Assurance knows exactly what to test
  • The client knows exactly what they will be getting.

Technical terms and abbreviations are easily understood by professionals in one field whereas they may be confusing to others from another field, and may be misunderstood. Therefore, it is necessary to understand the abbreviations and some of the terms that are used in the text and elsewhere in the industry.

The following are the essential industry terms and relevant abbreviations used in functional design specifications:

Table 1.2

Industrial terms and their abbreviations

Industry terms Abbreviations
AGC Automatic Generation Control
API Application Programming Interface
CORBA Common Object Request Broker Architecture
C & I Control and Instrumentation
CPU Central Processing Unit
CRC16 16-bit Cyclic Redundancy Check
CSMA/CD Carrier Sense Multiple Access/Collision Detection
CT Current Transformer
DC Direct Current
DCS Distributed Control System
DMS Distributed Management System
DNP Distributed Network Protocol
DOD Department of Defense
DOE Department of Energy
DISCO Distribution Company
DNP/DNP3 Distributed Network Protocol, version 3.0
DPI Double-Point Information
EMS Energy Management System
EMC Electromagnetic Compatibility
EMI Electromagnetic Interference
EPROM Erasable Programmable Read-Only Memory
FTP File Transfer Protocol
FDS Functional Design Specification
FS Functional Specification
FAT Factory Acceptance test
FMEA Failure Modes and Effect Analysis
FPGA Field Programmable Gate Array
GUI Graphical User Interface
GAMP Good Automated Manufacturing Practice
GAL Generic Array Logic
GENCO Generation Company
GPR Ground Potential Rise
HMI Human Machine Interface
HDS Hardware Design Specifications
I/O Input/Output
IED Intelligent Electronic Devices
ICCP Intercontrol Centre Communications Protocol
IEEE Institute of Electrical and Electronics Engineers
INEEL Idaho National Engineering and Environmental Laboratory
ISO Independent System Operator or International Organization for Standardization
IRIG-B Inter Range Instrumentation Group format B
ISA Instrumentation Systems and Automation Society
IT Information Technology
ITU International Telecommunication Union
LCD Liquid Crystal Display
LED Light Emitting Diode
LAN Local Area Network
MMI Man Machine Interface
MTBF Mean Time Between Failure
MTTR Mean Time To Repair
NIM Network Interface Module
NISAC National Infrastructure Simulation and Analysis Centre
NRC Nuclear Regulatory Commission
NTP Network Time Protocol
OASIS Open Access Same – Time Information System
ODBC Open Database Connectivity
PID Proportional, Integral and derivative controller
POSIX Portable Operating System Interface
PLC Programmable logic Controller
P & ID Process & Instrumentation Diagram
PSU Power Supply Unit
PCS Process Control System
PROM Programmable Read-Only Memory
PSTN Public Switched Telephone Network
PT Potential Transformer
RTU Remote Terminal Unit
REA Rural Electric Association
RTO Regional Transmission Organization
RAID Redundant Array of Inexpensive Disks or Redundant Array of Independent Disks
ROM Read-Only Memory
SCADA Supervisory Control and Data Acquisition
SAT Site acceptance test
SOE Sequence of Events
SNTP Simple Network Time Protocol
SPI Single-Point Information
SQL Structured Query Language
SWC Surge Withstand Capability
TASE Telecontrol Application Service Element
TRANSCO Transmission Company
TCP/IP Transmission Control Protocol/Internet Protocol
T&D Transmission and Distribution
UHF Ultra High Frequency
UPS Uninterruptible Power Supply
UTP Unshielded Twisted Pair
VDU Video Display Unit
WAN Wide Area Network

The General Design Principles (GDP) defines the number of conventions to be used.

For example, consider the standard color scheme. In one division of the plant a device is colored red, meaning ‘stopped’, and in another part of the plant the same type of motor is colored red, meaning ‘dangerous condition’. This may lead to disaster, but by following naming conventions, such risks will be reduced.

Adopting a standardized reliable naming convention for devices controlled by the system, will be favorable for scalable and maintainable systems in the long run. In some cases, the naming conventions used are forced on the system by external influences. Therefore, they should be properly documented in the GDP.

Examples of tagging and naming conventions are:

  • Graphic symbols
  • Instrumentation naming.

Naming conventions and standards are explained in further detail in the next chapter.

Philosophy is a belief or a system of beliefs, accepted as authoritative by some groups. Control philosophy is a guideline for a FDS which describes the basic dos and don’ts and requirements of a FDS from the point of view of the end user. It should describe the following:

  • Level of process automation
  • Information handling needs
  • Operational requirements
  • Requirement of flexibility
  • Level of control intervention
  • Operators work and skill
  • Management skills for both organization and data communication
  • Level of management needed
  • Extent of manual control required
  • Extent of the physical area the system is covering
  • Type of communication system
  • Level of security needed for communication
  • Type of control processing.

This chapter summarizes the following:

  • A functional specification defines what the system should do and what functions and facilities are to be provided.
  • An excellent FDS clearly specifies the following associated with the system:
  • Functions
  • Operator interactions control
  • Sequencing.
  • There are numerous benefits provided by a complete and coherent FDS, which include time savings of approximately 50% of total time and a saving of resources and money of approximately 25%.
  • It is necessary to understand the abbreviations and some of the terms that are used in the text and elsewhere in the industry.
  • Technical terms and abbreviations are easily understood by professionals in one field whereas it may be confusing to others and may be misunderstood
  • Adopting a standardized reliable naming convention for devices, controlled by the system, will be favorable for scalable and maintainable systems in the long run
  • Control philosophy is a guideline for a FDS, which describes the basic dos and don’ts and basic requirements of a FDS, from the point of view of the end user.
  • This field is for validation purposes and should be left unchanged.
Engineering Institute of Technology