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 1 provides 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 2 describes 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 3 describes the iterative software development methodology used in developing

the SCS class objects, and compares it with the conventional waterfall method.

Section4 describes the Simulator that supports the SCS application, for both testing and

operator training.

Section5 provides 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 Stock Plans

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

Documents

intelligent agents

software design

document outline

confidential information

command control

intelligent class objects

intelligent agent structure

contents contents