|
Windows for a Bank Teller machine?
I have often in the past had comments, or discussions as to the fact that windows would not be a suitable choice for a bank teller machine. Just the fact of the design ideals of a GUI vs a command system was often a issue. (prompt/command line driven systems tend to be a bit better for these 24/7 type applications, and often programs can run, but NOT need user intervention).
In fact, I remember being at SCO Unix meetings years ago where the opening slide of the presentation was a bank teller machine with a windows NT dialog box that had popped up (the ATM had obviously crapped out, and needed a user to click ok!......at that time, the screens where NOT touched senseitive, but had only buttons. No way to click ok!)
Certainly the slide was a great show stopper at the SCO meeting, and usually brought the crowed to a good round of snickers. The German bank company wound up dumping the use of the system!
Of course, that old NT core is a lot farther along now, and reliability of windows has reached a new high.
I was most surprised to read that a good many ATM companies are using windows for the bank tell os.
http://www.pcworld.com/news/article/0,aid,113997,tk,dn122303X,00.asp
Kind of a surprise that windows is being used, but then again the issue of developers, software tools and the all the other things put together make sense as to why this is happening. It is interesting that many of the teller machines used OS2/warp, but of course the issue of long term future is hurting this.
Albert D. Kallal
Edmonton, Alberta Canada
kallal@msn.com
http://www.attcanada.net/~kallal.msn
Albert D. Kallal
Tuesday, December 23, 2003
Way back when I was working on ATM machines (7 or 8 years ago) most of the new machines ran OS/2 and the older ones ran some proprietary NCR OS. I seem to remember the "fun" thing to do for a while was boot one of the new colour ATMs into DOS and install DOOM on it so that when clients wandered around there would be this ATM with the DOOM intro running on it...
As far as I remember the early OS/2 ATMs actually ran some form of emulator for the previous ATM OS and the actual software that was deployed on them was similar to the earlier machines; but it's a long time ago and I could be wrong on that one...
The NT based ATMs were just starting to come into fashion when I left the industry for investment banking...
Len Holgate (www.lenholgate.com)
Tuesday, December 23, 2003
I think a big reason is Windows lets the damn bank bombard us with ads while we are getting OUR money. ATM's should be mandated to be a text only screen. DOS would be fine, but no GUI.
Mike
Tuesday, December 23, 2003
c:\checking\balance.exe
I guess you don't mean that kind of DOS. ;-)
Merry x-mas.
www.MarkTAW.com
Tuesday, December 23, 2003
>>
In fact, I remember being at SCO Unix meetings years ago where the opening slide of the presentation was a bank teller machine with a windows NT dialog box that had popped up (the ATM had obviously crapped out, and needed a user to click ok!......at that time, the screens where NOT touched senseitive, but had only buttons. No way to click ok!)
<<
That seems more like an issue with the application code than the operating system. How is Windows to blame because a programmer decided to call MessageBox on a system without an appropriate input method attached? Surely SCO supports the ability to prompt a user for input?
SomeBody
Tuesday, December 23, 2003
Of course Unix can prompt the user. However, as a matter of general design, many programs and system utilities that run in Unix simply run, and return a error value if something went wrong. Often, this means that the system can run some program, and NO user intervention is required as opposed to a GUI system that sends up a dialog box.
This is not a hard and fast rule, but tends to be just one of those general differences you see in Unix/Linux designs vs a GUI based system like win2000. Joel had a recent article on this difference of philoshopy.
All in all, many times this very fact of Linux/Unix NOT needing user intervention was a positive argument for embedded systems like ATM machines, or what not.
So, when I did read the article that windows is now being adopted for bank teller machines, I was a bit surprised.
Like so many things in most industries, just one feature, or fact of a OS is not going to make it a success in the marketplace, but a combination of many things. Clearly that combination has been reached with winXP.
Using windows for bank teller machines is a rather big victory for MS, and shows that windows obviously has a high enough degree of reliability for such type applications.
Albert D. Kallal
Edmonton, Alberta Canada
kallal@msn.com
http://www.attcanada.net/~kallal.msn
Albert D. Kallal
Tuesday, December 23, 2003
I'm intrigued...
So if you have a teller machine kiosk app written in C running on Unix, and the app divides by zero, how does Unix keep the app from crashing? Does Unix really take care of *all* error handling and bounds checking?
I don't know how old you folks are, but I seem to recall a lifetime of banks, airlines, etc. being unable to serve me because "the computer's down" (and I'm pretty sure it wasn't a Windows 3.1 server back there)
Philo
Philo
Tuesday, December 23, 2003
Our new Tellers System is written in Java/Swing but runs on Windows XP. The OS on these machines is essentially irrelevant as they'll *only* be running the tellers app. *Nothing* else.
Bank Employee
Wednesday, December 24, 2003
"Of course Unix can prompt the user. However, as a matter of general design, many programs and system utilities that run in Unix simply run, and return a error value if something went wrong"
This is the correct way to do things on embedded or servers as you can't depend on a clued up user standing by to help you out. I ran into this recently with some backup software on NT. There is no override for "do you want to format this new media" when you backup to a tape that has not been previously used.
"The OS on these machines is essentially irrelevant as they'll *only* be running the tellers app. *Nothing* else." Until an RPC hole or something gets you. Although ATM's should not be connected to a network that connects to the web or common everyday desktop pc's, but we both know that won't be the case.
"I don't know how old you folks are, but I seem to recall a lifetime of banks, airlines, etc. being unable to serve me because "the computer's down" (and I'm pretty sure it wasn't a Windows 3.1 server back there)"
I worked at a place where we didn't tell customer's the computers we're down. We had to say the computer's were updating. They did a lot of updating. NT on Alpha. Although Windows reliability has thankfully improved.
Mike
Wednesday, December 24, 2003
Welcome back Albert!
rami
Wednesday, December 24, 2003
Mike - you didn't address how Unix keeps poorly-written applications from crashing or doing other non-kiosk-friendly stuff?
Philo
Philo
Wednesday, December 24, 2003
It won't. But a poorly written Unix app probably will not leave a window up looking for user input. No OS can overcome poor programming. As someoen alluded to earlier, it is basically the difference in design between a unix app and windows app. Unix typically is server stuff that a human doesn't touch directly, Windows is the opposite. Sometimes Windows developers take the desktop mindset to the server and you get dialogs waiting for an answer that isn't ever going to come.
Mike
Wednesday, December 24, 2003
Philo: you've obviously never had the amusing experience of stepping into an elevator and seeing "Your clock has been adjusted for daylight savings time" over the top of "2nd floor - menswear, books, home entertainment". Your loss.
Daryl Oidy
Wednesday, December 24, 2003
Philo,
I suspect those down computes were probably IBM mainframes. I don't see your point.
christopher baus (www.baus.net)
Wednesday, December 24, 2003
The computers down nearly always refers to the telephone connection I thought.
Stephen Jones
Wednesday, December 24, 2003
"But a poorly written Unix app probably will not leave a window up looking for user input. "
From this comment I assume you are trying to compare the "quality" of a UNIX program simply exiting, while a VC++ program on Windows brings up a dialog saying some strange error occurred in MFC.DLL.
To the user there is no difference wether they see a Windows program error message or a UNIX command prompt - either way they can't use the ATM - and this sort of comparison is good only for the opening slide of a SUN Powerpoint (or whatever the StarOffice equivalent is called) and nothing else from a users point of view.
ChrisO
Wednesday, December 24, 2003
Windows, 2000, NT (yea even 98) has been used for both teller and intermediate software for years.
An experience with WOSA is burned deep into my soul.
Simon Lucy
Wednesday, December 24, 2003
I think that UNIX is more robust for applications such bank ATM's because of default behavior.
My thoughts:
-For a case like divide by 0, UNIX would generate a signal inside of the process. If you don't explicitly handle a signal, the default behavior is to generate a core dump (a must for diagnosis) and exit.
-Core dump generation automatically generates logging data in the system logger. Monitoring the system log is part of normal care and feeding of UNIX systems, so a crash would show up.
-If the application is supposed to run at startup (like an ATM application would), one would probably put it in the inittab. It is easy to list an application in the inittab such that the OS automatically restarts the application if it crashes.
Compare this to Windows. A divide by 0 error would cause a structured exception to be generated. If you don't handle structured exceptions the default behavior is to pop a dialog. Windows applications don't generate core dumps unless you configure the OS for it (i.e. Dr. Watson). Of all of the variety of application start-up method there are (services, scheduled tasks, etc...), none of them support automatically restarting a crashed application. A crashed application does generate traffic in the event log so there is parity there.
Now, all of these differences with Windows can be overcome by programming and system configuration; however, that takes resources. The bottom line: a lesser programmer and system administrator could roll out a robust ATM application on UNIX than Windows.
Mark Smith
Wednesday, December 24, 2003
One other thing:
There are new Bank of America ATMs that have touch-screen GUI's that are clearly Windows based. The old BofA ATMs were all text interface with a row of 4 buttons running down the side.
The new ATMs are so much less efficient (from a task point of view), it's sick. Screen updates are longer (instaneous vs. something noticeable); occasionaly the touch screen misses (throwing off the rhythm of the transaction); they've seen fit to make it a true multimedia experience so there are load times associated with audio and video. Even after taking the time to customize the interface (it has an option to reconfigure the UI some and remember that in the future), it is much slower user experience.
While I understand all to well how applications like this make it out into the wild, I am greatly dismayed.
Mark Smith
Wednesday, December 24, 2003
Windows reliability has certainly come a long way, but doesn't anyone remember the following well publicized incident in 2000:
>> Human error, not Microsoft Windows NT, was the cause of a LAN
failure aboard the Aegis cruiser USS Yorktown that left the Smart
Ship dead in the water for nearly three hours last fall during
maneuvers near Cape Charles, Va., Navy officials said.
The Yorktown last September suffered an engineering LAN casualty
when a petty officer calibrating a fuel valve entered a zero into
a shipboard database, officials said. The resulting database
overload caused the ship's LAN, including 27 dual 200-MHz Pentium
Pro miniature remote terminal units, to crash, they said.
<<
What I think is oddball about adopting Windows as an embedded solution is that you have to buy a special embedded version of Windows that allows the display and other subsystems to be stripped and replaced as necessary. At least this was the case when a client looked at the Embedded Windows NT toolkit a couple of years ago.
This is basically saying that the version of Windows that you build for an embedded application has never really been tested by anyone before, it's a custom configured kludge.
NOT good, especially for "commercial" SW.
I also find it absolutely amazing (but not unexpected) that the ranks of product managers and PHBs stupidly don't comprehend that all you really need for an embedded OS is: task scheduling, networking, IO support, and a file system (maybe). And don't comprehend in their pea brains that more needless complexity compromises the reliability of the solution. And every additional subsystem - multimedia, mouse support, display, USB, etc - is just dead weight.
My point: Windows is one-two orders of magnitude of complexity in excess of that which is required for an embedded OS. Our industry suffers from youthful Alzheimer's - everyone (it seems) is too green and inexperienced to recognize obvious badness for a particular application.
Bored Bystander
Wednesday, December 24, 2003
Isn't the problem with the Windows dialog box that nobody else can use the ATM either?
Stephen Jones
Wednesday, December 24, 2003
The problem with the Windows dialog box in a bank teller app is that the screen and buttons on the ATM aren't part of the console IO system of Windows, so the user has nothing to "hit return" with.
A technician probably has to connect a keyboard and debug monitor to special ports on the ATM to get control, is my guess.
Bored Bystander
Wednesday, December 24, 2003
...whereas a prompt and blinking cursor would be better for an ATM because...?
Regarding Unix's appropriateness for an embedded system, while I have to chuckle at the beauty that a poorly-written application can reboot the system all by itself just happens to be desired behavior here, I still think the issue is simply one of "know your platform and code and test appropriately." A dialog box on an ATM means "someone screwed up" and that someone wasn't in Redmond.
Diagram that sentence.
About "the system is down" - I remember hearing that more growing up than I do these days. When I was growing up, the "system" was a mainframe with a paid team to manage it. Today it's a Windows (or other) box with a part-time sysadmin. Yet today's systems are in general more robust, no matter what flavor they are.
My point was that all this "if we use Windows as our business server we're all going to die" appears to have been less than accurate - there are lots of Windows systems running 24/7 today that are up and available on demand, versus mainframes that broke only on days ending with "Y"
Philo
Philo
Wednesday, December 24, 2003
>> A dialog box on an ATM means "someone screwed up" and that someone wasn't in Redmond.
That's true in theory, ultimately you can always blame the application developer.
But the low but statistically significant probability that it *can* happen is an indication that Windows is too fat/bloated/porky for embedded applications that need to be reliable. I hold that it may not be *possible* to test for this not happening.
Philo, beg pardon - have you ever done embedded development? I agree with your commentary on the use of business class servers running Windows, but embedded work is another matter entirely.
Embedded is loosely defined as development of applications that run on a computer that is concealed within a product, and generally applications that interact with customized peripherals. Think of a computer controlling strange hardware hooked up to it and the keyboard being locked in a cabinet 5 miles away. (in a virtual way, anyway.)
I don't mean this as an ad hominem attack, I am just curious if you've done this type of work. Maybe you have, and if you have and you don't grok basic objections to Windows an an embedded OS I would find that curious. If you haven't done embedded I would find your comments easier to understand.
<rant>
The objection I have to Windows as an embedded OS is that it contains a multitude of behaviors that are concealed, implicit, and/or unknowable. Windows is a huge clockwork of little state machines. And Windows was designed with the thought in mind that a human is always available to answer a stupid freaking dialog box that blocks an application.
Application developers commonly fight with strange interactions in the Windows API environment, things like crashes and GPFs that only happen infrequently and are not duplicable. And good ole Windows uses the dialog box as a primary means of communicating an unhandled exception. I am asserting that this is an added debugging and test burden on top of the requirements of embedded.
In real time programming (the usual territory of embedded programming) you always have the distinct possibility of unanticipated combinations of hardware events and other strange things occurring that may exploit weaknesses in a highly complex underlying piece of OS software.
My contention is that the OS should have behavior that is as simple as possible for the problem being solved, because it will become part of the test and debugging environment. As I already said, that behavior generally consists of basic services like file IO, peripheral control, multithreading, and some kind of networking support.
An embedded OS should generally be 100K's to a few dozen megabytes in size, NOT hundreds of megabytes of OLE and OCX fluff that is included just in case the ATM needs to run Powerpoint once in a while...
Windows is generally too damned big and complex for this type of work. That is my point...
</rant>
Bored Bystander
Wednesday, December 24, 2003
There's really no good reason to use an x86 system at all for an ATM. Personally, if I were designing one, I'd go with a RISC-based CPU or something even simpler like a Z80 or 65C02 if possible. Cheaper and less complex, thus less to go wrong. OS? Why is an OS even needed for an embedded system like this? Why can't the program handle the limited I/O functions directly?
Firebug
Wednesday, December 24, 2003
ah, my friend, because it's hard to program for. hard to have blinky ads show up. and friendly voices (i've got to try the headphone jack on the ATM I used earlier this week, though talking ATMs aren't new). and touch screen advanced stuff like selling stocks or buying stamps.
scarier than just windows: some ATMs use Internet Explorer.
mb
Wednesday, December 24, 2003
>> scarier than just windows: some ATMs use Internet Explorer.
Geeeez. My point exactly.
Bored Bystander
Thursday, December 25, 2003
Philo, you've been assimilated. You are marketing.
borg
Thursday, December 25, 2003
 Recent Topics
Fog Creek Home
| 
