Standardizing Communication Between Lighting Control Devices

A Role for IEEE P1451

Stephen Treado
Building Environment Division National Institute of Standards and Technology Gaithersburg, MD Stephen.treado@nist.gov

Peter Pettler
Vistron LLC Nevada City, CA USA pete@vistron.com
AbstractThe paper proposes a building equipment communications network based on a federation of existing standards and communications protocols. The proposed network concept provides a viable model for control manufacturers to provide advanced digital control of most building equipment. Keywords- building equipment; lighting controls; networking; BACnet; IEEE P1451; IBECS; DALI; building controls; communication protocols

To overcome these market barriers, the lighting industry is slowly transitioning from a primarily analog control world to a digital one. II. STATE OF THE MARKET

I.

INTRODUCTION

Integrated lighting controls can significantly improve building performance, increase energy efficiency, and enhance occupant comfort and satisfaction with the built environment. While previous research has shown that simple lighting controls such as occupancy sensors are effective at reducing the amount of electrical energy used for lighting in commercial buildings [1][2][3], advanced lighting control strategies have the potential to achieve even greater energy savings and offer many advantages over simple controls. But more advanced control strategies, such as daylighting or load shedding, which require a more systems-oriented approach, were less successful. Some of these difficulties are a result of the horizontal structure of the U.S. lighting controls market. While there are notable exceptions, the market is comprised largely of manufacturers of components (ballasts, switches and controls devices) rather than systems. Lighting controls components often do not work well together when specified as systems, especially in dimming applications where wiring is more elaborate. Lighting control equipment for implementing more complex strategies such as daylighting has proven difficult to commission in the field, leading to poor operation and user complaints [4]. Finally, the lack of agreement on communications protocols was identified in [5] as another market barrier.

A. Background For the last 15 years, the lighting control industry has provided analog-based components that are specialized for lighting control applications. A minimal generic control system consists of a controller, sensor and actuator as shown in Fig. 1. Most communication between actuators and controller and

sensor Controller sensor sensor

Environmental Variables: Temperature Light Airflow Occupancy CO 2 Fire

actuator

actuator

actuator

Building equipment

Building equipment

Building equipment

Figure 1. Shown is a generic diagram of the relationship between controller, actuators and sensors in a typical building control application. Sensors detect the key environmental parameters, while the controller decides which actuator is to be controlled and how. The actuators operate the building equipment, which, in turn affects the building environment. The physical connection between controller and actuator and controller and sensor usually takes place over wires carrying an analog signal.

sensors and controller takes place using hard-wired circuits running analog signals. In todays state-of-the-art, these control

This work was supported by the Assistant Secretary for Energy Efficiency and Renewable Energy, Office of Building Technology, Building Technologies Program, of the U.S. Department of Energy and by the California Energy Commission's Public Interest Energy Research (PIER) Buildings Program under Contract No. DE-AC03-76SF00098

0-7803-7883-0/03/$17.00 (C) 2003 IEEE

systems would be attached to the building lighting sub-systems, and would, ideally, efficiently manage electricity usage maximize occupant satisfaction, and minimize complaints. However, analog control systems are notoriously difficult to commission properly [4] especially when there are large number of controllers in the installation. Difficulties in commissioning have led the entire building industry to seek solutions that add networked intelligence to control system components. The idea is that by adding a modicum of intelligence to the things we want to control, they will better perform their tasks. A consequence of adding intelligence to building equipment and control devices inevitably tips the industry towards digital solutions. B. Transitioning to Digital Controls In the building industry, this transition will likely take place in two, possibly parallel, steps: 1. Digital, wired networks will replace analog networks 2. Wireless networks will replace wired ones In the building industry, the first manifestation of this transition from analog to digital is in the communication between control devices. Digital communication solves many of the cabling issues caused by analog control even though physical wires are still needed. Most digital, wired systems allow devices to share a physical cable, which simplifies the cabling and reduces installation errors compared to analog systems. The lighting ballast industrys adoption of DALI (Digitally Addressable Lighting Interface) represents the industrys first steps into the digital world. By embedding microprocessors into lighting ballasts (i.e., actuators) commissioning problems can be mitigated and the difficulty in specifying functional systems reduced. DALI, however, was never intended to serve as the communications protocol between controller and lighting sensors it is a lighting actuator protocol. Thus DALI, as it is currently implemented, does not accommodate communication with or between devices other than ballasts and lighting controllers, and does not provide a link to other elements of the building control system. A more general building equipment communications network would embed intelligence into lighting sensors and controllers, as well as actuators and provide a robust pathway for exchanging data and control signals between lighting actuators, sensors, controllers and other building automation systems. There are many advantages to adding intelligence and connectivity to building equipment. Here we discuss two main advantages: better access to building lighting systems and improved automation. Intelligent lighting devices that are also accessible via the network can be controlled from multiple users with different needs and levels of authorization. With networked overhead lighting, an occupant could call for more or less light as needed using a simple control panel on their PC. This would be much less expensive to implement than a physical dimmer with wires. In other words, the incremental cost of providing the occupant with a modicum of control of their lighting

