December 2005
  
AutomatedBuildings.com

Babel Buster Network Gateways: Big Features. Small Price.
Control Solutions, Inc. - Minnesota

(Click Message to Learn More)


Open Platform Technology

 

The Application of Lean Design Open Platform Technology to Facilitate Integrated Building Projects

Mark Hunter, MD
Integration Systems Limited (ISL)

Hong Kong

Introduction
In the summer of 2005, a wildcat strike by a number of disgruntled Heathrow airport catering company employees, supplying British Airways with on-flight hot meals, effectively shut down Terminal 4 and most of British Airways operations for nearly a week. The knock on effects reverberated around the world and led to huge, almost incalculable costs.

There are two important points to this dramatic event;

  1. The catering company was a single source supplier to British Airways.

  2. The interlinked nature of the various operations and entities involved led to a near systemic break down in the international air transport system of the world's busiest international airport.

Articles
Interviews
Releases
New Products
Reviews
Forums
Sponsors
Archives
Past Issues
AutomatedBuildings.com

Control Solutions, Inc

What has this got to do with building integration? There are numerous building projects that are so large that their footprint effects more than just their locale; some buildings are as large in capacity and scope as small towns. Having a single source supplier for the building control systems carries great dependency risk for the building's owners and the building users.

The drive for ever greater efficiency dictates the need for Intelligent or Integrated Buildings, however, there are a number of factors that offer resistance to this integration. A single source approach is seen as a way to overcome some of these resistive factors. And therein lies the dilemma.

This paper will propose that the application of Systems Engineering, its associated discipline of Lean Design and an open platform technology approach provides a solution to the dilemma. But first, let us examine Building Integration; what it is and what is stopping it being fully applied.

Building Integration – Why isn't IT working?
Commercial market forces determine that building developers and owners deliver comfortable, safe, efficient and cost effective environments for their building users.

The promise of integrated buildings, wherein the building's disparate control sub-systems, eg, HVAC, Security, Life Safety and Lighting, act in a cohesive and pre-determined, rational manner to provide a comfortable, safe, effective and efficient facility has been around for years if not decades.

However, it is fair to say that there are many new and existing buildings today that have minimal integration, with disparate non-communicative and non-cooperative control sub-systems. Why is this so? Why, if the beneficial promise of integration is recognised, do building owners not embrace the integrated building credo completely?

Unfortunately the reality of full building integration often falls far short of the promise and it is not uncommon for so called integrated buildings to end up with unwieldy, uncommunicative and complex dysfunctional systems and sub-systems that are expensive to install and to run. Again, why is this? What happened to initiatives such as BACnet and the interoperability of LonMark that were supposed to solve these problems? And what of the great new hope of Internet Technologies, such
as TCP/IP, HTML, XML, HTTP, Java etc?

In truth these technologies have great potential and have gone a long way in providing various levels or islands of integration but they have failed to totally deliver universal, new and legacy, Integrated Buildings and their full potential benefits. What is the reason for this?

The reason is simple; the risk of commercial failure or loss.

A building owner has to make a rational commercial decision on whether the benefits of full integration outweighs the associated commercial risks.

What are these risks associated with integration? There are two main risks that could be associated with going down the full integration path; Cost Risk and Technical Risk

Cost Risk.
It is accepted wisdom that the more complicated and complex a system is, the more costly it will be
to purchase, install, operate and maintain.

Technical Risk.
And once installed, a complex integrated system is perceived to be more prone to technical failure resulting in a total building control systemic break down rather than to an isolated sub-system. Indirectly, of course, this is also a cost risk since any failure in the system will inevitably have commercial consequences eventually.

So, let us examine some aspects of these risks mentioned above.

Supplying an Integrated Building.
There are generally two supply approaches for control systems on an integrated building project;

  1. the single source large integrated building controls supplier or

  2. an ad hoc multi sub-system supplier approach with some sort of integration layer specialist.

Both of these approaches have their respective advantages and disadvantages.

As previously, one of the main risks of the ad hoc multiple supplier approach is failure to achieve the benefits of integration due poor technical coordination and application.

The main problem with the single source supplier approach is that of dependency and the risk of price gouging at some point in the relationship.

In the building project world, it is not unusual to find large, single source building control system suppliers bidding for projects close to or at cost. It is intuitive, therefore, that to be commercially viable the suppliers must achieve adequate profitability by some other means. This is usually achieved by two methods;

  1. By aggressive billing on the inevitable contractual changes inherent to all conventional building
    projects.

  2. High margin support and maintenance contracts after the warranty period has expired on the
    installed systems.

