Supervisory Control using Intelligent Agents

Intelligent Agents for Supervisory
Control Systems
Design Philosophy
CONFIDENTIAL
This document contains confidential information that is the
property of Jayardee P/L.
No part of this document, nor any information contained in this
document, may be communicated to or discussed with any third party
without written consent of Jayadee P/L. This includes any verbal,
written, printed or electronic copy of the document, or any part
there-of.

Supervisory Control System. Material Handling Processes
Confidential. Jayardee P/L. September
2014
Contents
Contents .....................................................................................................................2
Introduction................................................................................................................4
SCS Overview .....................................................................................................................4
Document Outline..............................................................................................................5
Software Design. The functional approach ..................................................................7
Functional or System based Software .................................................................................7
References.........................................................................................................................7
Software Design. The objected oriented approach.......................................................8
Overview ...........................................................................................................................8
References.........................................................................................................................8
Object Modeling: Roles, Responsibilities and Collaboration .........................................9
Further Reading .................................................................................................................9
Text Books...............................................................................................................................................9
Web Sites................................................................................................................................................9
Intelligent Agents ..................................................................................................... 10
Philosophy ....................................................................................................................... 10
Command & Control.............................................................................................................................10
Intelligent Class Objects........................................................................................................................10
Topology ...............................................................................................................................................10
Intelligent Agent Structure ...................................................................................................................11
Analysis. Selecting Class Candidates.......................................................................... 13
Noun-Verb first cut........................................................................................................... 13
Analysis: SCS Application.................................................................................................. 13
SCS Entities ............................................................................................................... 15
SCS Entities: Overview .................................................................................................. 15
SCS Object Hierarchy ........................................................................................................ 16
SCS Data Class: Topology ............................................................................................... 17
SCS Class: Manager...................................................................................................... 18
Manager Role........................................................................................................................................18
Manager Responsibilities......................................................................................................................18
Manager Collaborations .......................................................................................................................18
SCS Class: Executor...................................................................................................... 19

2014
Executor Role........................................................................................................................................19
Executor Responsibilities......................................................................................................................19
Executor Collaborations........................................................................................................................19
SCS Class: Equipment................................................................................................... 20
Equipment Role ....................................................................................................................................20
Equipment Responsibilities...................................................................................................................20
Equipment Collaborations ....................................................................................................................20
SCS Class: Stock ........................................................................................................... 21
Stock Role .............................................................................................................................................21
Stock Responsibilities............................................................................................................................21
Stock Collaborations .............................................................................................................................21
Software Engineering Methodology.......................................................................... 23
Waterfall software development ...................................................................................... 23
Iterative software development ....................................................................................... 24
Comparison of Waterfall and Iterative software development........................................... 25
Further Reading ............................................................................................................... 25
Iterations in SCS Development.......................................................................................... 26
SCS Iteration 1.......................................................................................................................................26
SCS Iteration 2.......................................................................................................................................26
SCS Iteration 3. Release Version...........................................................................................................26
Simulation ................................................................................................................ 28
Simulator Description....................................................................................................... 28
Benefits ........................................................................................................................... 28
Testing ..................................................................................................................................................28
Training.................................................................................................................................................28
Building the SCS Application...................................................................................... 31
SCS Structure ................................................................................................................... 31
Building the Topology Variable ......................................................................................... 32
Calling the constructor functions at Initialisation.................................................................................32
Creating the Object Class Instances................................................................................... 33
Software Testing .............................................................................................................. 34
Operator Training............................................................................................................. 34
Hardware Architecture.............................................................................................. 35

2014
Introduction
This chapter provides an overview of this document and an Introduction to the
Supervisory Control System.
SCS Overview
SCS is a Supervisory Control System for Bulk Material Handling process such as found at a mine
site or a bulk port facility.
It is a combined PLC and SCADA application that supervises the operation of the bulk material
handling process.
SCS consists of five class objects. These objects can be deployed to different sites by
configuration only, i.e. no further programming is required.
Being an Object Oriented design, SCS has many advantages such as:
• Re-usable software objects
• Easy to maintain and troubleshoot
• Easy to re-deploy at new sites – configuration only
• Capture of client’s Intellectual Property and commercial advantages
SCS provides the management and supervisory functions expected in a Materials Handling
Environment. These include:
• Management and tracking of Material Inventory (Stockpile Management)
• Management of Production and Operational Plans (Ship loading plans)
• Management of Quality Data (Sample Station data management)
• Management and control of Equipment (Route Management)
SCS is currently completed to Proof of Concept stage in a Schneider environment. It is easily
portable to other environments. It is proposed to port it to GE Proficy Process Systems (PPS) where
each SCS object would be delivered as “PPS block” that integrates the PLC and SCADA logic into a
single class object.