environment can be made quite inexpensive. Furthermore, the necessary security considerations can be addressed in software. Intelligent, networked equipment is much easier to update with new control algorithms and improved commissioning software than dumb analog systems. Intelligence added to controllers and sensors will allow the lighting control industry to implement better control algorithms and improve commissioning. With improved control algorithms and more automated commissioning, lighting controls will be able to better perform their main function efficiently managing building lighting costs while improving occupant comfort and satisfaction. Initially, wires will be required to carry the communication signals between control components, and it is reasonable to assume that the cost of adding control wires will at first limit the digital controls market to new construction and major renovation. In the second phase of the industry transition to digital controls, wireless and powerline carrier technologies will play an increasingly significant role, especially in the vast existing building market where much of the energy savings resides. Today, however, wireless and powerline communications are too expensive to implement at the finest level (individual lighting fixtures, for example) and are beyond the scope of this paper. III. EXISTING PROTOCOLS RELEVANT TO LIGHTING CONTROL EQUIPMENT

In this paper, we propose a general model for a building equipment communications network that would combine several existing communications protocols into one unified framework. In this framework, all network activities and transactions become services that provide for control of and communications with networked building equipment. The definition of service here is quite broad; a service might be a virtual control panel on a users PC allowing them to dim their local lights. Or a service could be a control algorithm that allows the building facilities manager to implement demand responsive controls according to a pricing signal from the local energy provider. We pattern our robust networking framework after the Jini system [6] and take our goals as the same: No user intervention should be required when a service is added to or removed from the network. This requires a robust lookup and discovery procedure that provides self-identification when a new piece of building equipment (or software) is added to the network. The network should be self-healing. It must be able to adapt when services (and consumers of services) come and go. Finally, consumers of network services should not require prior knowledge of the services implementation. Rather, the end-user loads the service implementation dynamically and transparently, with no configuration or user-intervention required.

0-7803-7883-0/03/$17.00 (C) 2003 IEEE

Although the implementation of a such a general and robust network model will be a challenging task to the building controls community, there are several existing communications protocols -- specifically BACnet, IBECS and the IEEE 1451 Standard on Sensors and Actuators that, when used collectively, could form the foundation of such a network model. In addition, the DALI protocol for the digital control of lighting ballasts, which is gaining some acceptance among US ballast companies, can be accommodated and supported in this model. In this section, prior to proposing such a framework, we describe each of these protocols. A. BACnet BACnet is both a standard protocol for data communication services for building systems, and an abstract, object-oriented representation of the equipment comprising the building systems [7]. The building control system and the equipment being controlled are modeled as objects with standardized features, allowing communication between the components of the system without requiring specific knowledge of each device's internal design or configuration. BACnet services are commands that enable the transfer of information and control signals throughout the building systems. Within the realm of building HVAC systems, BACnet has become the predominant communications protocol, due to its non-proprietary nature and status as an ASHRAE standard [8]. Since buildings also incorporate lighting control systems, the capability of integrating the lighting control system with the building automation system should enable better performance, simpler operation and cost savings. Interoperability, however, does present some hurdles. In the case of lighting systems, there are particular operational characteristics that are unique to lighting, and may not be easily accomplished, or even possible, within the current structure of BACnet. In the formalized language of data communications, BACnet is based on a four-layer collapsed architecture that corresponds to physical, data link, network and application layers of an OSI (Open Systems Interconnection) model. BACnet itself defines the application and network layers, while the data link and physical layers are largely adopted from existing industry standards. The topology of a BACnet network is not prescribed by the standard, but rather is determined by the requirements of the underlying local area network. It is important to note that BACnet objects do not necessarily correspond to physical objects. While this might be the case for simple devices, such as sensors or switches, more complicated physical devices, such as a chiller, are typically represented by several BACnet objects. The critical point is that for any input or output to be accessible to the BACnet system, it must be represented by a BACnet object Many of the features and functions of lighting control systems can, in theory, be accommodated by existing BACnet objects and services. In some cases, the mapping is straightforward, such as mapping a simple switch as a binary input device, and a daylight sensor as an analog input device. Relays can be represented by binary outputs, and dimmers by analog

