Specify a system which permits a customer technician to lay out a series of screens to collect status, field measurements, and commentary from quality analysts on the production floor or in the lab.   Collections can be by shift, warehouse, lot, production line (or any other keyset).  These are then stored in database tables from which reports can be generated.   Collection is performed on a handheld (telnet or windows CE), or on a windows workstation.

A maintenance tool will be constructed that is used to describe each screen and the fields they will contain.   The field has a name and a screen legend (which can be internationalized) and a technical component comprised of the control, and its constraints.    Controls determine the screen interaction and data type and the constraints set up how the field will work and how validation will be done.   Constraints can be hard constants, or numbers which can be looked up in a spec.   The spec allows, for example, a limit setting to vary depending on the product type, the warehouse, or the species of the product.

Once the design is set up, these are made into configuration files which are then downloaded into the handhelds where they will operate.   The database tables are set up and provisioned to work with the screen design.

The handhelds communicate with a server via web service protocols.   A service on the backend processes the interactions with the handheld screens and saves the data in the database as needed.

There will also be a way of building high level menus so that an operator can get down to their data collection screens.   Another optional system is the ability to specify a workflow.    In a workflow scenario, the system will know what fields need to be filled in by an operator in a particular role.   If serveral people are in the same role, they can each work on parts of the data collection.   Once a screen is filled in, that (and the id of the operator and the time) is also recorded, so the the remaining parts of the workflow can be assigned to the next operator.

Individual screens are each attached to a master key.  The keys are typically some business entity, like a Lot/Warehouse/Tank, or a Warehouse/Shift, or a Warehouse/Shift/Measurement (for random or periodic measurements), or the Lot/Item.   These typically are stored as a single row in the database where all of the screens of the same key use the same table (this can be overridden to make different tables if desired--screens of a given master key would then have any number of discrete tables as desired).

There are currently three different clients for the client side of the application:

·         A .net WPF client running in a workstation application we call the Studio.

·         A Windows Compact Framework application that works on several versions of Windows CE.

·         A VT100 compatible version for older text based handhelds, dedicated, and fork lift mounted hardware.  The client connects via telnet or SSH to the server.

The client programs communicate to the central server via the .net WCF framework (web services) to get their configuration and screen layouts as well as handling the dialog between the user and the backend software.

The server runs as a windows service and communicates with the database and interactions with the clients.   It will automatically build the configuration files for the clients and update them when the configurations change and will provision the database (creates tables or add fields) as needed.

The system can be integrated in with various types of business objects within your ERP or warehouse management system.    Users, Warehouses, Cases and Pallets, Shifts, Lots, and other entities can be used as keys or fields (and can be looked up in the ERP database).  These can be used for validation (only a valid object can be used) or for simple lookups to display values from these entities on the screen, such as looking up a case and seeing it's weight, or looking up a lot and seeing it's production date.   Simple lookups can also be used as values for field constraints.

Our client architecture allows devices, tanks, tubs, lines, printers, scales (durable pieces which are parts of the factory or are continuously recycled and don’t leave the factory like pallets and cases do) with permanent barcodes which are encoded with a noun-type and a unique identifier.  These barcodes can be printed on durable tags (such as stainless steel or plastic) and permanently mounted on these items.    The scanners will automatically see these nouns and put the data into the correct fields on the screen automatically.   A handful of nouns, can also have associated action barcodes which can cause a value to be set or read on a device, like reading the value from a telemetry system, like a scale reading or a temperature reading.   Some actions can also be triggered to make an ad-hoc measurement that will automatically be entered into the reporting database.   Transient inventory entities can be tagged this way as well (lots, pallets, cases) for specialized reports which you might want to scan but you would not want to send these types of barcodes to your end-customers.

A handful of action barcodes aren’t tied to a noun, but perform a special action on the dialog you’re in (often in lieu of a similar keyboard action), like incrementing a tally, scrolling up or down on the screen.

