embedded software boot camp

Automated kiosks

Monday, December 21st, 2009 by Nigel Jones

I’m not prone to rants on this blog, but I think it’s time to vent about automated kiosks. Automated kiosks are popping up everywhere – airline check in, the movies, grocery stores and so on. While it’s true that as a consumer I can’t say I particularly like these beasts, I think it’s the engineer in me that’s really ticked off. Why is this you ask? Well I have several beefs with them.

Processing Speed
I am constantly amazed at how amazingly slow most of these kiosks are. It’s ridiculous the number of times I’ve stood in front of a kiosk while it tells me ‘System Processing’. What exactly does ‘System Processing’ mean – and how in the age of Gigahertz processors do I find myself having to wait for a computer to do something as pedestrian as process a credit card payment?

Lack of Parallel Processing
Why is it that these terminals do tasks sequentially that could (and should) be done in parallel? For example, at my local grocery store coupons are only printed after payment has been accepted. Why aren’t they printed on the fly?

The up time of these kiosks seems to be amazingly bad. My local cinema has three kiosks. I have never seen all three working at the same time. The availability of check-in kiosks at airports can be even worse.

So what to make of this? Well I think the reasons for these problems becomes apparent if one notices that these kiosks all have a common hardware platform (a CPU with a color flat panel display, a touch screen, a card reader and a printer) and all are trying to solve a common problem (provide an easy to use interface to a big database). I don’t know for sure, but I think it’s highly likely that most of these kiosks are running a Windows X86 platform and that they are programmed in VC++ by folks who do VC++ PC programming. In short they are computers and not embedded systems, and as such are programmed using the usual PC mindset. No wonder they are so bad!

Before I leave this topic, I’ll mention that there is one class of kiosk that for the most part doesn’t have the aforementioned problems – and that is Automated Teller Machines (ATMs). While I can find the user interface on ATMs quite maddening at times, I’ve never gone to use an ATM and found myself staring at the Windows logo. My suspicion is that when it comes to ATMs, banks worked out a long time ago that they needed robust systems with high availability and thus they they went the embedded systems approach as opposed to the PC approach. Without a doubt this is a much more expensive – but boy can I tell the difference!

I went Christmas shopping today. I went to pay for car parking only to be faced with a kiosk stating ‘Printing ticket’ and a piece of paper stuck to the kiosk saying ‘Out of order’. I tracked down another kiosk and successfully paid the parking fee. When I went to exit the car park, the card reader could not read the ticket. A (human) attendant had to manually let me out…



7 Responses to “Automated kiosks”

  1. Kyle Bostian says:

    I went to look for a reference and could not find it quickly, but I've read somewhere that the leading platform for deployed ATM's is x86 running OS/2 or its successor, ecomstation.

  2. Kasper says:

    Today it is all too common to see the dreaded blue screen of death of windows NT, 2000 or XP on ATMs.If only the "embedded" systems were programmed using VC++… no such luck! Mostly they use a diabolical combination of Internet Explorer (HTML+JavaScript) for the front end and Visual Basic 6 together with MS Access providing the "back end".These are exactly the kind of systems that should be built using QNX or even Windows CE, using only C/C++ and simple user interface primitives!BTW: these devices require you to insert your credit card or passport. They use a standard Windows OS and they have ethernet networking, but are not patched because they are "embedded". They also have USB ports inside, and will happily execute any .exe on a USB stick. Just think of the possibilities for credit card and identity theft!

  3. Greg says:

    I found an error message on an ATM in California a few years ago. The touch screen was obviously not hooked up to the system mouse input, so I couldn't hit OK or Cancel!

  4. Nigel Jones says:

    An interesting set of responses. It appears that at least some of the ATMs out there are using Windows. I agree particularly with Kasper that the (lack of) security is absolutely astounding. I also whole heartedly agree that a true embedded RTOS should be used – preferably running on bespoke hardware.What I find stunning about this is that I have worked on Point of Sale equipment that have had to handle debit card transactions. The keypads for debit card readers are impressive pieces of equipment – as mandated by VISA. Despite this VISA apparently allows banks to run ATMs based on Windows. Amazing.

  5. Anonymous says:

    In the UK we have a lot of Windows-based ATMs. The other day I was amused to see one that was displaying Internet Explorer apparently trying to download an update from some website (fortunately it seemed to have failed). A few moths earlier another one swallowed my bank card before eventually attempting (and failing) a reboot.

  6. ashleigh says:

    ATMs USED to be dedicated hardware and very carefully crafted software. I went to a presentation once by a local bank on how they worked – the amount of internal checking is (was) astonishing.Cost pressures have I suspect driven the move to embedded windows (and I've done some of that also!).Building embedded windows machines is touted as "so easy you will have your OS and application running in half a day".When I went through the exercise, to actually build the embedded OS, have it work, do what you want, and REALLY understand whats going on. Tweak and tune it. Turn off things like NTFS file access time updates (else you get flash memory drive wearout)… doing all this, building a stable deployable image, for the OS NOT THE APPLICATION RUNNING ON THE OS. This took 3 months.I wonder how many people spend 3 months making their embedded windows OS?The issues are many and varied and there is no one single reference that you can go to that says "here are good practices". Its a shambles.

  7. Nigel Jones says:

    I couldn't agree more Ashleigh. I was parenthetically involved with a project a few years ago in which a WINCE platform was running mind numbingly slowly. Eventually a consultant was brought in who managed to track the problem down to some obscure configuration issue.

Leave a Reply