outputs. In other cases, such as creating groups of fixtures that can be controlled as a unit, existing BACnet functions can be used, but the implementation is not as simple. Other lighting control features, such as preset scenes, cannot be easily implemented using current BACnet functions. Thus, it appears that additional BACnet objects will be needed for lighting control applications. Since that is the case, it would be beneficial to create a robust set of BACnet lighting control objects, specifically designed to meet the needs of lighting control systems. In that manner, lighting control system designers could use BACnet lighting objects instead of having to cobble together existing BACnet objects. Some general concerns about lighting control systems and BACnet include the need for fast response to manual inputs, so that when a light switch is turned on, the fixtures immediately illuminate. This is also needed for manual control of dimming level. It is likely that some components of lighting systems, such as switches and ballasts, may not be suitable BACnet devices due to cost constraints, and thus, may not be included on the BACnet network. They may either not be on any network, or may be connected using IBECS, DALI or a proprietary system. In addition, there are other lighting controlrelated protocols in use, such as DMX 512 and EIB. It would be useful to provide for a straightforward mechanism for interfacing with these types of systems B. IEEE P1451 IEEE P1451.4 is a developing standard that brings selfidentification to analog transducers (sensors or actuators) [9]. The standard specifies how an analog transducer is augmented with an embedded Transducer Electronic Data Sheet (TEDS) that contains technical information identifying the transducer, specifying its interface, and describing its use. In short, the TEDS table contains the critical information required by the network for plug-and-play connectivity. While IEEE P1451 came about to serve the needs of the sensor and measurement industries, the TEDS concept has profound implications for other industries, including the lighting controls industry. The first portion of the TEDS (basic TEDS) contains basic identification information: manufacturer ID, model number, and serial number of the transducer. In addition, the TEDS contains one or more IEEE standard TEDS, which typically contains the information needed to properly configure the electrical interface and convert the measurement data into engineering units. Typical TEDS parameters include measurement range, electrical output range, sensitivity, power requirements, and calibration information. The transducer TEDS can also include a calibration TEDS that specifies either a lookup table or a calibrated transfer function represented by a set of polynomial coefficients. The last portion of the TEDS lets the end user store custom data and information specific to that sensor or actuator. For example, for lighting ballasts, this portion of the TEDS table could store the physical location of the ballast in a labeling system logical to the facility (i.e., room number). Additional maintenance information or other custom information would also be stored in this memory area.

0-7803-7883-0/03/$17.00 (C) 2003 IEEE

Implicitly, the IEEE P1451 standard recognizes that, for the next several years, sensors will need one foot in the digital camp and one in analog. The transition from analog to digital will not take place overnight. Thus a viable market strategy for sensors must take account the need to accommodate analog signals while providing the additional functionality that digital control offers. C. IBECS (Integrated Building Environmental Communications System) The goal of the IBECS project is to develop and demonstrate an integrated building equipment communications network that will allow flexible automation of lighting systems to increase energy efficiency, improve building performance, and increase occupant comfort in the built environment. An ideal lighting control system would be able to respond automatically to changes in occupancy, daylight levels, and energy costs, while at the same time giving occupants more control over their personal lighting environment. This is best accomplished by being able to control or communicate with individual light fixtures. Historically, individual fixture control has not been cost-effective, but recent developments in embedded device networks now make such fine level lighting of control economical. An embedded device network is a collection of smart devices (often called slaves because they are part of a master/slave network architecture) that connect to a common bus (Fig. 2). The address space is huge so that theoretically every physical device that has been created or will be created could have its own unique address. The bus is a physical cabling system similar to CAT5 cable that is used in computer networks. All slave devices have a globally unique address so each can be digitally addressed from a bus master. Embedded device networks use a single master/ multiple slave architecture. With only one master per network, data packet collisions are avoided. As the name master/slave implies, the bus master controls and initiates all communication between attached slave devices using a hierarchical set of rules.

