Vending Machines for Schools
POS Interface Architecture
for the
Reimbursable School Meals Program
Information technology landscape
iGuard™ LM-SM-5000:
configured as the Master
iGuard device
Application Programs Running on the
In-School Food Service Server
<DAILY_STUDENT_ADMIN_UPDATE (T.B.D.)> 1
<VENDING_REQUEST>
All iGuard Devices Are
Connected to One
Another and the API via
Router to the In-School
LAN
Vending
Machine
Vending
Machine
6 Vending
Machine
6 Vending
Machine
6 Vending
Machine
6 Vending
Machine
6 Vending
Machine
6
7
Multiple iGuard™ LM520-FSCs:
• Configured as Slave devices
• Communicate Directly with SuperMaster™ to
Retrieve Student Fingerprint Templates for PINs Not
Resident on the Individual Device
• Communicate Directly with iGuard™ API for POS
Message Processing
(1)
iGuard – POS Interface Configuration, Version 6
RSMP Equip Config Overview_V6.ppt
<VENDING_RESPONSE>
iGuard API
(using the
API Server
Module & its
Windows
Messaging
Capabilities)
In-School Student
Information System
Server
• Connected to other
In-School
Applications via
Router& the Inschool LAN
• Source of Student
Admin Update
Data
POS System
Middleware
POS System
<VENDING_REQUEST>
<VENDING_RESPONSE>
(i.e. – YES or NO, plus Any
Essential Messages to Be
Displayed on The iGuard LCD)
In-School Food
Service Server
Daily_Student_Admin_Update will likely be accomplished through a download from the POS System, since it already
receives a daily update from the Student Information System Server; actual iGuard update process is still to be defined.
2
Interface communications sequence
•
Interface Communication Start
Student enters PIN and presents fingerprint to iGuard scanner mounted on
vending machine
– iGuard authenticates identity of student using fingerprint template
– iGuard retrieves student fingerprint template from SuperMaster™ for any PIN
entered at the machine that is not found in the local device
•
iGuard sends a data structure to iGuard API via LAN and waits for response
(i.e. – vending decision); agreed data structure will contain:
– PIN of authenticated student
• Exact format of PIN to be specified for each POS System
• Will likely be the normal POS PIN now used by student in a check-out line
– Any other data elements deemed essential & mandatory by the project team
stakeholders
iGuard – POS Interface Configuration, Version 6
RSMP Equip Config Overview_V6.ppt
3
Interface communications sequence (continued)
•
•
•
iGuard API receives iGuard data structure and sends to POS Middleware a
<VEND_REQUEST> message containing {STUDENT_PIN} and waits for
response
POS Middleware receives <VEND_REQUEST> and relays to POS for
processing
POS System
– Receives and processes <VEND_REQUEST> message & processes request from
student for reimbursable meal
– Generates <VEND_RESPONSE> message (in an agreed data structure)
• Must contain {VEND_SALE} [This is a YES or NO decision on the sale of a
reimbursable meal to the awaiting student] [Mandatory]
• May contain a {VEND_ RESPONSE_MSG} string constant for display in iGuard LCD to
the awaiting student [Optional]
– Sends <VEND_RESPONSE> message to POS Middleware
•
POS Middleware receives <VEND_RESPONSE> message and relays to
iGuard API for processing
iGuard – POS Interface Configuration, Version 6
RSMP Equip Config Overview_V6.ppt
4
Interface communications sequence (continued)
•
•
iGuard API receives <VEND_RESPONSE> from POS Middleware and relays
to the awaiting iGuard
The awaiting iGuard receives the incoming <VEND_RESPONSE> message
and
– Interprets the {VEND_SALE} response & generates vending action command to
the appropriate vending machine circuitry
– Displays any {VEND_ RESPONSE_MSG} message in iGuard LCD
– Generates a <VEND_RESULT> message containing {MEAL_SERVED} and sends
to the POS Middleware for relay to POS System
• {MEAL_SERVED} confirms delivery/non-delivery of a reimbursable meal to the
awaiting student [MANDATORY]
• {NOT_SERVED_REASON_CODE} can be included if desired [OPTIONAL]
• <VEND_RESULT> completes the audit trail for food service accounting
Interface Communication Complete
iGuard – POS Interface Configuration, Version 6
RSMP Equip Config Overview_V6.ppt
5
Data element transfers required of the interface
iGuard API-to-POS
1.
<VEND_REQUEST> {STUDENT_PIN}
POS-to-iGuard API
2.
<VEND_RESPONSE> {VEND_SALE}
including optional {VEND_ RESPONSE_MSG}
when desired
3.
<VEND_RESULT> {MEAL_SERVED}
including an optional
{NOT_SERVED_REASON_CODE} when
desired
What is the simplest way to transfer these three messages between systems so
that communications are independent of the specific POS System that
controls food service operations in the school?
• We think it is through the use of the iGuard API and its Windows
Messaging protocol…, but
• Is this the best overall technical solution?
iGuard – POS Interface Configuration, Version 6
RSMP Equip Config Overview_V6.ppt
6
Data element dictionary
Data Element
Definition & Example
1. {STUDENT_ID}
Normal 4 or 5 digit POS PIN Code used by student at cafeteria line
check-out register [e.g. – 4552]
2. {VEND_SALE}
A one-bit switch that authorizes or denies sale of a reimbursable
school meal to the awaiting student [e.g. – 1 = YES; 0 = NO]
3. {VEND_ RESPONSE_MSG}
[Optional]
A string constant that can accompany {VEND_SALE} to convey a
message to the awaiting student [e.g. – if VEND_SALE = 0, then
{VEND_RESPONSE_MSG=“Declined, Please See Cashier”
4. {MEAL_SERVED}
A one-bit switch that confirms:
• Delivery of a reimbursable meal to the awaiting student, or
• Non-delivery of a reimbursable meal to the awaiting student
[e.g. – 1 = DELIVERED; 0 = NOT DELIVERED]
5. {NOT_SRVD_RSN_CODE}
[Optional]
A string constant accompanying {MEAL_SERVED} that conveys to
the POS a reason why the meal was not delivered. [e.g. – if
VEND_SALE = 0, then {NOT_SRVD_RSN_CODE = 2} if reason
for non-delivery was “Vending Machine Malfunction”. Acceptable
values and definitions will be predefined.
iGuard – POS Interface Configuration, Version 6
RSMP Equip Config Overview_V6.ppt
7
Using iGuard API as a common vending interface
• Reasons to use the API (Pro’s)
– It is already developed, tested & deployed with other interfaced
applications today
– It uses standard Microsoft Windows messaging protocol to communicate
– Through this API, we can provide any data structure needed by the
interfaced POS application
– This API could serve as the standard interface point for use in
communications with any POS System [using a very small set of standard
data elements]
• Reasons not to use the API (Con’s)
– It makes the interface OS-dependent (i.e. – Microsoft Windows)
– It does not contain as many robust features as would a standard TCP/IP
Client-Server application interface1 for managing
• Dropped communications and the resulting missed messages
• Reprocessing open / unresolved messages until they are satisfactorily
processed
1 As
iGuard – POS Interface Configuration, Version 6
RSMP Equip Config Overview_V6.ppt
outlined in POS – iGuard™ Interface Specification, Version 2
8