As the vending industry faces a customer base comprised of smaller accounts, vending operators have no choice but to improve their operating efficiencies to become more profitable. One tool that will allow them to do this is the innovative technology that new vending machines are offering.
There is a handful of different technologies in today’s vending machines, each identified by an acronym. Regular readers of Automatic Merchandiser have come across acronyms such as DEX, MDB and possibly DTS. This article will attempt to explain these technologies and how they work together.
Generic technology emerges
A multi-drop bus, MDB, is an internal communication protocol designed to ensure that coin mechs, bill validators and cashless payment devices can be properly interfaced to a vending machine controller without regard to proprietary manufacturing. The key benefit MDB brought is the fact that it is a generic technology.
MDB has often been compared to the plug-and-play standards common to generic computer component interfacing. One consistent standard covers bills, coins and credit/debit cards. It replaced prior practices built on product-specific design connectivity. Each device had its own interface with separate and incompatible harnesses.
MDB represents a movement toward open system architecture enabling a variety of peripheral devices to automatically become functional.
DEX: Another open architecture
The Data EXchange standard, DEX, is another open architecture. DEX is the set of data protocols that enable a vending operator’s software to communicate with the machine’s data collection.
DEX allows for the capture of product inventory, product movement and cash auditing data. DEX data is designed to assist operators with machine replenishment strategies,
product mix rotations, and validation of cash collected. The immediate benefit that DEX provides a vending operator
is improved cash accountability.
Expanded cash accountability enables comprehensive control by product, cash meter, and cash collection. In order to optimize profit margins while controlling operating expenses, DEX data can play an important role in productivity and profitability.
Data transfer standards
Since standards existed that controlled the collection and storage of data, a Data Transfer Standard, DTS, was
devised so that the data could be
exported from the machine in a decipherable electronic format.
Once the information is transmitted, it can be entered into a vending management software system and used to determine product replenishments and warehouse requirements to refill each machine. This is known as pre-kitting. Often, the DTS protocol is considered an integral part of the DEX standard.
Let’s consider how MDB, DEX and DTS work together.
MDB supports peripheral devices
MDB is also known as the multi-drop bus/internal communication protocol (MDB/ICP) and is maintained jointly by the National Automatic Merchandising Association (NAMA) and the European Vending Association (EVA). One standard operates globally.
The MDB standard defines the serial bus interface used in electronically controlled vending machines so that all machines supporting peripheral equipment communicate identically. MDB is designed to capture transactional data, including method of payment, purchase price and change paid. When combined with time of transaction and possibly column information, it can formulate a transaction record.
While the MDB bus is designed to support up to 32 peripheral devices simultaneously, there typically are three devices connected to the MDB bus:
1) coin mech (acceptor/authenticator/storage/change dispensing), 2) bill validator (acceptor/authenticator/storage), and 3) cashless payment device.
The master communication channel
A vending machine has one master communication channel, the vending machine controller (VMC). The role of the VMC is to control the peripheral equipment (coin mech, bill validator, cashless payment device, etc.) interfaced with the electronic circuitry of the machine so component parts operate properly.
The MDB standard allows many devices to connect to the same interface point, yet still function independently of other interfaced devices. Since each interfaced device has its own unique address on the bus, the VMC can issue a poll to the device that addresses and then waits for a reply to determine which device, or devices, is active and communicating.
MDB: the ‘brain’ in the coin mech
For example, MDB enables the VMC to determine which coins the coin mechanism accepted; which bills were stored by the bill validator; and how much credit is available through a cashless payment device.
It is a way for the VMC to direct the coin mech to pay out correct change or how much credit should be returned to the cashless media.
There are several peripheral devices beyond the coin mech, bill validator and cashless device, with which the VMC can communicate via MDB interfacing. The MDB standard allows a vending operator to select peripheral devices based on reliability, performance, features and price, as opposed to proprietary connectivity.
MDB relationships
Since MDB establishes the manner by which each component device communicates with the VMC, the connection to each device has to be standardized. As part of the standard, each peripheral device has two MDB connectors to allow it to both connect to the MDB serial bus (one connector) and provide connectivity for an additional device (second connector).
This design reduces the number of primary connectors that attach directly to the bus as well as providing interfacing of additional devices. This is similar to the plug-and-play connectivity feature available through USB hubs in desktop computing.
When a new device adheres to the standard, the hardware and connectors to add the device are already in the machine. In many cases, a simple VMC software update allows the device to be supported in the machine.
In the past, there were two categories of interfaces: electromechanical and serial. Electromechanical vending machines typically handled only single-/4-/10-price vending. Electromechanical interfaces were inefficient and potentially hazardous as they used high voltage to directly control vending machine parts. Electromechanical interfaces have been replaced by serial interfaces capable of supporting multiple pricing (i.e., each column can be assigned its own price).
MDB, the most popular of the serial interfaces (see sidebar on page 20), operates as a master-slave configuration. In the MDB master-slave relationship, linked peripherals are treated as slave units while the VMC is the master unit.
Master-slave configuration
The master unit continuously polls, surveys or scans the slave devices (units are polled every 25 to 200 milliseconds). Once detected, peripheral activity is deciphered and the master responds with an acknowledgement (positive or negative) and/or a request for specific data based on current activity (e.g., command to retransmit data).
If a peripheral does not respond to the master’s request within a predefined time, the master will repeat the request, send a different command, or assume the peripheral is nonresponsive and issue a reset command.
The independent serial bus interferences are dropped in MDB since each peripheral only responds to the master upon being polled. Since there is only one master, and the master initiates all communication, bus conflicts or crashes are avoided.
Self-correcting actions
In the case where a peripheral does not respond, or is not on the bus, the VMC regains control of the bus and can send additional commands. The peripherals are programmed to recognize commands sent by the master, thereby allowing for disabling of individual peripherals for various reasons (e.g., interruption of a current transaction or technique).
Similarly, self-correcting actions required for peripheral devices can be accomplished by using validation checks or through issuance of a retransmit command.
To ensure compatibility with the VMC, the functionality of each peripheral device is assigned a “level” designation within the MDB standard. The “level” describes the corresponding capabilities of master and slave units. For each peripheral device, there is a prescribed set of functionality corresponding to each level designation.
Levels of device functionality are established when a peripheral has added or extended commands and responses to its predecessor. The VMC must initially determine the level of a peripheral before determining which commands it can issue to that device.
The current level of conformity for MDB devices is referred to as Version 3 or Level 3. Level 3 devices, introduced beginning March 2003, incorporate monitoring features necessary for efficient completion of cashless transactions.
Consider the following coin mechanism example.
Level 2 versus Level 3 changers
There currently are two levels of support defined for a coin mechanism peripheral interface: Level 2 and Level 3. The level of the coin mechanism device is sent to the VMC in the response to a request for status.
For Level 2 coin changers, the VMC operation consists of monitoring inputs from the coin mechanism, accumulating credit, issuing a coin acceptance disable command when appropriate, and issuing appropriate payout commands based on VMC decision rules.
For Level 3 coin changers, VMC operation is the same as defined for Level 2, with the addition of an expansion command. The expansion command initiates a request to the coin mechanism to transmit its manufacturer code, serial number, model number, software version and optional features.
Based on this information, the VMC will determine the appropriate operating mode to enable the coin mechanism features to be applied.
This process allows the VMC to accommodate existing and extended capabilities that, in turn, provide more detail relative to specific coinage in and changer payout activity, thereby allowing coin credits to be decremented as coins are dispersed.
MDB ensures device functionality
Effectively, the VMC and peripheral units need to support the highest common level while maintaining backward integration of lower level device compatibility. It is for this reason that the software embedded in the peripheral devices and the software of the VMC must be compatible. The purpose of MDB is to ensure that the necessary functionality of any device on the bus (i.e., interfaced equipment) is consistent with the capabilities of the VMC.
MBD and DEX standards
Sales transactions rely on MDB processes to initiate the transaction and result in generation of DEX data for auditing and reporting purposes. DEX and MDB do not do the same thing.
The fundamental difference between DEX and MDB is that MDB is the only method for a coin mech, bill validator, or cashless payment device to manage credit deposited to authorize a purchase transaction. DEX cannot do this. This fact makes it mandatory to have MDB installed.
How DEX and MDB differ
DEX, while needed for sales reporting, is not necessary for the machine to operate. From a payment perspective, MDB data may prove more useful than DEX data since it details parts of the transaction which, when coupled with data captured by a cashless peripheral, equates to a comprehensive electronic transaction record (e.g., card or account number, transaction value, product(s) sold, date, and time) for reconciliation.
Results of each transaction lead to the creation of an MDB record (often referred to as the “Electronic Transaction Record”).
If a vending operator does not offer cashless vending, then DEX data often is sufficient to provide necessary managerial information. It is for this reason some vending operators only use MDB for cashless transactions, and ignore DEX data. For those operators desiring DEX data, a DEX cable can be used to transfer the DEX file along with the cashless MDB data.
MDB allows instant status update
MDB allows for instantaneous updating of machine status (e.g., coinage in, change paid-out, products sold, etc.). It is for this reason that the MDB standard is considered a transaction-based mechanism, unlike DEX, which is an interval and cumulative audit-based reporting system.
The MDB protocol allows for the attachment of an audit (i.e., DEX) device that, acting as a passive slave, receives information of all events that happened in the machine through MDB (e.g., vends, sold-outs, coins and bills accepted, etc.). On the other hand, DEX involves the retrieval of stored information (a snapshot) via local or remote transfer.
In a DEX connection, a polling device actively surveys the vending machine for stored information, and then follows DTS standards for transmission. Once the data transfer is completed, DEX data can be entered into a vending management software (VMS) package for detailed analysis.
DEX standards allow data transfer
DEX standards have established baseline data to be collected within a vending machine.
In the past, machine manufacturers varied in how data exchange transmissions occurred. In response, DEX designers and equipment engineers have established standards governing data recordation, file formatting, and file exportation through common interface linkages.
As a consequence, vending machines are manufactured as DEX-enabled and are often labeled “DEX-compliant.” From a sales perspective, DEX provides the vending operator the ability to track column/product preferences at the point of purchase.
DEX benefits to the operator
In order to know which products are selling, DEX data must be correlated to a planogram, or product map, to interpret column vends into product movement. Effective use of DEX data has been found to improve sales performance, reduce operating expenses and alert operators to machine malfunctions.
In addition, DEX enables space-to-sales analysis for machine-level column allocation optimization in vending management software. This is an important outcome of a DEX-compliant device. The main benefit of line item tracking is accountability and machine planogram (i.e. rotating menu of product offering) development.
More timely analysis now possible
The fact that data can be exported to a remote warehouse, central office or product fulfillment center extends the opportunity for more thorough, immediate and frequent analysis.
Since there has been a proliferation of diverse vending products, and several variations in the packaging of the same product, the DEX standard has been refined to acknowledge and differentiate between product offerings. While not all vending operators demand identical informational output, vending machine circuit boards are built to possess similar data collection capabilities to ensure the delivery of consistent content.
DEX allows data polling
For example, A DEX-compliant machine relies upon DEX architecture to enable vending machine polling. The vending machine exports its unique identification number and stored data to an external system for analysis and processing. An optional element of this data stream is the machine’s service history, including the last date the machine was serviced.
Once DEX data is exchanged with a vending management system, various transaction audits can be performed. Since captured data is not accessible or editable prior to interfacing to an auxiliary system, cash accountability will be accurate and complete.
Machine level tracking
Also, the ability to track product information at the machine level enhances productivity, as machine fulfillment is improved and manual data entry eliminated. The DEX protocol enables different makes and models of vending machines to communicate in a consistent manner.
DEX data sets include sales mix, cash collection, product movement and malfunction alerts. Additionally, DEX specifications may soon include a standard for reporting error codes for payment validation, dispensing jams and other operational problems. Proposed specifications are pending approval.
DEX utilization will take time
Since vending machines have an average life of 10 years, it may take a generation of new installations to fully realize the DEX potential. DEX provides an indisputable, auditable accounting method for cash collections, units sold and product price recording that are capable of enhancing route efficiency and improving warehouse operations.
For example, how much cash should be in a machine at the close of a sales period? A route driver, unable to view the DEX electronic record, will have cash collections compared against the machine-level electronic record. Balancing cash against collections provides management with a unique level of information and control.
Traditionally, vending operators have used one of two methods to reconcile machine sales to cash balances. The first method involves a comparison of cash collected to products sold, while the second method involves cash, or unit, meter readings. The cash-to-products comparison method can be effective, but requires accurate machine inventory reporting whenever cash is collected and reliance on trustworthy route personnel.
Traditional cash accounting
The cash-to-sales comparison method may be prone to manipulation by an unscrupulous route person who opts to supplement product sales with his/her private product replenishment. In this case, the driver places unauthorized products in a machine, thereby making it appear that sales are artificially lower than actual.
The second method of cash control necessitates reliance on a cash metering system (vend meter in a single-priced machine or a cash meter in a multi-price machine). While cash meters provide cumulative data, interval readings can be derived to produce period differences. This method can work accurately, but also places a heavy dependence on route personnel to accurately record the meter reading.
With DEX data, it is possible to know how much money awaits collection; such information helps simplify the detection of cash skimming and sales volume falsification.
Cash control data fields
Two important data fields from this set that target cash controls are “Cash Out” and “Tube Cash.” Together, these fields provide tighter audit controls that close the accountability loopholes encountered in the two traditional methods of cash control.
By determining the variance between “Tube Cash” less “Cash Out,” cash shortages and product supplements should be eliminated.
Levels of DEX capatibility
Vending machines can be purchased in a variety of DEX-capable stages. Newly manufactured machines are likely to be fully DEX-compliant at the time of purchase, while older machines may be partially DEX-enabled or require some degree of retrofitting to gain DEX capabilities. There are four classifications of DEX-compliant vending machines:
- Non-DEX compliant: Machines manufactured before the adoption of standards were produced without regard to DEX capability. Retrofit kits, audit boxes and the like can be installed into older machines to render them DEX-capable. DEX retrofit kits, supposedly easy to install, range in cost from $120 to $200 per machine.
- Cash meter DEX-compliant: Some of the earliest DEX capable machines only support a cash meter reading via the machine’s DEX port. While this level of automation is superior to manual cash meter recordation and reporting, it is limited in application scope.
- Cash audit DEX-compliant: Recently produced machines are capable of supporting a DEX cash audit. DEX cash auditing includes a report of cash into the machine (by coinage, currency and cashless media), cash out of the machine (change tendered), and how many coins (by denomination) were deposited into the coin box and change tubes.
- Fully DEX-compliant: Machines currently being produced are capable of reporting product sales by price, by column location, or selection button assignment. This information matched to a machine plan-o-gram (or product mix list) can result in more efficient and effective management.
DEX data reading fields
DEX data readings for each data element are provided in two separate data fields: interval and cumulative. An interval reading includes only DEX data collected since the last data reading.
After an interval reading is concluded, the interval tracking mechanism is reset to zero, thereby ensuring the next interval reading contains only data aggregated since the last reset.
A cumulative reading is maintained in summary, indicating a perpetual total since DEX data collection was initialized. A cumulative metric represents all data collected to date, while the interval metric involves only data recorded since the last interval reading. While interval readings reflect recent activity, cumulative readings can be used to prove the accuracy of interval values.
Next month, we will explore how DEX and DTS have allowed for more versatile data collection in vending.
<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>
Three serial interfaces currently available for electronic machines
Serial interfaces are used to send messages between components in a vending machine. There are three serial interfaces available for U.S.-based currency and cashless payment peripheral devices.
Available protocols include:
1) MDB — MDB/ICP — originally
developed by CoinCo (early 1990s) for Coca-Cola to allow development of a low-cost coin changer that would rely on the capability of the vending machine controller (VMC) to effectively manage purchase transactions.2) MEI Micromech — Designed in the early 1980s, this allowed full control of the changer by the VMC. The name Micromech
is attributable to the fact this interface places the power supply for the coin changer in the VMC (not in the changer) and allows for the removal of several other control electronics, thereby rendering a smaller mechanical configuration (i.e., a micro-mech).The installed base for Micromech interfaced machines is 30 percent, with a steady decline expected. Micromech is being phased out as newly manufactured machines are being ordered with a MDB interface.
3) Simplified III L+ — This protocol is an extension of the Micromech interface and was developed by NRI, Simplex III and Coinco in the mid-1980s. It removes the references to specific coins that tied the interface exclusively to the U.S. market and, through the addition of logical extensions, allows the interface to be used in any machine supporting a three-tube changer.
<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>
DEX enhances data compatibility
DEX standards have allowed vending machine circuit boards to possess consistent data collection capabilities. As an example, three data elements referenced in the DEX standard allow different machines to
provide compatible data:
1) Value and number of bills held in the bill stacker.
2) Value of coins sent to the coin box.
3) Number of vends or products sold.
<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>
DEX data fields for cash control
Correlating readings against
DEX data provides an unparalleled level of control. Specific DEX data fields identified by streamware.com include:
CASH IN — cash deposited into the machine
CASH OUT — cash paid out by the machine (change tendered)
BILLS TO STACKER — bills received and deposited in the bill stacker
COIN TO BOX — coins dropped into the coin box
TUBE CASH — coins used to replenish coin tubes
CARD CASH —total value of cashless transactions