available dimmable lighting ballasts as well as light switches and sensors [11]. With the IBECS system, each fluorescent ballast and switch to be controlled as well as each occupancy sensor and light sensor would be equipped with an appropriate network interface and connected to the microLAN. (The microLAN is a type of field bus). The interfaces would contain 1-Wire devices appropriate to the functionality of the connected ballast, control or sensor. The master controller (usually a type of network bridge) controls the communications between all devices attached to the microLAN using the 1-Wire protocol -- an open standard serial communications protocol available for no charge [13]. However, to use the 1-Wire Net protocol, manufacturers must embed at least one Dallas Semiconductor slave into each controlled product. The bridge can control over 100 devices and attaches to the Internet, thus providing TCP/IP network connectivity to the microLAN. The IBECS concept is important to the overall control framework because it treats all building equipment down to the individual light as just another device to be controlled, measured, or responded to (Fig. 3).
Ethernet (existing)
Facility Managers Workstation Occupants Personal Computers More microLANs as necessary

MicroLAN (1,000 linear feet typical with 100 devices) microLAN

Network Interfaces

Fixture with dimming ballast

IBECS addressable light switch

Light sensor

Occupant sensor

Lighting Power Meter

Lighting Equipment

Figure 3. A small IBECS network consisting of a bridge, the microLAN, and equipment-specific network interfaces designed to control and communicate with building lighting control devices and equipment. The system is scalable since more microLANs can be added as necessary and their operation controlled over the buildings Ethernet.

As the market develops, we anticipate that lighting equipment manufacturers would embed the devices in all the ballasts, switches, sensors and meters to be controlled and simple networks (often called field busses) would be installed throughout the building connecting all the devices together to networked bridges.
Figure 2. A minimal 1-Wire network consisting of one master and two slaves connected via a wire. The master and attached slaves operate in open-drain mode. In 1-Wire, as in most master/slave networks, the master initiates all network transactions.

IBECS is an adaptation of a general-purpose embedded device network technology from Dallas Semiconductor/MAXIM to the problem domain of lighting and building equipment control [10]. The first step toward realizing this advanced networking concept is designing prototype network interfaces tailored to control commercially-

Much of the design for IBECS is driven by the need to add intelligence and connectivity to small building equipment at very low cost. This makes the choice of where to concentrate intelligence of paramount importance in the network design. To avoid the cost of inserting a complete microprocessor into each ballast, IBECS embeds just an intelligent slave to each ballast and concentrates the control intelligence to operate the networked lights in the bridge. The bridge contains all the hardware and software to control and communicate with all networked devices regardless of whether the bridge is connected to the larger Internet.

0-7803-7883-0/03/$17.00 (C) 2003 IEEE

D. DALI DALI (Digital Addressable Lighting Interface) is a protocol for addressing lighting ballasts. DALI is a dedicated protocol for lighting control, which has been marketed in Europe for several years, and is now being imported to the US lighting controls market. DALI was not designed to control other systems such as building management systems nor does it treat sensors. However, DALI is effective for scene selection and for getting feedback regarding faulty lamps. This makes DALI very useful to use together with a more general building equipment network that provides sensor information into DALI and provides remote supervising and user control. More information on DALI is available from [12]. IV. UNIFIED FRAMEWORK FOR A BUILDING EQUIPMENT COMMUNICATIONS NETWORK

We propose that the IEEE P1451 Standard for Sensors and Actuators, together with BACnet, serve as the standards basis for governing the communication between digital lighting control devices and automation systems in commercial buildings. In Fig. 4, we show diagrammatically the relationship between IEEE 1451, BACnet, IBECS and DALI in the proposed

