10-PLC_Software_Engineering_Handbook_3QPL4H_v1_4

IDM UID

3QPL4H
VERSION CREATED ON / VERSION / STATUS

30 Jan 2013 / 1.4/ Approved
EXTERNAL REFERENCE

IT Technical Specifications

PLC Software Engineering Handbook
This document lists the rules and guidelines applicable to the development of software for
PLCs deployed on the ITER project.

Author
CoAuthor
Reviewers
Approver
Read Access

Approval Process
Action
Affiliation
30-Jan-2013:signed
IO/DG/DIP/CHD/CSD/PCI
12-Feb-2013:signed
IO/DG/DIP/CHD/CSD/PCI
12-Feb-2013:recommended
IO/DG/DIP/CHD/CSD
24-Mar-2013:approved
IO/DG/DIP/CHD

Document Security: level 1 (IO unclassified)
RO: Evrard Bruno
LG: QA DOC Editors, AD: ITER, AD: External Collaborators, AD: Division - Control System Division EXT, AD: Section - CODAC - EXT, AD: Section - CODAC, AD: Section - Plant Control and Instrumentation,
project administrator, RO, LG: PLC group, LG: CODAC team
Name
Evrard B.
Prasad S.
Wallander A.
Thomas P.

PDF generated on 24-Mar-2013
DISCLAIMER : UNCONTROLLED WHEN PRINTED – PLEASE CHECK THE STATUS OF THE DOCUMENT IN IDM


Change Log
Title (Uid)

Versio
n

Latest Status

Issue Date

Description of Change

PLC Software
Engineering Handbook
(3QPL4H_v1_4)

v1.4

Approved

30 Jan
2013

V7.0 Update

PLC Software
Engineering Handbook
(3QPL4H_v1_3)

v1.3

Approved

09 Feb
2011

Version after external review of PCDH V6.

PLC Software
Engineering Handbook
(3QPL4H_v1_2)

v1.2

Signed

10 Jan
2011

Integration of John Poole Comments.

PLC Software
Engineering Handbook
(3QPL4H_v1_1)

v1.1

PLC Software
Engineering Handbook
(3QPL4H_v1_0)

v1.0

Ready for External Review.
Signed

04 Jan
2011

Version after CODAC internal review.
Version ready for external review.

In Work

06 Dec
2010

PDF generated on 24-Mar-2013
DISCLAIMER : UNCONTROLLED WHEN PRINTED – PLEASE CHECK THE STATUS OF THE DOCUMENT IN IDM


ITER_D_3QPL4H v 1.1

PLC Software Engineering
Technical note

Abstract
This document is listing the applicable rules and guidelines to be applied for the
development of Software for PLCs deployed on the ITER project.

Author
CoAuthor
Reviewers
Approver

External Number: ITER_D_3QPL4H v 1.0 Date: 13 September 2010
Name
Affiliation
Evrard Bruno
IO/DG/DIP/CHD/CODAC
Prasad Sawantdesai
ITER I&C IPT
IO/DG/DIP/CHD/CODAC
D Bora
IO/DG/DIP/CHD
Page 1 of 60

Document Revision History
Version

Status

Date

Summary of Changes

1.0

Draft

13/12/2010

Draft

1.1

Issued

04/01/2011

First Version

Page 2 of 60

Table of Contents
Table of Contents ........................................................................................................................3
Table of Figures...........................................................................................................................6
1

Introduction.........................................................................................................................7
1.1

PCDH Context.............................................................................................................7

1.2

Purpose of document ..................................................................................................7

1.3

Scope.............................................................................................................................8

1.4

Organization of document..........................................................................................8

1.5

Acronyms .....................................................................................................................8

1.6

Definitions....................................................................................................................9

1.7

Reference Documents .................................................................................................9

2

Context and Constraints ..................................................................................................11

3

Generic Requirements of PLC Applications on ITER ..................................................12

4

Software Architecture of a PLC application. .................................................................13
4.1

PLC Core Application ..............................................................................................14

4.2

CODAC Interface .....................................................................................................15

