58th International Astronautical Congress , Hyderabad, India, 24 - 28 September 2007. Copyright IAF/IAA. All rights reserved.

IAC-07-D2.I.03
PROCESS AUTOMATION SYSTEMS FOR
PROPELLANT SERVICING OF LIQUID STAGES
FOR SATELLITE LAUNCH VEHICLES
Srinivas Anand Yalamarty RSN
Manager, CS-ESPS, LSSF
Indian Space Research Organisation (ISRO), SDSC-SHAR, India
Email: yrsn@shar.gov.in
Naga Satyanarayana Mamidala
Manager, CS-CPS, LSSF
Indian Space Research Organisation (ISRO), SDSC-SHAR, India
Email: mnsatya@shar.gov.in
Dhanumjaya Rao MMV
Dy. Manager, CS-CPS, LSSF
Indian Space Research Organisation (ISRO), SDSC-SHAR, India
Email: mmvdrao@shar.gov.in
Sambhu Prasad Sesham
Engineer SE, CS-ESPS, LSSF
Indian Space Research Organisation (ISRO), SDSC-SHAR, India
Email: sambhu@shar.gov.in
Palani PT
General Manager, LSSF
Indian Space Research Organisation (ISRO), SDSC-SHAR, India
Email: ptpalani@shar.gov.in
Malay Krishna Sanyal
Deputy Director, LSSF
Indian Space Research Organisation (ISRO), SDSC-SHAR, India
Email: mksanyal@shar.gov.in

ABSTRACT
Satellite launch vehicles use solid and liquid propelled stages. Liquid
Propelled rocket stages need to be serviced at the launch pad during the
final phases of the launch count down. Due to the nature of the
propellants being used, requirement to service in a fully automated, safe
and reliable manner from a remote location and perform the functions in
stipulated time frame even under single point failures, distributed fault
tolerant control systems, with Triple Redundant Programmable
Computer Controller (PCC) Architecture, were realised for liquid stage
servicing. Hardware Implemented Fault Tolerance (HIFT) and Software
Implemented Fault Tolerance (SIFT) schemes were employed for
determining healthiness of signals read or generated to the field. The
software was developed in-house, using International Standard Software
development life cycle model. The software is built using “layered
architecture” for the tasks identified in each system. A Client–Server
based Supervisory Control and Data Acquisition (SCADA) System, with
dual redundancy is implemented for providing real-time graphical display
of process at remote control centre. The Paper discusses the architecture
of the process automation system implemented to meet the above
requirements and the issues addressed to meet the safety, reliability and
fault tolerance requirements of the system.

1
 FULL TEXT
withstand all single point
INTRODUCTION
failures. Under all nominal and
Satellite launch vehicles use a off-nominal conditions, the
combination of liquid and solid automation system should be
propelled stages. Rocket stages able to complete the scheduled
including the satellite are activities in time.
assembled at the launch
complex. The solid motor stages Distributed fault tolerant control
are brought to the assembly / systems were realized for
integration facilities in pre-cast servicing Earth storable and
condition. Due to hazardous and Cryogenic propellants separately
highly toxic nature of the interfacing to 20000 process
propellants, temperature elements and onboard systems,
constraints, corrosive nature, the with a deterministic response
liquid propellants are filled to the time requirement of 100ms for
rocket stages after integration control and monitoring including
and at the launch pad. They network performance. The
need to be chilled and filled to system is configured for
the stages at the specified distributed control and
temperatures at controlled flow monitoring using Programmable
rate and pressure. The propellant Computer Controllers (PCC) with
servicing and gas charging triple redundancy having
operations required for the liquid Software and hardware
stages need to be carried out implemented fault tolerant
remotely, safely and reliably architectures to avoid single
during the count down point failures. The IO data
operations for the launch acquisition systems are
mission. connected on triple redundant
networks to the distributed
The propellant servicing process locations to ensure reliability and
is required to be controlled using high availability.
E/P Valves, propellant pumps,
flow control valves etc. Feedback The Supervisory Control and
parameters such as pressure, Data acquisition activities are
temperature, flow etc., are performed using Client Server
measured using sensors. It is architecture. 48 Client displays
also required to monitor / control are provided on the network to
the safety systems. facilitate simultaneous real-time
graphical viewing of the process
Since the activities are carried activity, real-time alarm
out during the final phase of the monitoring, trend information,
count down, it demands that the and system health monitoring.
automation system planned The total system is configured on
should be fault tolerant and a distributed network system

