Postal services - Open standard interface between image controller and enrichment devices (OCRs, video coding systems, voting systems)

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.

Postalische Dienstleistungen - Offene Normschnittstelle zwischen Bildbearbeitung und Anreicherungsgeräten (OCR, Videocodierungssystem, Abstimmungssysteme)

Services postaux - Interface standard ouverte entre le contrôleur d’images et les dispositifs enrichis (OCR, systèmes d’encodage vidéo, systèmes de votes)

Poštne storitve - Odprti standardni vmesnik med obdelovalnikom slike in napravami za obogatitev (optično prepoznavanje znakov (OCR), sistemi za videokodiranje, glasovalni sistemi)

Namen tega tehničnega poročila je določiti zahteve za vmesnik standarda OCR/VCS in te zahteve bralcu podati v kontekstu.
Ta dokument je razdeljen v 4 glavne točke, kot je opisano na sliki 1:
– UCM (model primerov uporabe) opisuje primere uporabe za vmesnik IC/ED na podlagi diagramov zaporedij s sporočili.
– IDD (opis zasnove vmesnika) določa podatkovni model za vmesnik IC/ED.
– SDD (opis zasnove sistema) določa obvezno specifikacijo vmesnika IC/ED v smislu arhitekture, storitev in vedenjskega modela. V splošnem delu te točke ni določena nobena vmesniška programska oprema ali transportna plast. Splošen del te točke naj bi bil neodvisen od vmesniške programske opreme.
– SDD-TCP/IP, SDD-CORBA, v teh specializiranih točkah. Zagotovljene so specifikacije za dve združljivi transportni rešitvi TCP/IP, CORBA. Dodatne rešitve vmesniške programske opreme (kot je SOAP) se lahko dodajo, ko so na voljo, če so v celoti združljive s splošnim delom.
(...)
Kot je prikazano na sliki 2, obstaja veliko vmesnikov od naprave za obogatitev do preostalega dela sistema. V tem dokumentu je obravnavan le del celotnega standardnega vmesnika, povezan z obdelavo pošiljk.
Obdelava pošiljk vključuje pošiljanje pošiljk v obdelavo v napravo za obogatitev.
(...)
Na sliki 3 je prikazan model sistema naprave za obogatitev. Iz slike je razvidno, da je lahko naprava za obogatitev:
– OCR:
ena sama naprava ali skupina naprav za samodejno prepoznavanje in razlago znakov, ki lahko pridobi informacije s slike pošte brez človeškega posega;
– VCS:
ena sama miza za video kodiranje ali skupina miz za video kodiranje, ki pripravi rezultate na podlagi slik pošiljk; vse naloge, povezane z upravljanjem kodirnikov in kodirnih miz so enkapsulirane v sistemu VCS ali so dostopne prek vmesnikov, ki ne spadajo v področje uporabe vmesnika, opisanega v tem dokumentu;
– sistem Voter:
sistem, ki lahko določi najustreznejši rezultat za pošiljko z uporabo podatkov in/ali slike pošiljke; običajno sistem Voter izbere najustreznejši rezultat na podlagi dveh ali več rezultatov.
Ta dokument torej ne zajema vmesnika za obdelavo pošiljk med kontrolnikom slike in napravami za obogatitev.
V tem dokumentu so opisane zahteve v primeru sprotne obogatitve: način delovanja naprave za obogatitev, pri katerem naprava v določenem času odgovori kontrolniku slike; kontrolnik slike mora spremljati vse pošiljke, ki čakajo na odgovor naprave za obogatitev. Naprava za obogatitev ne hrani pošiljk zunaj povezovalnega kanala s kontrolnikom slike. Naprava za obogatitev mora imeti na voljo obdelovalno moč za obogatitev pošiljke. Za posamezno pošiljko je mogoč le en odziv.
V poznejši različici dokumenta je treba opisati primer odložene obogatitve: način delovanja naprave za obogatitev, pri katerem lahko naprava predhodno zahteva pošiljke iz kontrolnika slike. Naprava za obogatitev mora hraniti pošiljko za poznejšo obogatitev in shraniti rezultat, ki bo na voljo na zahtevo kontrolnika slike. Kontrolnik slike ne pričakuje odziva iz naprave za obogatitev.
Vmesnik med kontrolniki slike NI del tega dokumenta.
Poleg tega je lahko več kontrolnikov slike povezanih z več napravami za obogatitev, kot je prikazana na naslednjem predmetnem modulu.
(...)
Strategija predložitve, ki se uporabi, če je en kontrolnik slike povezan z več napravami za obogatitev, ni del vmesnika. Gre za optimizacijo toka pošte v primeru enakih naprav za obogatitev ali za opredelitev vrstnega reda aktivacije različnih naprav za obogatitev (postopna ali istočasna predložitev).
Strategija predložitve kontrolnika slike je del specifikacije in certifikacije kontrolnika slike, ki ni del tega dokumenta.

