PROTOCOLS & BUSES USED IN HOUSE

Summary:

prtocols & buses in house

1. General aspects related at the communication protocols used in house (a comparative image about communication protocols)

1.1. Overview of home appliance implementation protocol 

The building automation domain represents one of the most important domains that use the distributed systems in order to control the environment and facilities in miscellaneous buildings and at home.

A distributed control system (DCS) supposes a system that includes computation and control of the resources dissipated in a large area, which could be a home, a building or the neighborhood of the building. In the case of DCS the network that link the component elements of system plays a very important role.

It assures the information transfer between all the components and in the case of slow processes, (typical for in-home or building controlled processes) we can consider that the control of the system is performed in “real time”. This means that the control parameters are opportune, in correlation with the processes’ time constant delivered to all the elements in the system. 

The overall rules that describe the hardware needs and the algorithms implemented by software for the communications between the elements of the system are put together in protocols. The communication protocols are conceived thus that to avoid errors in transmission or reception of information.

The vast majority of commercial and institutional buildings are constructed today with a series of stand alone intelligent systems controlling the air conditioning, lighting, security and access control, fire protection, vertical transportation, and the electrical power supply system.

The building automation industry has now evolved to the point where almost all manufacturers offer systems that have a network of powerful primary controllers placed in central locations, generally plant rooms, and a large number of low cost secondary controllers residing on sub-networks to control small local plant.

Interfacing building automation systems to other intelligent building services has been limited and expensive because interfacing has been done through proprietary drivers written on a manufacturer-to-manufacturer basis. These have several major weaknesses such as:

  1. High cost because they are expensive to develop and are often restricted to a single platform for the given project.
  2. They also restrict future options for modifying the controlled systems. Any changes made to the operating system or upgrading to a new version may render the interface inoperable.

The first move to open protocols in the building industry was American Society of Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE) decision in 1987 to form Standing Project Committee SPC135 to develop an open communication standard for building automation.

The first open protocol solution was presented by Echelon Corporation in the early 1990s with their Lonworks protocol, based on their Neuron chip. This has been the dominant method of achieving interoperability.

In the late 1980s Johnson Controls also had success, opening their proprietary MetaSys network to outside equipment manufacturers (OEMs) as a mean to interface to other mechanical and electrical equipment. However, this didn't help connect to any other automation manufacturers. This method of establishing a de facto standard through open publication of a proprietary standard is quite common in the industrial area, but not in the buildings area.

In 1995 the ASHRAE BACnet standard 135 was published. This was a far more complicated solution than Lonworks, in that it required manufacturers to completely develop their own implementation from scratch. Consequently, the first practical BACnet (Building Automation and Control Networks) implementations took several years to reach the marketplace. Competitive bidding on Native BACnet solutions has only been an option for the last five years.

Over the past five years the Internet has become a driving force in all facets of IT technology and the automation industry is no exception. Most manufacturers are now moving towards web-based interfaces and eliminating the requirement for proprietary software tools for client access of their systems.

Open protocols provide advantages to building owners purchasing control systems. Advantages of open platforms include:

  1. Single seat operation of multiple building services.
  2. Exchange of data between different building services
  3. Single front end graphical interface to access systems from multiple vendors
  4. Competitive bidding on service contracts
  5. Competitive bidding on retrofits and system expansion contracts.

Web-based interfaces are the current directions of the industry and also provide several advantages:

  1. Unlimited number of points of access to the system without license.
  2. Single point of residence for graphics. Graphics do not need to be kept up to date in multiple machines.
  3. Intuitive software access to system. Clients do not need to learn multiple interface software packages.

Now the protocols are written as a series of "layers" each designed to handle a specific communication task. The world has generally accepted the OSI (Open Systems Interconnection) seven-layer reference models for communications systems. These layers are:

OSI Model

Animation 5.1 OSI Model

  1. Layer 7: The application layer represents the level where communication partners are identified, quality of service is identified, user authentication and privacy are considered, and any constraints on data syntax are identified. (This layer is not the application itself, although some applications may perform application layer functions.)
  2. Layer 6: The presentation layer is usually part of an operating system, and is where incoming and outgoing data is converted from one presentation format to another (for example, from a text stream into a popup window with the newly arrived text), sometimes called the syntax layer.
  3. Layer 5: The session layer sets up, coordinates, and terminates conversations, exchanges, and dialogs between the applications at each end. It deals with session and connection coordination.
  4. Layer 4: The transport layer manages the end-to-end control (for example, determining whether all packets have arrived) and error checking. It ensures complete data transfer.
  5. Layer 3: The network layer handles the routing of the data (sending it in the right direction to the right destination on outgoing transmissions and receiving incoming transmissions at the packet level). The network layer does routing and forwarding.
  6. Layer 2: The data-link layer provides synchronization for the physical level and does bit-stuffing for strings of 1's in excess of 5. It furnishes transmission protocol knowledge and management.
  7. Layer 1: The physical layer conveys the bit stream through the network at the electrical and mechanical level. It provides the hardware means of sending and receiving data on a carrier.

