Secret Sauce, (Putting the Mobile System altogether) |

I was recently contacted by JJ from France about the mobile terminal I am designing for one of my clients, specifically regarding how it would fit together and if he eventually emulated the design how he would interface it to his clients factory systems (SQL Server in his case) most importantly he was confused how the terminal could get by with such a small processor.

First let us recall the block diagram for the system

We’ve been talking exclusively up to now about the terminal but here we are specifically going to talk about the Service/Daemon that sits between your production system and the handheld terminal (this is your secret sauce!), it is the program that:

Manages the security of which terminals can access the system
Translates Simple requests from your dumb terminal into high level language SQL to populate or read your production system data-sets
Reads the production system statuses to decide which screens the terminal will present to the operator. eg in the systems I write barcodes are Code39 and the IDs are prefixed with the type of ID it is, thus a job barcode for say job 2345 would be J2345, if an operator scans this barcode and passes it to the service the service can read the prefix, know the operator has scanned a job and thus know to now use that job or if it expecting some other type of barcode, say an Asset or Stock then to ignore the barcode and pass back an error message.
Tracks the progress of the messages between Terminal and Service and so knows precisely the state of each.
Manages printing. If you click a button on the terminal to print a barcode or report it will send a very simple message to the service (Print barcode record XX) and it is the service that will work with the OS, Printer drivers etc to make that happen.
Displays and logs activity so that a supervisor/manager can see real-time what’s happening on the shop floor

For example lets think of the process of updating our hypothetical job system with the new volume of a vessel after the job has finished.

Our production system service requires 4 pieces of information to fully complete this task (Assuming Dates and times are actual timestamps)

The Unique Job Number (Barcode)
The ID of the person who is doing the operation. This can be gathered automatically by linking the MAC or IP address to the terminal to the operator ID (the supervisor could do this start of shift before handing out the devices), it could also be done using the RFID scanner and operator tags or just requesting a user ID password every time. I will be implementing the first option as it requires no additional complexity at the terminal end and the rest of the text will assume this.
The unique vessel ID (Barcode)
The new volume to update the job with (operator data entry)

So lets say the operator has just switched on the terminal by clicking the scan button, the following hypothetical workflow will need to happen:

The terminal need to connect to the WiFi infrastructure and obtain an IP address using DHCP, this may take a few seconds on a busy system, the terminal will need to store in Non-Volatile memory (NVM) the Access point SSID, Authentication Method and Passcode to do this.
The terminal needs to simultaneously (as the barcode scanner and WiFi modules have there own sub-processors) initiate a barcode scan so the operator will see NO delay whatsoever between pressing the scan button and scanning the barcode, even though the system may not yet be connected to the service.
If required we can display a processing message at this point though I think everything will be ready within a second or two.
Once WiFi is connected and the Barcode has been scanned, the terminal will need to form a simple message and send it to the services TCP Port. For this the scanner will also have to have stored the IP address of the service host and the TCP port it will be listening in on in the NVM during its setup (the port can be hardcoded with some arbitrary number as it is never really going to change say port 3000)
The service receiving this message will know automatically which IP address it came from and thus (if your tying the IP address to the user) which user is using it, it will also know if this terminal is not configured for a user and can reject it.
The service knows the ID is from a job barcode and will now run a SQL query back to the production database to check the status of that job, only jobs at a certain (open) status will be valid any other job number would be rejected.
The service would reply to the terminal with a simple message to show the job title and the list of valid operations, ie something like:
Operator sees message to scan the vessel barcode and does so, the terminal then sends something like:
As the service has no practical limitations in CPU or memory it can can hold the state of the message thread for thousands of these terminals and thus know this terminal has already scanned in a job number and is waiting for a valid asset number, a simple SQL query to the production database will tell it that the asset ID supplied in the barcode is valid for that job and it can either reject the message or confirm it using:
Operator is presented with message and numeric input on the touchscreen to enter new number of litres (or a dip in the case of a winery) the message would be something like:
Finally, in the simplest case the service would check this number against an expected range and either accept it or reject it, if accepted it would update the job/vessel status in the production system using SQL so that the action can be marked as complete and could not be done again and also initiate a print of a new label if required.