2014
Document Outline
Section 1provides an introduction to some of the software design techniques,
technologies and concepts that are utilized in the SCS system. These include:
• Object modeling methodologies: Roles, Responsibilities and Collaborations
• Intelligent Agents
• Method for modeling plant layout (Topology)
Some references for further reading are provided in this section.
Section 2describes the basic elements of the SCS system, i.e. the four object classes and
the data class that comprise SCS. It also provides an outline of the analysis process that led to the
definition of these components, and explains how these components are assembled into an SCS
application.
The objects that comprise SCS are:
• Object Class: Equipment
• Object Class: Material
• Object Class: Manager
• Object Class: Executor
• Data Class: Topology
Section 3describes the iterative software development methodology used in developing
the SCS class objects, and compares it with the conventional waterfall method.
Section4describes the Simulator that supports the SCS application, for both testing and
operator training.
Section5provides an outline for how an SCS application is built and delivered using the SCS
class objects.

2014
SECTION 1. Design Concepts

2014
Software Design. The functional approach
This chapter describes the disadvantages of the traditional software development
style. In this document we do not elaborate on this style. We simply refer to domain
experts and provide references for further reading.
This chapter is added for reference and completeness. It is not intended as a
complete treatise on the subject.
Functional or System based Software
Functional or System based software design is focused on software code that delivers a
functional system. In the Materials Handling sector examples include systems such as
• Stockpile Management Systems
• Anti-collision systems
• Route management systems
• Etc
In all these systems the focus is on the functional capability of the “system” rather than the
physical or logical entities within the system. For example:
• The stockpile management system is based on functional capabilities rather than the
individual components of the system, i.e. stockpiles
• Route management systems concentrate on sequencing routes rather than the physical
entities of the system, e.g. conveyors, reclaimers etc.
Maintenance and extensibility are therefore compromised. For example, if a conveyor line is added
to a route management systems additional tables and pointers would need to be added, new
sequences written etc. By contrast, in an Object Oriented system a new Conveyor Object would be
added.
References
“Neolithic programmers lived in a state of simplicity. Programs were composed of a singular
straight, unbroken line of instructions to the computer. Even today, many of us initially learn to
program by writing standalone functions:
The single method style of program construction is the easiest form of programming to learn, but
it breaks down quickly as the program becomes larger. Early programmers and computer scientists
soon realized that they needed some way of managing complexity as software projects increased in
scope and ambition.
……. the ability to decompose a single program into multiple subroutines, classes, or services gave
programmers some fantastic advantages over the monolithic block of code: divide and conquer. You
can turn a single big problem into a series of easily achievable tasks. The human mind simply can't
juggle so many different variables at one time. Decomposing a system allows you to deal only with
one issue at a time, whether that be data validation, retrieval, or display.”
Jeremy Miller. MSDN. http://msdn.microsoft.com/en-us/magazine/cc721605.aspx

2014
Software Design. The objected oriented approach
This chapter describes the Object Oriented approach to software design. It is
presented for completeness and reference only. It is not intended as a complete treatise
on the subject.
SCS uses an Object Oriented Design.
Overview
Object Oriented Programming OOP refers to a programming methodology based on objects,
instead of just functions and procedures. These objects are organized into classes, which allow
individual objects to be group together.
Objects encapsulate all data and functions of an object. Software objects are often designed to
model, or represent, physical objects in the real world. Examples might include a “Customer” in a
banking context or an “Aeroplane” in an aviation navigation context. In a plant control system an
object might represent a VSD or a PID controller. In such cases there would be one software object
for each physical object in the physical environment. Objects may also be “abstract” in nature where
there is no real world physical equivalent. SCS has objects of both types.
Object oriented design makes it easier to structure and organize software programs. This
therefore leads to programs that are easier to implement, document and maintain.
An additional advantage of OO design is software re-use. For example, in an application for Bulk
Materials Handling, the behavior of a Conveyor is always the same. Therefore a Conveyor Class
Object can be re-used at any Bulk Materials Handling facility where conveyors are used, i.e. ALL such
sites.
Some basic concepts of OO design are:
• Objects
• Classes
• Abstraction and encapsulation
• Inheritance
All the above features are incorporated into the design of SCS.
Some of the well documented benefits and advantages of OO design are:
• Clear modular structure for programs
• Easy to maintain and modify existing code, and easily extensible via the addition of new
classes
• Facilitates creation of libraries that capture corporate intellectual property
References
This topic is covered exceedingly in books, training texts and online. The reader is encouraged to
explore the following examples.
https://www.cs.drexel.edu/~introcs/Fa12/notes/06.1_OOP/Advantages.html?CurrentSlide=3
http://www.saylor.org/site/wp-content/uploads/2013/02/CS101-2.1.2-
AdvantagesDisadvantagesOfOOP-FINAL.pdf
http://wiki.tcl.tk/13398

