CEN/TS 15448:2006

SLOVENSKI STANDARD
01-januar-2007
3RãWQHVWRULWYH2GSUWLVWDQGDUGQLYPHVQLNPHGREGHORYDOQLNRPVOLNHLQ
QDSUDYDPL]DRERJDWLWHYRSWLþQRSUHSR]QDYDQMH]QDNRY2&5VLVWHPL]D
YLGHRNRGLUDQMHJODVRYDOQLVLVWHPL
Postal services - Open standard interface between image controller and enrichment
devices (OCRs, video coding systems, voting systems)
Postalische Dienstleistungen - Offene Normschnittstelle zwischen Bildbearbeitung und
Anreicherungsgeräten (OCR, Videocodierungssystem, Abstimmungssysteme)
Services postaux - Interface de standard ouvert entre un contrôleur d'images et un
dispositif d'enrichissement (lecteur optique de caracteres, vidéocodage, voteur)
Ta slovenski standard je istoveten z: CEN/TS 15448:2006
ICS:
03.240 Poštne storitve Postal services
35.240.60 Uporabniške rešitve IT v IT applications in transport
transportu in trgovini and trade
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

TECHNICAL SPECIFICATION
CEN/TS 15448
SPÉCIFICATION TECHNIQUE
TECHNISCHE SPEZIFIKATION
October 2006
ICS 03.240; 35.240.60
English Version
Postal services - Open standard interface between image
controller and enrichment devices (OCRs, video coding
systems, voting systems)
Services postaux - Interface de standard ouvert entre un Postalische Dienstleistungen - Offene Normschnittstelle
contrôleur d'images et un dispositif d'enrichissement zwischen Bildbearbeitung und Anreicherungsgeräten (OCR,
(lecteur optique de caractères, vidéocodage, voteur) Videocodierungssystem, Abstimmungssysteme)
This Technical Specification (CEN/TS) was approved by CEN on 3 July 2006 for provisional application.
The period of validity of this CEN/TS is limited initially to three years. After two years the members of CEN will be requested to submit their
comments, particularly on the question whether the CEN/TS can be converted into a European Standard.
CEN members are required to announce the existence of this CEN/TS in the same way as for an EN and to make the CEN/TS available
promptly at national level in an appropriate form. It is permissible to keep conflicting national standards in force (in parallel to the CEN/TS)
until the final decision about the possible conversion of the CEN/TS into an EN is reached.
CEN members are the national standards bodies of Austria, Belgium, Cyprus, Czech Republic, Denmark, Estonia, Finland, France,
Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania,
Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION
EUROPÄISCHES KOMITEE FÜR NORMUNG
Management Centre: rue de Stassart, 36  B-1050 Brussels
© 2006 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TS 15448:2006: E
worldwide for CEN national Members.

