1

A Distributed Configuration Tool

for Distributed Control Systems

Shelley POWERSBurning Bird Enterprises

Michael HITZIF

2

IntroductionP2P and Design, Collaborate, Plan

The supervisory control and data acquisition markets, along with other real-time control system markets, have been building distributed systems, over all sorts of networks, for decades

Only now, however, is software becoming available that will allow the people that engineer these complex systems to collaborate on their design and costing, before the project is sold

The key aim of this work is to reduce the error margins involved in estimating a project’s cost, which often averages ±30%

3

Business context In the DCS, SCADA and control system markets alone hundreds

of millions of dollars are spent each year tendering infrastructure projects for utilities.

Companies such as GE, Siemens, ABB, Valmet, Invensys, Fisher-Rosemount, Toshiba have international sales, manufacturing, engineering and software organizations

Projects such as energy management systems, light and heavy rail supervisory systems, electricity distribution management systems, and trans-European networks involve huge engineering efforts that are often poorly costed

Millions of dollars are lost as a result of (cost) poor coordination Merit-based competitiveness is eroded Globalization increases enterprise-wide dysfunction Sales efforts end up at the apex of pressure Increasingly accurate project estimates are required

4

The usual suspects (Or, why pricing complex systems is tricky)

Configuration constraints not often known Channel acquisition rates demand consistency,

process & timeliness Collaboration of a feather but rarely throughout

the enterprise Different people see different things Demand forecasts aren’t accurate It’s a black art Everything is always out of date Globalization, consolidation & competition Relationships over knowledge

5

Different rolesDifferent places

In one week, how do you price a distributed control system with:

Manufacturing in China Operations & Engineering in Sydney Hardware design in Brisbane Software integration in Boston Sales in Houston Marketing in Düsseldorf Finance in London?

6

P2P? Emerging P2P architectures support:

Distributed data, schemas & ownership Concurrency and conflict resolution Many users in many locations Workflow, roles, views Interfaces to ERP, MRP, and MIS (And of course, MP3 file sharing)

7

If only 1000 page specifications divided Clause by clause and product X-ref Centralized response and approval Latest pricing across system components Probabilistic manufacturing forecasts Accurate sales intelligence A global work-force could be utilized Product, constraint & business intelligence

could be “centrally disseminated”

8

Value proposition: case study

Average project cost around US$7m Up to 50 tenders a year with 10-30% success Overrun average within -10% to +30% For a mid-sized control systems company:

Reducing overrun risk to ±10% yields US$5-10m P2P collaboration allows for channel acceleration P2P configuration lowers training requirement P2P estimation lightens support burden P2P management amplifies operating visibility

9

+ve Side-effects Timeliness of data and interaction Collaborative yet constraint-driven P2P framework for on-the-fly

application development Abstract but clever: localizes

algorithms specific to an application Less interaction & time-zone friction Automated view into business

processes

10

Power usersAnd the sales process

Receive tender specificationDeclare system, geographical and telemetry

constraintsCalculate gate (P0) estimate for corporate approvalDeploy international Tiger Team & assignmentsWork to define constraints, collaborativelyGenerate initial (P1) estimate for sales &

engineeringWrite and collate tender documentationComplete system definition & calculate priceSubmit tender after gaining approvals

11

Not-so power usersOr, visibility and corporate intelligence

Concurrent projects may be rolled into the board-room via: User interface ERP (SAP, PeopleSoft, Oracle &c) MIS

Sales force activity summaries Increased timeliness of regional performance reports Demand and forecasting outputs to:

Manufacturing Sales System engineering and software development Human resource planning

12

Missing in actionSales team collaboration

Team members each enter data from the specification to a collaborative project-space

Discounts and constraints may be applied Slowly the system is defined based

NOT on knowledge of the product But on data found in the specification

Outputs during this process are iterative: Cost snap-shots (reconciled with historical data) Manufacturing demand Production scheduling & completion dates

13

Still missing in actionSales force management and business

statistics

While the sales force is geographically distributed, management often isn’t and require: Rolled up visibility into all projects Current demand activity Approval request notification Control over discounting and price-list

releases

14

Business Summary Distributed engineering processes require a

truly distributed solution Yet a single view of data is required for each

user Collaborative design & planning tools have

not yet been applied to the pre-project control systems configuration, nor automated

P2P frameworks provide a collaborative solution based around authority and authentication

15

Introducing the Technology Components

XML-based service and data requests Dynamic Constraint-driven and XML-

based services Collaboration support

Workflow Concurrent

Secure and reliable Transaction and encryption support

16

The Configurator A Hybrid P2P Application

Application functionality can be accessed remotely from peers or services

Application functionality can be installed locally

P2P because services can be distributed and use is collaborative – hybrid because clients don’t have to distribute the services, don’t have to collaborate

17

P2P! Team members can work on specific

individual tasks within the same project User interface dynamically changes

based on project status user role locale

On-demand updates of data keep members in synch

18

Constraint-Based XML It’s Constraint-Based

Tool constraints are defined within specialized XML vocabulary

On-the-fly updates Can override existing data with new New data is added to existing set of

constraints as New constraint Filtered constraint

19

User Interface Configurator components

lightweight, easy to install Client can access services through…

Web Trio Interface Through own client or server-side

applications Through other products such as Groove

20

Architecture The control system configuration tool

can exsist on a generic infrastructure So we have a framework that supports

the distribution of application services via: Lightweight Service Wrappers Service Dispensers

Data and Process Service Dispenser Locators

21

Services Lightweight, discrete Location independent Accessed through XML-based

protocol Requests and data processed as

XML Dynamic/Configurable and

Constraint-Driven

22

Accessing Services Services Location

Can exist on the client Services can exist on a central server Services can exist on a “peer”

Found through Locators Small lightweight framework services

that locate a requested service Locally or Globally

23

Locators Small lightweight service located on each client –

XML store Looks up service locally, caches in memory if

found If not local, looks up service through global locator

Global Locator stored in LDAP Accessed using DSML Cached

Once specific service located, all service requests are streamed to the specific service dispenser

Locations updated when client logs into system

24

Service Request Stream Service Requests are based in XML Based on SOAP, XML-RPC, BXXP

Supports common interface for all requests

Service fulfilling request pulls data from XML stream

Service returns results as XML Add new services without impact

to client

25

Trio External Wrappers Lightweight framework services

that provide connectivity into Trio Services EJB Wrapper COM/COM+ Wrapper CORBA Wrapper Groove Wrapper

Clients access the wrappers, which access the Trio Services

26

Constraints Control system entities inherit a context Tree based declarations (via XML) of

Entities Constraints Relationships

XML-encoded grammar defines constraints and descriptions of the system

Depending on the role, the leaf is Price Part number &c

27

Configurator Interface Custom Interface

Based on Mozilla XPFE Architecture User Interface elements defined in XML

XUL – eXtensible User-Interface Language Platform independent Task specific data updates

Groove-based Interface For stroke-by-stroke synchronization of data

28

Data Services Data is also a service

Service Dispenser access Locator for Data Store

As with services, location is found, cached

Requests/responses handles as XML Data service translates from native

data format to XML

29

Critical Elements of Architecture Transaction management

Transaction completely successful, or completely rolled back

Security All communication encrypted

Efficiency Locations cached for quick access Efficient LDAP Store design

30

Demonstration