The building owner naturally makes a judgment call on the initial cost of acquisition of the integrated system and can be overly swayed by a low bid. However, the inexperienced building owner ignores the above two points at his peril. Experienced building owners and developers are naturally once bitten twice shy and tend to seek ways and means to mitigate against this, usually by having reduced integration or by establishing rigorous contractual terms and specifications for the integrated building project.

The Technical Angle
As previously touched upon, a lot of effort and influence has been brought to bear by the building owners to reduce the ransom effect of proprietary systems and garner more choice of sub-system suppliers, BACnet being one such successful effort.

So, problem solved right? All building owners today have a free market choice to develop fully formed, integrated buildings from various system suppliers thereby delivering cost effectively, the promised benefits.

Not quite. If anything, the recent advent of universal openness has led to a situation where the building owner has even less choice since the systems suppliers have effectively aggregated all the building control sub-systems in to a single packaged offering. The choice then becomes one of choosing from a limited number of large single source, integration system suppliers.

Choice.
There really is no choice, building owners must have a large, single source system supplier for large building projects. It is as simple as that. Or is it? Is there no alternative or choice that will release true market forces to deliver a cost effective integrated building?

The contention of this paper is that the problem is not a technology issue since there are numerous successfully applied, integrated buildings but a problem of the building process itself that requires a radically different approach.

The Building Process
Let us start by examining the existing conventional serial process stages to build a building, so to speak. The following is a fairly typical building process in principle, consisting of two main phases; The Concept and Design Phase and The Build Phase.

Phase A – The Concept and Design Phase
A potential building owner devises a building project concept and arranges finance for the project based upon a business plan, (assume its finite and not government), and employs a design team to develop the building concept consisting mainly of;

a. Architects – form, layout, aesthetics etc,
b. Consultants – physical design, structural, etc.
c. Management – project, business, legal, etc

The design concept and specifications are developed to enable practical initiation of the project process. It is normally the case that the design will not be fully formed but be of adequate, generalised detail for tendering purposes. The winning bids from the nominated Main Contractors are examined and accepted to the initial conceptual specification and various criteria such as technical, financial and resource competence and cost.

Phase B – The Build Phase

Stage 1. Main Contract - The Main Contractor is appointed and made responsible for the complete building process as overseen by the design team. The Main Contractor announces invitation for M&E major sub-contracts and appoints winning bid based on costs, and technical competence to meet the generalised specification and scope of works.

Stage 2. M&E (mechanical & electrical) Contracts -The main M&E contractor(s) announces competitive tenders for the integrated building control sub-systems contracts eg Fire, Security, Lifts, HVAC etc. and selects winning bid(s) on the basis of cost and meeting a technical specification. At this point the M&E contractor has basically three choices;

a. Do they invite and award contracts to each of the individual sub-system suppliers and then integrate the various systems themselves in-house.
b. Appoint an integration specialist to handle this in cooperation with the sub-system suppliers and under their direction and control, or
c. Appoint a large integrated building controls system supplier than can supply the bulk of the subsystems as a complete package and also handle the integration of those outside its direct supply.

Stage 3. Sub-Systems Contracts - The appointed sub-system supplier(s) start design work to the generalised specification on their respective sub-systems and follow through to completion and handover, including the demonstration of integration aspects required by the original specification. There are a number of very important consequences that become apparent from this process;

The inevitable result of this common scenario is increased cost and time overruns. The following diagram summarises and illustrates this;

Fig. 1 The Notional Overrun Effect of Design Change Events on a Back Loaded Integrated Building Project.

Fig. 1 The Notional Overrun Effect of Design Change Events on a Back Loaded Integrated Building Project.

Going Big – Growing Pains
It would seem intuitive, therefore, that by having a single source supplier the management and hence execution of the project can be made more effective and efficient. However, is it assumed that building owners will appreciate less choice rather than more and the contention of the single source suppliers that by offering everything the building owners will accept being ring fenced?

As pointed out, choosing the large single source supplier route has its advantages and that some of the potential risk can be mitigated against by the use of stringent specifications, extended warranties and support contracts. Needless to say it is not uncommon to find that contractual safe guards are not enough, resulting in expensive legal action.

However, what if there was an alternative, a more independent choice that can unleash true competitive market forces?

Control Solutions, Inc Building Control Systems are a Commodity
This paper would argue that due to openness brought about mainly by Internet Technologies and BACnet, building control systems and sub-systems and their components are becoming more like commodities. It is therefore, reasonable to propose that the disparate control sub-systems can be incorporated and integrated to form a very cost effective integrated system.

Take for instance traditional CCTV systems: a CCTV sub-system would have been considered a specialised sub-system available from only a few specialist suppliers. Now, however, with the advent of IP technology and IP cameras, the number of potential suppliers is rapidly expanding and is already exhibiting the characteristics of a commodity product.