Contents Page
Foreword.4
Introduction.5
1 Scope .6
2 Normative references .9
3 Terms and definitions .9
4 Symbols and abbreviations.11
5 The use case model.11
6 Overall Description.12
6.1 Use-Case Model Survey.12
6.1.1 Connection Use Case Model .12
6.1.2 Channel Use Case Model.14
6.2 Assumptions and Dependencies .15
6.2.1 Image supply.15
6.2.2 Control .15
6.2.3 Output .15
6.2.4 Enrichment .15
6.2.5 Data Representation.15
6.2.6 Image Representation .16
6.2.7 Channel Concept .17
6.2.8 Client/server model .19
6.2.9 Naming Service.19
6.2.10 Connection Sequence .19
6.2.11 Flow Control Model .20
7 Specific Requirements.22
7.1 Use-Case Reports.22
7.1.1 UC001 - Publish Presence .22
7.1.2 UC002 - Connect .25
7.1.3 UC003 – Disconnect .32
7.1.4 UC004 – Open Channel .35
7.1.5 UC006 – Get Enrichment Device Status.37
7.1.6 UC101 – Close Channel.39
7.1.7 UC102 – Control Flow.43
7.1.8 UC103 – Request Channel Status .46
7.1.9 UC104 - Submit Mailpiece.48
7.1.10 UC105 – Transmit Result .50
7.2 Supplementary Requirements.52
7.3 Rejections.53
Discarded Use Cases .53
Annex A (normative) SDD .54
A.1 Purpose.54
A.2 Scope .54
A.3 Overview.54
A.4 Architectural Goals and Constraints .54
A.4.1 Client Server Model .54
A.4.2 Client / Servant Relationships.54
A.4.3 CORBA Naming Service.58
A.5 Class Model.60
A.5.1 Overview.60
A.5.2 Interface: IEnrichmentDevice .62
A.5.3 Interface: IImageController.65
A.5.4 Interface: IEDChannel .66
A.5.5 Method: requestChannelState() .67
A.5.6 Interface: IICChannel.68
A.5.7 Data definition.70
A.6 Behavioural Model.75
A.6.1 Connect .75
A.6.2 Disconnect .86
A.6.3 Open Channel .93
A.6.4 Close Channel.96
A.6.5 Control Flow.98
Annex B (normative) IDD .107
B.1 Purpose .107
B.2 Scope of IDD .108
B.3 Prerequisites.108
B.4 Overview.108
B.5 Section A – TIFF Definition.109
B.5.1 Tiff Usage .109
B.6 Section B – Mailpiece Data Definition .114
B.6.1 Requirements.114
B.6.2 Model Commitments .119
B.6.3 Domain Data Model & Types .121
Annex C (Informative) .179
C.1 Introduction to XML.179
C.1.1 XML Document Structure .179
C.1.2 Introduction to XML Schema.180
C.2 XML Schemas .182
C.2.1 Domain Instance Types .182
C.2.2 Base Types.183
C.2.3 Generic Types.191
C.2.4 Primitives .193
C.2.5 Example of a Customer specific Schema Definition .197
C.3 The XML Instance Document .201
C.3.1 Type Assignment in the Instance Document .201
C.3.2 Examples.201
Bibliography.213

Foreword
This document (CEN/TS 15448:2006) has been prepared by Technical Committee CEN/TC 331 “Postal
Services”, the secretariat of which is held by NEN in collaboration with UPU.
NOTE This document has been prepared by experts coming from CEN/TC 331 and UPU, under the frame of the
Memorandum of Understanding between UPU and CEN.
According to the CEN/CENELEC Internal Regulations, the national standards organizations of the following
countries are bound to announce this CEN Technical Specification :Austria, Belgium, Cyprus, Czech Republic,
Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania,
Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden,
Switzerland and United Kingdom.
Introduction
There is a growing demand on the postal operators to combine parts of their sorting automation equipment
from different suppliers to optimise performance. In the past this has led to project specific interfaces being
negotiated between one postal operator and one or multiple suppliers. These project-specific interfaces were
developed by the suppliers and maintained for an agreed period of time. This approach has several
disadvantages:
- The interface is derived from an interface that was not intended to be open.
- The interface is developed for a single project and works only in the context of that project (extra costs).
- Each participating supplier has to implement the interface (multiple effort).
- Experience shows that integration of components with project-specific interfaces is complex and
expensive.
- Project-specific interfaces are not integrated into the product line and once the initially agreed
maintenance period is over it may be difficult and expensive to maintain and/or may hinder the adoption of
equipment upgrades.
This has led to “open interfaces” defined by one supplier. These still have the disadvantage of being in
product use by only one supplier.
Within a group of postal operators and suppliers it was decided to develop a set of “open standard interfaces”
which will be developed by the suppliers and referred to by the postal operators. The benefits of these
interfaces are expected to be that they:
- are fixed in an international standard (with change control);
- are agreed and implemented by major suppliers;
- are agreed by customers and therefore used in calls for tenders;
- will result in net savings with the high initial development effort and consequent higher basic equipment
prices being more than offset by reduced project development, integration and maintenance costs;
- will minimize the need for project integration effort by reducing implementation timescales;
- will increase competition between suppliers by stimulating product improvements;
This standard covers the interface between an image controller and so called enrichment devices (OCR,
Video Coding System or Voting System).
Other work items (subject to agreement of CEN/TC331 and the UPU Standards Board) will be defined to
cover other areas as and when the need is identified and the resources for development become available. A
separate project group for each interface will undertake the work.
1 Scope
The purpose of this document is to define the requirements of the OCR/VCS Standard interface and to convey
these requirements in context to the reader.
The interface specification is contained in the two appendices of this document, both of them normative:
• System Design Description (SDD)
This document specifies the class model, dynamic behaviour and exception handling of the interface.
The API is included.
• Interface Design Document (IDD)
The IDD in Annex B defines the “payload” information for the interface. That is the data which is
required for processing a mailpiece e.g. TIFF image format and XML data.

