Post on 27-Mar-2015
transcript
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