On RFID software

There are customers and integrators that underestimate or do not appreciate the complexities of the problems involved in delivering an RFID solution. Software for RFID is something that is currently not well documented. The knowledge is not readily accessible to developers. At this post, let us consider some aspects of software for RFID.
1 - The customer often needs enterprise software for RFID. That means a solution that focuses on the business problems (and practical problems!). More often than not RFID will be just one piece of the solution. One important piece, and one piece that requires integration. But one piece among others likely. For instance, integration between the new system and ERPs or WMSs may be required. A good integrator will approach the problem aiming at a solution.
2- This is a corollary of the point above: RFID is not just about hardware. Many people spend lots of time thinking about the physics of RFID and forget (deliberately at times) about software. Good read rates is only part of the problem. (A non-problem really for software!) Middleware is a commodity now, so think of RFID hardware as any other hardware (printers, memory, hard disks, keyboard), and begin to work on how your software will address the business problems. Forget about read rates. Leave that with the hardware providers.
3- Think about the network. More specifically, the 'cloud' and the 'edge'. More generally, RFID requires software to be distributed because tagged objects are moving! Since objects go from A to B, your software needs to be in A and B. Now thinking about common roles and scenarios where RFID is deployed into, there's the 'cloud' and there's the 'edge' more often than not. RFID software in the 'cloud' is generally for managers and IT, whereas at the 'edge' is for 'warehouse workers'. This has many implications. The first direct implication is that the software gets to be partitioned: part lives at the cloud and part at the edge. While there's room for debate over what feature should live where, some restrictions apply. There's a network penalty for the edges to access the cloud. Ideally actions that require fast response or local data (data that applies to this instance of the edge) should be accessible from the edge. For instance, gadgets at the warehouse should be controlled by software at the edge and not the cloud. Reports (which require often consolidated data from all edges) are recommended to live in the cloud. Most middleware provide control for readers in a central location, so that's not a problem. Depending on the size of the deployment, you will want to think about the replication of two elements: data and rules. Depending on the location of the ERP and WMS systems you'll have data integration in the cloud. This data, however, is likely to be used at the edge. In the second case, depending on the size of deployment again, you'll want to update business rules (or new versions of software) only at the cloud and have them to migrate to the appropriate instance of the edge.
4- Time is important in RFID implementations. To begin with there are three agents that produce 'events' (there's a word that is abused): readers, software and humans. Tag reads happen and software has no control over when they happen (that is, they happen asynchronously. Well, there are synchronous tag reads. For example, tag reads triggered by handhelds are synchronous). Processes generally have two variants: those with beginning and end, and those which are 'continuous'. You may have a human beginning and ending a process, and you may have to coordinate or fit in tag reads within the (logical) process. Most software implementations will just ignore this and code everything inside the business components. And most middleware won't model the problem. (By the way, this has nothing to do with EPC-IS... initially). The best thing you can do is to think about timing issues and think about how to model processes generically. Besides the problem of coordinating time between tag reads and processes, there's always the UI. Yes, you'll have to take into account when tag reads occur and when and how to show them in the UI. With all this, try to design the software properly... (boa sorte, meu fio.)
5- Think about location and processes. Have your terms well-defined. When thinking about processes, the two variants above may convey different meaning. For instance, a tag read in the ' continuous' case may mean that the tag underwent the process (and is 'out' of the process). A tag read in a process with beginning and end may be held by the process until it's explicitly out of the process when it ends. This is specially true when there is a group of tag reads that 'enter' a process and depend on humans to exit the process. That is, it is as if tag reads are temporarily held at the process. From a business point of view the tag reads only occurred after the tags exited the process. Define a precise vocabulary with the business peers, setting what 'location' and 'process' mean.
6- Association is important. More often than not, RFID tags are attached to something. The business is usually interested in this something and not the tag itself! So think about tag associations. (One sample question to the customer: 'Are objects always associated to the same tag forever?')
7 - Think about when to use handhelds and when to use fixed readers. The primary business decision relates to labour and hardware costs. However, think about the differences for software. Mobile software is a subject that is vastly documented and explored, so there's no need for me to write too much about it. Software on handhelds must take into account network constraints (on-off connectivity, operating disconnected if needed, network latency, control of software version, manageability of software updates, etc), synchronization challenges (collecting or changing data offline), limited displays and resolutions (which requires a whole rethinking of the UI and usability), etc. Also, bear in mind that most middleware to-date are for non-mobile platforms (stay tunned, however...). You may be required to develop with proprietary APIs for handhelds. If you'll use a browser in the handhelds, be mindful of differences in JavaScript support among browser versions and so on.
8 - Think about tag encoding. Yes, tag encoding is the kind of thing that everybody knows that exists, is well documented and so on. When it's time to develop you'll find all sorts of practical problems on how to represent tag numbers. Is it binary, decimal, hexadecimal, hexadecimal string, ASCII of the binary, LSB or MSB and so on! Then add the EPC encodings and variants and there you go: if you don't plan it well, when tag numbers flow from one place to the other there's room for problems. It may be from database to business components, or from UI to business component, or from exchange between different internal modules, or with external software. Think about your encodings in detail, and of any transformation the encodings may undergo.
9 - Don't write to the tag what you can write in the database. A few people look for writable tags and rank tags according to the space available in user memory. Avoid writting structured information to tags. I would argue: avoid writting to tags if at all possible. Begin by thinking about the business problem you are trying to solve. Then think well about the software design. Seek advice from your friends on the software design. Criticize it and so on. Only after check if you need to write to the tag. The argument for not writting structured data to the tag is scalability. What if the structure changes and you have thousands of tags deployed? Will you recall and reencode all of them? Will you do so at once or live with mixed data structures? It would become a mess. If all the business requirements need is identification of goods/objects /entities don't complicate the software. Go with just reading the tag identification.
10 - EPC-IS é um bicho de 7 cabeças complexo e distante. É como Exú Caveira: todos dizem que existe mas eu nunca vi. Um dia eu vou aprender o aperto de mão secreto e vou entender pra que server EPC-IS. De acordo com os búzios, EPC-IS é um negócio complicado e misterioso que se aplica a troca de dados entre múltiplas empresas. Só os iniciados é que entendem e podem aplicá-lo. Mas pra que sofrer desnecessariamente? Como um bom brasileiro, pense no problema que seu negócio tem e vejas as ferramentas e alternativas disponíveis. Dê um jeitinho brasileiro.

That's all for today, folks.

Happy RFID deployment!