Economics of Open Systems and the Markov Switching Model

1. Economics of Open Systems and theMarkov Switching Model

2. VSEnergy ww.VSENERGY.us • Founded 2004 – • Energy Engineering • Owners, ESCOs, • Integration Engineering • Measurement and Verification • Expert Witness and Testimony • Mark Sankey • Undergrad in Eng. • MBA Finance • 28 yrs of controls, energy engineering & conservation projects • 12 yrs with a Major Controls Company • 10 yrs as Owner of an Independent Control System Dealer • 7 yrs Consulting for Bldg Owner

3. Welcome!

4. Building Automation • What do we mean by Building Automation? • Computer based Energy, Environmental and sometimes fire, security (lifesafety) control system • EMS – Energy Management System • BAS – Building Automation System • BMCS – Building Monitoring and Control System • And a few other less often used acronyms

5. The History of Building Automation • 1970s and 80s - Large investment in R&D by the major control companies, funded by the profitability of pneumatics • Began with central monitoring via multiplexing or distributed control • Johnson system 6000, JC/80, JC/85 series • Honeywell Delta Series • Powers System 600 • Resulted in proprietary systems • Extensive development cost required long product life cycles to recover • No standards for communications, so proprietary communication protocols were used.

6. Customer Satisfaction with proprietary systems • After the “joy of automation” wears off, the disenchantment of being tied to the same vendor / system provider for eternity sets in • Costs escalate – there is no substitute – when you can only buy – service, maintenance, upgrades, and repairs from one source the price goes up. • Satisfaction decreases as performance declines • Cost to switch are onerous – tear out and replace

7. The Problems with Proprietary • Initial Cost – moderate or even low • Maintenance Cost High • Upgrades – as technology changes are expensive from a single source • Switching cost – Astronomical • An “integrated system typically required a full replacement when expanding. • If not, an “integration” isn’t

8. Big Company Proprietary Gadgets

9. Economic and Performance pressure leads to standardization • Large companies and institutions (users) began with a grass roots effort to allow connection, and data sharing • In 1980, a Cornell University team led by Mike Newman began developing a program to allow systems from major manufacturers to communicate with each other

10. Cornell and BACnet • This system evolved over a ten year period into the ASHRAE BACnet standard for Building Automation and Control systems communication. • It was the first and remains the only non proprietary, fully open communications protocol with compliance by at least eight major manufacturers. • BACnet has evolved into an ANSII standard and is currently in use internationally • BACnet Testing Laboratory (BTL) is the testing entity which assures compliance with the BACnet standard

11. LONworks • In 1990 Motorola began an effort to develop a network device standard communication protocol including embedded chip communications technology, and standard development tools for network engineers and developers. • This standard has developed into LONworks

12. Microsoft and WebControl • The largest software company in the world has developed tools and standards to integrate numerous communication protocols. • OLE – Object Linking and Embedding • OPC – OLE for Process Control • SOAP – Simple Object Access Protocol

13. Current Technology – Open Systems are Standardized • Two real standards for Building Automation • BACnet • Used in medium sized buildings to campus application • Standard exists for all components from controller device to network communications • LONworks • Used in very small to medium sized buildings very successfully • Scaling to larger systems requires significant engineering and configuration effort

14. Small Scale Integrations • WebControl • SOAP • XML / HTML • OPC / ODBC

15. Open Systems – Supplier Sides • Secondary companies embraced the integration and open system technology first • First tier companies resisted • Why? • To protect market share – they had the most to lose.

16. Open Systems – Supplier Sides • Secondary companies embraced the integration and open system technology first • BACnet • Automated Logic • Andover (Continuum Line) / TAC • Alerton (BacTalk Line) • KMC – (Kreuter) • Delta • LONworks • Niagara Framework • CSI • Computrol

17. Open Systems – Supplier Sides • First Tier Companies followed suit • BACnet • Johnson Controls – only via NAE • Honeywell – only via Enterprise Building Integrator • and via Alerton purchase • Siemens – only at the Apogee workstation level, and some controllers • LONworks • Honeywell via Niagara Framework acquisition • Siebe, CSI and Invensys under the TAC umbrella • Johnson Controls

18. TRADITIONALLY • On a new installation prices are very competitive as companies aggressively seek to “set the hook.” • Automation companies selling proprietary technology can afford to install new systems at zero profit due to the lack of competition on future expansion, service and parts.

19. Enter Open Systems • Open Systems • Utilize publically available documented and tested communication protocols, media, transmission and carriers. • Are accepted either as a defacto (Microsoft) standard or as a nationally or internationally recognized engineering standard. (ASHRAE, ANSII, IEEE)

20. In the Early Years! • Many manufacturers claimed to be “open” • That meant they built proprietary drivers, gateways and translators to other large manufacturers proprietary equipment • That worked to varying degrees, sometimes, but usually rarely or never!

21. Mostly, early integrations were sold like this!

24. Open Systems allow: • Communication between (information sharing) • Interoperability means the ability for multiple controllers from different manufacturers to pass information between each other. • Monitoring of critical environmental and energy parameters, trending and data storage of information from multiple systems. • INTEROPERABILITY without the use of proprietary Gateways, Convertors, programs or other hardware.

25. Traditional Proprietary EMS

