B
I have had and continue to have a need to integrate security type card readers into PLC/RTU networks for identification purposes. Respondants from the security and/or access control side of the business seem to be of the opinion that existing, dedicated, off the shelf, turnkey systems are the only practical solution. And further, that adding identity verification directly within a PLC is "wasteful", a "duplication" and "re-inventing the wheel".
I suspect that the goals I'm trying to achieve are not uncommon to other members of the list. For the following (real life) situations, I have a
solution in mind. Please feel free to mercilessly pick it apart.
A municipality is responsible for the distribution of potable water and the collection of watewater. There are 8 major reservoirs with pumping facilities, 22 minor pumping facilities and about 30 metering vaults. All of these facilities have communications with a central site. 3 different protocols on 3 networks. None of the facilities including the central site are manned after hours. Generated alarms are automatically dispatched to oncall operators through dedicated hardware. The oncall operator has a laptop with wireless access to the central site. He sees everything the central site sees from anywhere he happens to be.
Security companies had installed various degrees of access control and monitoring at the 8 major sites ranging from automated gates with keycode
access and video cameras to simple intrusion alarms that required a coded keypad entry to prevent dialing out of an alarm. These measures seemed adequate until:
1. An operator responded to a low pressure alarm at 11:00 PM one evening. After entering the building he disabled the intrusion alarm - normal procedure and went downstairs to investigate (equipment is below grade). Unfortunately, he slipped and injured himself to the point he couldn't get back up the stairs. Since the problem had not yet been rectified, the automated call out system eventually went to a second level paging sequence and called another operator who unwittingly arrived as a rescuer. The victim's dilemma would have been even greater had he fixed the problem and fallen going up without an oustanding alarm to attract attention to his plight.
2. A second situation occurred more recently. An operator received an alarm from the largest facility. This location is contained within a fenced compound covering about 5 acres and contains 4 separate buildings. Access to the compound is through an automated gate that requires a code entry on a keypad. Closure is automatic after entry. Upon arrival the operator noticed one set of tire tracks in the relatively fresh snow through the gate ahead of her, yes her. Her laptop gave her access to the central site HMI which showed an open door at one of the buildings. This was not an alarm merely a status since a separate security system had been installed. Prudentlly she called the police who reacted as expected in the aftermath of Sept 11. As it turned out the 'intruder' was another municipal employee that was there retrieving a spare part he needed somewhere else.
Whereas at one time the police reacted to false alarms will ill humor they did not do so in this case. Constructive dialog ensued and some very good ideas surfaced. Management knew what they had. They just weren't aware of what they didn't have. A very simple wish list was produced. The list included one item with a number of caveats. Add every ingress and egress event at every facility to the existing Scada event log. Add an 'Entered by xxxxx at dd/hh/mm' display on each of the appropriate MHI screens while a facility is occupied. Use the existing communications infrastructure. Where possible integrate existing security mechanisms.
A possible solution involves issuing proximity type security access cards to all employees. If such a reader was equipped with a keypad and integrated to each PLC/RTU, the Scada system to which it is connected could log relavent activity. Additionally, where existing stand alone security or access control systems exist, they could be upgraded to also use proximity cards
and readers.
Readers are available with a number of interfaces including weigand, RS422 and RS232. Although I've had success with the RS232 format in the past,
weigand appears more suited to this situation. This is so because the format will be understood by the existing access control system and the data 0 - data 1 outputs of a weigand device should be able to be read by 2 devices simultaneously. This means that both a PLC and a card access controller could read the same data stream and do whatever they wish with the info. There is a relatively minor timing issue with respect to the PLC/RTU digital inputs but that is solvable.
Now maybe there are better ways to do this, but after attempting to work with the access control community on 4 different projects going back nearly 10 years now I've given up. Frankly, I'm tired of being told that getting 5 of something I don't need makes up for the absence of the one item I do need.
It is important to be aware that some companies that claim to provide security devices, systems etc. etc. are actually selling monitoring
services. Such companies could be expected to skew their recommendation towards a solution that includes monitoring, thereby ensuring an ongoing revenue stream. It is a mistake to grant any security organization carte blanche. They may in fact be the experts but do not assume they are sharing their expertise.
<flame shield up>
Regards,
Bob Lockert
Please note:
None of these comments are directed towards any listmember. My opinions are based on experiences gained during development of ultimately successful projects as far back as 1988. Whether by intention or ignorance much of the advice I received was poor (my opinion). There is a very strong NIH (not invented here) mentality within the security/access control industry that presents a barrier to looking at anything from another perspective. When and if that industry stops perceiving legitimate interest from the automation world as a threat, great opportunities for both will arise.
I suspect that the goals I'm trying to achieve are not uncommon to other members of the list. For the following (real life) situations, I have a
solution in mind. Please feel free to mercilessly pick it apart.
A municipality is responsible for the distribution of potable water and the collection of watewater. There are 8 major reservoirs with pumping facilities, 22 minor pumping facilities and about 30 metering vaults. All of these facilities have communications with a central site. 3 different protocols on 3 networks. None of the facilities including the central site are manned after hours. Generated alarms are automatically dispatched to oncall operators through dedicated hardware. The oncall operator has a laptop with wireless access to the central site. He sees everything the central site sees from anywhere he happens to be.
Security companies had installed various degrees of access control and monitoring at the 8 major sites ranging from automated gates with keycode
access and video cameras to simple intrusion alarms that required a coded keypad entry to prevent dialing out of an alarm. These measures seemed adequate until:
1. An operator responded to a low pressure alarm at 11:00 PM one evening. After entering the building he disabled the intrusion alarm - normal procedure and went downstairs to investigate (equipment is below grade). Unfortunately, he slipped and injured himself to the point he couldn't get back up the stairs. Since the problem had not yet been rectified, the automated call out system eventually went to a second level paging sequence and called another operator who unwittingly arrived as a rescuer. The victim's dilemma would have been even greater had he fixed the problem and fallen going up without an oustanding alarm to attract attention to his plight.
2. A second situation occurred more recently. An operator received an alarm from the largest facility. This location is contained within a fenced compound covering about 5 acres and contains 4 separate buildings. Access to the compound is through an automated gate that requires a code entry on a keypad. Closure is automatic after entry. Upon arrival the operator noticed one set of tire tracks in the relatively fresh snow through the gate ahead of her, yes her. Her laptop gave her access to the central site HMI which showed an open door at one of the buildings. This was not an alarm merely a status since a separate security system had been installed. Prudentlly she called the police who reacted as expected in the aftermath of Sept 11. As it turned out the 'intruder' was another municipal employee that was there retrieving a spare part he needed somewhere else.
Whereas at one time the police reacted to false alarms will ill humor they did not do so in this case. Constructive dialog ensued and some very good ideas surfaced. Management knew what they had. They just weren't aware of what they didn't have. A very simple wish list was produced. The list included one item with a number of caveats. Add every ingress and egress event at every facility to the existing Scada event log. Add an 'Entered by xxxxx at dd/hh/mm' display on each of the appropriate MHI screens while a facility is occupied. Use the existing communications infrastructure. Where possible integrate existing security mechanisms.
A possible solution involves issuing proximity type security access cards to all employees. If such a reader was equipped with a keypad and integrated to each PLC/RTU, the Scada system to which it is connected could log relavent activity. Additionally, where existing stand alone security or access control systems exist, they could be upgraded to also use proximity cards
and readers.
Readers are available with a number of interfaces including weigand, RS422 and RS232. Although I've had success with the RS232 format in the past,
weigand appears more suited to this situation. This is so because the format will be understood by the existing access control system and the data 0 - data 1 outputs of a weigand device should be able to be read by 2 devices simultaneously. This means that both a PLC and a card access controller could read the same data stream and do whatever they wish with the info. There is a relatively minor timing issue with respect to the PLC/RTU digital inputs but that is solvable.
Now maybe there are better ways to do this, but after attempting to work with the access control community on 4 different projects going back nearly 10 years now I've given up. Frankly, I'm tired of being told that getting 5 of something I don't need makes up for the absence of the one item I do need.
It is important to be aware that some companies that claim to provide security devices, systems etc. etc. are actually selling monitoring
services. Such companies could be expected to skew their recommendation towards a solution that includes monitoring, thereby ensuring an ongoing revenue stream. It is a mistake to grant any security organization carte blanche. They may in fact be the experts but do not assume they are sharing their expertise.
<flame shield up>
Regards,
Bob Lockert
Please note:
None of these comments are directed towards any listmember. My opinions are based on experiences gained during development of ultimately successful projects as far back as 1988. Whether by intention or ignorance much of the advice I received was poor (my opinion). There is a very strong NIH (not invented here) mentality within the security/access control industry that presents a barrier to looking at anything from another perspective. When and if that industry stops perceiving legitimate interest from the automation world as a threat, great opportunities for both will arise.