The industrial SCADA industry provides another interesting example wherein the standardisation of communication protocols such as Modbus, the main i/o component device - the PLC - and its universal and IEC61131 standard programmable language has been around for years. It is a common situation to have complete factory complexes with a mix and match plethora of PLC control systems from different manufacturers providing perfectly competent and efficient integrated systems.

The contention is that the new Internet Technologies also facilitates just such a model, and offers an alternative to the large single source supplier.

Applying a Systems Engineering Lean Design approach to the integrated building process
Because Internet Technology is truly open, huge swathes of previously closed and proprietary fields of building integration have been set free as follows,

  1. Communications backbone and infrastructure – Ethernet, ..

  2. GUI Supervisor – standard web browsers, Java Applets, ..

  3. Protocols – IP, http, html, XML, ..

  4. Database – SQL, ODBC, ..

  5. Hardware OpSys – Linux,

  6. Severs – Apache, ..

and because of this openness it is now feasible to accurately model many more aspects of an integrated building upfront during the design phase of the building process in the knowledge that all of the control sub-systems can be fully integrated. This ability to front load the design is a major characteristic of Lean Design.

Systems Engineering (SE) and Lean Design
Systems Engineering [1] is an all-encompassing or holistic life cycle appoach to delivering a product or project – from concept through to decommissioning. It seeks to view all the aspects of the project and its domain, as a complete system and not a separate set of functions, operations and entities, such as design, stakeholders, users, environment etc. SE is a large discipline and for the purposes of the subject matter we will concentrate only on those aspects relevant to this paper; specifically Lean Design and its related approaches of concurrent engineering, IPPD (Integrated Product and Process Development) etc.

However, it should also be noted that the Systems Engineering approach is becoming more and more relevant, if not a necessity to building projects, especially due to the environmental footprint of buildings and their effect on local communities.

The Lean Design approach (originally developed at the Toyota Motor Corporation) is an integrated team approach that allocates maximum design resources at the start of the product/project development cycle. It seeks to iron out any potential bottle necks, design flaws and errors, and to standardize design and processes, thereby reducing costly and time consuming modifications and errors further down the line. The effects are dramatic, with reduced lead times, costs and big improvements in quality. The following diagram illustrates this.

Fig. 2 Traditional Serial Approach Versus IPPD (Integrated Product and Process Development)

Fig. 2 Traditional Serial Approach Versus IPPD (Integrated Product and Process Development) [OU-UK, T837 SE]
Managing_System_Engineering_IPPD.pdf p21 Original Source: DoD (1996). Downloaded from
http://www.acq.osd.mil/ [accessed June 2003]

The question now becomes one of how to apply Lean Design to the Integrated Building project. The key is to complete as much of the substantial integration work upfront at the design phase, ie to separate the integration work from the build phase.

However, how can you integrate sub-systems that are not even purchased never mind installed? Is it possible to design and test upfront the automatic operational reaction of an integrated system, for instance, that when a fire alarm event occurs it should;

Due to the openness of Internet Technologies, it is now possible that this particular scenario can be designed, modeled, engineered and tested upfront in the knowledge that, for instance the graphical schematics can and will be viewable and accessible via any standard web browser and that the communication backbone for the fire alarm event to pass along will be standard Ethernet using TCP/IP and that the messaging will be via email or SMS.

So the question then becomes one of how to do in practice what in theory is feasible. The answer lies in providing a standard open technology platform to design, engineer and test the upfront integration work.

The Lean Design Open Platform Technology
The open platform should have three main components or systems;

  1. A universally available software design and authoring tool or application to produce the web based supervisor schematics with open scripting language capabilities such as Java. An analogous example would be AutoCad used within the building architectural and structural design process.

  2. A software database application to specify and setup all the various sub-system i/o points and communications, including a comprehensive set of sub-system drivers, that can then be tested in simulation of real events. The setup would be via a standard web browser and include logging, trending, alarms, interoperability, integration and communications.

  3. An open technology gateway hardware device, probably Linux based, to contain the database application and to act as a communication hub for the sub-systems complete with a web server and open Internet technologies such as WAN and LAN capabilities plus standard sub-systems drivers and communication ports, eg, RS232/RS485, USB and etc.

Parts 2 and 3 would be combined to form a single combined hardware/software component.

With this platform in place the following major integration works could all be engineered, tested and completed upfront during the design phase and prior to the build stage;

This large body of engineering works is now taken out of the contract build phase thereby drastically reducing the risk of overruns and attendant cost escalation. More importantly it reduces the dependency of the single source supplier lack of choice dilemma.

