I work for a very small company which is attempting to launch a line of small vending machine.
I'm a developer and I have the task to develop or outsource the embedded system to control the machine (currency validation, product displacement, inventory logging, remote managing, ...).
I'm a newbie, and while educating myself on the matter of embedded development a strange idea came to my mind, and I would like to share it with you.
The platform I'm building has some nasty specs:
- It must be low cost
- It must be viable to be made in very small numbers
- It needs to be very reliable, as it handles money.
- It requires internet connection, for remote administration and management
- It must be low power, to run on batteries
- It requires several serial interfaces (RS 232, MDB, pulse, ...)
I could use something like the pandaboard, which is very powerful and cheap, but is not low power. Or I could use something like friendly arm or embedded arm solutions, as they are very low power but are a little bit slow.
The third option, which is the idea that came to my mind, is to use a smartphone, like an android phone, and add serial ports as needed through USB. It has several advantages:
- It is VERY cheap. For 99$ I can get a 600 mhz CPU, a GPU, WiFi/UMTS/Bluetooth, and much much more...
- It is VERY low power (especially wireless-wise)
- I can buy tomorrow just one dev board in a brick and mortar shop
What do you think? Is it a crazy idea to use a off-the-shelf smartphone in a real vending machine?
Define small and how long the product cycle is expected to be.
Depending on ehther it is notes, coins or cards plenty of money recognition sub-systems are on the market already.
As always.
Depending on whether it is coins, money or cards has all sorts of requiremnets, including security of system from vandals, robbers and fraudsters.
Which gives a primary point of weakness for fraudsters, robbers....
Define run on batteries, hours, days, weeks, months, years..
So work out your list of interfaces and requirements first.
Sounds like you are trying to shoehorn some names of products, without working out the full requirements first.
Speed of processor is not the most important thing.
Work out what you have to do when and how quickly.
When they change in 3 months time and you cannot get that model and have to redesign mechanical mounting, wiring, software.
You also do not appear to know how USB works and I wonder how a USB slave becomes a USB master.
You are putting the cart before the horse.
You need to work out all the external interfaces and requirements and work BACK to the cpu from ALL of the other requirements.
--
Paul Carpenter | paul@pcserviceselectronics.co.uk
PC Services
Timing Diagram Font
GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
For those web sites you hate
What do you mean by "small"? And, how does that relate to your proposed choice of platform, here?
It seems to me that the first decision you face is whether
*you* are going to be doing the development or if some other (outsourced) third party will. In the latter case, the third party deserves consultation before you unilaterally make that design decision (unless you are willing to live with whatever consequences the third party imposes as a result of your decision).
Ouch.
(sigh) Having admitted a lack of experience, here, you should very carefully consider the consequences of your actions. Without a better understanding of the details of your application, it's hard to say, for sure, how big the effort will be. But, it is
*probably* safe to say that the task you have before you will make or break the product (and, depending on the resources your firm has available, could actually make or break the firm!)
"Low" is a relative term. *How* low? How much development time (nonrecurring) are you prepared to trade for manufactured (recurring) costs?
How small is "very small"? I've worked on systems where the lifetime build was *2*. Others that were on the order of "one a month". And others that were 250K/year. Will those quantities ever change? Will the product itself change over it's lifetime? (how *long* is that lifetime?)
This has consequences to the hardware, software, packaging, etc. I saw an access control system that could be defeated by simply unplugging a cable at the proper time; Slot machines that could be "confused" by shining a light into a photodetector (intended to count coins as they are dispensed); Phones that could be tricked into thinking money had been deposited by "shocking" them at the right time; etc.
There are also "system" issues that are beyond the scope of the hardware *or* software that dramatically affect this sort of security (go to a casino and watch how they conduct their business).
The point is, security isn't easy. Where money is involved (or, product dispensing), there is usually ample motivation for folks to figure out how to scam your device.
The first "island terminals" manufactured for Arco self serve gas stations were made of 1/4" steel and were the size of large refrigerators -- despite the fact that the internal electronics were no larger than a PC's main board. Reason: a lot harder to break into and/or walk off with a few hundred pounds of metal!
[of course, that's before we knew that folks would resort to crashing their (stolen) vehicles into the devices and carting them off their mounts!]
This, in itself, is a huge area of vulnerability. Now you have a doorway *into* your device. One that doesn't require physical presence to exploit (i.e., a thief can be located on the other side of the planet -- safe -- and still attack your device).
Again, without knowing specifics, consider some "in person" interface that is accessed when the machine is periodically restocked. Even if the maintenance individual acts as little more than a "SneakerNet carrier" (transporting secure media to/from the machine).
24/7/365? Or, just in the absence of power? How much of your power budget is devoted to the actual mechanisms of the machine vs. the brains controlling it?
Presumably because you are buying "smart peripherals" (e.g., coin mechs, bill validators, etc.) and these are the interfaces that they support?
What do you need all that horsepower for? Are you doing fancy animations on a screen? I.e., much of your work is probably rather slow -- even the user interface could consist of prebuilt screens (think *bitmaps*) that you just push into the display hardware when the time is right. Again, if power is a concern, I would think your user interface would be designed to NOT burn watts needlessly.
(sigh) This is the 2011 version of "We can just use a PC and add...". Until you start to realize what the cost (in terms of recurring dollars, non-recurring engineering AND RISK EXPOSURE) will be.
You can probably buy a PDA for even less! (tongue in cheek) Or, a small netbook/laptop for a bit MORE!
What do you NEED those things for? Think about what you *need*. Then figure out how to get it.
How are you *mechanically* going to add these interfaces that you need?
How are you going to protect the running system from EMI/RFI directed at it in deliberate attempts to trick it (crash it)?
What are you going to do next year (12 months from now) when that model is no longer being sold? What are you going to do 3 months from now when there is some hardware/software or mechanical modification made to it that forces you to redesign your end of the "system"?
Are you going to have *complete* documentation for the hardware and software in the phone? Or, just *partial* documentation? If you are buying small quantities (which you imply), then you're a "small fish" and attempting to get anything beyond "what's obvious" from the manufacturer will just be an exercise in futility. [conversely, a small manufacturer might be more inclined to cater to your needs]
Phones are designed to be recharged regularly. Their power profile is designed with that usage model in mind.
You can buy one of just about anything "tomorrow". Are you ready to start writing code TODAY? If your answer is "yes", you are almost certainly doomed to failure since you don't even know what you are
*designing*, yet!
Do yourself a favor and figure out what you *really* need. Don't design with a particular solution in mind. You'll end up with an abomination and greatly increased chance of failure.
Once you *know* what you need (and that will probably take the form of several "possible alternatives"), then look at how to get to that point most "efficiently" (which factors all costs into the equation).
Using a COTS smartphone as a SMARTPHONE would be an excellent idea! Anything else warrants an answer of "that depends..."
So you consider a 400 MHz module from FriendlyARM to be slow (I don't use their products, but just looked at their website), but consider a 600 MHz processor in a smartphone to be ok. Given your stage of development with this project, how can you possibly know this ?
For a vending machine, even one with remote Internet access, I would personally consider a 400MHz processor to be overkill.
Are you trying to write the software for this in some bloated interpreted language-of-the-month which requires vast resources (by embedded standards) to run ?
Even if you find a Android phone with a USB host instead of USB device, how do you know that you can add serial port devices to it ?
How do you know that the specific serial port chipset you want to use will be supported ?
How do you know that the phone hardware will allow you to attach more than one USB device to it at a time ? Some cheap USB host hardware I have seen in the past would only allow one USB device at a time to be attached to it.
If it's cheap you want, then look at the Olimex boards. I use them in my hobbyist work and they are at least designed to work in a embedded environment.
You can buy standalone GSM modules for which you can read the datasheets to see if they will do what you need. If they are not suitable for whatever reason, you could consider buying a board with a Ethernet connection and attach it to a local Internet capable network in that way.
(You would need to open a port through the firewall if you truly want remote administration instead of having the end user press a button on the vending machine to connect to you.)
Unlike most of the people in this newsgroup, I am a hobbyist and so I have a range of experience exploring the feasibility of making various off the shelf consumer electronics devices do things for hobby purposes that would never be considered for professional work.
With that experience in mind, I can tell you that this is a really bad idea.
Even I would never use a smartphone for something like this, even for pure hobbyist purposes. I would just buy a cheap board from the likes of Olimex instead.
For one simple example, how do you know that your smartphone will power up automatically in a fully on state after external power is applied to it ? Will your end user have to manually power up the smartphone as well as the rest of the vending machine ?
That one reason stops me using a range of COTS hardware for hobbyist use.
Simon.
PS: In future postings, please consider wrapping your text at under
80 columns. Thanks.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Before you go further, note that you are trying to build a vending machine controller. This means at least MDB, which requires a 9 bit serial protocol designed around an 8051 from long ago. There are other timing requirements in MDB that you should consider before thinking about Android.
Google suggests that a PC to MDB adaptor is nearly US$ 300. You will also need the MDB power supply.
We have developed several deep embedded MDB systems. If you are only building a small number, you can buy interfaces from several suppliers.
The idea of running MDB on batteries is a little strange if you are going to use conventional coin-mechs. I think that you need help with the specifications as well as the software.
Stephen
--
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
My company has now several vending machines installed and working. We buy the controller board from a third party which uses proprietary hardware and cables.
The goal is to add an additional controller board in some of these vending machines to achieve superior functionality.
The main objective is to gain remote monitoring, so that we will be able to know anytime how many products are left and thus reduce the cost of maintenance. Eventually we can think to remove the existing hardware and to use a solution tailored around our needs.
The project started 8 months ago when I showed a modification of an existing machine where I installed a wireless router with a USB port (TP-link
1043ND) with a script which can detect activation of the engine via a USB power detector and then ping a server via wifi to announce a sale.
The problem was that even if it needed a power cord as always-on wifi is power hungry. Thus I repeated this process with an android phone (htc desire) to achieve battery autonomy and my boss was very pleased with my work.
About your questions:
I have a budget of 2000 euros to realize a working prototype, based on our vending machine, to be installed and tested on the field, before investing more in R&D.
This is true. But being a developer with a strong background in cryptography and security I can say that I feel that with a virtual machine like J2ME or Dalvik, strong encapsulation, sandboxing of critical processes and use of SSH we can achieve a good security, at least regarding remote monitoring.
4 weeks or more is ideal (at a rate of 100 operations a day). 1 week is the minimum.
Remember that our machines doesn't have a display (just leds).
The problem is that I'm not sure which interfaces I need. I know that I will mostly use serial ports, but breing a newbie of hw development I don't know much more.
What interface use the MDB (multidrop bus)? Is it compatible over RS-232? How can I interface easily with multiple lights? Isn't it better to have a USB host and expand connectivity through it?
At the moment no. But in the future we hope to be able to add a touchscreen on the machine.
Moreover, I wrote a banknote validation algorithm that I hope to try on the machines. It is very resource hungry but it has a lot of potential...
I thought that, since all android devices has a MMU, then they are much more powerful and flexible than FriendlyARM, which doesn't have a MMU nor is Java capable.
Anyhow I'm not very educated on the subject so I might easily be wrong.
I thought that maybe I could use a usb hub with a dedicated chipset to extend functionality and provide easy access to hardware via the APIs... Anyhow I'm sure that having the ports installed on the machine is better.
Thanks everybody for your feedback... I think that some of you work in the field... After the gentle folks here will help me to clarify my confuse ideas I'll contact you in private to study the real practiability of this project.
Most of which are there for a reason and the proprietry may not be so proprietry for that industry sector.
Which may or may not exist in the existing hardware or configurations for it already.
Nice idea fraught with lots of issues of reliance on technology, when one unit does not report any stock reduction but has been defrauded mangled, stolen completely.
You don't appear to show enough knowledge of the total product issues to achieve this for at least three years.
Anybody can add a kludge to an existing system making it repeatable and cost effective requires a lot mmore thought.
Anything with a power cord or anything turned on can be deemed "power hungry", stop useing relative terms and define limits based on whole system.
A kludge is still a hludge that has opened up all sorts of potential vulnerabilities. Anyway this method is no good for even a run of one a month as in 6 months you are redesigning or buying on ebay.
Id that the hardware only budget?
There you go again add more points of weakness, EVERY item added is AT LEAST ONE more point of vulnerability.
Better security by LESS items especially in software. Better design and not high level bloat with many different peoples vulnerability paths added.
If this was to be used with credit card transactions in any part of the system it would be banned by the merchant companies.
LEDs can use lots of power as well, depending on size and quantity.
Research the interfaces internal and external FIRST, then you can work out what platform is needed.
There are plenty of resources that describe this, so RESEARCH THIS FIRST.
Lights can be anything from one low power led configuration to mains incandescent/fluorescent strips, it could on/off, timed, dimmed, pulsed or any other scheme we have no idea as you have not said.
Also research how USB works and then understand why your android is a bad idea.
Work on what you have now, add a fancy user interface on something larger than an android so all ages of the population can use the system many people do not have 20/20 vision.
Until you work out if you need it and what hardware it requires you cannot do anything with it.
WALK before you can run.
You are trying to shoehorn DESKTOP philosophy of poorly written bloat code that requires faster processors to HIDE wasted time.
Before you work out the processor work out the spec.
I bet the existing proprietry hardware is working with what you would consider VERY SLOW processors.
The android is NOT a DESKTOP PC it is a DEVICE, without ability to load drivers for USB hardware, as it is NOT a USB HOST.
Research How USB works.
Work out what you are doing then work out the machine must do.
All you specs must just have a box marked PROCESSOR and RAM for now with NO identification of any size, speed, language, operating system or any other software.
--
Paul Carpenter | paul@pcserviceselectronics.co.uk
PC Services
Timing Diagram Font
GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
For those web sites you hate
I bet your existing machine has no MMU and RAM measured in kilobytes.
Wifi is too serious a security weakness point to even consider for vending machine, I would want a steel cable duct burried in 6 inches of concrete all round.
USB on most operating systems may allow vulnerabilties from staff adding pen drives in the field, as smartphone apps are easy to get written.
Using a known bloated operating system means all its flaws are available to be compromised. As well as all its costs.
He is talking about BOTH. initial design, maintenance, even trying to produce for more than 2 months. Even mechanical fixings or moving of connectors on smartpohone means changes to mountings or cables.
In your application you would need a power cord to drive the charger, you will need a spare supply of chargers as well.
--
Paul Carpenter | paul@pcserviceselectronics.co.uk
PC Services
Timing Diagram Font
GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
For those web sites you hate
In my country, you can prevent your phone from working without your SIM.
Really?!? Could you point me to any more infos about this?
I'm 100% sure of this. I will need to develop custom hardware and software.
But before this, as I said in my previous posts, I need to have one working prototype for my boss. Just one. To work for a few months and show the potentiality of the idea (just remote monitoring is a huge cost-saver over maintenance).
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.