2014
Object Modeling: Roles, Responsibilities and Collaboration
This chapter describes the object modeling methodology referred to as “Roles,
Responsibilities and Collaborations”. This methodology is widely accepted as Industry
Best Practice, from organizations such as Microsoft.
This is the methodology used to design and describe the software architecture of the
SCS Application.
The Roles, Responsibilities and Collaboration model was first described by Rebecca Wirfs-Brock
and Alan McKean (see references). It is a simple and effective method to describe and specify the
object classes in an application. The method is often referred to as Class/Responsibility/Collaborator,
or CRC.
CRC Definitions
Class: This is the name the Class
Role: This is the Role of the class within the application
Responsibility: This refers to the specific tasks that the class is responsible to perform
Collaborators: This refers to
a) what other classes the class must collaborate with, and
b) the data structures use to collaborate.
Throughout this document, the CRC methodology is used to describe the role each class plays in
the SCS application, its specific responsibilities, and the mechanisms by which each class
collaborates with the other classes within the application. This provides a simple and logical method
of describing the application in its entirety.
Further Reading
Text Books
Title: Object Design. Roles, Responsibilities and Collaboration
Author: Rebecca Wirfs-Brock and Alan McKean
Publisher: Addison-Wesley
ISBN: 0-201-37943-0
Title: Object-oriented Software Construction
Author: Bertrand Meyer
Publisher: Prentice Hall
ISBN: 0-13-629049-3
Web Sites
http://msdn.microsoft.com/en-us/magazine/cc721605.aspx
http://agilemodeling.com/artifacts/crcModel.htm
http://www.methodsandtools.com/archive/archive.php?id=90

2014
Intelligent Agents
This chapter describes the concept of “Intelligent Agents” as utilized in the SCS
software.
SCS is based on a philosophy of Intelligent Agents. This is one of the key concepts that make the
SCS logic simple and easy to read and maintain.
It is also one of the key factors that make the objects re-usable across different sites since
regardless of site, a conveyor for example always behaves the same generic way.
Philosophy
When a human designs a conveyor network for example, the logic is usually presented
“generically”. This might be in the form of logical statements or maybe more formally in pseudo
code. For example consider the following hypothetical logic:
• When a conveyor is required to run in a sequence, it will start immediately its
downstream conveyor is running and up to full speed
• A conveyor can only run if its shuttle is in the correct position for the required route
• A shuttle cannot move if its feed conveyor is running and has ore on it
• A conveyor must not feed onto another that already contains material
• Etc. (Note these are hypothetical rules)
There are several ways to implement this kind of logic.
Command & Control
One way is to write a single supervisory program to control all the conveyors. This is quite
common where the network is simple (few routes). The concept does not scale well to larger
networks as has been found.
Intelligent Class Objects
Another method is to use intelligent class objects. With this method the logic is encapsulated
within the class.
This style of logic is then written using generic data such as:
• myConveyor
• myUpstreamConveyor
• myShuttle
• myRoute
• etc
Written this way the logic is very simple, and more importantly directly reflects the generic logic
in the FDS referred to above. That is, for each “Rule” in the FDS these is one line of logic in the PLC
code – no more, no less.
Topology
However, to make this style of programming possible, it is necessary for each object to know
• who is my myUpstreamConveyor ?
• who is my myShuttle ?
• who is my myRoute ?
• etc