Another barcode integration can be set up we call a verb tag.   A verb tag barcode will cause a handheld to automatically switch to the dialog which is indicated by the code.   These can be used to build barcode based work menus.  These are especially useful for forklift operators who wear heavy gloves and can’t use a keyboard but can still operate the trigger on the handheld (or a separate scanner for a fork-truck computer).   It can also be useful to quickly get to menus that tend to be tied to a place or a device (like taking a reading from something).

A barcode which is not specially tagged with a noun, verb, or action prefix will be sent to the server for disambiguation.  The server will try to determine what kind of business entity it is by trying to look it up.   If there’s a conflict (say that’s a valid case and pallet #), it will ask you to decide which it is.  If it can’t, the client will simply drop that into the current field.  

The system will also break up packed barcodes such as the EAN/UCC-128 style barcode and map the internal field identifiers onto a noun.   This can be used to enter several things with one scan.  These maps can be user assigned.  There are also a few of the unassigned identifiers which can be used for nouns outside of the EAN/UCC-128 scheme.

We can also perform similar integrations with various RFID devices.

Users must log in with a password (or a special barcode or RFID token) to use the system.   Each user is given a set of privileges which denote which screens they can see and modify.   Similarly, users are assigned to roles in the workflow system to denote how work will be given to them automatically.   Supervisors are given special privileges to permit them to set up the system and to assign privileges to others.

Besides providing one of the client environments for the system (under windows), the Studio also provides the tools to manage and set up the system.   This is where the user builds screens, defines workflows, assigns roles, make maps for barcodes, and reviews the collected data.

Studio is a tool that permits the users to work on several different things at once as needed and can also export data to Excel for further analysis.

It has its own security/access controls.

The system only has simple reporting and the ability to export data to Excel.   It is intended that this system work with a backend reporting system such as Crystal or Microsoft Reporting Services to generate initial paperwork – most QC departments will want to emulate their existing manual reporting with a set of similar preprinted reports and then may evolve into a fully online system with online reports or screens.

We will look through the reporting use cases and determine if some standard reports are appropriate.

Once this data has been collected it will be possible to do more long term analysis, doing more statistical work and trend  analysis.   We may include data collection tools to summarize this data and/or graph it.  

Similarly, some results or trends might trigger alarms which might need to be reported via email or even a pager.

 

 

A quick set of example controls.   We will be reviewing several use cases for this system to flesh out all of the control types and options which will be needed.

·         Inspection Types

o    Check (pass, fail, and not yet set) – allows an QC operator to judge the status of an item.

o    Temperature – record a temperature

o    Meter – record a meter reading

o    Count – record a count

o    Tally

·         Data Entry

o    Enter a string field

o    Display a value

o    Select an item from an enumeration

o    Enter a true/false

·         Optional/Mandatory Comment

·         Noun – set the noun type for the field (barcodes of this type will then drop into this field automatically)

·         Validate – the noun will be validated by the server to ensure that the value is relevant.

·         Min/Max against constant

·         Min/Max against spec

·         Min/Max against another field

·         Min/Max against table lookup

·         Constrain against SQL query

·         Is Key (or part of key) for a table lookup

·         Hard Limit – don’t permit value higher or lower to be entered

·         Soft Limit – permit value but flag it as out of range (turn red)

·         Soft Limit fail with Mandatory Comment

·         Comment Mandatory on check fail

List of potential key types (many other are likely) – the goal is to permit keys to be built dynamically as needed.

·         Lot

·         Lot/Tank  (Lot/Warehouse/Tank)

·         Warehouse/Shift

·         Warehouse/Shift/Random Sample

·         Warehouse/Measurement (time)

Specs are a set of numbers which can be used to determine constraints for field entries.   These permit the values to vary by some relevant attribute of what is being measured.

·         By Customer – different customers will have different quality standards

·         By Species, Item, or Product – different QC standards for each possible type

 

A lot of modern scanners can be equipped with camera instead of laser based barcode units.   Also, many of these cameras can be used as a simple camera (1-2 megapixel).

We want to add the capability for an adequately equipped scanner, to be able to capture pictures at will.   Any comment field will permit pictures to be attached to it, as will any screen.   If you operate the camera at any point it will capture the picture and let you tag it with a comment.