Blog · · Mark Finlay

Hardware fails. Plan for it.

How we connect note and coin validators, dispensers, printers and cameras. Own the protocol, believe the device, and say plainly when something is broken.

Software fails in ways you can read. Hardware fails with a jammed note, a loose cable, or a hopper that says it paid out six coins and dropped five.

Our kiosks take notes and coins and print tickets. Our cash machines pay them back out. SentinelGate watches a door through a camera. All of them have to keep working in a shop where nobody on the floor is an engineer. This is how we go about it.

Own the protocol

Note validators, coin validators, three makes of coin hopper, a note dispenser: we talk to them in SSP, ccTalk or the device’s own serial protocol, in our own code. Where we can, there is no vendor SDK in the middle.

It is more work at the start. But when a device misbehaves at nine on a Saturday night, we can read every byte that went down the wire, and we are not waiting on someone else’s support desk to tell us what their library did.

Where the only way in is the vendor’s own service, we wrap it, watch it, and restart it when it stops answering.

Believe the device, not the plan

Taking money in is the easy half. Paying it out is where hardware lies.

So a payout is a plan, and the plan is checked against what each device says it did, unit by unit. If a cassette jams, that denomination is left out and a new plan is made from what is left. If the machine cannot pay in full, it pays what it can and issues a ticket for the rest.

Mock every device

Every device has a stand-in. One setting swaps the real ones out, and the whole machine runs on a laptop with nothing attached. The stand-ins start, stop and fail the way the real devices do, so the tests cover the awkward paths too.

Say when it is broken

Devices are polled several times a second. On our kiosks, three failed polls in a row take the machine out of service, and it says which device and why. Two good polls and it comes back by itself. A hold that a person put on stays until a person lifts it.

Nobody has to guess, and nobody has to drive out to switch it off and on.

Money first

When a note is accepted, the credit is written to the machine’s own disk before anything else hears about it. If the screen, the network or the whole application falls over a moment later, the record is still there. Every coin in, every note out and every reject is logged the same way, so the cash in the box can be reconciled with the books.

Ordinary parts

Which validator, which hopper, which printer and which port are lines in a configuration file, not a build of the software. A shop can change one device without changing the rest.

SentinelGate is the same. It runs on a small ordinary PC, with any IP camera or a USB webcam. And it is honest about what a camera can see: a face that is too small or turned too far is ignored, not guessed at.

What we have connected so far

  • Note validators: ITL NV9.
  • Coin validators: CPI G13 and D4S.
  • Coin hoppers: Azkoyen T3, CPI Money Controls MK4 and ITL Smart Hopper.
  • Note dispensers: Fujitsu F53.
  • Receipt and ticket printers: Epson TM-T88V, Custom TL60, Custom VKP80 and K80, and Seiko SII RP-10.
  • Card readers: ACS ACR1252U for NFC, and keyboard-wedge RFID readers.
  • Barcode scanners: USB scanners, for tickets.
  • Cameras: IP cameras over RTSP, USB webcams, and the ITL ICU age estimation camera.
  • Screens: ILITEK multi-touch touchscreens, with a second display.
  • Cabinet lighting: serial LED controllers.

If yours is not on the list, it is usually one more driver.

The trade

None of this is clever. It is slower to build than plugging in a vendor’s kit and hoping. What you get for it is a machine that tells you the truth about itself, and that we can fix.

All posts on the blog

SentinelPay in manufacturing

Get In Touch

Let's make something great together.

Address

511 Blackhorse Avenue, Cabra, Dublin 7, Ireland, D07X9T3