building equipment network. The lighting control and building automation software would use BACnet as the language for addressing building equipment. All interactions between networked bridges and other building and energy management systems would be mediated using BACnet. For its part, IEEE P1451 provides the methodology for equipment to identify itself and its capabilities to the network and thus to users of lighting services in a flexible and secure fashion. By storing the TEDS with the equipment, the network always has available the information necessary to control and communicate with all equipment and processes on the network. IBECS extends this control framework to the smallest pieces of building equipment, i.e., individual fixtures, ballasts or even lamps, where cost pressures on added device intelligence and network connectivity are very high. Since DALI ballasts are now becoming available, we propose that capabilities of the intelligent bridge be extended so that DALI devices and the DALI network are accommodated as well. How does this framework achieve the ambitious goals set out earlier with respect to robust networking for building equipment? Below we show how this loose federation of different protocols provides a building-equipment specific solution to one of the thorniest problems that occur in networks: how the network discovers when a new device (in

Figure 4. System diagram of the proposed communications framework consisting of an IBECS network and a DALI lighting network controlled by a networked IBECS/DALI bridge. Additional bridges can be added to the system to accommodate more equipment as the system grows. The IBECS bridges would communicate using the BACnet protocol and be separated from the building Ethernet with a firewall. As shown by the indicator on the left, the different protocols have overlapping degrees of influence over the overall communications system. IBECS, and the underlying IEEE P1451, govern most communications at the equipment level and the attached DALInet. At higher levels of the network, the influence of IBECS diminishes and is taken up by BACnet, which governs communications above the bridge.

0-7803-7883-0/03/$17.00 (C) 2003 IEEE

our case, a light fixture, switch etc.) has been added to the network (or when an occupant wants access). A robust lookup and discovery process is the major pre-requisite to a practical and reliable building equipment control network. In our network model, any piece of building equipment to be controlled would be embedded with one (or more) slave devices that add intelligence and network connectivity to that piece of building equipment. Similarly, any environmental sensor or meter that we would want to read could be similarly embedded with intelligent slaves. In general, there need not be a one-to-one correspondence between slave device and building equipment. Indeed, how manufacturers choose to incorporate slave devices into their equipment will be determined by the needs of the market. A manufacturer of a ballast, for example, might elect to embed two slave devices in their 0-10 VDC dimming ballast product to 1) provide network control of light level and 2) provide the network with a diagnostic indicator of lamp status. After installation of the now-intelligent ballast, the network needs to discover the ballast and store into memory the information on how to interface reliably with that ballast. In the network model proposed here, that information would be stored with the equipment. The manufacturer would provide a secure means to identify the equipments technical capabilities to the network by loading the embedded slaves memory bank with the appropriate IEEE 1451 TEDS table for that piece of equipment. (The digital potentiometers and other 1-wire devices that IBECS uses contain a small bank of memory (about 40 bytes) that would be loaded with the compressed TEDS). It is important that the TEDS data be at the equipment level (rather than at the device level). Providing self-identification at the equipment level provides the network all the data it needs to communicate securely with the attached equipment using an object and data type appropriate to the domain. V. DISCUSSION

industry as it covers all the key components of a lighting control system (Fig. 1). Another advantage of the proposed framework is that it provides broad flexibility in the configuration and design of systems for building environmental control. This allows both manufacturers and system designers great freedom in developing and implementing new approaches without limiting their creativity by forcing their adherence to a fixed structure. For applications that are more cost-sensitive, a large portion of the control and communication could be accomplished at the IBECS level to help hold down first costs. More sophisticated applications could utilize a greater portion of the hierarchical control and intelligence capabilities afforded by integration with the building automation system via BACnet. The features of the IEEE 1451 standard help to provide user-friendly connectivity at the lowest levels of the network. Of course, a framework for better lighting and building control will only be successful if equipment manufacturers believe that adopting it would add significant value to their products. Which protocols comprise the framework is, therefore, important. If one or more of the protocols already have an established commercial track record, then it is more likely that manufacturers in different product areas would embrace it. This bodes well for the proposed framework since most HVAC manufacturers produce systems that are BACnet compliant today and the influence of BACnet on lighting control products is also growing. Although most of the commercially available applications for IEEE P1451 are currently in the sensor and measurement industries rather than in building controls, more IEEE P1451 compliant products continue to emerge. And most ballast manufacturers are now producing DALI ballasts for the US market. VI. SUMMARY

At first glance, the proposed federation of apparently unrelated protocols for the purpose of building equipment control might seem ad hoc. However, when these disparate protocols operate collectively in the proposed framework, the apparent deficiencies in one protocol are compensated for by the strengths in others. For example, while IBECS provides the hardware and software infrastructure to communicate with small equipment loads from an intelligent bridge, it does not address how these different bridges will communicate with one another or with other servers and processes. BACnet bridges this gap by providing the common terminology and underlying data structures that describes the important technical and operational attributes of building equipment as carefully defined BACnet objects. IEEE P1451 provides the mechanism to assure that the network always has available the necessary information to address building equipment using methods implemented by the equipment manufacturer and tailored to the manufacturers product capabilities. DALI does not treat sensors, but this lack is made up for by the domain of IEEE P1451, which includes all transducers -- sensors as well as actuators. IEEE P1451 treats sensors and actuators on an equal footing. This makes it appropriate to the lighting control