Figure 1 – Interface environment of an Enrichment Device
As shown on Figure 1, 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 2 – System model
Figure 2 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:

Figure 3 – Communication relationship between IC and ED

The submission strategy in case of one IC connected to many ED’s is not part of the interface. It is for
optimizing 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.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, or references to a version number, only the edition cited applies. For undated references and
where there is no reference to a version number, the latest edition of the referenced document (including any
amendments) applies.
1)
UPU S42 , International Postal Address Components and Templates
3 Terms and definitions
3.1
Actor
Coherent set of roles those users of uses cases play when interacting with these use cases. An actor has one
role for each use case with which it communicates. See [UML]
3.2
Attributes
All non-image information related to a mailpiece
3.3
Coding Desk
Computer or terminal equipped with a software to display images of mailpieces, and designed for a human
operator (video coder) to enter information about the mailpiece
3.4
Component
Software Unit with a defined interface; might contain other components
3.5
Data element
Simple data type
3.6
Data object
Assembly of elements [1.*] and/or other data objects; recursive type
3.7
Enrichment
Process of generating new information about a mailpiece
Note Any information about the mailpiece may be used in this process, such as the image, image information or
result data. The use of an image however, is not compulsory
3.8
Enrichment device
System designed to enrich information about mailpieces

1) UPU Standards are obtainable from the UPU International Bureau, whose contact details are given in the
Bibliography; the UPU Standards glossary is freely accessible on URL http://www.upu.int.
3.9
Flow control
Principle of sending images of mailpieces from an IC to an ED: either on request of the ED (“request” mode),
or at a pace defined by the IC, with emission suspended/resumed on request by the ED
3.10
Image
Data acquired by the Image Supply and stored as part of the mailpiece
3.11
Image controller
System designed to handle the flow of images and data issued by the Image Supplies and sent to the
Enrichment Devices
Note The Image Controller also controls the results from image enrichment
3.12
Infrastructure data
the basic information, such as identification references which an Image Controller and Enrichment Device
require in order to communicate effectively
Example Letter ID, Submission ID.
3.13
Mail object
Letter, Flat, Parcel, Postcard etc.
3.14
Mailpiece
All information stored about a single physical mail item (letter, flat or parcel) in an IC
3.15
Mailpiece data
The information which describes attributes of the physical mailpiece which is used to aid and is a product of
enrichment
Example mailpiece width & height, indicia information, address location, city name, sort code etc.
3.16
Offline
Operational mode of a sorting machine, in which some processing of mail is done after the mail has been
nd
conveyed in the machine; there is a need for printing an ID-tag, to identify the mail for which a 2 sorting pass
is required
3.17
Online
Operational mode of a sorting machine, implying all the processing of mail is done while the mail is conveyed
in the machine; there is no need for printing an ID-tag
3.18
Permanent Error
Fatal error as indicated by the middleware or application layer.
Note A non-fatal error may be considered to be a permanent error after repeated remedial handling
3.19
Result
Outcome of enrichment
3.20
Street
Street keying (street name and/or house number in street)
3.21
System
Consists of components and the relationships between them (interfaces, communication)
3.22
Voter
System which can determine the most appropriate result for a mailpiece using data and/or an image of a
mailpiece
4 Symbols and abbreviations
ED: Enrichment Device
GUI: Graphical User Interface
IC: Image Controller
ID: Identifier
IDD: Interface Design Description (Normative appendix of this document)
OCR: Optical Character Recognition
PC: Post code
PM: Project Manager
ROI: Region Of Interest
SDD: System Design Description (Normative appendix of this document)
UCM: Use Case Model document (Main part of this document)
VCS: Video Coding System
W3C: World Wide Web Consortium
XML: eXtendable Markup Language
5 The use case model
The Use Case Model (UCM) defines the requirements of the CEN OCR/VCS Standard interface. The
document utilises UML use cases and other modelling techniques as well as textual information to convey the
requirements.
The document contains the following sections
• Overall Description
The use case model for the installation is described
• Specific Requirements
The use cases are described in detail including all supplementary requirements.
6 Overall Description
Unified Modelling Language has been used to describe the use case model. Details of UML can be found in
[UML_OES], [UML_ALH] and [UML].
6.1 Use-Case Model Survey
The Use Case Model is separated into two groups of use cases: those which are relevant for the connection
to an Enrichment Device system, and those which are relevant for managing and using a channel.
6.1.1 Connection Use Case Model
The connection use cases (Figure 4) apply to the Enrichment Device as a complete component. They enable
a connection to be established and channels to be opened as well as the status exchange of the complete
Enrichment Device.
Figure 4 – Connection use cases
6.1.1.1 Actors
Name Description
Image Controller Software: The Image Controller is a complete software system which is possibly made up of many software
components deployed on multiple hardware nodes. The IC is responsible for distributing images from the image
Name Description
sources to the Enrichment Devices and handling the results which are generated. The IC is responsible for the
strategy for distributing the images.
Customer Human: The Customer actor is a human who is able to start and stop the components.
Timer Software: A timer which triggers events at defined intervals.

