Concept
General Communications Conventions
General communications conventions include the following:
BACnet COV subscriptions - between Servers and MP, b3, and MNB controllers
BACnet Command Priorities - between Servers and MP, b3, and MNB controllers
Infinet I/E (Import/Export) - between i2 Controllers and servers
The use of BACnet COV (Change Of Value) subscriptions is recommended for all communications variable transfers between BACnet controllers in the smoke control applications. This is between the Smoke Control Servers (AS-P/AS) and MP controllers, and also between the Smoke Control Servers and MS/TP field controllers.
The UL 864 timing requirements specify a 10 second response interval from the FAP alarm or FSCS override action and the control action starting in the controller (Smoke Control Server, Central IO modules, MP controller I/O, or MS/TP controller I/O). Using COV subscriptions for BACnet controllers and I/E for i2 controllers accommodates compliance with the timing required, and avoids creation of excess polling communications on the bus.
As a rule of thumb, any signal that needs to be shared with another server should be exposed as a BACnet object in the application folder (under BACnet interface).
The signal inputs and output to Script and Function Block programs are bound to values inside the Application folder of the Smoke Control Server to expose them as BACnet objects allowing COV subscriptions to be applied. This provides the most efficient communications between servers and fast updates.
On the MS/TP bus, COV value changes require the token to transmit the COV notifications. On the MS/TP bus with b3 controllers, the default b3 configuration implements Enhanced MS/TP token passing where the token is passed back to the Smoke Control Server after each b3. This maximizes the ability of the Smoke Control Server to distribute critical information such as the zone alarm, or the associated zone controls to the MS/TP field controllers.
The Enhanced MS/TP should always be enabled on the b3 controllers on the MS/TP bus used for smoke control. The MNB series controllers do not support Enhanced MS/TP. When using MNB controllers for smoke control, the Smoke Control Server serving the MS/TP bus to the MNB controllers should have the parameter designating Max Info Frames increased. When defining a new MS/TP port, the default Max Info Frames typically shows a value of 8. This parameter should be increased to a value equal to the number of MNB controllers in the smoke control application (on that MS/TP port) plus 5. If only serving one or two MNBs, you would not reduce this value to less than the initial default value.
On the Infinet bus with i2 controllers, the default i2 configuration uses Infinet I/E (Import/Export) for variable transfer between i2 controllers and between i2 controllers and the server. I/E provides a Broadcast by exception function which means that values are not polled but rather only transmitted when the value changes by the threshold which is configurable for each i2 point. I/E is very similar to BACnet COV in that it maximizes the ability of the Smoke Control Server to quickly distribute critical information such as the zone alarm, or the associated zone controls to the i2 Infinet field controllers.
Be sure to always utilize I/E between i2 controllers and between i2 controllers and the hosting server.
A building automation system may include objects that are manipulated and written to by other objects, operators, or applications. However, conflicts may arise when these different entities try to write to the same commandable value property of a BACnet object, such as a digital output.
In the smoke control application, the majority of equipment used for smoke control may normally be under the direction of HVAC comfort and energy management programs. When a fire alarm occurs, the equipment must give priority to the control guidance coming from the smoke control applications where the initial automated zone alarm response will be trying to operate the air moving equipment in a manner to contain and exhaust the smoke. This automated response must have the 2 nd to highest priority in the system. The automated response must stay in effect until the zone alarms have been acknowledged and reset where the FAP is no longer indicating any active zone alarm signals; OR the equipment is overridden from the FSCS panel. The control commands from the FSCS panel must have the highest priority in the system.
BACnet provides a very useful system function/feature for managing the control actions from differing sources with differing priorities. The BACnet Command Priority Array provides the capability to track control actions for 16 sources of differing priority. Basically, it is a table of 16 cells which may each hold a command value (or null for no command at that priority). The priority level goes from 1 (highest) to 16 (lowest) and the first cell with a non-null value controls the device.
The use of the BACnet Command Priority is recommended for all smoke control applications handling non-dedicated equipment. The BACnet standard provides several suggestions for application of the priority Levels. Priority level 1 (highest) is suggested for manual life safety applications by BACnet. This fits the definition and priority needs for the FSCS and level 1 is recommended for all FSCS control commands in the smoke control application. Priority level 2 is suggested for automatic life safety applications by BACnet. This is consistent with automated fire alarm response and level 2 is recommended for application to the automatic zone response programs in the smoke control system. Some of the other levels carry suggested or reserved application and are available for you to define to fit your application requirements.
|
Priority Level |
Description |
|
1 |
Manual life safety– This is a suggested priority level based on the BACnet Standard. In Smoke Control applications, this priority is recommended for FSCS overrides. |
|
2 |
Automatic life safety– This is a suggested priority level based on the BACnet Standard. In Smoke Control applications, this priority is recommended for the automated control response associated with the zone fire alarm. |
|
3 |
In Smoke Control applications, this priority is recommended for the automated weekly self-test process. Any fire alarm or FSCS override will override the self-test operation. |
|
4 |
Available for use |
|
5 |
Critical equipment control– This is a suggested priority level based on the BACnet Standard. |
|
6 |
Minimum on and off– This priority is reserved for timer-based Algorithms. (Read-only) Not available for manual control. |
|
7 |
Available for use |
|
8 |
Manual operator - This is a suggested priority level based on the BACnet Standard. |
|
9 |
Available for use |
|
10 |
Available for use. The default command priority in b3 BACnet controllers, unless specifying another within the write property command. |
|
11 |
Available for use |
|
12 |
Available for use |
|
13 |
Available for use |
|
14 |
Available for use |
|
15 |
Available for use |
|
16 |
Available for use. This is the default command priority in Building Operation unless configured otherwise in the interface manager. |
This section describes the alternate program scheme required in the i2 controller to facilitate control source priority decisions. As described previously in the BACnet discussion, in the smoke control application, the majority of equipment used for smoke control may normally be under the direction of HVAC comfort and energy management programs. When a fire alarm occurs, the equipment must give priority to the control guidance coming from the smoke control applications where the initial automated zone alarm response is trying to operate the air moving equipment in a manner that contains and exhausts the smoke.
This automated response must have the second to highest priority in the system. The automated response must also remain in effect until the zone alarms have been acknowledged and reset where the FAP is no longer indicating any active zone alarm signals; OR the equipment is overridden from the FSCS panel. The control commands from the FSCS panel must have the highest priority in the system.
The priority decision used to decide which control input source is applied in an i2 controller must be handled with specific program script in the controller. The following i2 Script program segment is an example of how to achieve a priority decision such as the one described previously in the b3 BACnet command priority discussion.
The i2 Script programs use a collection of nested if-then-else logic statements. The if-then-else sequence is arranged to deliver the highest decision priority early in the sequence. The control is based on the highest priority condition evaluated.
In the code sample that follows, the control decisions for the Supply Fan in Zone 1 are evaluated in the following order:
1) FSCS panel override off
2) FSCS panel override on
3) FSCS panel exhaust command
4) FSCS panel pressurize command
5) Automated response to smoke in the zone
6) Automated response to smoke in an adjacent zone
Basic Application Functions
FSCS Communication Status
Equipment Fault Detection