2
connecting the remote control
centre and the launch complex
on dual redundant Fiber Optic
network.
The application software is
developed in-house, following
International standard software
development life cycle model.
Application software for the
control algorithms in the Triple
Redundant CPUs are divided into
multiple independent tasks with
inter-task communications to
handle various related activities.
The tasks are configured to work
in a layered architecture in a
100ms cycle time with internal
functions using a “Call and
Return” Architecture. The
software is built taking into
consideration, necessary safety
aspects with respect to control
system functionality and the
liquid stage servicing process.
SYSTEM ARCHITECTURE
To meet the functional, safety,
reliability and performance
requirements of the control
system, for performing the
required activities of servicing
liquid stages of a launch vehicle,
Programmable computer
controller (PCC) based systems
were realised. The system is
configured for performing the
control functions of the total
process in a deterministic cycle
time of 100ms, in a distributed
architecture. The visualization of
the entire process in real-time is
provided using a SCADA system
configured using Client Server
Architecture.
3
The conceptual overall system
architectural diagram is depicted
in Fig 1.
Distributed Process
Control Systems
FO
SCADA Servers
Network
Client Stations
Fig 1: Conceptual Architectural Diagram
The following sections briefly
describe the architectural details
of every individual item in the
overall system.
Distributed Process Control
Systems
The system is configured using
PCC based systems to cater to
the requirement of interfacing to
large number of I/O devices. To
meet the requirements of fault
tolerance, safety and reliability of
operations to be carried out for
propellant servicing of liquid
stages of launch vehicles,
redundant systems were
envisaged.
Safety Vs. Reliability
There are two basic reasons to
use redundant systems for the
process control application,
first to achieve a higher safety
and second to get a higher
reliability. These both
requirements often contradict
each other [1].
In a high safety application,
we may require to switch on
some actuators only if all
redundant software and
hardware parts agree on
switching it on. If one of the
software parts fails, the
actuator will not be activated,
the plant does not make the
required action.
In another case we may
require, that the actuator is
switched as long as possible,
also if major hardware parts
or sensors fail. We would
possibly require that if only
one part of the redundant
software and one part of the
redundant hardware is
working, they shall still keep
the plant working.
The system required for this
application has to meet both
of the above requirements. It
is possible to design high
safety applications and high
reliability applications as well.
We can mix them and create
an application, including high
safety parts and high
reliability parts at the same
time. Both the features can be
achieved by the Scalable
Redundancy concept based
PCC systems selected for this
application.
4
PCC Systems
To meet the requirements of
fault tolerance, dual or triple
redundancy can be employed.
Dual redundancy has always
the possibility of contention of
which of the data is correct, in
case data from both elements
does not agree with each
other. To avoid contention
under such scenarios, the
system was configured with
triple redundant architecture
as depicted in Fig 2.
Fig 2: PCC Architecture
Three CPUs are configured for
each PCC system with their
own network interfaces and
other sub-systems. These
CPUs work together in a cyclic
fashion, similar to that of the
Programmable logic
controllers (PLCs) and can be
programmed independently.
The three CPUs communicate
between each other using a
dual redundant CAN interface
bus. One of the CPU assumes
the state of a Master CPU and
takes the responsibility of
synchronization of events and
activities carried out by the
other two CPUs, such that all
three CPUs would work
cohesively and generate
identical output at all times.
The CPUs exchange the
synchronization information
and common data over the
CAN Bus link. Each CPU is
equipped with three network
cards to communicate with
triple redundant Input and
Output device interface
boards (referred to as I/O
Slave Stations) over the
dedicated network links.
I/O Slave Stations
Three sets of I/O Slave
Stations are configured to
interface each type of field
device to take care of system
operations during single point
failure of the process control
system hardware elements.
Each I/O Layer consists of its
own CPU and network
interface boards for
communicating with the PCC
CPUs. The CPU in the I/O
Layer acquires the data from
the Input device, and sends
the data to the PCC CPU for
its usage. The Commands
from the three PCC CPUs are
acquired over the network,
voted using a two out of three
voting algorithm and the
resulted voted output data is
posted on the output circuit.
Scalable Redundancy Concept
The architecture of the PCC
system explained has the
advantage of being scalable
for various levels of
redundancy. The architecture
shown was with triple
5
redundancy. The above
architecture can be easily
modified into dual redundant
system by removing I/O layers
in column 2 of the above
architecture. Similarly
redundancy level could be
increased by increasing the
number of I/O layers and the
CPUs (example: 3 out of 5
Redundancies).
Logical data flow
The outputs originating from
the three I/O layers are
connected to a hardware
implemented fault tolerant
(HIFT) logic circuit (two of
three voting logic) to ensure
that only correct and validated
output only is posted to the
field. The typical HIFT based
voter can be implemented
using Relay Logics.
Thus, the inputs are validated
by the PCC CPUs using a
Software Implemented Fault
tolerant (SIFT) architecture,
and the outputs are validated,
at I/O Slave CPUs, using a
combination of Software and
Hardware implemented fault
tolerance architectures. The
Logical Input data flow is
shown in Fig 3 and the Logical
Output data flow is shown in
Fig 4.
 CPU Station