General Information

Status
Published
Public Enquiry End Date
13-Feb-2014
Publication Date
02-Feb-2015
Technical Committee
Current Stage
6060 - National Implementation/Publication (Adopted Project)
Start Date
05-Jan-2015
Due Date
12-Mar-2015
Completion Date
03-Feb-2015

Relations

Buy Standard

Technical specification
TS CEN/TS 15448:2015 - BARVE
English language
237 pages
sale 10% off
Preview
sale 10% off
Preview
e-Library read for
1 day
Draft
kTS FprCEN/TS 15448:2014 - BARVE
English language
246 pages
sale 10% off
Preview
sale 10% off
Preview
e-Library read for
1 day

Standards Content (Sample)

SLOVENSKI STANDARD
SIST-TS CEN/TS 15448:2015
01-marec-2015
1DGRPHãþD
SIST-TS CEN/TS 15448:2007
SIST-TS CEN/TS 15448:2007/AC:2009
3RãWQHVWRULWYH2GSUWLVWDQGDUGQLYPHVQLNPHGREGHORYDOQLNRPVOLNHLQ
QDSUDYDPL]DRERJDWLWHY RSWLþQRSUHSR]QDYDQMH]QDNRY 2&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 standard ouverte entre le contrôleur d’images et les
dispositifs enrichis (OCR, systèmes d’encodage vidéo, systèmes de votes)
Ta slovenski standard je istoveten z: CEN/TS 15448:2014
ICS:
03.240 Poštne storitve Postal services
35.240.69 Uporabniške rešitve IT pri IT applications in postal
poštnih storitvah services
SIST-TS CEN/TS 15448:2015 en
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

---------------------- Page: 1 ----------------------

SIST-TS CEN/TS 15448:2015

---------------------- Page: 2 ----------------------

SIST-TS CEN/TS 15448:2015

TECHNICAL SPECIFICATION
CEN/TS 15448

SPÉCIFICATION TECHNIQUE

TECHNISCHE SPEZIFIKATION
December 2014
ICS 03.240; 35.240.60 Supersedes CEN/TS 15448:2006
English Version
Postal services - Open standard interface between image
controller and enrichment devices (OCRs, video coding systems,
voting systems)
Services postaux - Interface standard ouverte entre le Postalische Dienstleistungen - Offene Normschnittstelle
contrôleur d'images et les dispositifs enrichis (OCR, zwischen Bildbearbeitung und Anreicherungsgeräten (OCR,
systèmes d'encodage vidéo, systèmes de votes) Videocodierungssysteme, Abstimmungssysteme)
This Technical Specification (CEN/TS) was approved by CEN on 15 March 2014 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, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania,
Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and United
Kingdom.





EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Avenue Marnix 17, B-1000 Brussels
© 2014 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TS 15448:2014 E
worldwide for CEN national Members.

---------------------- Page: 3 ----------------------