4.3
Hardware inputs/outputs interface .........................................................................17
4.3.1 General Description ................................................................................................17
4.3.2 Inputs/Outputs Wrapper..........................................................................................18
4.3.3 Interface Switch ......................................................................................................19
4.3.4 Anti-Rebounce ........................................................................................................19
4.3.5 Engineering Limits..................................................................................................19

4.3.6 FBS Wrapper ..........................................................................................................19
4.3.7 Electrical Signal to Engineering/Engineering to Electrical Signal Conversion.....19
4.3.8 Standardization .......................................................................................................20
4.3.9 Forcing ....................................................................................................................20

5

4.4

PLC Interface ............................................................................................................20

4.5

Fast Controller Interface..........................................................................................21

4.6

System Monitoring....................................................................................................21

Numbering and naming conventions. .............................................................................23
5.1

Block numbering convention ...................................................................................23

5.2
Block Naming Convention .......................................................................................24
5.2.1 Core Application Blocks naming convention .........................................................24
5.2.2 Peripheral Blocks and Generic Functions naming convention ...............................27
5.3
Variables naming convention ..................................................................................27

5.3.1 Imputs and Outputs variables..................................................................................27
5.3.2 DB variables............................................................................................................28
6

Programming Environment Standard Configuration...................................................29

Page 3 of 60


6.1

Step 7 Config .............................................................................................................29

6.2

Project Config............................................................................................................33

7

Hardware Config ..............................................................................................................35

8

Symbol Table.....................................................................................................................39

9

Standard PLC Software Structure (SPSS) .....................................................................40
9.1

SPSS Description.......................................................................................................40

9.2
SPSS Creation Procedure.........................................................................................41
9.2.1 Hardware Configuration .........................................................................................41
9.2.2 Import the “Standard PLC Software Structure” from external source files............42
9.2.3 Import the “Standard PLC Software Structure” from STEP7 Archive...................43
10

Peripheral Blocks Development.......................................................................................45
10.1 CODAC Interface .....................................................................................................45
10.1.1
Description..........................................................................................................45
10.1.2
Generation procedure..........................................................................................46
Hardware Inputs/Ouputs interface .........................................................................47

10.3

PLC inside plant System interface ..........................................................................47

10.4

Fast Controllers interface.........................................................................................47

10.5

Simulator interface ...................................................................................................48

10.6

System Health Monitoring .......................................................................................48

11

10.2

PLC Core Application Development...............................................................................49
11.1 Development Cycle and Deliverables ......................................................................49
11.1.1
Requirements Specification ................................................................................50
11.1.2
Design Specification ...........................................................................................50
11.1.3
Coding/Unit Testing............................................................................................50
11.1.4
Simulated Validation Testing .............................................................................51
11.1.5
Integrated Validation Testing .............................................................................51
11.1.6
Site Acceptance Test...........................................................................................51
11.2

Languages ..................................................................................................................52

11.3

CODAC Interface good practice. ............................................................................53

11.4

Standard Structure of a Process Function..............................................................54

11.5

Siemens Libraries......................................................................................................56

11.6

ITER library..............................................................................................................57

11.7

Alarms Management ................................................................................................57

11.8

Coding Rules .............................................................................................................57

12

Simulator Development ....................................................................................................59

13

Version Control.................................................................................................................60

14

Annexes ..............................................................................................................................61

14.1

Already Reserved Blocks for CODAC....................................................................61

14.2

Already Reserved Global Variables for CODAC ..................................................61

Page 4 of 60


14.3

Cooling Water System Example ..............................................................................62

Page 5 of 60


Table of Figures
Figure 1 : Schema of PCDH documents __________________________________________7
Figure 2: CODAC Architecture _______________________________________________11
Figure 3: PLC Conceptual Architecture_________________________________________13
Figure 4: PLC Core Application Environment____________________________________14
Figure 5: Simple Example of CODAC HMI ______________________________________15
Figure 6: Collaborative Data _________________________________________________16
Figure 7: Hardware Inputs/Outputs Interface Block Diagram _______________________17
Figure 8 : Control Block of a FBS Level 4 Function._______________________________25
Figure 9 : Step 7 Language Setting. ____________________________________________29
Figure 10 : Step 7 Date and Time of Day Format. ________________________________30
Figure 11 : LAD/FBD Layout. ________________________________________________31