(supervisory control) by the
Application
operator as per count down
cyclogram.
Input Voter

The SCADA system is realised as

IO Slave Station 1 IO Slave Station 2 IO Slave Station 3
Input Data Input Data Input Data Client-Server architecture. The
column 1 column 2 column 3
total hardware components are
Input Input Input
duplicated to handle single point
channels
column 1
channels
column 2
channels
column 3
failures and thus implementing
fault tolerance in the system. The
Field Process Server is connected to the PCC
Fig 3: Logical Input Data Flow systems on a dual redundant
network (Control network)
Field Process
through which it can read the
process data and also exchange
Hardware Voter
user commands with the PCC.
The Server communicates with
IO Slave Station 1 IO Slave Station 2 IO Slave Station 3 the Client Stations on a separate
Output Voter Output Voter Output Voter
dual redundant network (Client
Network). Multiple Client stations
are configured to meet the user
requirements to simultaneously
CPU Station 1 CPU Station 2 CPU St. 3
view and control various
Application 1 Application 2 Application 3 processes that are required to be
Fig 4: Logical Output Data Flow carried out during the propellant
servicing phase of the count
Supervisory Control and Data down activities. The client
displays are refreshed with the
Acquisition (SCADA) process data in real-time by
reading the data from the process
The total operations related to data base stored at the Server.
propellant servicing needs to be
carried out from a remote control The above architecture ensures
centre in view of the hazardous that only Servers would make
nature of the propellants being communication calls to the PCC
handled. The SCADA system systems which are mainly
provides monitoring and control controlling the process activity.
of the entire process in real-time. This saves the time spent by the
It provides necessary features for PCC systems to service network
acquiring the data from the PCC communication calls, which
systems, store data for offline would have been otherwise
analysis, necessary graphical required for servicing
user displays for showing the communication calls from each
process of servicing the launch Client Station and likely to have
vehicle in real-time and for impact on the response times of
initiating control algorithms the PCC system.
6

The SCADA system also provides
the facility to depict critical
parameters as Trends in real-
time to enable the operator to
take necessary decisions, where
required. Provision exists to
configure alarm data for
generating alarm messages to the
operator based on the process
value of selected parameters. The
total data is logged at the Server
as a central database which can
I/O slave stations on receipt of
synchronization signal start
transmitting with fixed delay
time, from the above event,
which is a function of the node
number of the I/O slave station.
This ensures that no collisions
occur during data transmission
between the stations on the
network.
RS2 FX
( RH1CX)