While the above protocols and standards can play a significant role in an overall building equipment communications network, each, taken by itself only solves part of the bigger control problem. But combining the features of BACnet, IBECS and IEEE 1451 as proposed in the paper provides the flexibility and functionality such that the power of the resulting framework far exceeds that of its individual elements. Such a framework would allow the integration of a wide range of components, each of which would only need to conform to the requirements of the particular subset of the system to which it would belong. This would allow network connectivity for low-cost components that now are usually considered to be too inexpensive to incorporate such technologies, while at the same time accommodating powerful intelligent hierarchical control strategies. One benefit of the use of standard protocols is that they provide for interoperability without constraining the internal design and operation of components and devices. As a result, manufacturers can differentiate their products based on whatever combination of price and performance they deem appropriate. Devices and systems can be designed and selected from a wide range of performance attributes to meet different goals as required for specific applications. Interoperability

0-7803-7883-0/03/$17.00 (C) 2003 IEEE

begets flexibility, which encourages design solutions tailored for optimum performance. ACKNOWLEDGMENT This work was supported by the Assistant Secretary for Energy Efficiency and Renewable Energy, Office of Building Technology, Building Technologies Program, of the U.S. Department of Energy and by the California Energy Commission's Public Interest Energy Research (PIER) Buildings Program under Contract No. DE-AC03-76SF00098. REFERENCES
[1] J. Jennings, F. Rubinstein, D. DiBartolomeo, and S. Blanc, Comparison of control options in private offices in an advanced lighting controls testbed, Journal of the Illuminating Engineering Society, Vol. 29, No. 2, pp. 39-60, 2000 B. Von Neida, D. Maniccia, and A. Tweed, An analysis of the energy and cost savings potential of occupancy sensors for commercial lighting systems." Journal of the Illuminating Engineering Society, Vol. 3, No. 2, pp. 111-125, 2001 T. Moore, D.J. Carter, and A. Slater, Long-term patterns of use of occupant controlled office lighting, Lighting Research & Technology, vol. 35, No. 1, pp. 43-59, 2003 J. Love, Field performance of daylighting systems with photoelectric controls, Proc. of the 3rd European Conference on Energy Efficient Lighting, Newcastle-upon-Tyne, England, 1995

[5] [6] [7]

[8] [9] [10]

[11]

[2]

[3]

[12] [13]

Department of Energy, Vision 2020: the lighting technology roadmap, unpublished, http://www.eere.energy.gov/buildings/research/lighting/ K. Arnold, B. OSullivan, R. Scheifler, J. Waldo, and A. Wollrath, The JINI Specification, Addison Wesley, 1999 American Society of Heating, Refrigerating and Air-Conditioning Engineers, BACnet- A Data Communication Protocol for Building Automation and Control Networks, ASHRAE Standard 135-2001, Atlanta, GA S.T. Bushby, H.M. Newman,. "BACnet Today" ,Supplement to ASHRAE Journal. pp. 10-18, October, 2002 D. Potter, IEEE P1451.4s plug-and-play sensors, Sensors, Vol. 19, No. 12, December, 2002. F. Rubinstein, S. Johnson, and P. Pettler, IBECS: an integrated building environmental communications system - It's not your father's network", Proc. of the American Council for an Energy Efficient Economy Summer Study on Energy Efficiency in Buildings, August, 2000, Pacific Grove, California. F. Rubinstein, P. Pettler, and J. Jennings, Dimming every light cheaply, Proc. of the American Council for an Energy Efficient Economy Summer Study on Energy Efficiency in Buildings, August, 2002, Pacific Grove, California. http://www.dali-ag.org/, unpublished Dallas Semiconductor/MAXIM, Application Note, Overview of 1-wire technology and its use, http://www.maximic.com/appnotes.cfm/appnote_number/1796

[4]

0-7803-7883-0/03/$17.00 (C) 2003 IEEE