Figure 12 : Block Sources. ___________________________________________________32
Figure 13 : Symbol Editor Import. _____________________________________________33
Figure 14 : Address .Priority._________________________________________________34
Figure 15 : STEP 7 HW Config Screen for a CPU Stations with 3 Remote IO
Racks. _______________________________________________________35
Figure 16 : CPU Config Clock Memory Setup____________________________________36
Figure 17 : CPU Config Startup_______________________________________________36
Figure 18 : CPU Time-of-Day Synchronization. __________________________________37
Figure 19 : Remote IO Rack Board organization. _________________________________38
Figure 20 : Main Cycle Loop Standard Structure _________________________________40
Figure 21 : 100ms Cycle Loop Standard Structure ________________________________41
Figure 22 : Warm Restart Block Standard Structure _______________________________41
Figure 23: Hardware configuration compiled to generate ‘System data’. ______________42
Figure 24: Add standard software structure as external source. ______________________43
Figure 25:UDTs and DBs organisation and dependencies for Control Function
“CWS-DHLT-WFC”. ___________________________________________46
Figure 26:UDTs and DBs organisation and dependencies for TCP connexion
parameters. ___________________________________________________46
Figure 27: Core Application Development Life Cycle ______________________________49
Figure 28: Closed Loop Control Example _______________________________________54
Figure 29: Conceptual Design of a Control Function in the Core Application ___________55
Figure 30: Standard Implementation of a Control Function in the Core Application______56

Page 6 of 60


1 Introduction
1.1 PCDH Context
The Plant Control Design Handbook (PCDH) [RD 10] defines methodology, standards,
specifications and interfaces applicable to ITER plant systems Instrumentation & Control

(I&C) system life cycle. I&C standards are essential for ITER to:




Integrate all plant systems into one integrated control system.
Maintain all plant systems after delivery acceptance.
Contain cost by economy of scale.

PCDH comprises a core document which presents the plant system I&C life cycle and recaps
the main rules to be applied to the plant system I&Cs for conventional controls, interlocks and
safety controls. Some I&C topics will be explained in greater detail in dedicated documents
associated with PCDH as presented in Figure 1.1. This document is one of them.

Figure 1 : Schema of PCDH documents

1.2 Purpose of document
This document intends to
- Define a standard software architecture for PLC applications developed in the ITER
Project .
-

Provide rules to have a standard approach for the development of the Control
Functions.

1.3 Scope
Page 7 of 60


This document covers the Development of Software for PLC Conventional Controllers. It is

not covering SIL-3 PLCs, Simatic F/FH Series, Interlock (PIS) or Safety (PSS) Controllers.

1.4 Organization of document.
A preliminary Chapter will present the generic requirements that every PLC should fulfil. The
rest of the document will give details on how to meet these requirements
The succession of the following chapters will follow as far as possible the PLC application
development process followed by a Plant System I&C Programmer, trying to give all
information in the order the programmer needs them:
- Standard Functional Architecture of the PLC Application
-

Naming and Numbering Conventions required all along the development of the
application

-

Hardware Configuration of the PLC

-

Standard PLC Software Structure.

-

Interfaces

-

Core Application Development

-

Software Configuration Management

-

Examples and Templates

In the document the following markers will precede some paragraphs:
[NR<w>] for naming rules,
[CR<x>] for coding rules,
[RD<y>] for reference documents,
[D<z>] for reference to PCDH ( [RD 10]) Deliverables.
These markers will be referenced in the document.

1.5 Acronyms
SSPS
PLC
FBS
PBS
CBS
FC
FB

Standard Software PLC Structure
Programmable Logic Controller
Functional Breakdown Structure
Process Breakdown Structure
Component Breakdown Structure
Function Chart

Function Block

Page 8 of 60


DB
UDT
SFC
SFB
FBD
LAD
CFC
SDD
PSH
COS
PCDH
I/Q

Data Block
User Data Type
System Function Chart
System Function Block
Functional Block Diagram
Ladder Diagram
Continuous Flow Chart
Self Description Data
Plant System Host
Common Operating State
Plant Control Design Handbook
Inputs/Outputs

