design and implementation of casino slot machine accounting protocol...
TRANSCRIPT
Design and Implementation of Casino Slot Machine
Accounting Protocol Engine
Sangmin Kim and Heejune Ahn*,
1 Dept. Of Electrical and Information Engineering, SeoulTech,
232 Gongneung-ro, Nowongu, Seoul, 137-743, Rep. of Korea
Abstract. IGT’s SAS (Slot Accounting System) protocol is the de facto casino
communications standards designed to automate slot machine meter reporting
and event logging, player tracking, bonusing, ticketing and cashless gaming. By
presenting the design experience of SAS protocol, this paper unveils the
technical details of SAS 6.0 standards, which is only exposed to the limited
industry circle. The engine is integrated with engine test UI and tested and
verified against the IGT EGM test software.
Keywords: Slot Accounting System, communication protocol implementation,
Casino Industry, and Slot Machine.
1 Introduction
The casino industry keeps growing it size every years steadily, reaching to 159 billion
dollars in 2014 world market at the increase rate of 9.3%. Among the casino games,
the slot machine plays a key role to recruiting casual non-serious customer [1].
IGT’s SAS (Slot Accounting System) protocol is the de facto casino
communications standards designed to automate slot machine meter reporting and
event logging, player tracking, bonusing, ticketing and cashless gaming. Due to the
unique requirement, poorly written specification, and the lack of experts, field and
development engineers encounter several difficulties in working and developing
systems. This paper presents the design example of SAS protocol engine, so that the
reader can understand the key service and technical components and mitigate the
development process.
2 SAS Protocol Standards [2]
The Fig. 1 illustrates the network topology for slot machine accounting in today’s
casino floor. The EGM and SMIB communicate each other in SAS protocol standards,
whereas communication between the SMIB and host is not standardized, which
interoperability and standards issue is resolved by new standards, G2S (Game to
Advanced Science and Technology Letters Vol.54 (Games and Graphics 2014), pp.65-68
http://dx.doi.org/10.14257/astl.2014.54.17
ISSN: 2287-1233 ASTL Copyright © 2014 SERSC
System) protocol. SMIB also provides touch screen and card readers for AFT and
player tracking service.
Fig. 1. The System architecture of SAS Protocol: SAS protocol is used for communication
between EGM and SMIB.
SAS protocol consists of 3 layers of physical layer, link layer, and application layer.
The physical layer leverages RS-232 at 9.2kbps of 1 start bit, 8 data bits, and
1wakeup bit and 1 stop bit. The wakeup bit is used for signaling the frame start byte
and needs special care in implementation (described later). Master-slave polling
mechanism is used for the medium access control similar to USB and traditional
remote terminal system. Each EGM is assigned a link address of 1 to 127. ‘0’ is used
for broadcasting. The polling rate ranges from 200ms to 5s but can be reduced to
40ms when EGM support RTE (real time event) mode.
SMIB uses two different types of polls, GP (general poll) and LP (long poll). GP is
one byte EGM address with wakeup bit set, and polls events generated in the
receiving EGM system. The receiving EGM should respond with 1 byte event code,
which is called ‘exception’ in the specification. The exceptions include non-priority
exceptions such as no event, game start, game end, system tilt, and priority exceptions
such as handpay condition, ticket out, ticket in, and fund-transfer request. LP is used
for SMIB to send command to EGMs and classified into R(read)-type, S(set)-type,
M(multi-game)-type, and G (global)-type. LP starts with 1 byte command value with
wakeup bit set, and the lengths of LP are fixed or variable depending on the command.
All LP except R-type contains CRC-16 (cyclic redundancy check) for bit error
detection. The response frame uses the similar format but with wakeup bit off. SMIB
use implied ACK mechanism for confirming the receipt.
Table 1. SAS Protocol Application Functions.
SAS Application Functions Description
ROM signature request Jurisdiction for integrity of system memory
Metric Performance metrics for wagered game count, win
amount, Progressive broadcast Progressive jackpot win amount for groups
Tournament operation Tournament game start and end
RTE (real time event) Event report more responsively Bonus Controller Legacy bonus provisioning
Jackpot hand-pay Handpay for large amount win or credit cancel TITO(Ticket in/out) Ticket to/from credit
Multi-denomination Multi-denom configurable system
AFT Automatic fund transfer Component Authentication Application component’s jurisdiction
Advanced Science and Technology Letters Vol.54 (Games and Graphics 2014)
66 Copyright © 2014 SERSC
3 SAS Engine Design
The commercial success of engine software depends on not only the performance and
reliability but also the flexibility and easiness for integration. For this purpose, we
benchmarked the commercial engine’s API interfaces (Digital dynamic [3]). Fig. 2
illustrates the interface and API for the engine with an overall architecture of the
engine.
3.1 Engine Architecture
For thread architecture, a single-thread, event based architecture is used for simplicity
for handling multithreading risks. One receiving thread waits for byte or event
arrivals; collects a frame data; call the handler function for specific command. Each
handler is defined for specific commands. Once called, it decodes the message using
SAS message library, generated response message for the commands based on system
state, and return the encoded message using SAS message library.
Serial Layer
Link Layer (Thread)
Application
Reader-StatCheck
(thread R)
Writer
(thread)
Pro
tocol Ife
rface
response/event
Message L
ib
LP/GP RX
wakeup/byte
AF
T
GP handler
(Event
Queue)
timers
TIT
O
Mete
rs
Syste
m
Slot machine Data
GP/LP_arr/ack
LP dispatcher
Config Events
Game
API
Callback
SAS EGM Engine Game
Meters
SMIB
RS-232C
Fig. 2. SAS Engine Architecture.
Message En/Decoding library is built for binary message to structured (precisely
C++ class) mapping. Because normal PC hardware and OS does not support 9bit
communication, which is used in SAS communication mechanism, the parity bit is
used for the wakeup bit. Whereas normally the parity bit is set or reset based on the
odd/even/space/mark parity setting, the sender has to toggle parity mode between
mark mode if first byte and space mode otherwise. The receiver should set up with
space parity and get the wakeup bit set using error detection. To handle both event 1
byte normal and RTE mode, multi-bytes EGM, RTE mode format is used for event
queue and transmitted depending on the system mode.
Advanced Science and Technology Letters Vol.54 (Games and Graphics 2014)
Copyright © 2014 SERSC 67
3.2 Application Message Handling
Due to the limit of space, only metering and handpay scenario are describe in the
paper. For Metering, over a hundred of meter codes are defined for accounting and
gaming performance analysis (per-machine meters or per-game meters). The game ID
0 is used for reading the machine level meters and should be summed up for all
corresponding per-game meters.
Handpay condition occurs when the win level or credit cancel amount is too high
by jurisdiction. Main game software initiates the handpay transaction. The SAS
engine should send 0x51 exception to the host. Typical resolution method is paid in a
check by an attendant (0x3E exception) or ticket-out after validation of an attendant
(0x3D exception). The host (SMIB) will query the handpay info by the ‘Send
Handpay Info’ LP (0x1B), which is usually responded by Pending status response.
When the handpay reset is done by an attendant, the SAS engine should sends the
‘Handpay Reset’ exception (0x52). Finally the host query with ‘Send Enhanced
Validation’ LP (0x4D) and gets result information of the handpay. The engine should
update the information in the persistent storage. The persistent storage management is
the role of game part.
4 Evaluation and Conclusion
The engine’s functional and performance verification is done with IGT EGM test tool
and our SMIB implementation, except bonus, progressive, RTE, and multi-denom
features (due to the limit of understanding of service scenarios). The performance is
tested sending upto 40 ms, and the CPU utilization is less than 5 % in the typical slot
machine hardware environments. We are developing SAS to G2S protocol [4, 5]
converter so that existing EGMs can be used together with new standard based host
systems in the transition periods, which is expected at least 10 to 15 years,
considering the normal lifetime of EGMs in the field.
Acknowledgments. This study was supported by the Korea Healthcare
Technology R&D Project, Ministry of Health and Welfare, Republic of Korea
(A120157) and Technology Development Support Project, SMBA (Small and
Medium Business Administration), Republic of Korea (S2100260).
References
1. Kilby, J., Fox, J., Lucas, A. F.: Casino Operations Management 2nd Ed. John Wiley & Sons
Inc. (2005)
2. IGT: Slot Accounting System version 6.01 (2003)
3. Digital Dyamics SAS Engine, online: http://www.digdyn.com/sas-engine.html (2014)
4. GSA: G2S Message Protocol v2.0.3, Game to System (2009)
5. GSA: GSA SAS 6.02 Interoperability Requirements: Rev. B (2006)
Advanced Science and Technology Letters Vol.54 (Games and Graphics 2014)
68 Copyright © 2014 SERSC