Editor's Note: In the September 2009 Automatic Merchandiser, contributing editors Mike Kasavana and Glenn Butler authored an article on the National Automatic Merchandising Association's "open" technology standards. The article reviewed the progress of the association's technology task force for in developing standards that allow operators to use different providers' products in unified applications. The standards make it easier for operators to use cashless, remote monitoring and vending management software.
In the interest of further educating the vending community on the benefits of these technology standards, Kasavana and Butler prepared another article that examines many aspects of this technology, such as differences between DEX and MDB, different types of data, and why the data is reliable.
There are primarily two types of machine-level data that can be monitored in the vending industry: transactional data and operational data. Transactional data includes facts related to product selection, pricing, sales, and payments while operational data involves error messages, conditional alerts, and malfunction reporting.
Simply stated, vending operators desire technology capable of reliably passing these data from one software application to another, so that multiple applications can contribute to a comprehensive, networked solution. It is for this reason that there is growing interest in developing technology standards that enable data sharing among desperate component parts. Creating a platform for such integration is the work of the NAMA Vending Data Interchange (VDI) Task Force.
DEX and MDB
The NAMA Data Exchange (DEX) standard defines an ASCII data set that can be read from the vending machine using a handheld PC or telemeter (remote communication) device. This data does not include details on every vended product, but instead includes readings from a series of internal meters, that function similar to automobile odometers, designed to track deposited coins and bills, credit/debit card swipes, and column sales.
Vending Management Systems (VMS) and/or telemetry systems can detach (parse) this data and compare it to previous DEX readings to determine coin and bill acceptance, credit/debit card activity, and item sales between readings (interval analysis). DEX can also report a limited number of operational errors (although regrettably somewhat inconsistently) at the time the DEX data is read.
Since most telemetry or handheld PC systems read DEX at predetermined intervals, the DEX data becomes invaluable for cash accountability, pre-kitting (also termed pre-packing), and dynamic scheduling. Unfortunately, DEX is not a "push" protocol and therefore is incapable of providing "real time" notification for machines capable of generating alerts related to temperature variance, bill jams, column sellouts, or other conditions requiring corrective action.
The NAMA Multi-Drop Bus (MDB) protocol, developed more recently than DEX, is a "real time" interface that various peripherals use for communicating with the vending machine controller (VMC). MDB was primarily designed to allow bill validators, coin mechanisms, and card readers to interact with the VMC in such a way that telemetry system could actively monitor connected devices to detect problems (for example, functionality failures) that often occur in the field. In addition, some telemetry devices are capable of recording and time stamping all transactional activity at the machine - thereby providing a higher level of detail that cannot be obtained through DEX data readings.
Transactional Data
Transactional data at the machine-level includes purchase price, column location, time of transaction, and method of payment. Together this data can be used to create a transaction record. Fortunately, transactional data can be captured through an electronic control board installed within the vending machine.
Aggregating machine-level data enables remote review of transactions and inventory without having to have a physical presence at the machine. This data can be exported to a remote warehouse, central office, or product fulfillment center thereby extending the opportunity for more thorough, immediate, and frequent analysis as well as cash accountability, pre-kitting and dynamic scheduling.
As mentioned above, the MDB standard defines the bus interface used within the vending machine so that all machines supporting peripheral equipment communicate identically. MDB is designed to communicate real time transactional data, including method of payment, purchase price, column location, and time of transaction so that a transaction record is properly formulated.
Examples of Transactional Data
- Purchase activation (coins, bills, or cashless)
- Product selection (column or spiral)
- Product dispensing (certainty guarantee)
- Change tendering (credit management)
- Currency Report (coins to tubes and bills to recycler)
- Cashless/Electronic (reconciliation details)
Operational Data
Operational data is normally expressed in terms of events. Events are occurrences in the vending machine that can be used to monitor performance and/or to notify support staff of an interruption in service. The "exact change" light, for example, is auto-activated when the machine detects insufficient currency to deliver proper change.
Events can be in the form of error messages, conditional alerts, and malfunction reporting and can be relayed via remote data transmission to a mobile data device, cellular phone, or office PC. Events may be caused by functionality detection such as door openings or closings and temperature variances or through more sophisticated approaches requiring analytical detection. For example, calculating a sold out spiral can be derived through a conditional algorithm (beginning inventory minus sales equals ending inventory). For each event the date, time, duration, and cumulative number of events can be tracked.
Examples of Operational Data
- Bill Validator Functionality
- Cabinet Door Functionality
- Cashless System Functionality
- Coin Mechanism Functionality
- Communication System Functionality
- Dispensing System Functionality
- Refrigeration/Temperature Functionality
- Security Functionality
- Emergency Alerts Functionality
As referenced earlier, operational data can be reported through DEX readings using a handheld or telemetry device, but more robust data is derived through a telemeter since it can monitor MDB alerts as event occurs.
Event States
When an event is reported, it may be described as being in State 2 or State 3. Event states are normally differentiated as follows:
State 1 - no incidence - this state indicates a normal condition in that an event is not occurring. This is the normal state (i.e. nothing unusual)
State 2 - incidence and active - in this state an event has occurred and remains active (i.e. not repaired or self-correcting).
State 3 - incidence and inactive - this state is used to describe that an occurred but is inactive (i.e. repaired or self-corrected).
An event will only be included in a report if it is in State 2 or State 3 and is only reported if it occurred since the last reported transmission and remains active.
Alerts Survey
A recent survey conducted by the NAMA VDI Task Force indicates that the six most critical events related to sales and product integrity include items related to an inability to sell, violation of data integrity, and harmful environmental conditions. The following items were deemed the six most critical alerts:
1) Bill Validator Alert - non-functioning device
2) Coin Mechanism Alert - non-functioning device
3) Control Board Error/issue - failure in accountability
4) Temperature Alert - potentially hazardous condition
5) Remote Host Error/Issue - telemetry communication failure
6) DEX Transmission Alert - inability to transport machine-level DEX data
VDI Standards
The purpose of NAMA VDI standards is to establish transparent, non-proprietary interfaces that enable transportation of data among the main components of a vending system (e.g., vending machine, telemetry system, cashless payment system, specialty applications, and vending management software). The non-proprietary nature of NAMA VDI renders it an open standard. The essence of the NAMA VDI standards is to enable data movement through a messaging technique that ensures data integrity, regardless of whether it was pulled or pushed to one or more server(s). In other words, these standards render vending technology capable of linking together diverse software solutions, from different vending technology providers, into unified applications. This synergy may well represent a tipping point in the accelerated adoption of vending technologies as operator concerns related to supplier-dependence are significantly reduced through an open standard.
NAMA VDI relies on messaging standards to satisfy data interchange needs and is not concerned with the entity transmitting or receiving such messages. For example, a messaging standard governing the transmission of machine-level DEX data may originate from the vending machine, an advanced telemetry device, or the file server of another entity. NAMA VDI mandates that the message format conform to the technical specifications of the standard, regardless of the entity creating the message.
Data Concepts
There are at least three important data concepts in the movement of vending data: parsing, compression, and encryption.
Parsing - by definition, parsing involves separating a data block into smaller chunks, by following a set of rules, to enable easier interpretation, management, or transmission within a system.
Spreadsheet programs, for example, may parse data to fit the parameters of a desired cell. This could also apply to a vending management software application that requires only a fraction of the larger DEX data file for analysis. By purging the unneeded components, there are efficiencies in transportation and subsequent storage requirements.
Similarly, parsing can also be used to describe the search and conversion of a string of text being scanned to locate embedded format codes requiring modification. For example, some vending industry telemetry devices parse machine-level data before sending it over a cellular connection to reduce transmission costs. Unfortunately, if this occurs prior to data exchange between two candidate systems, then the data that may be required by the second application may have been parsed by the first recipient and thereby wiped out the necessary input. Fortunately, VDI standards require that an entire DEX file be sent.
Compression - Data compression is the process of encoding information using fewer units (bytes) than the size of the original file. By adhering to a specific encoding scheme, compressed data can be received and understood so long as the decoding method is known by the receiver. Compression is useful because it helps reduce the consumption of expensive resources, such as disk space or bandwidth used in a cellular connection (used by most vending telemetry providers). Since DEX data is an ASCII standard, it is highly compressible and
easy for telemetry systems to optimize.
Encryption - Encryption is the conversion of recognizable data (plaintext) into an alternate format for consumption by an unauthorized receiver (ciphertext). Decryption is the process of converting encrypted data back into its original form, so it can be understood. In order to recover the contents of an encrypted signal, a decryption key is used to reverse the encryption algorithm. Encryption and decryption is especially important in securing wireless communications. This is because wireless circuits are easier to intercept than are hard-wired networks.
It is for this reason that vending suppliers rely on encryption as a most effective means for achieving data security. It is important to note that even if an installed telemetry system does not have its own proprietary encryption for sending DEX data, the cellular protocols transmitting the data will automatically encrypt it.
Most telemetry systems rely on a combination of parsing, compression, and encryption to secure data and optimize bandwidth. VDI standards allow for compression but do not prescribe a specific methodology; it is likely that future VDI versions will define specific compression and encryption algorithms.
Data Sets
NAMA VDI is an innovative set of protocols designed to package vending machine-level data (e.g., DEX and MDB data, alerts data, cashless transaction data, etc.) into a message format that can be shared among diverse supplier systems to enable multiple software applications on the identical data set. The current VDI standard initially defines sending DEX data, but future standards will cover additional data like alerts and cashless processing.
For example, consider the situation in which a telemetry provider remotely polls DEX data from a vending machine (e.g., Company "X"). The telemetry provider transfers machine-level generated data file to its server (e.g. "X" Server). The server in turn authenticates the file with a NAMA VDI message wrapper and labels its contents for subsequent communication to any other provider's server in a vending operator's network (e.g., Company "Y" or Company "Z," etc.). Additionally, the vending operator may have machine installed cashless readers that collecting electronic payment data for transmission to cashless gateway for reconciliation. The polled data set would consist of both DEX data and electronic payment data and packaged into an aggregated data set. Movement of the data set to a host vending management software (VMS) system capable of processing DEX data could occur while simultaneously forwarded data to a cashless gateway system could be applied for processing and settlement. This multiple tasking one a single data set is indicative of the robust nature of VDI messaging.
The functionality of VDI standards is somewhat analogous to an email communication in that the file of machine captured data file forms the content of the message while VDI programming places a wrapper, akin to an email message envelope that enables distribution among any number of file servers (e.g. email recipients), regardless of supplier, provider, or manufacturer.
NAMA VDI standards, for example, allow for DEX data to be transmitted by a telemetry device or server in real time. This approach provides a platform for a vending operator's VMS to upload data nightly for use in pre-packaging (also referred to as pre-kitting) and/or dynamic scheduling algorithms that rely on variable replenishment strategies.
The goal of NAMA VDI standards is to ensure that a vending operator can confidently implement multiple, diverse vending technology solutions while utilizing operational data in existing application software (regardless of supplier). NAMA VDI specifications are open architecture technology standards designed to be extensible, uniform, stable, and manufacturer neutral.
VDI Benefits
The NAMA VDI standards afford several direct benefits to operators and bottlers, especially those embarking on technology decisions. When purchasing vending technology from a company adhering to NAMA VDI standards, the buyer can be assured that:
- Investment in VDI compliant technology will be compatible with major suppliers.
- There is no longer a need to rely on the success of a single supplier.
- Multiple telemetry devices will work with a variety of VMS providers.
- Selling or acquiring VDI compatible components simplifies continued operations
VDI Messaging
The NAMA VDI Task Force has identified the following seven elements as important to vending data messaging (interchangeable/exchangeable data files):
1) DEX data messaging - sent or requested captured DEX data file
2) Alert data messaging - may originate from the VMC, DEX, or MDB depending on telemetry provider.
3) Device Status -- device configuration and/or service request
4) Device Configuration - sent device configuration and/or status reporting
5) Security Authorization - defines cooperative agreement partners
6) Machine Message - reconfigures machine to EVA standards
7) Device Messaging - provides confirmation of download instructions
Summary
Major vending technology providers participating in NAMA VDI development have created a tipping point for accelerating the implementation of vending technology. Increased interest in addressing operator concerns has resulted in an unprecedented cooperation among vending technology suppliers to enable harmonic data interchange.
NAMA VDI ensures that operators can feel confident in technology investment, choice of suppliers, and be assured that hardware and software will work together now and in the future. There has never been a better or safer time to invest in cashless vending, remote machine monitoring, or VMS technology.
About the Authors
Michael Kasavana is the NAMA endowed professor in hospitality management at Michigan State University in East Lansing, Mich. He has been researching vending technology for several years and can be reached at [email protected].
Glenn Butler is former vice president and chief technology officer at Crane Merchandising Systems and is now president of CTO Services, LLC and can be reached at [email protected].