be retrieved for offline analysis of

the process.
LAN 5 LAN 6 LAN 7

Network Architecture
The overall network architecture
is divided into multiple individual Fig 5: Network Architecture of PCC System
sub-nets. Each PCC system is
configured with three The network communication link
independent networks for from Server to PCC systems and
establishing communication Server to Client Systems are
between the CPU station and I/O realised as separate networks, as
slave stations. shown in Fig 6, to ensure that
the network communication
Ethernet communication network between Server and Client
is non-deterministic in nature. A Stations does not affect the
Process Control system needs to performance of the data
provide deterministic response communication between the
while servicing various field Server and PCC systems.
elements. In order to make the
Ethernet communication network
deterministic, the networks
between each chain of I/Os are
made independent of each other,
reducing the collision domain of
the network. The network
architecture of one PCC CPU
communication with the I/O
slave stations is shown in Fig 5.
The CPU stations generate a
synchronization signal to the I/O Fig 6: Overall Network Architecture
Slave layers, which are
numbered by node numbers. The
7
Application Software Architecture Voting of input data
(Environment Software
Application software for Inputs) and processing
controlling the process resides in of input data into
the PCC system CPU. The engineering units.
application requires to be Process application
executed in a deterministic cycle algorithms (Divided into
of 100ms to ensure that outputs multiple tasks based on
are maintained as per the the process
process requirement. The requirements)
application software is developed Data output to field
following an incremental model of (Environment Software
software development life cycle. outputs) and data
The Software requirements are communication to
analyzed using Structured external network
Analysis techniques and the devices.
necessary software architecture Each of the above activity is
is formulated. To ensure that all divided into individual tasks
CPUs generate outputs in and configured in a layered
synchronization with each other, architecture in the order
Event based State transition provided above. Within each
techniques are employed. All task, application requirements
software life cycle activities are are met by building function
carried out as per ESA-PSS-05 calls which are inter
Software engineering standards dependent on each other. The
[2]. function calls are generated
Architecture using a “Call and Return”
To achieve the deterministic Architecture.
cycle of 100ms the PCC
system operates using a cyclic The application tasks are
architecture. Each CPU of the designed to be independent to
PCC System carries out the each other such that any
following activities change in a particular
sequentially every cycle in application task does not have
deterministic manner. any implication on the
System health execution of any other task.
monitoring functions, Standard interface structures
Acquisition of data from are created for inter-task
I/O CPUs, data communications by building
acquisition from interface function macros with
Network resources standard arguments. These
Exchange functions ensure that the task
synchronisation data implementation is
between Master and independent of the interface
Slave CPUs. with other tasks. For example,
all inputs from the field are
8
acquired by the “Environment
Software Inputs” task. This
task takes care of voting the
input data and generating
voted information and
conversion of the data into
engineering units. The
application tasks, whose
algorithms are used to control
the process, access these data
by way of using environment
software macro interfaces,
which gets the relevant data
from the “Environment
software inputs” task
variables.
Each algorithm of an
application task is assigned to
any one of the states viz.,
SLEEP, INITIATED, READY,
AUTHORISED, SCHEDULED,
and COMPLETED/ABORTED,
which are self-explanatory. By
controlling the state of the
algorithm of each application
task, the necessary jobs are
executed at the PCC system.
An algorithm by default will
be in SLEEP state. An
algorithm can be brought to
an INITIATED condition only if
an operator initiates this
activity. The algorithm
indicates its READINESS,
once its initial conditions to
carry out the process are
satisfied. The algorithm waits
for an AUTHORISATION from
the Chief of Operations to get
SCHEDULED and run to
COMPLETION.
9
Voting Algorithms
“Environment software
Inputs” application task has
to carry out the necessary
voting of IO data before it is
handed over for processing to
the process algorithm.
IO voting means to select one
input or output signal from
three signals. The aim of
voting is to avoid processing
faulty signals. Voting
algorithms are software
functions, which select one
signal from multiple input
signals. There are different
voting algorithms for digital
and for analog signals.
The input signals of a voting
algorithm can have either
valid values (e.g. 0 or 1 for a
digital signal) or they can have
a special value, indicating that
the signal is missing or faulty.
Voting algorithms can handle
missing and faulty signals and
they have an exactly defined
behaviour in case of missing
or faulty signals. This special
value is identified as Safe
value, which takes care of fail-
safe criticality.
Voting Digital Signals
Digital voting algorithms
use either democratic
voting algorithms, or voting
algorithms, which make a
simple logical combination
of the input signals.
Democratic voting
algorithms select the
status from those signals
which is in majority.
Therefore it is necessary to
have an odd number of
signals. Democratic
algorithms cannot be used
if only two signals are
available and they have
different values. For this
case either a predefined
value, the failure value, is
used or a master majority
decision will be made,
which prefers the value
from the master CPU
station. The inputs values
are validated with the
healthiness of the
hardware used for reading
the values before they are
subjected to voting.
Democratic Voting logic
can be of two types viz.,
Safe Democratic and
Available Democratic with
Master Majority. Safe
Democratic voting
algorithms are selected
when Odd number (>1) of
healthy inputs are to be
considered for evaluating
the voted result. If 3 inputs
are available, two out of
three voting is performed.
If only two inputs are
healthy and they are equal,
then one of them is
returned as voted value.
For all other cases, the
voting algorithm returns a
failure value (Safe value for
process). This type of
voting is usually referred
as 3-2-0 voting logic. In
case “Available Democratic
with Master Majority”
10
voting is selected, the voted
value is determined similar
to the above logic, but in
case the values do not
match, it generates the
value read by the Master
CPU as the voted value.
Also this returns the single
value if only one signal
(from Master CPU only) is
healthy. In all other cases
this logic returns a failure
value. This type of voting is
usually referred to as “3-2-
1-0” logic.
For fail safe applications
the voting logic requires
that all three signals
should be healthy and
equal. This is referred as
“3-0” voting logic.
Voting Analog Signals
Analog Signals also can be
voted based on the fault
tolerance or fail-safe logics.
The healthy analog signals
are compared to be within
a valid discrepancy value.
The analog signals whose
values are within the
discrepancy tolerance
value and within the
specified time period
(discrepancy tolerance
period) are considered for
usage. Depending upon the
usage and application
area, highest of the values,
lowest of the values or
average of the values is
taken as valid data. The
following are the possible
 analog signal voting applications are synchronised