SIST-TS CEN/TS 15448:2015
CEN/TS 15448:2014 (E)
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 (UCM) . 11
5.1 General . 11
5.2 Overall Description . 12
5.2.1 General . 12
5.2.2 Use-Case Model Survey . 12
5.2.3 Assumptions and Dependencies . 15
5.3 Specific Requirements . 22
5.3.1 Use-Case Reports . 22
5.3.2 Supplementary Requirements . 45
5.3.3 Rejections . 45
6 Interface Design Description IDD . 46
6.1 Purpose . 46
6.2 Scope of IDD . 47
6.3 Prerequisites . 47
6.4 Overview . 47
6.5 Section A – TIFF Definition . 48
6.5.1 Tiff Usage . 48
6.6 Section B – Mailpiece Data Definition . 53
6.6.1 Requirements . 53
6.6.2 Model Commitments . 57
6.6.3 Domain Data Model & Types . 58
7 System Design Description (SDD) – Common Part . 132
7.1 Purpose . 132
7.2 Overview . 133
7.3 Architectural Goals and Constraints . 133
7.3.1 General . 133
7.3.2 Client Server Model . 134
7.3.3 Client / Servant Relationships . 134
7.3.4 Server Selection . 136
7.4 Service Model . 137
7.4.1 Overview . 137
7.4.2 Exception Handling . 139
7.4.3 Logical link between IC and ED services . 139
7.4.4 Interface: IEnrichmentDevice . 139
7.4.5 Interface: IImageController . 143
7.4.6 Data definition . 147
7.5 Behavioural Model . 147
8 System Design Description (SDD) – Middleware dependent parts . 148
8.1 SDD TCP/IP Implementation . 148
2

---------------------- Page: 4 ----------------------

SIST-TS CEN/TS 15448:2015
CEN/TS 15448:2014 (E)
8.1.1 Communication layer . 148
8.1.2 Server selection . 149
8.1.3 Message definition . 149
8.1.4 Behavioural Model . 151
8.2 SDD CORBA Implementation . 167
8.2.1 General . 167
8.2.2 Server Selection . 167
8.2.3 Exception Handling . 169
8.2.4 ORB Implementation . 169
8.2.5 Interface Definition . 169
8.2.6 Behavioural Model . 172
8.3 SDD SOAP Implementation . 199
Annex A (informative) Introduction to XML . 200
A.1 Introduction to XML . 200
A.1.1 General . 200
A.1.2 XML Document Structure . 200
A.1.3 Introduction to XML Schema . 201
A.2 XML Schemas . 203
A.2.1 Domain Instance Types . 203
A.2.2 Base Types . 209
A.2.3 Generic Types . 217
A.2.4 Primitives. 219
A.2.5 Example of a Customer specific Schema Definition . 223
A.3 The XML Instance Document . 225
A.3.1 Type Assignment in the Instance Document. 225
A.3.2 Examples . 226
Bibliography . 237

3

---------------------- Page: 5 ----------------------

SIST-TS CEN/TS 15448:2015
CEN/TS 15448:2014 (E)
Foreword
This document (CEN/TS 15448:2014) has been prepared by Technical Committee CEN/TC 331 “Postal
services”, the secretariat of which is held by NEN.
The document supersedes CEN/TS 15448:2006.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. CEN [and/or CENELEC] shall not be held responsible for identifying any or all such patent rights.
According to the CEN-CENELEC Internal Regulations, the national standards organizations of the following
countries are bound to announce this Technical Specification: Austria, Belgium, Bulgaria, Croatia, Cyprus,
Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany,
Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland,
Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United Kingdom.
4

---------------------- Page: 6 ----------------------

SIST-TS CEN/TS 15448:2015
CEN/TS 15448:2014 (E)
Introduction
There is a growing demand on the postal operators to combine parts of their sorting automation equipment
from different suppliers to optimize 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 document covers the interface between an image controller and so called enrichment devices (OCR,
Video Coding System or Voting System).
The communication partners of this interface will be called Image Controller (IC) on the one side and
Enrichment Device (ED) on the other side.
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.
5

---------------------- Page: 7 ----------------------

SIST-TS CEN/TS 15448:2015
CEN/TS 15448:2014 (E)
1 Scope
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.

Figure 1 — IC/ED Interface Document Structure

Figure 2 — Interface environment of an Enrichment Device
6

---------------------- Page: 8 ----------------------

SIST-TS CEN/TS 15448:2015
CEN/TS 15448:2014 (E)
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 — System model
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:
7

---------------------- Page: 9 ----------------------

SIST-TS CEN/TS 15448:2015
CEN/TS 15448:2014 (E)
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 4 — 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 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).
8

---------------------- Page: 10 ----------------------

SIST-TS CEN/TS 15448:2015
CEN/TS 15448:2014 (E)
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
Not applicable.
3 Terms and definitions
For the purposes of his document, the following terms and definitions apply.
3.1
actor
coherent set of roles those users of uses cases play when interacting with these use cases.
Note 1 to entry: An actor has one role for each use case with which it communicates. See [UML].
3.2
attributes
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 1 to entry: Any information about the mailpiece may be used in this process, such as the image, image
information or result data. However, the use of an image is not compulsory.
3.8
enrichment device
ED
system designed to enrich information about mailpieces
9