Most communication protocols are starting to be based on common existing standards for individual layers:

1.2. A summary of most used protocols

A summary of some most common and relevant protocols is listed in Table 5.1.

Table 5.1 - Common Real Time Control Protocols


Protocol

Intended Market

Controlled by

Developed by

BACnet

Buildings

ASHRAE committee

ASHRAE committee

DNP3

Utilities Power Generation

DNP3 User Group

Westronic

EIB- European Installation Bus

Buildings

Siemens

Siemens

Lonworks

Residential, Buildings

Echelon

Echelon

Modbus

Industrial

Schneider

Modicon (Schneider)

OPC – OLE for Process Control

Manufacturing

OPC Foundation

Microsoft and other companies

X10

Residential

X10

X10

IEC 870 – 5 -101

Utilities Power Generation

IEC organization

Siemens

There are other industrial protocols such as: Profibus, FieldBus and Devicenet that have not been listed. All of the protocols above, except BACnet and OPC were had been started as proprietary interests only, and then published.
A brief description of each protocol is presented bellow for comparison purposes:

BACnet

BACnet was developed by ASHRAE standing Project Committee 135. The protocol was developed specifically to address interoperability and proprietary system concerns in the building automation industry.

The protocol is now spreading to all facets of the intelligent building services, particularly lighting, security and access control, and fire protection. BACnet is based on a collapsed version of the OSI model, including the following layers: Application, Network, Data Link, and Physical layer.

BACnet defines multiple physical architectures to handle high and low speed networks, as well as point-to-point connections. This emulates the structure of most automation systems. BACnet defines objects of information to be communicated over these physical media and defines services to handle the flow of objects between BACnet devices.

Because BACnet is based on a "client-server" model of the world, BACnet messages are called "service requests." A client machine sends a service request to a server machine that performs the service and reports the result to the client. BACnet currently defines 35 message types that are divided into 5 groups or classes.

DNP3

DNP originally created by Westronic, Inc. (now GE Harris) in 1990. In 1993, the 'DNP 3.0 Basic 4' protocol specification document set was released into the public domain. Ownership of the protocol was given over to the newly formed DNP Users Group in October 1993, a group composed of utilities and vendors who are utilizing the protocol.

DNP 3.0 is an open, intelligent, robust, and efficient modern SCADA protocol. The DNP3 protocol is based on the standards of the International Electrotechnical Commission (IEC) Technical Committee 57, Working group 03 who have been working on an ISO three layer named "Enhanced Performance Architecture" (EPA) protocol standard for tele control applications. It is used to exchange data between RTUs (Remote Terminal Units) and remote control points.

The development of DNP3 was a comprehensive effort to achieve open, standards-based interoperability between substation computers, RTUs, IEDs (Intelligent Electronic Devices) and master stations (except inter-master station communications) for the electric utility industry. DNP has also become widely utilized in adjacent industries such as water / waste water, transportation and the oil and gas industry.

EIB European Installation Bus

In building services automation, a distinction is made between three hierarchical levels: the management, automation, and field levels and this is the formal segmentation in Europe under the CEN. EIB was originally designed as a field level bus control in Europe

. EIBnet has been recently been recognized for the building services automation level as well as the field level. The proximity of the EIBnet to BACnet makes it easy to transfer data from the automation level to the management level.

The EIB was initially developed for the field level with a data-signaling rate of 9,600 bps. The EIBnet protocol, developed for the automation level, now makes data transfer via Ethernet 10BaseT possible at a speed of 10 Mbps. Data transfer from the automation level to the management level is made possible by EIBnet's proximity to BACnet.

Lonworks

Echelon Corporation developed Lonworks. It is a dedicated low speed network that talks to Echelon's Neuron chips, essentially a protocol on a chip. This is both Lon's strength and its weakness for building automation applications. Lon is the simplest protocol for manufacturers to implement because most of the development work has been done for them already.

The weakness this imparts is that the implementer is fixed in scale by the limitations of the Neuron chip. Lon has been widely implemented not only in the building industry, but also over a number of diverse industries. Lon communicates over its own low speed bus or over Power Line Carrier, to take advantage of existing power wiring systems. Lon is used in the rail industry and is moving into the residential market.

A number of Lon companies have formed the Lonmark Association to develop a plug and play approach to fixed algorithm design of various types of air conditioning controllers.

Modbus

Modbus® was developed by Modicon for the industrial purpose and is the most widely used protocol for that industry throughout most of the world. Modbus is commonly seen in the building industry as an interfacing protocol for equipment that is commonly used in both industrial and building environments.

