Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 A Distributed Configuration Tool for Distributed Control Systems Shelley POWERS Burning Bird Enterprises Michael HITZ IF.

Similar presentations

Presentation on theme: "1 A Distributed Configuration Tool for Distributed Control Systems Shelley POWERS Burning Bird Enterprises Michael HITZ IF."— Presentation transcript:

1 1 A Distributed Configuration Tool for Distributed Control Systems Shelley POWERS Burning Bird Enterprises Michael HITZ IF

2 2 Introduction P2P 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 projects cost, which often averages ±30%

3 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 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 arent accurate Its a black art Everything is always out of date Globalization, consolidation & competition Relationships over knowledge

5 5 Different roles Different 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 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 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 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 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 10 Power users And the sales process Receive tender specification Declare system, geographical and telemetry constraints Calculate gate (P0) estimate for corporate approval Deploy international Tiger Team & assignments Work to define constraints, collaboratively Generate initial (P1) estimate for sales & engineering Write and collate tender documentation Complete system definition & calculate price Submit tender after gaining approvals

11 11 Not-so power users Or, 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 12 Missing in action Sales 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 13 Still missing in action Sales force management and business statistics While the sales force is geographically distributed, management often isnt and require: Rolled up visibility into all projects Current demand activity Approval request notification Control over discounting and price-list releases

14 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 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 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 dont have to distribute the services, dont have to collaborate

17 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 18 Constraint-Based XML Its 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 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 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 21 Services Lightweight, discrete Location independent Accessed through XML-based protocol Requests and data processed as XML Dynamic/Configurable and Constraint- Driven

22 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 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 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 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 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 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 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 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 30 Demonstration

Download ppt "1 A Distributed Configuration Tool for Distributed Control Systems Shelley POWERS Burning Bird Enterprises Michael HITZ IF."

Similar presentations

Ads by Google