---------------------- Page: 11 ----------------------

SIST-TS CEN/TS 15448:2015
CEN/TS 15448:2014 (E)
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
IC
system designed to handle the flow of images and data issued by the Image Supplies and sent to the
Enrichment Devices
Note 1 to entry: The Image Controller also controls the results from image enrichment.
3.12
infrastructure data
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
information stored about a single physical mail item (letter, flat or parcel) in an IC
3.15
mailpiece data
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 1 to entry: A non-fatal error may be considered to be a permanent error after repeated remedial handling.
10

---------------------- Page: 12 ----------------------

SIST-TS CEN/TS 15448:2015
CEN/TS 15448:2014 (E)
3.19
result
outcome of enrichment
3.20
street
street keying (street name and/or house number in street)
3.21
system
components and relationships between these (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
OCR Optical Character Recognition
PC Post code
PM Project Manager
ROI Region Of Interest
SDD System Design Description
UCM Use Case Model
VCS Video Coding System
W3C World Wide Web Consortium
XML eXtendable Markup Language
CORBA Common Object Request Broker
TCP/IP Transmission Control Protocol/Internet Protocol
SOAP Simple Object Access Protocol
5 The Use Case Model (UCM)
5.1 General
The Use Case Model (UCM) defines the requirements of the CEN OCR/VCS Standard interface. The
document utilizes UML use cases and other modelling techniques as well as textual information to convey the
requirements.
This clause contains the following sections:
— Overall Description:
11

---------------------- Page: 13 ----------------------

SIST-TS CEN/TS 15448:2015
CEN/TS 15448:2014 (E)
the use case model for the installation is described;
— Specific Requirements:
the use cases are described in detail including all supplementary requirements.
5.2 Overall Description
5.2.1 General
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].
5.2.2 Use-Case Model Survey
5.2.2.1 General
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.
5.2.2.2 Connection Use Case Model
5.2.2.2.1 General
The connection use cases (Figure 5) 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 5 — Connection use cases
12

---------------------- Page: 14 ----------------------

SIST-TS CEN/TS 15448:2015
CEN/TS 15448:2014 (E)
5.2.2.2.2 Actors
Name Description
Image Software: The Image Controller is a complete software system which is possibly made up of
Controller 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.
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.
5.2.2.2.3 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 utilize 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 1)
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
5.2.2.3 Channel Use Case Model
5.2.2.3.1 General
These use cases (Figure 6) apply to a channel which has been previously opened. They allow the closing of a
channel, the processing of mai
...

SLOVENSKI STANDARD
kSIST-TS FprCEN/TS 15448:2014
01-februar-2014
3RãWQHVWRULWYH2GSUWLVWDQGDUGQLYPHVQLNPHGREGHORYDOQLNRPVOLNHLQ
QDSUDYDPL]DRERJDWLWHY RSWLþQRSUHSR]QDYDQMH]QDNRY 2&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)
Ta slovenski standard je istoveten z: FprCEN/TS 15448
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
kSIST-TS FprCEN/TS 15448:2014 en
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

---------------------- Page: 1 ----------------------
kSIST-TS FprCEN/TS 15448:2014

---------------------- Page: 2 ----------------------
kSIST-TS FprCEN/TS 15448:2014

TECHNICAL SPECIFICATION
FINAL DRAFT
FprCEN/TS 15448
SPÉCIFICATION TECHNIQUE

TECHNISCHE SPEZIFIKATION

November 2013
ICS 03.240; 35.240.60 Will supersede CEN/TS 15448:2006
English Version
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,
Videocodierungssysteme, Abstimmungssysteme)


This draft Technical Specification is submitted to CEN members for formal vote. It has been drawn up by the Technical Committee CEN/TC
331.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania,
Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and United
Kingdom.

Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to
provide supporting documentation.

Warning : This document is not a Technical Specification. It is distributed for review and comments. It is subject to change without notice
and shall not be referred to as a Technical Specification.


EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Avenue Marnix 17, B-1000 Brussels
© 2013 CEN All rights of exploitation in any form and by any means reserved Ref. No. FprCEN/TS 15448:2013 E
worldwide for CEN national Members.