6.1.1.2 Use Cases
ID Name Description
UC001 Publish Presence The Enrichment Device presents is presence to the Image Controller when it is switched
on. Following strict client-server rules, the ED (the server) is passive and is connected-to
by an IC (client).
UC002 Connect The IC detects an ED which it wishes to utilise for processing mailpieces. It connects to
the ED in order to use the processing capabilities of the ED. During the connection, the
capabilities of the ED are exchanged with the IC.
UC003 Disconnect A disconnect is bi-directional. A disconnect implies closing any opened channel within the
connection
UC004 Open Channel The Image Controller opens a coding channel.
A channel defines the subset of the published capabilities
The flow control is related to a channel.
UC005 Put ED Status 2
The ED indicates to the IC any relevant data about its status
UC006 Get ED Status The IC needs to know the global status of ED:
• to be able to go further in the transactions
• to display the status of the ED on the IC’s GUI

Deleted: This use case describes a message and not a use case. Remove this UC because the aims of the message
can be covered by a) ED disconnects from IC is covered in UC - Disconnect. B) The need for the ED to know if the IC is
present, can be fulfilled by checking if "Get ED Status" is executed or by observing its channels
6.1.2 Channel Use Case Model
These use cases (Figure 5) apply to a channel which has been previously opened. They allow the closing of
a channel, the processing of mailpieces and the exchange of the channel status.

Figure 5 – Channel use cases
6.1.2.1 Actors
Name Description
Image Controller Software: The Image Controller is a complete software system which is possibly made up of many software
components deployed on multiple hardware nodes. The IC is responsible for distributing images from the image
sources to the Enrichment Devices and handling the results which are generated. The IC is responsible for the
strategy for distributing the images.
Disconnect Use Case : See UC003 - Disconnect
State Manager Software: In a “real-time” processing environment the Enrichment Device must have the ability to control the flow
of images which is receives from the IC. This actor is used to represent the capacity of the ED. . When this
capacity of the channel is exhausted, the flow of images from the IC is stopped and vice-versa.