26. Proprietary Integration • Examples: • Siemens Apogee • Modbus • BACnet • Johnson via N2 • Honeywell • Via Enterprise Building Integrator (EBI) • BACnet • Legacy Honeywell • Lon • Johnson • Via NAE • Siemens • BACnet

27. Proprietary Integration The integration remains proprietary

28. Open Standard Integration • Multiple Vendors interoperating • Common Communication Protocol • Multiple Choices when adding, upgrading or replacing

29. Why Open Systems • Economics: • First cost is lower – more equal competition provides higher levels of competition and equal performance • Maintenance cost is lower – multiple service providers can work on the system, provide parts, etc. • Expansion costs are lower, numerous compatible vendors can provide competitive pricing on expansions and additions.

30. Why Open Systems • Economics: • When there is limited competition (1-2 vendors) prices go up • When there is high quality competition (5-6 vendors) price / value is optimal • Over 6 competitors, winners curse take effect – whoever makes the biggest mistake estimating gets the job. • Cost to switch from one vendor to another is minimal

31. Why Open Systems • Higher Vendor Performance is product of competitive pressure • If the cost of switching is minimal, when there is lower performance the owner has the opportunity to switch without negative financial impact

32. Why Open Systems • As an Integration Platform • Allows you to leverage your existing investment • Extend the life and enhance the performance of existing systems • Integrate campuses and buildings to operate more cost effectively • Information systems are consistent and integrated

33. Why Open Systems • New Construction • Specification and evaluation become more consistent • No more proprietary system with an added “or equal” clause. Because “or equal” never really is.

34. Markov Model • Describes the probability of switching from and between multiple discrete states • Is used to predict brand switching, military strategies, medical conditions, and many other discrete dependent switching conditions.

35. Definitions • Q (probability of switching) is a vector of three parameters • Πj for j= 1 to (n-1) where n is the probability of choosing state j as the initial state • αj,k for j=1…(n-1), k=1…n is the probability of switching from state j to state k, or one control system provider to another. • Bj(0) for =1…(n-1) and 0, is the probability of emitting symbol 0 from state j, or the probability of ending at one specific supplier from a given starting supplier.

36. Switching Costs and theMarkov Model Typical Markov Switching Table

37. Cost to switch drove the model Prior to standard communication: • Cost to switch was enormous • Integration was technically complex • Whole system replacement was nearly the only option

38. Historic Markov Model Switching from anything other than the incumbent provider was a very low probability due to the high COST of switching.

39. Supplier Pricing Structures • Penetration pricing – first system installed dictated future expansions • Monopolistic or oligopolistic going forward • Monopolistic – one system • Oligopolistic very limited number of systems on a campus (limited competition) • First cost does not reflect the true “long term cost” or cot of ownership of a proprietary system.

40. Open Systems and the Markov Model Cost to switch between vendors is removed

41. The Markov model • This illustration is only for the purpose of explanation and prediction of customer propensity to switch and the constraints under which switching may occur • It is NOT necessary to construct a Markov Matrix for any specific project

42. Open Systems and Competitive Pricing • First consequence of open systems is competitive pricing for the initial project • Open systems means multiple service vendors (competition) • Interoperability means competitive pricing on future projects • Quality of specifications has a greater impact on pricing

43. Vendor performance Open Systems • Vendor performance is the only reliable indicator of a customer’s propensity to switch from an existing control system provider • Quality of engineering sets the foundation for true interoperability and open system platform

44. Proceeding to Open Systems • There is a limited skill set in the traditional Architectural and Engineering community with the specific knowledge of system integration, legacy systems and the technology challenges of each, specific integration and open system architecture required. • A more cost effective approach is to proceed with careful evaluation of site specific legacy systems, and preparation of a well conceived integration specification congruent with the facility long term plan based on a technically suitable open system platform.

45. Integration and open systems projects • Process • Develop OPR –Owners Project Requirement document • Engineer / Consultant develops design, with BOD document attached • Commissioning plan is attached • Competitive Bid Process • Installation is supervised with system commissioning as systems (HVAC / lighting / fire & security) are completed

46. Owner Project Requirements • Preparation and thoughtfulness in the development of the OPR will pay big dividends! • Selection of a good integration engineering firm will be a critical decision • Track record • Understanding of available technology • Empathy with the customer • Results oriented

47. Design • Consultant develops design • Critical element in the process • Designing firm should fully document existing systems (software and hardware, generation, etc.) along with the specifics of what will be reused, integrated or replaced • Document existing networks, media, router locations • II security requirements If you leave all this up to the vendors – prices will vary widely and so will the scopes of work!

48. Need for Commissioning • In an integration project a qualified commissioning agent is necessary for an open protocol or integration project. • Cx needs to have hardware and software tools to identify problems with installation, performance, etc.

49. Design (contd.) • Design documents should incorporate: • Statement of intent • Complete documentation of systems to be reused or integrated • Prescriptive performance requirements • Products • Network • Control software • GUI • Documentation • Training • Warranty and maintenance • Commissioning plan and vendor responsibilities under the plan

50. Basis of Design (BOD) • BOD (Basis of Design) is the document which speaks to the veracity of the design • Details the assumptions of the design • Details the design criteria and objectives • Ties together the OPR and the commissioning plan