1.6 Definitions
PLC Application
PLC Core Application
Shared DB variable
Process Variable
Plant System I&C
Programmer
Configuration Database
Peripheral Blocks
Configuration
Configuration Variable
States
State Variable
Standard Control Block
Interface
Control Function
Control Block

All Software developed in a PLC
All Software or Control Blocks implementing the Control
Functions. All what is not implemented in the Peripheral
Blocks
Generic term used for any variable in a PLC
Generic term used for a Variable in the EPICS environment.
Person Responsible of Programming CODAC, PLC or Fast
Controller applications.
PLC software Blocks implementing the interfaces and the
Health Monitoring.
Set of all configuration variables for a PLC.

An EPICS PV transmitted to the PLC through a Shared DB
Variable.
Set of all PLC Shared DB variables transmitted to the CODAC.
A PLC Shared DB variable transmitted to the CODAC through
an EPICS PV.
In and Out parameters of a FC or a FB for a Control Block
deployed in the PLC Core Application
Function achieved by a Controller in the Context of a Functional
Analysis.
FC of FB in the Context of a Siemens Step 7 application.

1.7 Reference Documents

[RD 1]
[RD 2]
[RD 3]
[RD 4]

IDM Number
2UT8SH
28QDBS
34V362
353AZY

Title
“I&C Signal and Process Variable Naming Convention”
“ITER numbering system for parts/components”
“The CODAC – Plant System Interface”
“Methodology for PS I&C design”

Page 9 of 60


[RD 5]

2FJMPY

[RD 6]
[RD 7]
[RD 8]
[RD 9]
[RD 10]

32GEBH
32Z4W2
35W299
333J63
27LH2V

“ITER Function Category and Type for ITER Numbering
System”
“Plant System I&C Architecture”
“Self-description data editor - User manual”
“Cooling Water System Prototype Specification”
Siemens S7 PLC Catalogue
Plant Control Design Handbook

Page 10 of 60

2 Context and Constraints

Figure 2: CODAC Architecture
The architecture of Plant System I&C is defined in [RD 6]. The PLCs will communicate with
the CODAC through the PSH. The PSH is a standard computer running EPICS. Its
configuration will be generated for each Plant System I&C. The communication with Step7
PLCs will be done through TCP/IP Socket communication. The general structure of the frames
has already been settled.
The PSH will implement the COS that has to be synchronized with the State of the PLC.
PLCs inside a Plant System may have functional interfaces with other PLCs, Fast Controllers
and COTS Intelligent Devices. These interfaces will be supported by the PON.

Page 11 of 60


3 Generic Requirements of PLC Applications on
ITER
-

Flexibility.
o During integration and Commissioning, all interfaces may be not available. The
application should give possibility to force some signals, or to simulate partially
the missing interface.

-

Maintainability
o Enough system information of the system should be provided.
o The PLC Application should be built in a way that modifications has only
located impact.

-

Ability to be tested.
o Unit testing of PLC Functions should be made easier
o Control Systems Software should be tested independently from the system. The
idea is to test the Control System disconnected from the System and connected
to a Simulator. The plant System has to define beforehand what Controllers has
to be tested together.

-

Readability
o Every information transformation should be easy to track.

Page 12 of 60


4 Software Architecture of a PLC application.
CODAC Core
System

PLC
CODAC interface

2

8

4

7

9

12
11

7

System
Monitoring

PLC Core
Application
6

10

13

PLC
Interface

Fast
Controller
Interface(s)

PLC(s)

Fast
Controller(s)

11
5

3

Hardware Outputs/Inputs Interface

Equipments
PIS
PSS
COTS

Simulator

Figure 3: PLC Conceptual Architecture
The idea is to have a common architecture of the application inside all the PLCs deployed on
the Project. Depending of PLC Application all the blocks might not be present. For example:


A “Master Controller”, in an I&C architecture (see [RD 6]) will not have any Hardware
Inputs/ Outputs Interface and will have a lot of Interfaces with other PLCs of the Plant
System.



