In networking, Peer-to-Peer Architecture is defined as: "Often referred to simply as peer-to-peer, or abbreviated P2P, a type of network in which each workstation has equivalent capabilities and responsibilities. This differs from client/server architectures, in which some computers are dedicated to serving the others-Webopedia. Usually, when there is a client/server relationship, there is still some P2P sharing going on.

The architecture of a CBAS system is actually a form of client/server, in that the Automation Server is the keeper of the master database. The controllers look to it to get their share of the database and any subsequent changes to it. Also, logic that commands points on controllers can be executed on the Server.

In CBAS systems, Peer-to-Peer is not an architecture, but the concept is similar in that it allows controllers to share information (status of points) with each other, without the help of the Automation Server. Peer-to Peer generally co-exists with client/server just as it does in most computer networks.

In what situations would you want to use Peer-to-Peer?

• Stand-alone systems: a few controllers without an Automation Server.
• Communication to the Automation Server is down. You can't really know when this going to happen, but if you set it up in advance, you have added redundancy to the system.

Limitations:

• Peer-to-Peer will work with the following controllers:
• 8X
• 16X
• 32X
• 64X
• VAV Controllers
• LC-ER32
• Only available on versions of CBAS from 1.5.21 forward (Feb 2003)
• Point types that can be PEER points:
• Binary Hardware or Software
• Analog Hardware or Software
• Point types that cannot be PEER points:
• Multi-state
• Meter
• Panel
• Channel
• Fire
• Peer-to-Peer will not work across a Router on TCP/IP networks
• Must be able to send/receive "broadcast" packets
• When writing Logic involving a PEER point, do not use the "is in alarm" phrase referring to that point. The packet sent by PEER points does not contain that information.
• Commandable points can be shared as PEER points, but the PEER version of Points are not commandable. (A PEER version of the original point resides on the controller(s) that it is shared with)

Programming PEER points is easy. First, go to System, then Peer To Peer Setup and you will see the editor.

• Click the "Add Point to Shared List" button and choose the points you want to share from the list that appears.
• Once shared, highlight a point and you will see a list of controllers it is shared with in the list on the right.
• Click the "Add Controller to Destination List" button to choose controllers that will receive status updates from the shared point.
• Highlight a point in the shared list and use the buttons in the middle of the editor to change the minimum and maximum amount of time that statuses are sent.
• Click the "Generate Report" button to see a report that shows each point and the controllers it is shared with. With one page per shared point, the report can be quite lengthy.
• All CBAS reports can either be printed, or saved in one of many different formats. Click on to save the report.

Go to Hardware View. In each controller that a point is shared with, you will see that point listed with the word "PEER" after it’s name. This point will never show the correct status that is shown on the original point. However, the correct status will be displayed on a Handheld device.

Routing is also shown on the PEER Editor screen and is configured automatically depending on whether the host controller has 485 channels programmed. Controllers with no 485 channels are assigned "No Routing", meaning that the status is broadcast only by that controller. Controllers with 485 channels are assigned "Routing 1", which means that status is broadcast on all channels. When another controller receives the status, it re-broadcasts on all channels except the one it was received on.

When writing a logic statement involving a PEER point, you will not see the local "PEER" point listed as a selectable point. You have to go to the "All Points" list and select the original point. CBAS knows that it is a PEER point and will take care of the rest for you.

Some good examples of points that might be shared between controllers include:

• Outside Air Temperature
• Outside Air Humidity
• Summer/Winter Mode
• Building Master Schedule
• AHU Master Schedule

When configured properly, Peer to Peer can add sophistication and/or redundancy to a sequence of operation. It can turn a small group of stand-alone controllers (without server) into a real interactive system, similar to one with a server. Or it can add some redundancy in the case when a server is off-line.