2014
In the SCS this is achieved via the use of a Data Class named Topology. This class defines all the
equipment in the plant and the layout of the conveyor network in the plant. One instance (variable)
of this Class is created. This variable is then passed to all Equipment objects, which interprets the
layout and determines the upstream and downstream equipment etc.
Intelligent Agent Structure
The structure of the Equipment Class object is illustrated in the diagram. There are five
components:
1. Upstream Equipment Interface
2. Downstream Equipment Interface
3. Executor Interface
4. Plant Interface
5. Generic Class Logic
It is important to note that this structure separates the complexity of the plant layout from the
simple generic logic for the equipment. The four interfaces are placed in separate program segments
that are normally never visited during troubleshooting.
Upstream Equipment Interface
This component determines the state (running, stopped, ore-on, fault) etc of the upstream
equipment.
Downstream Equipment Interface
Similar to Upstream interface
Executor Interface
This component determines the state of the “Executor”, i.e. the object that has custody of
the equipment.
Plant Interface
This component determines the state of the physical equipment *conveyor, shuttle, balance
machine etc) that it represents. It also sends control commands to the equipment based on the
Generic logic.
Generic Class Logic
This component contains the generic control logic for the equipment it represents, i.e. the
start, stop, move, interlock etc commands for the equipment.
Logic for class
Abstracted
Executor Interface
Plant Interface
Downstream
Equipment
Interface
Upstream
Equipment
Interface

2014
SECTION 2. SCS Design

2014
Analysis. Selecting Class Candidates
This chapter provides a high level view to the procedure used to identify the class
objects in the SCS application. It is intended to provide an insight into one method of the
process, not a detailed analysis document.
Noun-Verb first cut
One methodology used to derive the Object Classes of an application is the “Noun-Verb” first
cut. This method involves the following steps:
• Write / review a description of the application. This description should be a plain English
description of the process at high level. It should not include detailed descriptions of
logical functions
• Highlight the nouns and verbs in the document
• Make a list of these, and eliminate duplicates and obvious non-candidates
• The remaining list is the basis of the class objects for the application
Analysis: SCS Application
The text box below contains a high level description of SCS, with key nouns and verbs
highlighted.
Supervisory Control System
Introduction
The Supervisory Control System (SCS) is a real-time application to control the site-wide operations
of a material handling facility, such as a mining or port facility. The SCS is a PLC-based application to
provide real-time control coupled with a SCADA system to provide Operator Interface. The SCS system
communicates with the Plant Control System (PCS) which comprises multiple PLCs controlling plant
level equipment. It is also linked to a database for storage of plans, QA results etc.
Details
The SCS provides the high level control of the Material Handling Equipment, such as Conveyors,
Shuttles, Stackers, Reclaimers, Ship loaders, Train Unloaders, Sample Stations, Ore Processing Facilities,
and Buffer Storage Bins etc.
The SCS also manages the material (ore) at the site. The material is stored in stockpiles. The SCS
maintains the quantity, type, location and other data related to the material as it moves through the
site.
The SCS controls the movement of material through the site by controlling (start, stop,
configuration) of the Equipment. The equipment may be configured in a flexible network by use of
shuttles, blending etc. For example at a Port facility these movements are referred to as “pours”, i.e. a
pre-determined quantity of material delivered from a source (stockpile of Train Unloader) to a hold on a
ship. There may be many (5-10+) concurrent movements at the site. A set of Equipment capable of a
movement are referred to as a route. A piece of equipment may be a member of many routes, but only
one at a time.
The movements are based on the elements of a Plan, e.g. a Ship Loading Plan or a Train Receival
Plan. At a Mine Site, the movement may be based on an Operations Plan. The SCS therefore Executes
the requirements of the Plan.

2014
Class Candidate How Modeled in SCS Comment
Material Handling
Equipment
Conveyors
Shuttles
Stackers
Reclaimers
Shiploaders
Train Unloaders
Sample Stations
Ore Processing Facilities
Buffer Storage Bins
Class Object: Equipment
Variants are Sub-classes
It would seem obvious that the most
important class in a Materials Handling
Application would be the Materials
Handling Equipment Class
Materials
Stockpiles
Class Object: Stockpile The second obvious class in a Materials
Handling Application is the Materials
Class.
We call it the Stockpile Class as this is
typically the smallest unit of record of
material
Manage Class Object: Manager This class manages the storage,
retrieval, creation, editing and data
validation of Plans
Executes Class Object: Executor This class executes plans by acquiring
custody of the equipment and
stockpiles necessary to complete the
requirements of the Plan
Plan
Operations Plan
Shiploading Plan
Inloading Plan
Data Class: Plan
Variants are Sub-classes
A plan is a list of activities that
need to be executed, e.g. pours,
movements, blends etc
This data is stored in the SQL database
and is:
• managed by the Manager Class,
and
• executed by the Executor Class
Movement
Pour
Not modeled explicitly
These are elements of plans. See
above
Consistent with S88 Process Model
Standard
Network Data Class: Topology There is one instance of this class per
application, i.e. per site.
It models the layout of the site.
Route Not modeled explicitly Consistent with S88 Process Model
Standard

