Security/Access....(was wiegand protocol)

B

Thread Starter

Bob Lockert

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.
 
C

Curt Wuollet

Not an expert in this field, but it sounds a lot like a clock recovery setup would do this. Record data with a shift register. Mark on first transition, stop when this is at the end. Find the closest two transitions and using this as the pulse width, sample the center of the data windows to recover ones and zeroes. IF you have enough bits, great, else reject. What you do with with it after that, I have no idea, but that should be the capture part. Of course, this implies a sampling frequency much higher than the data rate. I don't know if this is realistic on a garden variety PLC but with a high speed card it might be worth a try. Might be easier to code on a coprocessor. Or a LinuxPLC with microsecond scan times. It would be great if you could just get the security folks to cooperate and send you the events.

Regards

cww
 
P

Peter Whalley

Hi Bob,

The other "open" communications standard that is getting some support in the security industry is LonTalk. A number of companies (eg Kaba, Motorola and Honeywell Europe) have released card readers that have a LonTalk interface which you may be able to connect to your PLC/RTU network. Try a Google search or e-mail me if you need further information.

The Toshiba Neuron chip has 4 Wiegand interface ports on it that could be used if you want to do some hardware hacking.

Regards

Peter Whalley
 
C

Carl Ramer, Engineer

Bob Lockert wrote: (Please excuse the nearly complete reposting)

> 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.
>
In some situations the political pressure is greater than the technological for keeping IA and ESS separated even though, as Geoff said earlier, there are companies offering full up solutions with security, facility automation, energy management and other features. Granted, they're generally best suited to a full retrofit, but there are vendors who provide less than full system integration as well.

<snip>
> 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.

Again, this is a standard entry for even residential grade security boxes, commonly called opening/closing reports. The "wish list"
is so critical to the generation of a requirements document that it should be made an industry standard. It boils down to the customer
wanting a system/subsystem with certain capabilities and letting vendors demonstrate their product's ability to satisfy those requirements. You may want to give DMP a look/call (http://dmpnet.com/products/twocolumn.cfm) to see what they may have that can fit your needs. Most of their line carries UL listing for Fire, Security or both.

> A possible solution> involves issuing p> roximity type secur> ity 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.

Now here's where I start to disconnect. In situation 1. the credential technology is irrelevant to my mind. The injured employee
needed the medical alert feature common to most security keypads, but likely wouldn't have been able to reach the keypad anyway. A more
typical "fix" for that scenario would be a wireless pendant or belt clip that could alert someone and get help rolling. We use Inovonics,
Inc. (http://www.inovonics.com/) products for this type of solution when adding such a feature to a "legacy" system (and do we EVER have
some museum piece legacy systems!). In situation 2. the credential technology again falls away since the proper access method was used, but the necessary transfer of information from the access control system to the SCADA system didn't occur. If SCADA indicated an "open" door, then some sensor was providing that data. The message didn't indicate correctly that the door was open and was not forced open. That should be a pretty easy fix.


> 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.

