NTCIP Standards
The 1202 NTCIP standards allow for additional information to be provided by the detectors to the controller. This allows the controller to display detector errors in addition to logging failed detection.
Under the 1202 section 2.3.2.13 Vehicle Detector Reported Alarms, the following as a mandatory data type.
"This object shall return detector device reported alarms (via some communications mechanism). Inductive Loop Detector Alarms are indicated as follows:
Bit Definition
0 Other
1 Watchdog Fault: This detector has been flagged as non-operational due to a watchdog error.
2 Open Loop Fault: This detector has been flagged as non-operational due to an open loop (broken wire).
3 Shorted Loop Fault: This detector has been flagged as non-operational due to a shorted loop wire.
4 Excessive Change Fault: This detector has been flagged as non-operational due to an inductance change that exceeded expected values.
5-7 Reserved
Once set a bit shall maintain its state as long as the condition exists. The bit shall clear when the condition no longer exists."
This may be a mandatory data type, but it only works if the communications between the controller and the loop amplifier is a data stream, instead of a wire with an ON / OFF switch.
TS2'ish Standards Within the NTCIP Requirements
Under the 1202 section 2.3.5.4.2 Occupancy data standard, the detector provides the following information to the controller.
Range Meaning
0-200 Detector Occupancy in 0.5% Increments
201-209 Reserved
210 Max Presence Fault
211 No Activity Fault
212 Open loop Fault
213 Shorted loop Fault
214 Excessive Change Fault
215 Reserved
216 Watchdog Fault
217 Erratic Output Fault
218-255 Reserved
The table above is essentially an continuation of the TS2 standards.
This really only works if the controller has the ability to transmit not only the fact that the detector channel is on, or off, but provides a bit stream of data to the controller. This can be done with TS2 detection, but not with TS1 or standard CalTrans 332 data.
By using the TS1 or 332 standard for detection, the detector provides a contact closure on a wire to an input on the controller. This is either on, or off, not a system of transmitting data.
TS2 Detection Provides Better Intelligence
With the TS2 standard, the serial communications transmits data streams between the equipment, which allows for more than an on / off switch, like the TS1 or 332 data. The TS2 data stream is more robust, allowing for one set of bits to say one of the following messages
This is helpful for a bunch of reasons. When any controller is talking to a central system, the controller and central system can be set up to log the detector failure status - based on whatever detection diagnostic parameters are programmed into the controller. The TS2 controller can not only provide the fact that the diagnostic has failed, but it can also tell you what failed (see codes 210 to 217 from the list above).
This means that with a TS2 controller that is reporting back to a central system, the signal can provide actionable information to the engineer and technician to determine what the problems are, in addition to the fact that there is a problem.
It is a straightforward prospect to determine what has gone wrong, and help the fixing of a problem... Is it a cut wire, or is it a splice? Knowing in advance what happened to the loop can be the difference between going out to fix the problem, and then going back to get the proper equipment, or knowing that you need to schedule a loop cutter. Since this data can be recorded in the central system, the user can run reports and determine what should be done system wide, and most importantly, find a bunch of loops that need to be replaced quickly, and efficiently - but only if the controller gets the coded information. This is why we are looking at putting TS2 detection into 332 cabinets.
Detector Reset
Another TS2 / NTCIP standard requires the remote resetting of detection amplifiers. Some controllers do this. Many don't, even when they say they are "NTCIP" or "TS2". I asked one controller manufacturer (who will remain nameless) why their controller and central system did not allow for remote resetting of detection amplifiers, even though they stated that they were fully NTCIP and TS2 compliant. The response was "Nobody ever asked us about that".
From NTCIP 1202 section 2.3.2.14, Vehicle Detector Reset, there is a mandatory requirement that the detectors can:
"This object when set to TRUE (non-zero) shall cause the CU to command the associated detector to reset. This object shall automatically return to FALSE (zero) after the CU has issued the reset command. NOTE: this may affect other detector (detector channels) that are physically attached to a common reset line."
Other Reasons Why Data Is Better Than On / Off Switches
There is another reason why the TS2 detection is helpful. Most NTCIP based controllers keep a log of the failures, including the detection failures. One of the things that happens quite often, is an engineer or technician opens the door up, and they want to clear a fault by pulling the detector card, and resetting it... Hopefully, the fault goes away. What if you want to know what the reason was for the fault, after you cleared the card?
Since this information is kept in the controller, in a log, the engineer or technician can navigate through the controller menu to get to the logs, and see what the problem was. In my case, we use Naztec Apogee software, so the code is reported as a hexadecimal code, not an easy number. That is why I have a cheat sheet with me...
The 1202 NTCIP standards allow for additional information to be provided by the detectors to the controller. This allows the controller to display detector errors in addition to logging failed detection.
Under the 1202 section 2.3.2.13 Vehicle Detector Reported Alarms, the following as a mandatory data type.
"This object shall return detector device reported alarms (via some communications mechanism). Inductive Loop Detector Alarms are indicated as follows:
Bit Definition
0 Other
1 Watchdog Fault: This detector has been flagged as non-operational due to a watchdog error.
2 Open Loop Fault: This detector has been flagged as non-operational due to an open loop (broken wire).
3 Shorted Loop Fault: This detector has been flagged as non-operational due to a shorted loop wire.
4 Excessive Change Fault: This detector has been flagged as non-operational due to an inductance change that exceeded expected values.
5-7 Reserved
Once set a bit shall maintain its state as long as the condition exists. The bit shall clear when the condition no longer exists."
This may be a mandatory data type, but it only works if the communications between the controller and the loop amplifier is a data stream, instead of a wire with an ON / OFF switch.
TS2'ish Standards Within the NTCIP Requirements
Under the 1202 section 2.3.5.4.2 Occupancy data standard, the detector provides the following information to the controller.
Range Meaning
0-200 Detector Occupancy in 0.5% Increments
201-209 Reserved
210 Max Presence Fault
211 No Activity Fault
212 Open loop Fault
213 Shorted loop Fault
214 Excessive Change Fault
215 Reserved
216 Watchdog Fault
217 Erratic Output Fault
218-255 Reserved
The table above is essentially an continuation of the TS2 standards.
This really only works if the controller has the ability to transmit not only the fact that the detector channel is on, or off, but provides a bit stream of data to the controller. This can be done with TS2 detection, but not with TS1 or standard CalTrans 332 data.
By using the TS1 or 332 standard for detection, the detector provides a contact closure on a wire to an input on the controller. This is either on, or off, not a system of transmitting data.
TS2 Detection Provides Better Intelligence
With the TS2 standard, the serial communications transmits data streams between the equipment, which allows for more than an on / off switch, like the TS1 or 332 data. The TS2 data stream is more robust, allowing for one set of bits to say one of the following messages
- "I was off, and I am still off"
- "I was off, and I am now on"
- "I was on and I am not off"
- "I was on, and I am still on"
This is helpful for a bunch of reasons. When any controller is talking to a central system, the controller and central system can be set up to log the detector failure status - based on whatever detection diagnostic parameters are programmed into the controller. The TS2 controller can not only provide the fact that the diagnostic has failed, but it can also tell you what failed (see codes 210 to 217 from the list above).
This means that with a TS2 controller that is reporting back to a central system, the signal can provide actionable information to the engineer and technician to determine what the problems are, in addition to the fact that there is a problem.
It is a straightforward prospect to determine what has gone wrong, and help the fixing of a problem... Is it a cut wire, or is it a splice? Knowing in advance what happened to the loop can be the difference between going out to fix the problem, and then going back to get the proper equipment, or knowing that you need to schedule a loop cutter. Since this data can be recorded in the central system, the user can run reports and determine what should be done system wide, and most importantly, find a bunch of loops that need to be replaced quickly, and efficiently - but only if the controller gets the coded information. This is why we are looking at putting TS2 detection into 332 cabinets.
Detector Reset
Another TS2 / NTCIP standard requires the remote resetting of detection amplifiers. Some controllers do this. Many don't, even when they say they are "NTCIP" or "TS2". I asked one controller manufacturer (who will remain nameless) why their controller and central system did not allow for remote resetting of detection amplifiers, even though they stated that they were fully NTCIP and TS2 compliant. The response was "Nobody ever asked us about that".
From NTCIP 1202 section 2.3.2.14, Vehicle Detector Reset, there is a mandatory requirement that the detectors can:
"This object when set to TRUE (non-zero) shall cause the CU to command the associated detector to reset. This object shall automatically return to FALSE (zero) after the CU has issued the reset command. NOTE: this may affect other detector (detector channels) that are physically attached to a common reset line."
Other Reasons Why Data Is Better Than On / Off Switches
There is another reason why the TS2 detection is helpful. Most NTCIP based controllers keep a log of the failures, including the detection failures. One of the things that happens quite often, is an engineer or technician opens the door up, and they want to clear a fault by pulling the detector card, and resetting it... Hopefully, the fault goes away. What if you want to know what the reason was for the fault, after you cleared the card?
Since this information is kept in the controller, in a log, the engineer or technician can navigate through the controller menu to get to the logs, and see what the problem was. In my case, we use Naztec Apogee software, so the code is reported as a hexadecimal code, not an easy number. That is why I have a cheat sheet with me...
No comments:
Post a Comment