---------------------- Page: 3 ----------------------
kSIST-TS FprCEN/TS 15448:2014
FprCEN/TS 15448:2013 (E)
Contents Page
Foreword . 4
Introduction . 5
1 Scope . 6
2 Normative references . 10
3 Terms and definitions . 10
4 Symbols and abbreviations . 12
5 The Use Case Model (UCM) . 13
5.1 General . 13
5.2 Overall Description . 13
5.2.1 General . 13
5.2.2 Use-Case Model Survey . 13
5.2.3 Assumptions and Dependencies . 17
5.3 Specific Requirements . 24
5.3.1 Use-Case Reports . 24
5.3.2 Supplementary Requirements . 48
5.3.3 Rejections . 48
6 Interface Design Description IDD . 49
6.1 Purpose . 49
6.2 Scope of IDD . 50
6.3 Prerequisites . 51
6.4 Overview . 51
6.5 Section A – TIFF Definition . 51
6.5.1 Tiff Usage. 51
6.6 Section B – Mailpiece Data Definition . 57
6.6.1 Requirements . 57
6.6.2 Model Commitments . 61
6.6.3 Domain Data Model & Types . 62
7 System Design Description (SDD) – Common Part . 135
7.1 Purpose . 135
7.2 Overview . 135
7.3 Architectural Goals and Constraints . 136
7.3.1 General . 136
7.3.2 Client Server Model . 136
7.3.3 Client / Servant Relationships . 136
7.3.4 Server Selection . 139
7.4 Service Model . 140
7.4.1 Overview . 140
7.4.2 Exception Handling . 142
7.4.3 Logical link between IC and ED services . 142
7.4.4 Interface: IEnrichmentDevice . 142
7.4.5 Interface: IImageController . 146
7.4.6 Data definition . 150
7.5 Behavioural Model . 150
8 System Design Description (SDD) – Middleware dependent parts . 151
8.1 SDD TCP/IP Implementation . 151
8.1.1 Communication layer . 151
8.1.2 Server selection . 152
2

---------------------- Page: 4 ----------------------
kSIST-TS FprCEN/TS 15448:2014
FprCEN/TS 15448:2013 (E)
8.1.3 Message definition . 152
8.1.4 Behavioural Model . 154
8.2 SDD CORBA Implementation . 171
8.2.1 General . 171
8.2.2 Server Selection . 171
8.2.3 Exception Handling . 173
8.2.4 ORB Implementation . 173
8.2.5 Interface Definition . 173
8.2.6 Behavioural Model . 176
8.3 SDD SOAP Implementation . 206
Annex A (informative) Introduction to XML . 207
A.1 Introduction to XML . 207
A.1.1 General . 207
A.1.2 XML Document Structure . 207
A.1.3 Introduction to XML Schema . 208
A.2 XML Schemas . 210
A.2.1 Domain Instance Types . 210
A.2.2 Base Types . 216
A.2.3 Generic Types . 225
A.2.4 Primitives . 227
A.2.5 Example of a Customer specific Schema Definition . 232
A.3 The XML Instance Document . 235
A.3.1 Type Assignment in the Instance Document . 235
A.3.2 Examples . 235
Bibliography . 246

3

---------------------- Page: 5 ----------------------
kSIST-TS FprCEN/TS 15448:2014
FprCEN/TS 15448:2013 (E)
Foreword
This document (FprCEN/TS 15448:2013) has been prepared by Technical Committee CEN/TC 331 “Postal
Services”, the secretariat of which is held by NEN in collaboration with UPU.
This document is currently submitted to the Formal Vote.
This document will supersede CEN/TS 15448:2006.
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.
4

---------------------- Page: 6 ----------------------
kSIST-TS FprCEN/TS 15448:2014
FprCEN/TS 15448:2013 (E)
Introduction
There is a growing demand on the postal operators to combine parts of their sorting automation equipment
from different suppliers to optimize 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 document covers the interface between an image controller and so called enrichment devices (OCR,
Video Coding System or Voting System).
The communication partners of this interface will be called Image Controller (IC) on the one side and
Enrichment Device (ED) on the other side.
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.
5

---------------------- Page: 7 ----------------------
kSIST-TS FprCEN/TS 15448:2014
FprCEN/TS 15448:2013 (E)
1 Scope
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.