algorithms. with each other.
Safe highest value
Safe middle value The sequence of the running
Safe lowest value of the application / system
Safe average tasks in the PCC system is as
Available highest explained in the Software
available value Architecture above.
Available middle
available value Due to the cyclic nature of
Available lowest execution of the application in
available value the PCC, advantage can be
Available average taken by synchronizing the
available value program state and user events
“Safe” algorithms are used and some critical control data.
in 3-0 voting logic. That is, All CPUs will be allowed to
these voting algorithms run asynchronously. The
require that all three CPUs will start their cyclic
signals are healthy before execution at the same time
voting. “Available” (synchronized by call from
algorithms are used in “3- System Manager in Master
2-0” or "3-2-1-0” voting CPU). The systems will
logics. That is, these voting acquire data from all the
algorithms are used under interfaced sub systems. The
failure mode conditions. If CPUs will wait for the
all signals are available synchronization call after
(healthy), all three signals reporting completion of the
are used, else if two are above activity.
healthy, two analog values
are used for voting and so On Synchronization call the
on. CPUs start executing the
application logic
Synchronized operation of simultaneously. The first
activity is to synchronize the
algorithms in all CPUs
data marked for
The three CPU stations
synchronization. Since the
execute the three application
Input data set is ensured to
programs, which can be
be identical amongst all CPUs,
identical or can be different.
due to voting, it is ensured
To achieve data integrity and
that if the processing logic is
concurrent application
same in all CPUs, they would
program processing, the
generate identical outputs.

11

Fig 7: Application Synchronization
The processing algorithm acts
on the input data set available
from “Environment Software
Inputs” Task and generates
output. The output generated
is presented on the output
system by all CPUs
simultaneously at the same
instant by synchronising the
event with the help of System
Manager Task call. This is
illustrated in Fig 7.
First the three CPU stations
execute the three application
programs. The application
programs may have a different
duration. The system waits
until the slowest application
program has finished and
starts system activities only
after all applications have
finished. After executing
system activities a similar
synchronisation takes place.
The system waits until all
CPU stations finished their
system activities and starts
the applications subsequently.
This process runs cyclically,
repeating application
execution and internal
activities.
12
N-Version Programming
When same application
software is executed in all
the CPUs as explained in
the previous section,
possibility of an erroneous
implementation of the
software would result in
not meeting the process
requirements properly. The
hardware and the software
architecture built provides
for having different
software in each of the
CPU.
The application software
for each CPU can be
developed by independent
programmers and loaded
into the CPUs. The State
transitions and the
synchronization events
need to be handled at the
time of software design
that all CPUs handle the
same state and event(s) at
a given time instant.
This ensures that the
system is robust against
bugs in application
software also, since no two
programmers are likely to
generate erroneous code at
the same location.
This feature of N-Version
programming with the
above Software
Architecture provides high
reliability in terms of
application software also.
Safety Aspects
Safety of the process also
forms primary responsibility
for the application software
architecture and design. This
is required in order to ensure
that process is handled in a
way that all safety precautions
are scrupulously followed.
The safety features built into
the software are addressed to
take care of situations related
to safe operation practices
and any abnormal conditions
that may arise during the
course of propellant servicing
to the stage.
The following features are
provided in order to have safe
operation practices.
All authenticated and
trained operators are
provided with necessary
security levels, which
they can gain access by
logging into the system
using their access
rights. This ensures
that the system cannot
be operated by any
unauthorised
personnel.
Group Authorisation –
Each group of process
elements is associated
with a group
authorisation. Unless
the group is authorised,
it is not possible to
operate the field
elements identified
under the group. The
group definition is
ensured that elements
13
related to a particular
activity only are
grouped. This ensures
that during a particular
activity, elements
related to other
processes cannot be
operated inadvertently.
Inhibition feature for
operation of process
elements. This feature
allows a process
element to be marked
as “Inhibited”, which
does not allow even the
automatic algorithm to
change its state of
operation without a
prior approval from the
operator. The operator,
authorised to give
permission to operate
such “inhibited” process
elements is identified
with a higher level of
security level. Thus
these elements cannot
be operated without the
knowledge of the
Supervisor.
Mode of Operation –
Each PCC system is
identified with various
modes of operations.
The default mode of
operation being “Idle”.
The “Idle” mode of
operation only acquires
the data from the field
and displays the data to
the operator. No
operations can be done
on the system under
this mode of operation.
Other modes of
operation are defined
 based on the type of logics, surveillance
application tasks that algorithms also take
are programmed on the necessary corrective
PCC System. The mode action in case of an
of operation selected alarm generation.
determines which
application tasks get
executed (can be taken
REFERENCES
out of SLEEP state) at
the PCC Systems. This [1] M Blanke, “Concepts and
type of architecture Methods in fault tolerant
provides safety against control”, Tutorial at American
operating applications Control Conference, June
related to a non- 2001
relevant task. [2] ESA Board for Software
The following safety features Standardisation and Control
are provided as part of the (BSSC), “ESA-PSS-05-0 ESA
application logic to ensure Software Engineering
that they are terminated or Standards Issue 02”, ESA,
handled properly. France, February 1991
Wherever analog data is
used for determining
the termination of logic,
multiple samples are
considered to positively
confirm the action being
taken. The samples are
correlated with the
trend of the parameter
to ensure that
processing is not done
based on wild samples.
Surveillance algorithms
are built in and get
executed automatically
such that they keep
monitoring for the
parameters to be within
the nominal operating
range. These logics will
generate necessary
alarms for the
application and the
operator whenever a
parameter violates its
safe limits. For critical
14