Sas Engine

Advanced Science and Technology Letters Vol.54 (Games and Graphics 2014), pp.65-68 http://dx.doi.org/10.14257/astl.2014.54.17

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 *[email protected]

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

ISSN: 2287-1233 ASTL Copyright © 2014 SERSC

Advanced Science and Technology Letters Vol.54 (Games and Graphics 2014)

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 ROM signature request Metric Progressive broadcast Tournament operation RTE (real time event) Bonus Controller Jackpot hand-pay TITO(Ticket in/out) Multi-denomination AFT Component Authentication

66

Description Jurisdiction for integrity of system memory Performance metrics for wagered game count, win amount, Progressive jackpot win amount for groups Tournament game start and end Event report more responsively Legacy bonus provisioning Handpay for large amount win or credit cancel Ticket to/from credit Multi-denom configurable system Automatic fund transfer Application component’s jurisdiction

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

Application Slot machine Data Meters

Config

API Callback

P r o t o c o l I f e r f a c e

M e s s a g e L i b

M e t e r s

T I T O

A F T

Events

S y s t e m

timers

GP handler (Event Queue)

LP dispatcher

Link Layer (Thread) GP/LP_arr/ack LP/GP RX

response/event

wakeup/byte Reader-StatCheck (thread R)

Writer (thread)

Serial Layer Game

SAS EGM Engine

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.


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 t ool 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 2 nd 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)

68


Sas Engine

Recommend Documents