Fast Controllers Interfaces will probably be very rare and may use the CODAC interface,
as Fast Controllers are running EPICS and are consequently connected to Channel Access.

TBD

Except for the PLC Core Application, the inside structure of all other blocks will be standard
for all PLCs deployed on the Project. Only the volume and structure of the datas computed in
these blocks will be different. As far as possible, these blocks will be generated automatically,
using the “Configuration Database” as input. The Codac Interface (“2”on Figure 3) is already
fully generated by the SDD package. For the other blocks, the static inside structure will be
developed in this document. Further generation activities will be based on these structures.

Page 13 of 60


4.1 PLC Core Application
The PLC Core Application (“1”on Figure 3) is the place where the Control Logics, Grafcets,
State Charts, Regulation Loops of the process will be implemented. In this place we should
find only the process programming. The PLC Core Application will implement the “Control
Functions.” Its operation will be affected by all the interfaces represented on Figure 3. All
programming or treatment not directly involving the process are performed in the other
“Peripheral blocks” (Interfaces, System monitoring).
CODAC Interface
Simple
Commands
Comfiguration

Collaborative
Datas

States Variables

PLC Core Application

Outputs

Controller
Interface(s)

Inputs

Hardware Outputs/Inputs interface

Figure 4: PLC Core Application Environment
The PLC Core application will use the configuration variables (See Figure 4) transmitted by
the CODAC interface as main inputs from operation.
Some Configuration variables examples:
- ON/OFF requests
- OPEN/CLOSE requests,
- HIGH VACUUM/ROUGHING/VENTING request,
- Current Setpoint,
- Temperature Setpoint
- …
Hardware Inputs and Outputs (See Figure 4) are in their engineering format. The PLC Core
Application, make a complete abstraction of the fact that these values are coming from real
equipments or simulated or forced.
PLC Core Application will compute the CODAC Configuration variables and the Hardware
Inputs and generate the outputs in order to reach the configuration requested. The States
variables report the effective State of the process. The main principle is that on the CODAC, it
is always possible to have an easy comparison between the state (configuration) that was
requested to the Process, and the effective state of the Process. A simple example is given in
Figure 5 of what will be a CODAC HMI for a simple device.

Page 14 of 60


Easy Comparaison of
Configuration and State

Easy Comparaison of
Configuration and State

Power Supply

Power Supply

State

Configuration

Configuration

ON

Amps

95.00

ON

Amps

95.00

State

ON

Amps

95.00

Interlocks

OFF

Amps

0.00

Interlocks

Water Cooling NOK

Water Cooling NOK

Temperature OK

Temperature OK

24 VDC OK

24 VDC OK

Fuse OK

Fuse OK

Power OK

Power OK

Normal Operation

Off - Normal Operation

Figure 5: Simple Example of CODAC HMI
Collaborative Datas (See Figure 4) are State Variables produced by other Plant Systems and
Transmitted by CODAC Core System. In PCDH transversal wired links between Plant System
is strictly forbidden. Transmission of information between Plant System will use the
Collaborative Data link.
The interfaces with other Controllers within the same Plant System I&C impacts also the
processing, it will be developed in § 4.4 and § 4.5.

4.2 CODAC Interface
The main function of the CODAC Interface (“2”in Figure 3 ) is to manage the PLC side of the
communication with the CODAC developed in an EPICS environment. The CODAC side of
the communication is managed in the PSH running a specific driver.
This communication is broken down in 4 categories, as represented in Figure 4:
- Configuration Variables
- State Variables
- Simple Commands
- Collaborative Data

The main use of Configuration variables is developed in § 4.1. In Figure 3 the link “8”
represents another use of these variables: it will give configuration to the Hardware
Outputs/Inputs Interface. Mainly, it will provide Physical to engineering conversion
parameters, forcing values and inhibitions, it will also affect the simulation mode. It is
developed in § 4.3
The States Variables are transmitting the state of the Process:

Page 15 of 60


-

-

Directly from the Hardware Inputs/Outputs Interface (“6”in Figure 3 ). This direct
link is necessary as the CODAC Core Applications will use these variables without
computing required in the PLC Core Application.
It is important to note here that these variables here are in their engineering values, they
can also can be forced or simulated.
From the computed variables issued by the PLC Core Application (“7”in Figure 3 ).
From the System Monitoring (“9”in Figure 3 ).