2014
Routes are elements of topology.
See above
SCS Entities
This chapter describes the Classes in the SCS Application in terms of Roles,
Responsibilities and Collaborators.
The object hierarchy of the application is also documented.
SCS Entities: Overview
As described in the previous chapter, there are five main components of the SCS application.
Four of these are Class Objects, the other is a Data Class, also known as a Used Defined Type (UDT)
or similar in PLCs.
The Data Class is
• Topology
o This data class models the plant layout
o There is 1 instance of this class in the SCS Application
The Object Classes are
• Manager
o This class manages the Plans, both Shiploader and Train Unloader
o There is one instance of this class per Berth in the SCS Application
• Executor
o This class Executes the Plans by taking custody of the required equipment and
stockpile
o There is one instance of this class per Shiploader and Stacker in the SCS
Application
• Equipment
o This class models the behavior of equipment such as conveyors, shuttles,
balance machines, sample stations etc
o There is one instance of this class per physical equipment item in the SCS
Application
• Stock
o This class models the behavior stockpiles
o There is one instance of this class per stockpile in the SCS Application
These entities are described later in this section.

2014
SCS Object Hierarchy
The diagram below provides a high-level view the Class Hierarchy, and how the classes interact
(collaborate) with each other.
SCS Object Hierarchy
At the top level, the Manager Class manages the storage and retrieval of the plans from the
database, and validation, activation and editing of Plans. The activated Plan is “published” for
execution by the Executors.
The Executor looks at the pours in the plan. It also reads the Topology variable, and status of all
equipment and stockpiles. Based on this data, it then takes custody of the required equipment and
stockpile in order to execute the plan. NOTE: The Executor does not control the equipment with
start/stop commands. The equipment objects are intelligent objects and work out what to do
themselves.
The Equipment objects are Intelligent Agents. Each equipment object reads the Topology
variable and determines its upstream and downstream equipment (its neighbours). It reads the
status of its Executor (the Executor that has its custody) and what route the Executor is using, and it
reads the status of its upstream and downstream equipment. It then decides what it should be doing
at any point in time and sends the appropriate commands to the physical equipment at the plant
level PLC. The Sample Station sub-class also manages data storage of QA data.
The Stock object manages the stockpile database for each stockpile, locks it when in use and
passes the data to the plant level balance machines for processing.
Execu
tor
Pours StockPlans
Inventory
Inventory
Equip
ment
Status
Topology
Mana
ger
Header
Plant
QA Data

2014
SCS Data Class: Topology
Topology is a Data Class, or User Defined Data Type, that describes the plant layout. It is not a
Class Object in the normal sense. It is presented first as it is a precursor to the presentation of the
other Class Objects. The data definition for Topology is shown below.
Topology Data definition
Topology is a Data Structure consisting of three multi-dimensional arrays of BOOLs. These arrays
are:
• Routes
o This array represents the equipment in each route. There are 31 routes allowed
for, and a maximum of 128 equipment instances. Each equipment has a unique
Id. The Bool variable is set to one if the equipment exists in the route
o The snippet below visualizes the Routes array
• Connx
o Each Equipment has a Boolean array indicating its “neighbouring” equipment in
the plant layout, i.e. it Upstream (US) equipment and its Downstream(DS)
equipment
There is ONE instance of this class in the ACS application, as the ACS applies to ONE plant. A
different plant, for example a mine site, would have a different Topology variable.
Snippet of Routes Array

2014
SCS Class: Manager
Manager Role
The role of the Manager Class is to manage plans for the site.
There is one instance of the Manager class for each Berth to manage shiploading plans and one
instance for each TUL to manage in-loading plans.
Manager Responsibilities
The responsibilities of the Manager Class include:
• Storage and retrieval of the plan from the database
• Data validation
• Plan activation
• Management of Plan states
• Publish Plan data (collaboration)
Manager Collaborations
The Manager Class Collaborates with:
• Database – read/write
• Executor – by publishing activated plan

