G2S Building blocksMay 2010Green Valley Ranch - Las Vegas, NV Ales Gornjec, Hermes SoftLab

How to speed up the implementation of GSA

standards into new products

Slide 2

Agenda

Why GSA and G2S Approach to providing G2S solutions

to gaming machine vendors Why developing our own set of tools? Generic implementation versus

specific Integration challenges and solutions G2S host and S2S protocol building

blocks

Slide 3

Hermes SoftLab At a glance

HERMES SoftLab is an international provider of software engineering services & IT solutions

Established: 1990 Member of ComTrade Group since 2008 Headquarters: Ljubljana, Slovenia, EU Employees: 850+ Main markets:

gaming & storage industries telecommunication service providers financial institutions and the public sector

Quality certificates: ISO-9001/TickIT by BSI

Slide 4

The need for GSA and G2S?

For heavily regulated industries (like gambling) standards are very important

Single vendor environments are easier to build but – players require variety

Standards break vendor lock-in situations

First important steps already made Now certification program and GSA

university are also available

Slide 5

Complexity -GSA Protocol sizes and growth

started today (May 2010)protocol

classes pages classes pages exten-sions

BOB (2004) 16 300+ replaced by G2SG2S

(2006) 22 1240 23 1825 7S2S

(2004) 15 375 25 1130 2SAS* 14 190

*SAS included only for comparison of spec and functionalities covered

Slide 6

Hermes decision and goals? Previous experience with industry standards Knowledge transfer from other segments (XML, SOAP,

security) The need

Due to its complexity G2S requires significant investments (time, resources, knowledge)

Standards can’t be deployed successfully without wider vendor support

Vendors are asking themselves: to develop or to buy and integrate?

Implementation goals: Compatibility with vendor platforms (OS and language) Low resource consumption (ram and processing power) Easy integration Clear separation between protocol stack, integration and

platform to allow easy maintenance

Slide 7

Build or buy decision

Buy (+) Shorter time line Portable design Clear and stable API Proper support for

extensions Phased integration – low

risk from the start Maintenance covered Internal resources not

locked into long implementation project

Build

Full control No external dependencies Optimal implementation and

integration into the platform Possibility to reuse platform

features (persistence, logging, …)

Slide 8

Timeline projection

7/10 10/10 1/11

7/10 10/10 1/11

5/10 - 7/10Initial

investigation

7/10 - 8/10Core

classes integration

8/10 - 11/10Full integration

11/10 - 12/10Certification

and verification

6/10 - 6/10Feasibility workshop

7/10 - 9/10Know-how gathering

9/10 - 10/10Infrastructure

implementation10/10 - 6/11

G2S Class implementation

1/11 - 7/11integration and platform adjustements

4/11 7/11 10/11

7/11 - 10/11Certification

and verification10/10 - 6/11

G2S Class implementation

1/11 - 7/11integration and platform adjustements

Slide 9

Project – investigation & planning

High level management decision: we need G2S! Project team is formed to

study the protocol basics, investigate feasibility and prepare high level estimates takes 2 months, estimates 10 EM for basic implementation

Implementation team is formed to prepare high level architecture, designs and project plan takes 3 months, plan to finish in 8 months, discovered that

testing will be difficult and testing tools need to be developed or acquired

...

Slide 10

Project risks

When building own solution for G2S Resources

Engineers Know how

Product: Performance impact Interoperability Compliance

When buying and integrating Platform compatibility External dependencies Difficult to evaluate quality in advance

Slide 11

Platform requirements

Persistent Memory usage G2S with three main classes: ~6 kB raw data

(30kB with SQLite) G2S with all 23 classes: ~84 KB raw data (150kB

with SQLite) Minimal system requirements

Memory (RAM): 20 - 50 MB CPU consumption

Game-cycle simulation: about 20ms/cycle That is 50 games per second can be simulated

on a dual-core PC

Slide 12

Phased integration process

Main goal is to identify and mitigate risks as early as possible

Designed in a way to answer critical questions early: Is platform able to fulfill G2S requirements ? Integration feasibility (interfacing, process and threading

model, resource management...) ? Hardware: are CPU and memory resources sufficient ? NVRAM usage

Prof of concept phase gives basic working integration

Additional functionalities integration is dictated by customer and it’s priorities

Final phase helps with certifications and product deployment

Slide 13

Integration points and APIs

High level API is easier to integrate Covers 90% of class functionality (ordinary use) Can be combined with raw G2S API for special cases

Raw API is a direct mapping of G2S commands: Classes Commands Similar structures

Technical Services

Foundation (Platform Abstraction)

Application Services

G2S Classes

EGM Platform Adapter

EGM Platform

Persistency Adapter

Slide 14

Protocol versions and maintenance Currently 2 major G2S version branches (1.0.3 and

2.0.3) Only deployment of version 1.0.3 is publicly known

Several S2S versions released Several version deployed Several dialects Interoperability problems quite common

Maintenance cost can be considerable Upgrades to new versions Interoperability fixes Backward compatibility issues

Using a generic implementation is a good path to Reduce costs, Reduce interoperability issues and Shorten time to market

HSL host implementation provides multi-version support

Slide 15

Supporting G2S tools

Needed for stack development and testing Internal tools allow our own pace for supporting new

versions Possibility to develop different incarnations

Complex GUI for manual testing Console application for load/performance testing Scriptable client for test automation

Slide 16

Testing Unit testing

over 200 unit tests, cover all G2S commands System testing

test cases for each class ( 30-100 test cases per class) Automation

host simulator workflows Performance

latency and CPU usage measurement Stress testing

using command line EGM simulator EGM simulator instance with 200 game devices ~16MB

of RAM for 1000 instances, 16GB RAM.

Slide 17

Interoperability

Problems seen: optional commands, elements and attributes protocol versioning protocol backward compatibility is not 100% problems with extensions

How to improve: defensive approach to design and implementation design with multi-version in mind version and extension agnostic APIs design protocols need to improve in this area too

Slide 18

What is still ahead of us

Wider product support (both host and EGM side) Push seen from distributed gaming side (lotteries) Individual deployments with some operators Push in some jurisdictions

Initial interoperability issues resolved Still a lot of work needed

Improvements in products based on new features available Bigger push /need from operators will come after that

Slide 19

Questions?