I recommend you talk to HID Corporation (http://www.hidcorp.com/) for a likely candidate reader device. They have all sorts and a
great staff as well.

> 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.
>
> 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.

Welcome to the fiefdom rich environment of electronic security. The industry is vaguely broken into three levels, residential, commercial and industrial. What you need is support from industrial level people and it sounds like you've been exposed to the other two.
Most industrial grade companies provide system solutions without any offer of monitoring service since they don't do monitoring and assume
that you'll have a resident capability for it somewhere. You can expect a sales pitch for a complete system, but you'll be able to get the
lower level of subsystem integration support with a little perseverance.

The above is a personal, professional posting and not an endorsement of any product or service by my company or the U.S. Government.


> > <<...OLE_Obj...>>
> Carl Ramer, Engineer
> Controls & Protective Systems Design
> Space Gateway Support, Inc.
> Kennedy Space Center, Florida
> (V) 321-867-1812
> (F) 321-867-1495
 
G
(No need for the flame shield Bob, I'm just trying to get a more thorough understanding of why your solution is more suitable to your application than mine. I'm not so pig headed as to believe my ideas are better than everyone elses but I have confidence (backed by 20 years experience) in what I do).

Working backwards through your mail, your experiences of the security industry have obviously left you with a bitter taste in the mouth, and rightly so if you are getting held to ransom by installer/maintainers and if you/your clients are ending up with systems that don't achieve the desired end result.

I have come into contact with many many of these situations over the years. I can't speak for the situation in the US but on this side of the Atlantic the industry has its problems.

Excessive competition and low margins at the low end of the market drives companies into the more lucrative sectors. Flimsy or non-existant national standards and regulations, no European-wide standards, very little specialist training or education etc all contribute to a very uneven quality of service from suppliers.

Although there are a number of well established, well run companies offering systems integration, it really is rare to find any one company with real strength across all the disciplines of the industry, and even more rare to find one with all of these and some knowledge of the control/automation industry.

(beginning to think I might need my own flame shield soon...)

Often the installer/maintainer is also a distributor or agent for some other manufacturer (it's the only way to get good enough prices to be able to compete in some sectors) and so they're going to favour their "own brand" rather than what's best for the job....sound familiar?

The main problems I've experienced over the years have been:

1. the security aspect of a project is left to last because no-body thinks it's very important, and as a result, the security system is "tacked on" at the end, the un-integrated system.

2. the client doesn't actually know what it is he wants to achieve, just this nebulous entity called "security". Thorough threat analysis is the first thing to do, followed by risk assesments for the various threats. Your incident with the lone worker would have showed up straight away if we'd done the threat analysis (I know, I would say that wouldn't I :) but actually lone worker situations are something that we have to cover under our health and safety at work regulations).

You pointed out yourself that the problem with the systems you had were that the customer didn't realise what they didn't do. That's part of not knowing thoroughly what you want.

You can't expect the poor customer to be an expert in security as well as everything else, you need to have mechanisms in the requirements definition process which extract the clues from the customer which go together to paint a picture of what it is he wants, even though he can't express it clearly himself.

Admitedly if you want this process done well, and you want a thorough and impartial system design specification producing you need to go to a consultant, and you'll have to pay him money...but if he's any good then his experience will be invaluable in pointing out threats you might not spot.

Anyway, back to your scenarios.

I'm not sure I understand specifically why either of the situations you descibe are the fault of the security systems you have installed. Maybe I'm missing something.

However it appears to me that the access control products you employ in these situations needs to have "presence in area" functionality. This is available on all the higher specification products, especially those aimed at corporate use.

The "presence in area" facility in our own product offers functions like:

1. anti-pass back (you must use a token in sequence ie in then out then in then out etc you cannot use the same token to get in twice consecutively. You can define multiple "in" and "out" readers and assign them to areas)
2. maximum/minumu users in area (you can define limits on the number of people in any specific area and generate alarms when the limits are passed. You can define people in terms of their tokens or their user groups). Obviously this function also keeps count of the people in an area, you can interrogate the system to find that out whenever you want.
3. users in area (we can set up a logical alarm to trigger when specific users or combinations of users are in an area. Again the users can be defined in terms of their specific token ID or their user group)
4. time in area (generates an alarm if the user is in an area for more than a specific length of time)

In addition to all this there are quite comprehensive time and date profiling and interlock facilities for readers, users and user groups that define when and how tokens can be used.

The alarms can be assigned to relay outputs for simple alarming or they can generate messages that can be re-directed to serial ports or over the network. Of course all alarm events are logged (you can individually enable/disable alarm logging and set other alarms based on alarm buffer fullness etc etc etc).

The sophistication generally isn't required but it does give us the flexibility to use the product in situations where other people's systems might need "kludging" ;)

The goals you are trying to achieve are not un-common, they are identical in many respects to the goals we are trying to achieve.

I still think you're re-inventing the wheel because it appears to me that the specific examples you've brought up could be tackled with an off the shelf product offering presence in area functionality.

Clearly you need to decide who's going to have responsibility for the remote communication side of things but passing a few messages into the SCADA system shouldn't be too burdensome.

This isn't NIH it's AIH (already invented here, so why do it again??).

I stated way back in the first mail I contributed to this thread that the control and security industries had a lot in common, I agree entirely that there is a lot of scope for cross fertilisation of ideas. Perhaps we are unusual because we sit in the middle dealing with both security and building management systems so that cross fertilisation is natural and already
happens here.

I'm afraid I'd have to say that I see far more snobbery with regard the control industry adopting work that has already been done by companies such as ours than vice versa.

At the end of the day we all have an obligation to do the best we can for our customers and different people will make their own minds up about what this means. Both the control industry and the security industry are obviously different where you are to how they are where I am and this must have a bearing on how you and I will fulfill our obligations.

I hope I will continue to have an open mind.

Regards

Geoff Moore
====================================
Straight Forward Solutions Ltd
Maynooth Road, Prosperous,
Naas, Co.Kildare, Ireland
Phone : +353 (0)45 892739
Fax : +353 (0)45 893880
Mobile : +353 (0)86 8179683
email : [email protected]
====================================
 
R

Ramer-1, Carl

Bob (Lockert) et. al.:

Please save the last posting from Geoff Moore and have it printed on parchment. Geoff's "State of the Industry" synopsis is as true for the U.S. as it is for our neighbors across the Atlantic. We have pseudo-standards in security, but nothing like the hard ones for Fire/Life Safety (NFPA 72 and the National Electrical Code are real standards). Underwriters Laboratory is a real standards agency, but in a different vein. If we ever get a national security standard, and a real licensing standard, the security industry will gain a much better professional posture. Such standards would also eliminate a fair amount of those low end companies that sell junk then disappear only to resurface under a new name with some other brand of junk.

Geoff identified several things that are wrong with the security industry and provided excellent advice on how to avoid problems. My only add to that would be when seeking a consultant, see if you can find one who comes from a technical background and has a CPP (Certified Protection Professional) license from ASIS. ASIS is the American Society for Industrial Security, but it's an international organization. They offer the CPP under similar rules to a PE in Florida and other states.

Carl Ramer, Engineer
Controls & Protective Systems Design
Space Gateway Support, Inc.
Kennedy Space Center, Florida
(V) 321-867-1812
(F) 321-867-1495
 
B
Geoff,

Fault, wasn't an issue at all. I'm not the customer in this case. I'm merely one of many contractors he uses to solve certain problems. My expertise is in controls and communications, not security. The existing security equipment or systems were supplied and installed by highly respected, qualified experts in their field. Knowing the customer, I can only believe that he got exactly what he wanted at the time from these experts.

An integral part of automation and control of any process involves safety. That includes the personal safety of all individuals that may come in contact with the facility at any time. Process control has legitimate responsibility for this aspect and I cannot see any professional in the business, abdicating that responsibility. A PLC simply reads real world
inputs, makes decisions and provides outputs. But as in all computers, garbage in - garbage out applies. All I really want is to read additional inputs, to make more/better decisions.

As an aside, the customer is an employer in the province of Alberta, Canada. The province has enacted new legislation covering safety issues relating to workers working 'alone'. In evaluating their compliance or lack of same, the
previously described incidents, came to the forefront.

From that perspective, the customer's initial objectives were related to safety issues. Adding the capability to log the time and identity of any occupant at any facility is not a major undertaking. The PLC's, the communications, the HMI and the paging system already exist. To all concerned, this was a 'controls' function that could be integrated by a contractor in that field. 99% of the needed components were alredy in place. Nothing was being duplicated. The intent was to PROTECT PEOPLE, specifically, employees. Ballpark estimates on costs were less than $1000.00 per site. (excluding wiring)

After September 11, security took on a new meaning. In that new environment, another need was identified, namely PROTECT the FACILITIES. I am the first to agree that the security and access control industry is more suited to dealing with these issues. I was not involved in this aspect at all, and really didn't have any interest in it. However, the projected costs of a solution as proposed by the security experts to PROTECT the FACILITIES was nearly 10 times what I had proposed to PROTECT PEOPLE. Granted, there was a much broader range of detection devices etc. but the bulk of the additional costs were related to duplicating an existing communications infrastructure.

The customer had difficulty justifying the cost of this duplication. Although the purpose of each project was different, the actual components
were more similar than dissimilar. Merging the two sets of requirements into one project with security and controls people collaborating seemed a logical step.

But that collaboration is not easily achieved. The dialog between local access control/security experts and myself is almost identical to the dialog you and I have exchanged. I've heard "duplication", "wasteful", "why would
you want to?" and similar comments over and over again. To you AIH means already invented here. In my situation it means already installed here. Continuing to assert that your definition is more significant that mine is part of the problem.

> However it appears to me that the access control products you employ in
> these situations needs to have "presence in area" functionality. This is
> available on all the higher specification products, especially those aimed
> at corporate use.
>
> The "presence in area" facility in our own product offers functions like:
>
> 1. anti-pass back (you must use a token in sequence ie in then out
then in
> then out etc you cannot use the same token to get in twice consecutively.
> You can define multiple "in" and "out" readers and assign them to areas)
> 2. maximum/minumu users in area (you can define limits on the number
of
> people in any specific area and generate alarms when the limits are
passed.
> You can define people in terms of their tokens or their user groups).
> Obviously this function also keeps count of the people in an area, you can
> interrogate the system to find that out whenever you want.
> 3. users in area (we can set up a logical alarm to trigger when
specific
> users or combinations of users are in an area. Again the users can be
> defined in terms of their specific token ID or their user group)
> 4. time in area (generates an alarm if the user is in an area for
more than
> a specific length of time)
>
> In addition to all this there are quite comprehensive time and date
> profiling and interlock facilities for readers, users and user groups that
> define when and how tokens can be used.
>
> The alarms can be assigned to relay outputs for simple alarming or they
can
> generate messages that can be re-directed to serial ports or over the
> network. Of course all alarm events are logged (you can individually
> enable/disable alarm logging and set other alarms based on alarm buffer
> fullness etc etc etc).

This is the classic case. I (actually the customer) defined a requirement; identify an occupant and display that on an existing HMI display at a central site. My proposal does this.

You are suggesting at least 4 features that have little value in this situation, you want to duplicate an alarm mechanism, and you have not put anything on the HMI displays.

Yes, you can use a laptop to drive a nail. But a hammer works too. :)

> Clearly you need to decide who's going to have responsibility for the
remote
> communication side of things but passing a few messages into the SCADA
> system shouldn't be too burdensome.

Well, that's where this thread really started. Serial ports on a PLC are often at a premium. Available digital inputs are usually not a problem. The weigand standard is very, very close to being ideal for interfacing security type devices to a PLC using 2 digital inputs. A little bit of "kludging" is needed that I haven't been able to justify in the past since only a few readers were involved. Hence I used RS232 devices. But for this project, 60 or more devices are needed.

> This isn't NIH it's AIH (already invented here, so why do it again??).


Here's what I'd like to have:

A device that accepts a 26 bit weigand format data stream (on data 0 and data 1), then propagates the data stream again on another data 0 and data 1 pair at a selectable (slower) rate. Basically, a FIFO buffer.

As an option the device could append a station identifier byte to the stream. I'm not sure about this because readers themselves may have this capability as an option.

If it's already invented, get me a shopping cart.

I welcome all replies. Those of a purely commercial nature can be sent directly to me, offlist.

Regards,

Bob Lockert
 
What you are looking for would be a Concept 3000/4000 security/access system. It also has frontend software so as to track personal coming and going, what areas they have accessed, what doors they have opened and man down/dead man
features. Very simple to use, or try Tecom access system (not installer friendly) or Radionics control panels. Just my 2 cents.
 
Top