2014
SCS Class: Executor
Executor Role
The role of the Executor Class is to execute the plans.
There is one instance of the Executor Class for each Shiploader to execute out-loading plans and
one instance for each stacker to execute in-loading plans.
Executor Responsibilities
The responsibilities of the Executor Class include:
• Determine current and next pour
• Determine route for pour
• Manage state of each pour
• Publish its own state and the state of its pours (collaboration)
Executor Collaborations
The Executor Class Collaborates with:
• Manager
o By reading activated plan
• Topology
o By reading global Topology variable
• Equipment
o By reading status of equipment
• Stock
o By reading stockpile data

2014
SCS Class: Equipment
Equipment Role
The role of the Equipment class is to model the behavior of the material handling equipment.
There is one instance of the Equipment for each physical item of equipment. Equipment includes
shuttles, conveyors, TULs, Sample Stations, Balance Machines, etc.
Sub Classes
Each of these equipment types are “sub-classes” of the Equipment Class. Referring to the
Section on Intelligent Agents, there is only a small component of this class that is different for each
sub-class. This is the “Class Logic” section shown in the diagram in that section. The vast majority of
the class is common for all types, eg the various interfaces. Therefore this is an ideal candidate for
exploiting sub-classes.
Equipment Responsibilities
The responsibilities of the Equipment Class include:
• Monitor state of the physical (plant level) that it models
• Monitor state of Executors to:
o Determine which executor has its custody
o Determine status of current activity of its executor
• Monitor status of its neighbouring equipment
• Determine actions required
• Send required actions to the plant level equipment
Equipment Collaborations
The Equipment Class Collaborates with:
• Topology
o By reading the global Topology variable so that it knows who its neighbours are
• Executor
o By reading Executor status so that it knows what is expected
o By publishing its own status so it can make decisions
• Equipment
o By publishing its status so that its neighbours know what is going on
o By reading status of its neighbours so it knows what to do
• Plant
o By monitoring real time plant status
o By issuing commands to the plant level equipment
• Database
o To store QA data (Sample Station sub-class only)

2014
SCS Class: Stock
Stock Role
The role of the Stock class is to model the behavior of stockpiles.
There is one instance of this class for each stockpile.
Stock Responsibilities
The responsibilities of the Stock Class include:
• Store, retrieve and validate stockpile data to database
• Store, retrieve and validate stockpile data to balance machines
• Manage locked status of stockpile
Stock Collaborations
The Stock Class Collaborates with:
• Executor
o By publishing its status so Executor can make decisions
• Database
o To store and retrieve stockpile data

2014
SECTION 3. Software development Methodology

2014
Software Engineering Methodology
This chapter discusses some of the more popular software engineering
methodologies, and describes the Iterative development methodology used to develop
the SCS Application.
Waterfall software development
Traditional software development cycles utilized the “Waterfall” method.
This involves completing each step of the process sequentially. This is illustrated in the diagram.
There are many disadvantages
of this process. These include:
• Any errors in design are not identified until very late in the process, usually only after
testing, or even after the software is put into operation. These errors are then “locked
in” with little or no opportunity for remediation, except piecemeal improvements at the
periphery of the problem, and bug fixes
• Little opportunity for the user to be involved in the process. Involvement is only at the
very beginning during system requirements capture, and at the end during testing
(perhaps) and operations
• An assumption that ball requirements are known and can be annunciated by the end
user and captured by the designers at the beginning of the project
• It is impossible to know the status of any individual component or function of the
application until all the components are finally integrated together. This is usually very
late in the process, and perhaps not even until installation in the production
environment
• Testing is deferred to the very end of the project when there are often project pressures
to move the application into production, which reduces testing time. Final testing is
often completed during production.
Waterfall model

2014
Iterative software development
As its name implies, Iterative software development consists of a number of iterations. This
process is documented extensively in the literature and training courses in software development.
Iterative development is not prescriptive. The approach can be adapted to meet the specific
requirements of the project. The two graphics below are typical of the approach.
In the Iterative Model the deliverable at each iteration is a complete, functioning, tested
application that can be reviewed by the client and users. Each iteration has a clearly defined set of
objectives and clearly defined steps.
The advantages of this approach are:
• Early involvement of users and client to shape the outcome
• Early identification of issues
• Early identification of gaps in specifications and improvement opportunities
• Early integration of all functional components of the system
Each Iteration typically comprises the following steps:
• Definition of objectives for the iteration
• Identification and assessment of risks
• Develop, test and implement the software for the iteration
• Review the results, and plan the next iteration

