Draft Agenda SIA Standards Access Point Controller SC by ybg79195

VIEWS: 5 PAGES: 3

									                   SIA Standards
                   Access Point Controller Subcommittee
                   Teleconference Meeting
                   Tuesday, February 20th 2007
                   10:30 a.m. – 2:00 p.m. (EST)




                                                                  DRAFT AGENDA


1. Call to Order ............................................................................................................Mr. DeVoe

2. Roll Call . ........... . ...................................................................................................Ms. Vago

3. SIA Antitrust Policy ..................................................................................................Mr. DeVoe

4. Approval of the Draft Agenda...................................................................................Mr. DeVoe

5. Approval of the Draft Minutes of the Joint 2007/01/16-18 Meeting.........................Mr. DeVoe

6. Chairman’s Remarks ..............................................................................................Mr. DeVoe

7. Access Point Controller Data Model ........................................................................Mr. DeVoe

[The 2000212 Version of the APC Data Model has been posted to the SC website at:
http://www.siaonline.org/response.asp?c=stds_sc_cr00&r=1024]

     a.    Review of user feedback concepts
     b.    Review of field device types concepts
     c.    I/O Point discussion and decision

8. Open Discussion ...................................................................................................All

9. Next Meeting                 ...................................................................................................Mr. DeVoe

10. Adjournment                 ...................................................................................................Mr. DeVoe
Bill DeVoe / HID
Hello all,

I’ve been working through some of the issues that were raised at the last subcommittee meeting and have
been finding it difficult to answer some of the concerns. The concerns surround the credential readers and how
those devices will be accessed/commanded/provisioned from an external provisioning system.

If I recall the conversation correctly, one proposed solution was to provide numerous specializations of these
field devices and provide the ability to provision or command the individual “lines” (inputs/outputs) associated
with that device. For example, the specialization might provide exposure of the ‘red LED’ and the ‘green LED”
lines. While this is a much reduced form of the discussion, I believe it retains the gist of it. If not, please let me
know! :)

Another solution proposed was to abstract the actual implementation from the field device and provide “plug-
ins” that would be manufacturer defined. This expanded on the concept in the model of a “user feedback
device” that could be commanded to show certain states.

As I’ve considered the various mutations of these two basic concepts, I am left with two things. First, the idea
of a “plug-in” is not truly feasible as I had originally intended. Far too many concerns are raised about it that I
feel it’s untenable. There are many different platforms available and at the level I considered, manufacturers
providing an extension seems horribly unwieldy. Second, the concept where the underlying technology is
exposed (as in the first solution) also seems equally untenable. Given the variety of mechanisms by which
certain behavior is elicited on various devices, this seems too difficult to model at the level we’re currently
exploring.

As a result, I see that there is an extension to the originally-documented model of user feedback states that I
think we should explore more in-depth during the web conference. The model currently provides for a
Consumer to command a user feedback device (which could be LEDs, a video system or LCD screen) to
display a certain state. While the states would be defined by the manufacturers of those devices, I propose that
we extend the model to allow for a re-mapping of those states. For example, a provisioner could say: “I know
your default ‘ready’ state is ‘red LED illuminated’. I want to change that state to be your default ‘grant’ state,
which is ‘green LED illuminated’.” This seems to provide a great deal of flexibility within the model to allow
customization (something that integrators have expressed the need to maintain) while not exposing specific
implementations based upon device model (e.g., an iClass R10 reader). It also avoids the myriad ways of
addressing those devices (RS485, RS232, Wiegand, I/O points, etc) and the inherent need to provide
information about the addressing. Therefore, I will plan on including in the model this new capability. I would
appreciate it if you can review this portion explicitly. This is documented as the
apcUDUserFeedbackStateMapping message and associated special structures and data element definitions.

Also, to expand upon the concept I introduced last meeting about connecting any type of device that reports
event information as being able to fulfill a role within an Access Point, I will document that point more fully and
provide some examples for us to discuss. Additional interfaces will be added to support this and I will call it out
specifically.

Finally, I would like to call out the way that I've modeled readers - each "type" of reader is a separate device
type. This means that a single bioClass reader (bio, kepad, LCD screen and card reader) would be modeled as
4 separate devices - a user feedback device (LCD), a keypad reader, a biometric reader and a card reader.
The other option is to model them as composite devices - one device with 4 "subtypes". I believe that breaking
out the devices as distinct from one another better models an abstraction of the device. This provides the
ability to address each type independently - e.g., each could have an enable schedule independent of the
others. This abstraction of course is most evident when there are truly 4 separate physical devices. A potential
downside is that a basic Prox reader (card reader with LEDs) would appear as two devices - a user feedback
device and a card reader. I would appreciate any feedback you have about the concept.
One big change you will notice is that some of the items are no longer generalized from OSIPS elements. This
is because I removed an old version of the elements and have been working to update the links, but I wanted
to get this out now for comment. So it's intentional, but only because of the upgrade that's occurring. This will
be corrected shortly, but I wanted to call it out so that it wasn't overly surprising when you looked at the model.
:)

I would still like this to be a very involved subcommittee with a model built on consensus. If any of you see
alternative means by which the behaviors described above can be accomplished by other mechanism, please,
by all means, bring those suggestions to the web conference, send them via email or call me directly to
discuss it. I’m certain there are some who have considered this problem from different points of view and I
want to make sure that we have ample opportunity to discuss those points of view before deciding on a final
implementation. We all have very different experiences in this space and, admittedly, I am still something of
“young pup” when compared to some of you. :) I am committed to making this a strong model and insuring that
we meet many needs within the single data model.

Thank you all for your continued participation. I look forward to our web conference on the 20th and the
opportunity to vet these ideas.

								
To top