Core Elements of the Intelligent License Plate

As mentioned in my last post, the concept around intelligent license plates relies on contextual information (meta data) combined with a scan event to trigger 1 or more workflows that can automate the job of the manufacturer.  In a typical software automation solution, the logic related to all operations exist in the core of the application.  By using this new paradigm, the scan itself can trigger unique business rules outside of the core system.

An ILP (intelligent license plate) system needs a way to manage the existence and archival of unique sequences of digits.  This system should include the ability to insure uniqueness as the use of the system grows.  Note that as the size of digits grow, the size of the barcode needs to also be considered.  An ILP needs the ability to include non-unique barcodes which may be unique for a specific purpose or external party.  An example would be generation of UCC128 data.  Some large customers require specific ranges of data to meet their needs.  The distribution of these numbers must also support client side generation for disconnected operations.  Ranges or unique seeds must be created to avoid duplication of digits.

Secondly, ILP systems need to manage the mapping of the barcode + metadata to a set of workflows or states within a state machine.  The workflow management should allow for synchronous and asynchronous execution.  Asynchronous would be a good candidate for secondary reporting data that drives a data warehouse or reporting cube.  In scenarios where the mapping results in a sparse matrix (many possible inputs) and a workflow is known, ranges of values must be easy to define.  In scenarios where a workflow is not known, a special workflow termed “universal state” should be in place as a sort of “catch all” for loosely defined or highly dynamic business rules.

ILP Processing Engine consumes the inputs and processes the state machines and workflows.  It is tightly coupled with the ability to query various areas of the core system as well as generate external calls (service end points).  It must transact inventory operations (change, move, transform), generate new ILPs, produce audit trails, and generate user messages.  The processing engine is responsible to providing a standardized approach to all these areas.  To deal with a variety of needs, the processing engine must support fast operations, and slower loosely coupled operations that must traverse large sparse matrix of states.

About these ads