Simple Commands are variables set to “TRUE” during one Cycle in the PLC. These simple
Commands are used in the cases where it is not required to memorize the action related to this
command, like with configuration variables.. Typical examples are “Reset” of some devices.
Reset is not a stable configuration, it is a transient command.
Collaborative Data are state variables transmitted between Plant System I&Cs. A Strong
requirement of the PCDH is a that no transversal wired link is allowed between Plant System
I&Cs. This link will be a “Software link” between 2 PLCs from 2 different Plant System
I&Cs. This collaborative Datas will be States Variables with a specific Status of

“Collaborative Data”.
Note, that if several Controllers have to share the same information (A temperature, a Pressure,
…) it is important that this information has exactly the same origin.
CODAC Core
system

EPICS Channel Access

PSH

PSH

States Variables

Collaborative Data

PLC X.1

PLC Y.1

Plant system I&C
“X”

Plant system I&C
“Y”

Figure 6: Collaborative Data

4.3 Hardware inputs/outputs interface
4.3.1 General Description

Page 16 of 60


Codac Interface
Configuration

States

PLC Core Application

Hardware Inputs
interface

Hardware Outputs
interface
“Forcing”

“Forcing”

Analog

Electrical Signal
to Engineering
Conversion

Digital

Analog

Digital

Engineering
Limits

Standardization

Digital

Analog

Engineering to
Electrical Signal
Conversion

FBS Wrapper

Standardization
Digital

Analog

Analog

Anti-Rebounce

FBS Wrapper

Digital

Interface Switch

Inputs Wrapper

Wiring

Plant System

Interface Switch

Simulator
Interface

Outputs
Wrapper
Wiring
RawSocket

Simulator
Interface

RawSocket

Plant System Simulator

Figure 7: Hardware Inputs/Outputs Interface Block Diagram
The Hardware Interface is divided in two parts: inputs interface and outputs interface. Almost
same functions are present in both parts but are processed in reverse order. In order to explain
the working of this interface, here is the process flow of a wired input coming from a Plant
System:

-

The signal is wired between the Plant System and the Input Board of the PLC .

Page 17 of 60


-

-

-

-

-

-

In a first Software Function called the “Inputs Wrapper” (2), the signal is copied from
an I/Q addressing area to a DB addressing area. Example Input “I0.0” is copied in
“DB1.DBX0.0”. Note: PLC absolute addressing is used here for better understanding,
but Symbols should be used. The signal is now becoming a Shared DB variable.
If the signal is Boolean (coming originally from a digital signal), the variable is going
through an “Anti-Rebounce” layer.
The Shared DB variable is transmitted to an “Interface Switch” Block where it is
chosen to use the wired signal or a signal coming from a Simulator. Another Shared
DB variable is issued.
The issued Shared DB variable is transmitted to a “FBS Wrapper”, where the variable
is copied from a Component Naming Convention (“PPPPPP-TTTNNNN:AAAASSSS”) to a FBS Level 3 convention (FBS-L3.variable). See [RD 1].

Another Shared DB variable is issued.
From the “FBS Wrapper”, the Shared DB variable can have a different processing,
depending if it is a numerical (coming originally form a analog signal) or a boolean
variable (coming originally from a digital signal).
o Numerical Variable: it is being transformed in an engineering value according
to a linear regression, or a Look Up Table, etc… “Signal to Engineering
Conversion” (5). Another Shared DB variable is issued.
o Boolean Variable: here the Boolean value can be negated or not, depending on
the logic the Developer wants to use in the Core Application. Example: in
order to have a fail-safe logic, the status of a device could be notified by a “0V”
signal, what it is more convenient to program a “TRUE” in the code.
“Standardization Layer” (6). Another Shared DB variable is issued.
The variable is going through a “Forcing” Layer (7), where its value can be forced by
the user, for commissioning or maintenance purposes. The variable issued is the one
issued by the Hardware Input Interface.
The variable is systematically transmitted to the “States Variables” (8) transmission
mechanism of the CODAC Interface. And can be used by the PLC Core Application
(9).