Modbus Protocol is a messaging structure, widely used to establish master-slave communication between intelligent devices. Since Modbus protocol is just a messaging structure, it is independent of the underlying physical layer. It is traditionally implemented using RS232, RS422, or RS485 over a variety of media (e.g. fiber, radio, cellular, etc.).

Modbus TCP/IP was recently developed to provide a faster interface and uses TCP/IP and Ethernet to carry the MODBUS messaging structure. MODBUS/TCP requires a license but all specifications are public and open so there is no royalty paid for this license.

The MODBUS protocol comes in 2 variants:

  1. ASCII transmission mode: Each eight-bit byte in a message is sent as 2 ASCII characters.
  2. RTU transmission mode. Each eight-bit byte in a message is sent as two four-bit hexadecimal characters.

OPC - OLE for Process Control

OPC (OLE - Object Link and Embedded for Process Control) is software standard for open software application interoperability between automation/control applications, field systems/devices and business/office applications.

Primarily, OPC was developed for the manufacturing environment to allow complete systems such as inventory, conveying systems, and robotics to communicate at a system-to-system level rather than directly between devices. It was developed with the participation of Microsoft, which pretty much ensured that it would be based on a PC to PC interface.

OPC defines a common, high performance interface based upon Microsoft's COM/DCOM technology. COM (Microsoft's Component Object Model) enables the definition of standard objects, methods, and properties for servers of real-time information such as distributed control systems, programmable logic controllers, I/O systems, and smart field devices. DCOM (Distributed Component Object Model) is the network-aware version of COM technology, providing data via local-area networks, remote sites or the Internet.

X-10 Residential Protocol

X-10 is a power line carrier (PLC) protocol designed for the residential market that allows compatible devices to communicate via the 110VAC/220VAC power wiring within the house. X-10 allows for a maximum of 256 addresses. X-10 and Lon are the predominant protocols at the residential level. X-10 is included in this list to show the differences between a powerful scalable protocol and a simple practical protocol that has been developed with a single low cost target market in mind. Typically, X-10 devices would have very limited options, such as start/stop and would be programmed from a standard residential PC.

IEC 60870-5-101 Protocol

It is similar to the DNP3.0 protocol based on exchanging telegrams between the central station and PC or other equivalent element. The RTU uses a RS485 (X.27) LAN with four wires, which allows control up to 256 different RTU. The protocol manages not only the functional messages but also the time stamp information existing between the RTU and central station. The protocol is especially used in the distribution of energy field (PTD).

1.3. A comparison between common in-house protocols and buildings network protocols

Nowadays, the interface of most building systems or services is achieved by either dedicated drivers written for that specific project or by standard driver interfaces that are supported by the majority of vendors. The most common driver at the PC level is DDE (Dynamic Data Exchange) by Microsoft.

BACnet and Lon are the two protocols that are clearly becoming the world standards for building services. There is a rapid movement to Internet based solutions. Lon has solved this by using Cisco routers. BACnet has incorporated Annex J in Addenda B, which was approved last year, to make UDP/IP a part of the BACnet protocol stack.

Protocol Options Evaluation

More manufacturers have chosen to implement the Lon works at the device level than BAC net have implemented. Lon works have been in the market for longer time and it is better established. The largest automation manufacturers support more Lon works than BACnet.

Among the different solutions presented for integration of building services, BACnet will become the only official world standard. BACnet has been established as multiple national and international standard. (ANSI standard, ASHRAE, CEN standard, Korean National Standard, Arabic Standard). It is the only protocol that is becoming a world standard and is currently at the Committee draft stage as an ISO standard (TC-205).

Lon is already established as a de facto world standard at the device level.
BACnet has seen rapid acceptance because architectures can be scaled to any size application. BACnet can be as easily applied at the device level to create an interoperable sub-network of intelligent systems. BACnet can be implemented at the front end providing communication between intelligent systems.

BACnet is a significantly better technical solution for the automation industry. Lon has a large lead in the commercial market place. Modbus offers interfacing solutions for specific applications. Modbus is commonly used in the industrial environment and is the most commonly used protocol for energy monitoring.
A competitive comparison of Lon and BACnet is given below.
BACnet Strengths:

  1. Scalable. A complete communication protocol for the management level, automation level, field level.
  2. Completely open. Manufacturers can implement the protocol without any licensing fees.
  3. Specifically designed to meet the needs of the building industry.
  4. Constantly evolving. Built in mechanism for updating and enhancing the standard through industry consensus.

There is no vested interest controlling the development of BACnet.
BACnet weaknesses:

  1. No standardized programming language. Proprietary programming tools must be bought from each manufacturer.
  2. No standard configuration tools. Proprietary configuration tools must be bought from each manufacturer.
  3. Expensive for manufacturers to develop.
  4. Many large manufacturers are resisting moving to open protocols because of the exposure of service work and expansion to competition.