2014
Comparison of Waterfall and Iterative software development
The following is an extract from IBM web site. IBM have formalized this process into an internal
standard.
Further Reading
Title: Code Complete
Author: Steve McConnell
Publisher: Microsoft Press.
ISBN: 0-7356-1967-0

2014
Iterations in SCS Development
The SCS system development follows the Iterative development methodology. The following
paragraphs describe the development to date and the steps to follow.
SCS Iteration 1.
Objectives
• To analyse the SCS requirements and define the Class Objects of the system
• To build a Proof of Concept (PoC_1) that demonstrates:
o the roles and responsibilities of each class, and
o how these classes would co-exist (collaborate) to form a fully functioning
application
• To prepare a Design Philosophy document (this document) to form the basis of the next
iteration
• PoC_1 and the Design Philosophy document are intended t provide:
o An insight to clients as to what an Object Oriented SCS would look like as this
style of development is relatively new to the Materials Handling industry
o A basis for discussion with potential clients with a view to deployment in their
specific applications
Status
Iteration 1 is complete and is considered successful
SCS Iteration 2.
Objectives
• To convert the PoC into the target environment for the client.
o We will refer to this as PoC_2.
o PoC_1 has been built using Schneider technology (purely as a matter of
convenience)
• To add some high-level client specific capabilities to the model
• To use PoC2 as the basis of discussion with the client to develop detailed functional
requirements for the Release Version
Status
Iteration 2 has not commenced. However some high-level review and assessment of the GE PPS
environment is underway.
It is estimated that the second iteration of PoC will take 6-8 weeks. This would be completed by
the author.
The client would be responsible for the development of the Requirements Specification for the
release version.
SCS Iteration 3. Release Version
Objectives
• To implement and test the Release Version
Status
• It is anticipated that this Iteration would be completed by the client, thus
retaining critical Intellectual Property In House.

2014
SECTION 4. The SCS Simulator

2014
Simulation
This chapter describes the Simulator that will be included with the project.
Simulator Description
As part of the ACS system there is a Simulator application. This application simulates the
behavior of the plant level equipment and stockpiles.
The Simulator is also an Object Oriented System with two Classes, an Equipment Class and a
Stockpile Class. The Equipment Class has subclasses equivalent to the SCS Equipment Object.
The Simulator runs in a PLC, and simulates the behavior of the plant level PLS, such as start, stop,
move to position, ramp up to speed etc. Equipment such as Conveyors etc also simulate Ore
Tracking functions, and in fact uses the same Ore Tracking PPS block as the real plant.
The interface to the simulation is exactly the same as the interface to the actual plant level
conveyors. Therefore, the SCS can be fully tested using the Simulator, and when necessary the SCS
can be disconnected from the Simulator and connected to the real plant with no change.
Benefits
There are two major benefits of the Simulator are Testing and Training.
Testing
Using the simulator, the SCS software can be tested throughout the entire development phase
of the SCS software. This will ensure that any issues will be identified early in an environment that is
as close to real world conditions as possible.
The Simulator has the ability to:
• Accelerate time
• Decelerate time
• Freeze time
This provides extremely powerful capabilities. At the Supervisory level, events occur at a much
lower rate (but remain real-time events). For example, a ship is berthed perhaps daily, while new
pours occur in a timeframe of multiple hours. This compares with say a VSD startup which occurs in
seconds and minutes.
By accelerating time we can “skip through” a pour, then slow down the simulation to identify
and solve any issues as they arise.
In this way we can compress months of testing time into a matter of days.
Training
Using the simulator, operators can be fully trained on the SCS, using real world ship loading
plans and stockpile data. This will provide an environment that EXACTLY emulates the real world
control desk. The operators cannot detect the difference between the Simulation and the real world,
except perhaps the lack of CCTV evidence!

2014
This Operator Training can also serve as “black-box” software testing of the SCS. That is, it can be
conducted with no programmers present. These guys typically “nurse” the software through the
training regime. The result is a much more robust SCS software outcome.

2014
SECTION 5. SCS Application Construction and Deployment