Naturally these are not the real messages going back and forth and you would use simple byte codes to keep things “Microprocessor friendly” and the data sent small, there may also be timeouts and/or other secondary supervisor checks.

From the above you can see that the terminal does not need to be a Linux or MS behemoth, nor does it require 100’s of Kilobytes of memory to process, nor even an operating system, it could (almost) be done with an arduino and literally requires just the ability to format and send very small messages of a maximum of a few hundred bytes (unless you decide to be clever with showing pictures) so even using a PIC32 is effectively overkill!

It is also important to note in the above that for security we are using a combination of the fact:

We are using a secure WiFi system onto the company network (this is usually the main gate of security on to your network so I would strongly advise not using an open access point!)
The service will only be responding to IP addresses that have been configured in our DHCP to be given out to our specific terminals MAC addresses (the same way the system administrator may reserve a printer to a specific IP Addresses) in practice this can be tied in with the firewall to only allow the terminal to talk to only the specific server and on a single TCP port, this is good practice and a good reason for reserving the addresses of the terminals.
The Terminals IP address must be linked to a user in our service before it will accept a message, this would be done by a supervisor having a list of terminals and users and connecting them via a drag/drop operation or whatever.
Using ‘security by obscurity’ in that we are using an unknown port and an unknown plain text protocol to do the transactions, both easily printed out through a network packet sniffer, however..
Messages will only be valid with specific combinations of job, asset, Stock or other ID’s all other combinations will be rejected. Without knowing the system intimately this task would require some very serious analysis of the traffic indeed. The operators job sheet is effectively the key to this!

There is no encryption between terminal and service envisaged ever, and the above will be adequate for the simple fact that, it is going to be used in a factory, generally a controlled access environment and any hacker would need some serious knowledge of the system, most importantly there is no value whatsoever to be had from monitoring the traffic nor, if possible, modifying it as any and all information put in by the system is still checked and confirmed by an office person before the job is closed and data committed, most systems have integrity checks and warnings to be acknowledged if anything is out of the ordinary.

Needless to say if this is not enough security for your particular area then don’t use it, but even writing both the production system, the service and the terminal and designing the database it would be beyond me without being on-site and having my laptop plugged into the network and having a valid job sheet. – Go figure.

And yes the whole of the service could be done using an off the shelf web server such as apache or Microsoft Internet server (web server tcp ports are easily changed) but you would need a scripting language such as PHP, ASP or Python which can access printer services if printing is required. You would need to use some sort of message format compatable with HTML eg messages sent from the terminal to the service would be something like http://192.168.0.1/service.php?barcode=J1234

And the PHP would be something like (and I apologize here as I’ve not used PHP for several years)

<?php

// check terminal is registered on our server database
if($res=mysql_query("SELECT OperatorID FROM terminals WHERE IPAddress='".$_SERVER["REMOTE_ADDR"]."))
{
  if($data=mysql_fetch_row($res))
  {
     $OperatorID=$data[0] // good get operator who owns terminal
  }
  else
    die("Not registered");
}
else
  die("Go away unknown terminal!");

if(isset($_GET["Barcode"])) // Check barcode
{
  if(LEFT($_GET["Barcode"],1)=="J")
  {
    if($res=mysql_query("SELECT JobStatus,JobTitle FROM jobs WHERE JobID='".MID($_GET["Barcode"],2,9)."))
    {
      if($data=mysql_fetch_row($res))
      {
        if($data[0]==20) // good job status so respond..
         die("OK:JOBTITLE=`".$data[1],"`:PLEASE SCAN ASSETID");
        else
         die("BAD Status");
      }
      else
        die("BAD Job Barcode");
    }
    else
     die("BAD Query"); // We Dont really want to report this to terminal!
 }
 else
   die("BAD Barcode Type");
}
else
  die("BAD parameter");

?>

So thats it, the way its all going to work (eventually). Not so hard really is it?

However back to the real world, I’m still real busy on both Islands of New Zealand. Vintage starts Monday in Gissy and early March in Marlborough, two months of nothing but support,

I cant wait to get back to normality!

Post Views:	00017
Site Views:	07486

Secret Sauce, (Putting the Mobile System altogether)

Roving Dynamics Ltd

Meta