Figure 1 — IC/ED Interface Document Structure
6

---------------------- Page: 8 ----------------------
kSIST-TS FprCEN/TS 15448:2014
FprCEN/TS 15448:2013 (E)

Figure 2 — Interface environment of an Enrichment Device
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.
7

---------------------- Page: 9 ----------------------
kSIST-TS FprCEN/TS 15448:2014
FprCEN/TS 15448:2013 (E)

Figure 3 — System model
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;
8

---------------------- Page: 10 ----------------------
kSIST-TS FprCEN/TS 15448:2014
FprCEN/TS 15448:2013 (E)
• 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:
9

---------------------- Page: 11 ----------------------
kSIST-TS FprCEN/TS 15448:2014
FprCEN/TS 15448:2013 (E)

Figure 4 — 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 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.
2 Normative references
Not applicable.
3 Terms and definitions
For the purposes of his document, the following terms and definitions apply.
3.1
actor
coherent set of roles those users of uses cases play when interacting with these use cases.
Note 1 to entry: An actor has one role for each use case with which it communicates. See [UML].
10

---------------------- Page: 12 ----------------------
kSIST-TS FprCEN/TS 15448:2014
FprCEN/TS 15448:2013 (E)
3.2
attributes
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 1 to entry: Any information about the mailpiece may be used in this process, such as the image, image information
or result data. However, the use of an image is not compulsory.
3.8
enrichment device
ED
system designed to enrich information about mailpieces
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
IC
system designed to handle the flow of images and data issued by the Image Supplies and sent to the
Enrichment Devices
Note 1 to entry: The Image Controller also controls the results from image enrichment.
3.12
infrastructure data
basic information, such as identification references which an Image Controller and Enrichment Device require
in order to communicate effectively
EXAMPLE Letter ID, Submission ID.
11

---------------------- Page: 13 ----------------------
kSIST-TS FprCEN/TS 15448:2014
FprCEN/TS 15448:2013 (E)
3.13
mail object
letter, Flat, Parcel, Postcard etc.
3.14
mailpiece
information stored about a single physical mail item (letter, flat or parcel) in an IC
3.15
mailpiece data
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 1 to entry: 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
components and relationships between these (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
12

---------------------- Page: 14 ----------------------
kSIST-TS FprCEN/TS 15448:2014
FprCEN/TS 15448:2013 (E)
IDD: Interface Design Description
OCR:
Optical Character Recognition
PC: Post code
PM: Project Manager
ROI: Region Of Interest
SDD: System Design Description
UCM: Use Case Model
VCS:
Video Coding System
W3C: World Wide Web Consortium
XML: eXtendable Markup Language
CORBA: Common Object Request Broker
TCP/IP: Transmission Control Protocol/Internet Protocol
SOAP: Simple Object Access Protocol
5 The Use Case Model (UCM)
5.1 General
The Use Case Model (UCM) defines the requirements of the CEN OCR/VCS Standard interface. The
document utilizes UML use cases and other modelling techniques as well as textual information to convey the
requirements.
This clause 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.
5.2 Overall Description
5.2.1 General
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].
5.2.2 Use-Case Model Survey
5.2.2.1 General
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.
13

---------------------- Page: 15 ----------------------
kSIST-TS FprCEN/TS 15448:2014
FprCEN/TS 15448:2013 (E)
5.2.2.2 Connection Use Case Model
5.2.2.2.1 General
The connection use cases (Figure 5) 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 5 — Connection use cases
5.2.2.2.2 Actors
Name Description
Image Software: The Image Controller is a complete software system which is possibly made up of
Controller 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.
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.
14

---------------------- Page: 16 ----------------------
kSIST-TS FprCEN/TS 15448:2014
FprCEN/TS 15448:2013 (E)
5.2.2.2.3 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 utilize 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.
1)
UC005 Put ED Status
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

5.2.2.3 Channel Use Case Model
5.2.2.3.1 General
These use cases (Figure 6) 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.

1) 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.
15

---------------------- Page: 17 ----------------------
kSIST-TS FprCEN/TS 15448:2014
FprCEN/TS 15448:2013 (E)

Figure 6 — Channel use cases
5.2.2.3.2 Actors
Name Description
Image Software: The Image Controller is
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.