A Distributed Configuration Tool for Distributed Control Systems

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

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 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. 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