The following paragraphs give a more detail description of t every layer.

4.3.2 Inputs/Outputs Wrapper
The purpose of this layer is to directly use at the lowest level aSiemens Data Blocks addressing
area. (Shared DB variables) There are 2 advantages:
- Information can be organized in hierarchy in systems and subsystems with different
depth.
- The whole volume of variables can be handled with only one simple block.
Complex interfaces like FM453 positioning modules, CP441 serial communications modules
will also be implemented in this layer.
There is link between this layer and the Health Monitoring function. All the the variables

issued by the Wrapper will be transmitted to the Health Monitoring System. The Health

Page 18 of 60


Monitoring System transmits these variables to the CODAC interface. The purpose is to have
the raw values of the CODAC available on a system screen. For debugging purposes.

4.3.3 Interface Switch
Connecting a process simulator to the controller will give the following possibilities:
- Validate the software without being connected to the process
- During integration and commissioning, modify the software and test these
modifications on a different platform, before loading on the real control unit.
The Interface Switch is just Switching the origin of the signal variables to the real process or to
a simulator. Whatever the Simulator is, we can consider that the interface will be a Data Block
The control of the Interface Switch will be a CODAC configuration variable (Figure 3 – “10”).
This command has to be secured in the sense that it cannot be operated during real operation.

4.3.4 Anti-Rebounce
TBD

4.3.5 Engineering Limits
For numerical outputs, it is necessary set limits expressed in engineering format, reflecting the
limit of the actuator or of the physical process. If these limits are exceeded, the PLC output
may be erroneous.
The limits will be set by configuration variables.

4.3.6 FBS Wrapper
This blocks simply copies the signal variables presented in a PBS naming convention
(PPPPPP-TTT-NNN:AAAASSSS) to a FBS naming convention (FBS-L3.variable).

A segregation is made between digital and numerical signal variable because the above layers
are different.

4.3.7 Electrical Signal to Engineering/Engineering to Electrical Signal
Conversion
For most of the numerical signal variables, a conversion will be required. This conversion can
be linear, quadratic, of superior orders. It can be also a look-up table.
All the conversion parameters will be provided by CODAC configuration variables.

4.3.8 Standardization
The idea here is to standardize the code as much as possible in the PLC Core Application. For
a same type of devices, we should always control it with the same PLC function. The fact is
that sometimes same type of devices will be wired with a different logic. If we take the
example of a valve. The Limit Switches of some valves will be wired in a positive logic
(24VDC – position reached) and some in a negative logic (0VDC – position reached). While
the Control of the valve is the identical...

Page 19 of 60


The function of this standardization block would be to process all the negation required to all
discrete signals, in order to present a standard signal interface of the different types of devices
to the PLC Core Application
All the negation parameters will be provided by CODAC configuration variables.

4.3.9 Forcing
During integration, commissioning and sometimes during maintenance, engineers will
inevitably want to force some signal variables to a value, because the related signal is not
connected, is missing, is not operational or is failing. This is the reality of highly integrated
systems during non-operational phases. It is better to take this fact into account into the

software design, so that this “unregular” (and can-be-dangerous) behaviour will be kept under
control. The idea here is to avoid dangerous “temporary-permanent” practices like forcing
some signal with PLC hardcoded modifications, hardwired modifications, screwdrivers sticked
in the relays.
This forcing layer has to be developped. We can consider ie:
- some signals that cannot be forced at any time because impact can be destructive.
- The control unit (or the all I&C) cannot reach an operational state as long as signal
variables are forced.
- Inhibiting this forcing feature.
All permanent and runtime parameters will be provided by CODAC configuration variables.

4.4 PLC Interface
This interface addresses communications between PLCs of a same Plant System I&C, in case a
functional interface is required. The Siemens Protocol used will be defined later in the
document.
From conceptual point of view, we can consider 3 different cases:
- It can be master/slave link where the master PLC is sending commands (Boolean or
numerical) to a slave PLC
- A point-to-point link where 2 PLCs are exchanging states between each other. This
state transmission can be Inputs/outputs of another PLC.
- A Multipoint Communication where a PLC is Publishing states to a group of PLCs.
In a Master/Slave architecture, the Master Coordinator will send orders to the Slaves. A
communication paradigm has to be defined for the communication of these orders. TBD
Each case will be implemented with the most appropriate Siemens Technology.