Lon Strengths:

  1. Widest implementation over wide range of applications due to early entry into market.
  2. Standard programming tools.
  3. Simple for manufacturers to implement through standardized tools also because the protocol is pre-configured on the Neuron chip.
  4. Has power line carrier implementation

Lon Weaknesses:

  1. Not scalable. Limited by the size and speed of the Neuron chip. Suitable for device level networks only.
  2. No facility for programming complex routines or large algorithms such as energy management.
  3. Not an end-to-end solution. Only suitable for device level automation.
  4. Not based on an open wiring standard. Lon is a proprietary wiring system.
  5. Proprietary hardware. Neuron chips must be purchased with a licensing fee to Echelon.
  6. All Lon solutions require multiple software packages to configure system, and transform the beneficiary of system in a captive customer

1.4. How to show an Ideal Protocol that could be used in home appliance systems?


Which are the features that characterize an ideal in-home appliances protocol:

  1. A complete and universal available communication protocol, which means that a single communication protocol would be used for all building and house communications. All intelligent system devices in the building would talk to each other. Each of the intelligent systems in the building this common language would be available for a range of manufacturers.
  2. Using a single software package for system engineering, including graphics preparation, and configuration would be suitable. This single engineering tool could configure and program multiple systems.
  3. Controllers used by many manufacturers have to reside on the same LAN
  4. Enterprise applications by third party APIs are supported, in order to interface with other client enterprises
  5. The building network elements (controllers) must be realized like “plug and play” systems, including the controllers provided by different manufacturers
  6. The protocol must be able to accept a Web based interface for all intelligent systems (controllers).
  7. Communications could be established and implemented out of the box without specialized engineering and IT commissioning agents, which means that the controllers present a friendly comprehensive setup user.
  8. Clearly established guidelines for delineation of responsibilities in engineering and commissioning communications between intelligent systems.
  9. The software used to access the application is already generally accepted to be a web browser. (Windows Explorer, Netscape, or some other web browser).
  10. On the maintenance side, the tools must be designed to allow a competitive bidding between the service companies in handling all the intelligent systems in one building. This feature will simplify the provisioning and installation for system integrators.

Nowadays, the majority of older buildings contain legacy systems that are hard wired electric, pneumatic, and electronic control systems for mechanical services and hard-wired electric lighting and security systems.

The majority of newer buildings have proprietary intelligent systems for some or for all of their building services. These systems are rarely integrated. When they are, it is usually through interfaces implementation, using one-time drivers that do not allow upgrading the PC operating system or the two intelligent building services being integrated.

We are seeing that some integration has been achieved over the last five years using Lon devices at the sub-network level existing on one bus. These tend to be restricted to the air conditioning, and to an extent, to lighting.

We are just starting to see about integrated BACnet systems for multiple air conditioning manufacturers on the same site. BACnet is starting to be commonly used as a common gateway protocol.

There is no single ideal solution for today’s technology. Optimum solutions will vary with the individual needs of different types of clients within the constraints of the imperfect solutions available today.

Building owners and consultants need to consider what their long-term requirements are going to be. If a building is going to have only one small stand alone automation system then the criteria for specifying and evaluating proposals will be very different than for a one building in a large site where there is motivation to integrate all the intelligent building services.

Additionally, exciting advancements at the software level are moving platforms to Internet browser based interfaces rather than proprietary software interfaces. Vendors present a variety of solutions available these days.

For a client that is integrating multiple platforms, has multiple sites, or wishes access for multiple locations this is a necessity.

The majority of newer buildings have proprietary communication protocols for each intelligent building service, each one operating as a completely stand alone system. Many organizations that have multiple buildings and sites such as institutional owners like universities or hospitals, and property management companies, and their consultants are now attempting to migrate to open systems to achieve one or more aims:

  1. Single seat operation of lighting
  2. Logical interaction between intelligent systems
  3. Multiple manufacturers systems
  4. Interaction with energy management
  5. Interaction with client enterprises such as accounting systems

Today's solutions involve compromise. Selecting the correct automation system today is partially dependent on guessing which protocol will be the world standard.

The path towards a future single open protocol is complex and it is likely that multiple protocols will remain due to divergence of interests in the market place for the near term. The clear trend is towards both open protocols and Internet based systems due to the many advantages they provide to building owners.

Owners and consultants need to choose solutions that will move all automation towards a completely open environment rather than perpetuating the proprietary solutions of the past, simply because it is less complex and confrontational to continue proprietary implementations.

BACnet is clearly the most complete protocol for the building industry. However, Lon is much more widely available and entrenched. The best thing for owners to do is to select solutions that will leave them the most flexibility for future changes while providing the most advantages today, such as Internet connectivity.

Privacy | About Us | Contact
Copyright © 2008 Home Automation - JAEC - All the rights reserved