6.1.2.2 Use Cases
ID Name Description
UC101 Close Channel Close the channel and optionally discard any pending work
UC102 Control Flow Control the flow of mailpieces from the Image Controller. See 6.2.11Flow Control Model
UC103 Request Channel Status The IC requests from the ED any relevant data to manage a channel
UC104 Submit Mailpiece A mailpiece is submitted to the ED for processing.
UC105 Transmit Result A result is transmitted from the ED to the IC for every mailpiece which was previously
submitted.
6.2 Assumptions and Dependencies
6.2.1 Image supply
Image supply is to be understood as a resource of images. Images might come from:
• Image capturing devices
• Fed via network or from an image server
• Other systems that can supply images
6.2.2 Control
The Image Controller (IC) handles the flow of images and data. It also controls the results from image
enrichment. If parts of an image are distributed to different Enrichment Devices it is the task of the IC to keep
track of these parts and collect the returned data.
• There may be more than one ED connected to an IC.
• There may be more than one IC connected to an ED.
6.2.3 Output
The enrichment will produce results, which have to be delivered to other systems. This would normally be
sorting machines or statistical systems.
6.2.4 Enrichment
This part of the system enriches the mail piece data. This might be done by Video Coding, OCR or Voters.
The interface described in this document should allow for parts of an image to be distributed.
Example The stamp region might be sent to a special stamp reader or the address region to an address reader.
6.2.5 Data Representation
Only image relevant data will be stored within the TIFF image. All postal data (mailpiece attributes) will be
transferred using XML. Infrastructure data needed for communication between IC and ED will be transferred,
not necessarily in XML – see [Annex B] for more detail.
Mailpiece attributes (in XML), image (in TIFF), and infrastructure data are transmitted together, excluding:
• embedding XML in TIFF
• embedding TIFF in XML
• referencing of the image in the XML data
Transferring images by reference shall be evaluated in a later version of the interface; this is not done in the
current version of interface for following reasons:
• need to define the protocol for referencing
• added complexity of the interface: need to add a GetImage use case as an alternative flow of
SubmitMailpiece
• added complexity of the interface to handle error cases, like ED failing to access the image
However, the need for transferring by reference exists:
• it may allow to reduce the network load within the ED
• it may allow to transmit different images (binary, greyscale, ROI…) depending on recognition step

6.2.6 Image Representation
All images are represented using the TIFF file format. The following restrictions apply:
rd
• TIFF file format will conform to the TIFF Revision 6.0 (June 3 1992) [TIFF] Baseline specification.
• TIFF file format will utilise the extensions described in [TIFF_TN2] to facilitate the inclusion of grey
scale images with baseline JPEG compression in the TIFF
• TIFF file will not contain any other data other than that which is required to describe the image itself.
• Refer to [Annex B] for a complete specification of the TIFF file format.

6.2.7 Channel Concept
The architecture of the interface is based upon the concept of virtual channels presented in Figure 6.

Figure 6 – Virtual channels concept
An interface between the Image Controller and an Enrichment Device consists of the following concepts:
• Connection:
There is only one connection between an IC and an ED. The connection is requested by the IC and
enables the ED to allow or deny the connection. ED may need to register its features in a repository
known by IC. The connection defines infrastructure information such as the version of the interface
and all the capabilities of the ED. The connection applies to the logical connectivity of the devices.
There is no restriction about the physical connectivity.
• Channel:
One connection may have many channels. A channel is a logical connection between an Image
Controller and an Enrichment Device. A channel defines the processing type; each channel has its
own flow control. A channel is associated to a unique bi-directional message and processing request
queue. More than one channel can be opened at the same time between an Image Controller and a
physical Enrichment Device.
• Session:
Sessions define a time periods, which are primarily used to control statistical information. Therefore it
is not within the scope of this version of the Mailpiece Processing interface. The interface allows more
than one simultaneous session to be active on a single channel. Since a session is a statistics
reporting device, it may be defined on attributes other than time, for instance originating machine, or
mail center.
Figure 7 and Figure 8 depict two typical uses of the channel concept, for an OCR system:

Figure 7 – Channel concept use cases

Figure 8 – Channel concept use cases

6.2.8 Client/server model
As far as possible the interface shall adhere to a strict client/server model, where the IC is the client and the
ED the server:
• all exchanges are initiated by the IC
• there is one and only one reply for each request
• the only exception are the exchanges required by the Flow Control mechanism (see 7.1.7 “UC102 –
Control Flow”)
6.2.9 Naming Service
In order to enable the components of the system (IC and ED) to communicate with each other with the
rd
minimal configuration effort, a naming service will be employed. A naming service is 3 party software which
enables object references from a component to be published for discovery by components which wish to use
these objects. See [OMG_NS] for more details.
6.2.10 Connection Sequence
The diagram on Figure 9 shows the agreed (CEN Suppliers Workshop 03/12/2003 – 05/12/2003 Barcelona)
connection model between an Enrichment Device and the Image Controller.
Note The sequence diagrams contained within these sections are for explanation purposes only and reflect the
common understanding which was gained by the CEN Suppliers group during the development of the specification. The
SDD in Annex A specifies the behaviour of the interface in detail using sequence diagrams