4.5 Fast Controller Interface
This interface addresses communications between a PLC and a Fast Controller. We consider
here 3 cases.
- It can be master/slave link where the PLC is sending orders (Boolean or numerical) to a
Fast Controller.

Page 20 of 60


-

It can be master/slave link where the Fast Controller is sending orders (Boolean or
numerical) to a PLC.
A point-to-point link where a Fast Controler and a PLC are exchanging states between
each other.

In a Master/Slave architecture, the Master will send orders to the Slaves. A communication
paradigm has to be defined for the communication of these orders. TBD
The Technology used will be defined in a later Paragraph.

4.6 System Monitoring
A Task will be dedicated to PLC System Monitoring: the following Parameters will be
monitored:
 Operating Mode: RUN/STOP
 Memory:
o Load Memory Assigned: 0..100%
o Work Memory Assigned: 0..100%
o Retentive: 0..100%
 Scan cycles:
o Shortest
o Longest
o Average
o Standard Deviation
 CPU Time: Date and Hour
 Communication

o Configured
o Max numbers of connexion available
o Number of connection used
 I/Os:
o Board Statuses
o Raw value of each signal
 Alive Counter.

Page 21 of 60


5 Numbering and naming conventions.
5.1 Block numbering convention
A Siemens PLC Program is composed of several Blocks. There are different Block Types :
OB, FC, DB, etc.. A number is attributed to each of these blocks. The numbering areas will
be divided in 3 Categories:
1. “System” Blocks
2. “CODAC Reserved” Blocks including:
o Control Blocks produced by the CODAC in the scope of Standardization. Some
of these Blocks will be used the Peripheral Blocks, some in the Core
Application.
o DBs used in Peripheral Blocks with content specific to the application but
unique.
3. “Application Specific” Blocks including:
o DBs used in Peripheral Blocks with content specific to the application and with
a number of Blocks specific to the application.
o All Blocks in the Core Application produced by the Plant System I&C
Developer.
Numbering
OB

Siemens Default

UDT
System
CODAC Reserved
Application Specific

1..99
100..299
300..65535

DB
CODAC Reserved
Shared
Instance
Application Specific
Shared
Instance

1..49
50..99
100..299
300..999

FC
System
CODAC Reserved
Application Specific

Siemens Default:1..99
100..199
200..999

System
CODAC Reserved

Siemens Default:1..99
100..199

FB

Page 22 of 60


Application Specific

200..999

SFC

Siemens Default

SFB

Siemens Default

5.2 Block Naming Convention
As we want to enforce symbolic Programming, a name will be attributed to each Block.
Naming is an important topic in large projects. ITER has already issued documents that have to

be applied. See [RD 1], [RD 2] and [RD 5]. Naming of components inside the PLCs is not
simple as many factors has to be considered:
 FBS and PBS naming Conventions
 System Blocks have predefined names
 Some Blocks are related to the Core Application, some to the Peripheral Blocks
 Few Metacharacters are allowed in Siemens
Naming rules will be spread all over the document. However some generic rules can already
be mentioned here.
[NR 1]
[NR 2]
[NR 3]

UDTs names will always begin with ”_” (underscore character)
.
Instance DBs will always begin with “i”.
When a block name or part of name is related to FBS, the FBS identifiers will always
be in capital letters, and separated by “_” (underscore character).
Examples: "_WFC_CIStates", “WFC”

5.2.1 Core Application Blocks naming convention
The rules will be illustrated with example taken from the FBS of the Cooling Water System
Prototype in its actual state. See Annex §14.3 for summary or [RD 8] We will take the case of
the Water Flow Control Function.
There will be one FC in the PLC for the Control of the WFC. A FBD representation of a
Siemens Control Block of the WFC is represented in Figure 8. The figure represents an
example with a FC and an example with a FB.

Page 23 of 60