The following diagram illustrates this open platform technology architecture ....

Fig. 3 The Lean Design Open Platform Technology Architecture.

Fig. 3 The Lean Design Open Platform Technology Architecture.

Reliable Controls With this software/hardware platform duality now in place, the project design team can simply get on with the job of designing, and more importantly, engineering and testing the completed integrated building system without the need for the control sub-systems to be physically present.

During the build phase of the project it is simply then a matter of mapping and connecting the subsystem equipment and its data, such as, i/o points and alarm events etc., to the upfront engineered integrated platform.

The benefits that flow from this are substantial and commercially valuable as per but not limited to the following list;

The following diagram illustrates the notional effect of this ...

Fig. 3 The Lean Design Open Platform Technology Architecture.

Fig. 4 The Notional Overrun Effect of Design Change Events on a Front Loaded Integrated Building Project.

The OEM Solution. (Original Equipment Manufacturer)
The question now becomes one of availability of this open platform technology. Who are the suppliers? Such technology will obviously require sophisticated design, engineering and support and will therefore have some aspect of proprietary supply.

So we are back to square one? Not quite. Potential suppliers of these open platforms realise that the building owners also have the choice of going the single source large supplier route. The solution for the open platform suppliers is to continue the principle of openness and provide the building owners and there agents with an open solution: OEM Supply.

OEM supply would consist of transferring the platform technology to the building owner or developer under a commercial contractual agreement and include features such as the source software being made available via an escrow account held by a mutually acceptable legal entity.

The hardware aspect of the platform is therefore liberated from the supply process and the building owner is basically free to chose from a multitude of hardware and operating system (Linux) suppliers.

With this OEM approach, the building owner now has total practical control of the building integration process and building life cycle; from concept and design, to choice of sub-systems supply, to support and maintenance, to running and modification and finally to phase out.

Conclusion
Of course there are as many variations to this approach as there are the variables involved, for instance, it is probable that the Life Safety and/or Security systems suppliers could be involved during the design phase to give their specialist advice. That being so, it may be logical for them to be the nominated integration specialists. Alternatively, a Design, Build, Operate Model would dictate that a Main Contractor type entity would establish in-house integration services as part of its project bid package.

The main point is that in any of these cases the integration design and engineering can be completed upfront and prior to the build phase due to the open integration platform. The result is greater freedom and choice no matter where or at what level it is supplied and applied, with the attendant benefits for the building owner, users and stakeholders.

Worked Example Scenario: Mega Mall

Object: A prospective conceptual Shopping Mall (Mega).

Purpose: To visualize and give scope to the amount of conceptual design that must be completed and to consider the following design points and how can you truly engineer this upfront.

Contention: A conventional paper design can be rigorously applied but can never be tested until the end of the build cycle.

Scope: Modern present day mega malls can be up to a mile long and commonly have over 10 levels, hundreds of separate shops, 1000's of patrons and employees, 10's of restaurants, parking for 1000's of cars.

Questions: How would the facility management handle a fire event; its confirmation, the evacuation of staff and patrons, the event management control; Who and how to disseminate all the information to the emergency services, shop owners, etc; How to control and overriding of automatic subsystems such as Access Control, HVAC fans, Lighting etc; How would this be visualized via the BMS Supervisor, how many separate schematics would be required to be accessed, how are the alarms from the effected sub-systems handled and displayed, are the alarms linked to the schematics automatically, do they do what they are supposed to do?

This is a monumental body of engineering work that must be tested and be ready for opening day, what if your single source integrated building controls suppliers fails to perform as promised, or demands additional funds to complete, or quelle horror, goes bankrupt towards the end of the build cycle! Who is in control then?


About the Author

Mark Hunter email: mark.hunter@intsysco.com
MD of Integration Systems Limited (ISL) ( www.intsysco.com ) – independent building Systems Integrator (SI), and director of botech-asia.com – provider of OEM solutions for open platform, web based building integration.
Quals: - HND Mech. Eng. (Ulster), PGDip and ongoing MSc dissertation, Computing (OU-UK).
Experience: 20 years building controls ex. Trend Controls, Temec & CdC, Consultancy, UK; Hong Kong – ISL, 12 years, distributors for Trend, Cylon Controls, National (NAIS), ElControl, Botech – clients include Motorola, Chase Bank, RHKJC, Macau Government, UA, Guardforce/Chubb etc.
Systems: BMS - HVAC, SCADA- PLC-, Fire, Security- CCTV. Power Monitoring,

footer

OAP
[Click Banner To Learn More]

[Home Page]  [The Automator]  [About]  [Subscribe ]  [Contact Us]

Events

Want Ads

Our Sponsors

Resources