Figure 9 – ED- IC connection model
The Enrichment Device registers its presence and the services it provides in a repository, when it starts
running.
Insofar, the ED is the initiator of the connection.
The Image Controller tries to establish a connection to the ED through browsing the repository for the desired
service. The ED can accept or deny the connection request.
After a connection has been established, the IC requests the capabilities of the ED; the ED returns its
capabilities.
The capabilities should describe the full functionality of the ED, not considering temporary conditions derived
for example by the status of the Video coding pool.

6.2.11 Flow Control Model
The flow control between an Enrichment Device and the Image Controller can be based on one of two
possible models, request or semaphore model. The model-of-choice selected in the suppliers workshop (CEN
Suppliers Workshop 03/12/2003 – 05/12/2003 Barcelona) is the semaphore model; this decision is logically
linked to the decision of declaring the IC as the client and the ED as the server, as this simplifies the
transactions between ED and IC and helps sticking to a “pure” client/server model.
The major shortcoming of this model is the possible “overflow” of the ED, while the IC has not processed the
flow control request; this is critical in case of on-line video coding and has been solved by setting a limit in the
number of pending transactions.
The Image Controller opens the required channel (depending upon the mailpieces which require processing).
The Enrichment Device allows or denies the open channel request. Mailpiece processing may now start.
The sequence diagram presented on Figure 10 shows how the IC can open the channel for the capability C1,
and how the flow control (PutChannelStatus) can be used by the ED over this channel to request mailpieces.

Figure 10 – Open a channel for certain capabilities
The diagram presented on Figure 11 shows how the ED regulates the flow of mail pieces submitted by the IC

Figure 11 – Mail pieces flow regulation
In the semaphore model, the Image Controller submits mailpieces to the Enrichment Device until the
Enrichment Device signals that the Image Controller should stop.
The Enrichment Device maintains an internal queue which has upper and lower threshold limits. When these
are reached, the Image Controller is instructed to stop or start submitting mailpieces respectively.
Results may be transmitted out of sequence.
The Enrichment Device may dispatch the images internally for parallel processing, but the enrichment
operations (OCR or video coding) will not necessarily complete in order. Since the IC has to keep track of
outstanding requests anyway, it should be able to handle out-of-order result transmissions.
In case of many ICs connected to the same ED, the ED must guarantee one queue for each IC. If there is a
maximum number of IC connections (or Channels) acceptable for an ED, and if this maximum number of
channels has been reached, the next Channel request should be refused by the ED. The ED has the
responsibility to manage load balancing between the different channels.
After closing of a channel, neither the IC nor the ED has to keep track of any outstanding transaction. The ED
shall delete the relevant images.
7 Specific Requirements
7.1 Use-Case Reports
7.1.1 UC001 - Publish Presence
7.1.1.1 Brief Description
When an Enrichment Device is switched on and ready to be used by an IC, it publishes its presence in a
naming service which the IC can use to discover Enrichment Devices which are available.
7.1.1.2 Actors
• Customer
7.1.1.3 Flow of Events
7.1.1.3.1 Basic Flow
The basic flow covers the scenario where no exception handling is required. The naming service for
publication is available and can be reached by the ED, and there is no existing entry for this ED.
1. The customer switches on the Enrichment Device
2. The Enrichment Device starts and prepares itself to handle connection requests from the Image
Controller.
3. When the Enrichment Device is ready to handle connection requests, it publishes its presence in the
naming service which is used by the IC to discover available Enrichment Devices.
4. The entry in the naming service is identified by the following parameters:
a. The manufacturer of the Enrichment Device
b. Name of the Enrichment Device as defined by the manufacturer
c. The version of the interface
d. Incarnation Identification
a unique identification of this Enrichment Device in the naming service.

Figure 12 – State diagram ED
The state diagram (Figure 12) shows that the ED is only published when it is ready to accept a connection
request.
If it is not ready to handle a connection request, it is not published.

7.1.1.3.2 AF001-01: Enrichment Device cannot register.
If the Enrichment Device cannot register into the naming service, it will attempt to register again after a delay
defined by the supplementary requirement Publish_Retry_Delay. Until the registration is successful the
Enrichment Device will remain unavailable for the Image Controller.

7.1.1.3.3 AF001-02: Naming Service contains an entry for the Enrichment Device
If the naming service already
...