The purpose of this Technical Specification is to define the requirements of the OCR/VCS Standard interface and to convey these requirements in context to the reader.
This document is arranged under 4 main clauses as described in Figure 1:
- UCM (Use Case Model) describes the use cases for the IC/ED Interface using sequence diagrams with messages.
- IDD (Interface Design Description) defines the data model for the IC/ED interface.
- SDD (System Design Description) defines the mandatory specification of the IC/ED interface in terms of architecture, services and behavioural models. In the Common Part of this clause no middleware or transport layer is specified. The common part of this clause is intended to be middleware-independent.
- SDD-TCP/IP, SDD-CORBA, in these specialized clauses. The specifications for 2 compatible transport solutions TCP/IP, CORBA are provided. Further middleware solutions (such as SOAP) can be added when available, provided that they are fully compatible with the Common Part.
As shown on Figure 2, there are many interfaces from an Enrichment Device to the rest of the system. This document is only concerned with the Mailpiece Processing part of the complete Standard Interface.
The mailpiece processing is concerned with the passing of a mailpiece to an Enrichment Device for processing.
Figure 3 depicts the system model of an Enrichment Device. As visible on the figure, an Enrichment Device is one of:
- an OCR:
a single or a pool of automatic recognition and interpretation engines, which are capable of retrieving information from an image of a mailpiece without human intervention;
- a VCS:
a single or a pool of video coding desks, which produce results from images of mailpieces; all tasks related to the management of the coders and the coding desks are encapsulated within the VCS system, or are accessible via interfaces which are outside the scope of the interface described within this document;
- a Voter:
a system which can determine the most appropriate result for a mailpiece using data and/or an image of a mailpiece; typically, a voter determines the most appropriate result from two or more results.
This document therefore covers the Mailpiece Processing interface between the Image Controller and the Enrichment Devices.
The document describes the requirements in the case of real-time enrichment: operational mode of an Enrichment Device, where the ED replies within the specified expiration time to the IC; the IC has to keep track of all mailpieces waiting for a reply from an ED. The ED does not keep persistence of mailpieces outside a channel connection with the IC. The ED has to have the processing power available to enrich a mailpiece. There is one and only one response for a mailpiece.
A later version of the document shall describe the case of deferred enrichment: operational mode of an Enrichment Device, where the ED may pre-request mailpieces from the IC. The ED has to keep persistence of the mailpiece to enrich it later and keep the result available for a result request from the IC. There is no response expected by IC from the ED.
The interface between Image Controller and Image Controller is NOT part of this document.
Furthermore, there may be many IC connected to many ED’s, as shown in the following object model:
The submission strategy in case of one IC connected to many ED’s is not part of the interface. It is for optimizing the mail flow in case of identical ED’s, or for defining the order in which different ED’s are activated (cascaded versus parallel submission).
The submission strategy of the IC shall be part of the specification and certification of the IC, which is not part of this document.
Required fields are indicated with *