2014
Building the SCS Application
This chapter describes how the SCS Objects (PPS Blocks) are assembled into an SCS
application.
Note that this requires no logical programming, only the creation and configuration
of Class Objects.
This chapter also discusses application testing and hardware architecture.
SCS Structure
There are two sections in an SCS Application. This is illustrated in the screenshot below. The two
components are:
• Initialisation
In this section the Constructor functions for the Topology variable are called.
• SCS Objects
In this section the instances of the SCS Object Classes (PPS Blocks) are created.
Note that in the example there is a third section for the Simulator objects. In the PoC these are
in the same PLC purely for convenience. They could be in a separate PLC. In a real deployment of SCS
there would be no Simulation and the SCS would communicate with plant level PLCs.

2014
Building the Topology Variable
While Topology is a complex variable, it is simple to create thanks to the two “Constructor
Functions” in SCS. These functions help to populate the Topology variable during initialization. That
is, we let the PLC do the hard work.
As can be seen below, building the plant topology variable is very simple and can be
programmed directly from the routes matrix.
The two constructor functions are:
• Is_In_Route
o This function builds the Routes Array (shown above)
• Topology_Def_CNX
o This function builds the Upstream and Downstream arrays for each equipment
Constructor Function Definitions
Calling the constructor functions at Initialisation
Initialising Routes
The Routes variable is populated by using the “Is_In_Route“ function. The function call is
illustrated below. The first function call (first line) says that TU601 is in Route 1. The Topology
variable is passed to the function so that it can be populated and the Equipment variable is
passed so that the function can identify the equipment Id and name.
Initialising Connections
The Connection variables are populated by using the “Topology_Def_CNX“ function. The
function call is illustrated below. The first function call (first line) says that CV903 is downstream
from CV906. The second function call (second line) says that CV908 is downstream from CV906.
The Topology variable is passed to the function so that it can be populated and the two
Connection Arrays.

2014
Creating the Object Class Instances
The second step in creating an SCS application is creating the object instances. Here we consider
how to create objects for Conveyors. Other classes and objects use exactly the same process.
First step is to assign each object (conveyor) a unique Id (1…n). In the PoC example Conveyors
are numbered 1...26. Then, for each conveyor in the network, create a class instance, assign its
unique Id, and “connect” the other variables to the pins of the object. This can be seen in the screen
shot.
The inputs to the object are:
• Unique Id so it knows who it is
• Constants purely for programming tidiness
• Topology so it knows where it is in the network
• Executor Data so it can see who is its custodian
• Equipment so it can see status of its neighbours
• Plan_Data so it can see status of pours
• Sim_Interface to control the simulator. In real world this would be plant interface
That’s it.
Application complete.
No further programming required.
Assign Id
&
Topology
Object knows:
• Who it is
• Where it is in current route
• Who it belongs to (custodian)
• etc

2014
Software Testing
Once the SCS application (PPS blocks) is built there is no need for functional testing. The only
testing required is:
• Model testing
This testing is to ensure that the Topology variable is correctly constructed.
The SCADA application component of SCS provides visual tools to assist this testing.
This testing would require less than half a day
This testing is an off-line test and does not represent any risk to production
• Database interface testing
This testing is to prove the interface between SCS and the plant database.
An image of the real data is used to replicate live conditions
This testing is an off-line test and does not represent any risk to production
• Interface testing
This testing is to prove that the interfaces to the plant level PLC is operating correctly.
It is estimated that interface testing of each piece of equipment would require maximum
1 hour. The equipment would need to be out of service.
There would be no downtime implications from testing in this way
Operator Training
The Simulator would be used to train operators in the use of the new SCS application. This is
described elsewhere.
The operator training process would provide an additional level of software testing not available
with conventional bespoke software systems.

2014
Hardware Architecture
This chapter describes the recommended hardware architecture for the SCS.
The ACS Application is a PPS Application comprising both the PLC application and the Cimplicity
server components.
The architecture would be as illustrated below.
The key aspects of the system architecture are:
• SCS delivered as a single supervisory application
• High availability (redundant) CPUs are used to ensure availability, reliability and integrity
High
Availability
CPUS
GE IC695CRU320
HA CPU
Plant
Control
System
Supervi
sory
Control
System
SCADA
Server

Supervisory Control using Intelligent Agents

More Related Content

What's hot

Viewers also liked

Similar to Supervisory Control using Intelligent Agents

Supervisory Control using Intelligent Agents