TCN - Global Business Analysis

EUROPEAN COMMISSION

Energy & Transport Directorate General

Unit : ITS Galileo

DG TREN

TACHOnet

Global Business Analysis

01_30

30.01.2006

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 2

Document Approval

NAME DATE SIGNATURE

Prepared by: F. Silvestre 22.01.2003

Checked by: F. Dugardin 18.03.2003

Quality control by: Ch. Timmermans 18.03.2003

Approved by: Y. Hardy 21.03.2003

Distribution List

COMPANY NAME FUNCTION FOR INFO / APPROVAL

DG TREN Y. Hardy Project Manager Approval

DG TREN L. Huberts Porject Owner Info

Change Control History

VERSION DATE AUTHOR DESCRIPTION PARAGRAPHS

00_01 23.01.2001 F. Silvestre 1st internal draft

01_00 26.09.2001 F. Silvestre 1st external version

01_01 17.05.2002 F. Silvestre Official version –

Feasibility Study

01_10 10.11.2002 F. Silvestre TCN 2

Phase – 1

draft

01_11 22.01.2003 F. Silvestre TCN 2

Phase – 2nd draft

01_20 21.03.2003 F. Silvestre TCN 2

Phase – Official

release

01_30 30.01.2006 Y. Hardy Insertion of the

TACHOnet management

procedure

See Annex

Document information

CREATION DATE:

22.01.2003

FILENAME:

TCN-GBA_01-30_EN.doc

LOCATION:

NUMBER OF PAGES:

119

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 3

TABLE OF CONTENTS

Introduction......................................................................................................................................... 5

Chapter 1: Context .................................................................................................................................... 7

Overview............................................................................................................................................. 7

Legal framework................................................................................................................................. 8

Context of Work................................................................................................................................ 10

Chapter 2: Requirements........................................................................................................................ 11

Overview........................................................................................................................................... 11

Types of Requirements...................................................................................................................... 12

List of Functional Requirements....................................................................................................... 15

List of Non-functional Requirements................................................................................................ 17

Chapter 3: Analysis of the Business Processes...................................................................................... 20

Overview........................................................................................................................................... 20

Section 3.1 - Card Issuing & Enforcers Process Hierarchy................................................................... 21

Section 3.2 - Administrative tasks......................................................................................................... 24

Overview........................................................................................................................................... 24

First issue a card................................................................................................................................ 25

Lost/Stolen card declaration.............................................................................................................. 33

Malfunctioning card declaration ....................................................................................................... 37

Suspended card declaration............................................................................................................... 41

Lost/stolen card hand in .................................................................................................................... 45

Renewal of a card.............................................................................................................................. 49

Exchange of a card............................................................................................................................ 50

Replacement of a card....................................................................................................................... 55

Check tachograph card status............................................................................................................ 56

Check driver’s issued card ................................................................................................................ 60

Bulk check of issued driver card holders .......................................................................................... 61

Section 3.3 - System tasks..................................................................................................................... 64

Overview........................................................................................................................................... 64

Users & access rights management................................................................................................... 65

Statistics management....................................................................................................................... 70

Logging & Monitoring management.................................................................................................73

Chapter 4: Business Object Model......................................................................................................... 75

Overview........................................................................................................................................... 75

Section 4.1 - Class Diagrams................................................................................................................. 76

Overview........................................................................................................................................... 76

Local Business Object Model ........................................................................................................... 77

Tachograph cards .............................................................................................................................. 79

Section 4.2 - Classes.............................................................................................................................. 82

Overview........................................................................................................................................... 82

Class <Tachograph card>.................................................................................................................. 83

Class <Driver card> .......................................................................................................................... 85

Class <Company card> ..................................................................................................................... 86

Class <Control card>......................................................................................................................... 87

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 4

Class <Workshop card>.................................................................................................................... 88

Chapter 5: Use-Case Model .................................................................................................................... 89

Overview........................................................................................................................................... 89

Introduction....................................................................................................................................... 90

Actor Catalog .................................................................................................................................... 91

Use Case Catalog .............................................................................................................................. 92

Use Case 01 – Check driver(s)’ issued cards .................................................................................... 95

Use Case 02 – Check tachograph card status.................................................................................... 98

Use Case 03 – Declaration of card status modification................................................................... 101

Use Case 04 – Send Card/Driving License Assignment ................................................................. 105

Use Case 05 – Get Phonex Search Keys......................................................................................... 108

Use Case 06 – Get US/Ascii Transliteration................................................................................... 110

Use Cases 07 up to 13..................................................................................................................... 112

Use Case 14 – Log the message...................................................................................................... 113

Use Case 15 – Generate MS statistics............................................................................................. 114

Use Case 17 – Generate global TACHOnet statistics..................................................................... 115

Use Case 17 – Browse MS statistics ............................................................................................... 116

Use Case 18 – Browse global TACHOnet statistics ....................................................................... 117

Annex - TACHOnet Change Management Procedure……………………..………………………..118

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 5

Introduction

Purpose of

the Global

Business

Analysis

In order to be able to suggest a system to a customer, one should understand the

customer’s business by performing a Global Business Analysis. This activity aims at

formalizing the user requirements at both of functional and non-functional level, and

will allow to verify the understanding of the business and to identify what is

expected from Getronics (i.e. detail the scope of intervention).

By formally establishing the business by means of a modelling approach, one is

compelled to think about business concepts and precisely define them. One is

automatically confronted with inconsistencies in the understanding of the issue and

differences in interpretation between domain experts and IT staff. The analysis

documents the existing business situation and the target environment, including the

requirements for a transition path and defines the set of use cases that describe the

business situation. Modelling the business helps discovering the business tasks that

an application would support. Use cases will then be derived from this business

model.

The Global Business Analysis outputs two models: the Business Object Model and

the (Enhanced) Use Case Model. These models represent what the customer expects

from the application. Therefore it is very important to use a customer oriented

vocabulary when naming and describing objects.

Scope of the

Project

The current phase of the TACHOnet project aims at carrying out a detailed analysis

& design which will :

• Take into account the legal and operational framework applicable for such

interchange system (business needs, application features, security aspects, network

infrastructure)

• Take into account the user requirements which current list is given below

(“requirements” chapter) but obviously subject to be extended during the study in

close collaboration with DG TREN and Member States Representatives (Task

Force 2 from Card Issuing Working Group).

• Take into account the results of the feasibility study.

References

The present document makes references to the following documents:

• [1] TACHOnet Analysis & Design: Technical Annex

• [2] Council Regulation (EC) N° 2135/98

• [3] Annex IB – Chapter IV – Constructions and Functional Requirements for

Tachograph Cards

• [4] TACHOnet Software Architecture Document

• [5] Card Issuing Working Group – General Report – URBA 2000

• [6] Access to some data through Tachonet by the enforcement officers during road

side checks - SNRA/WG1/TF1/005 – Th. Granturco – 18-Oct-02

• [7] TACHOnet XML Messaging Reference Guide – Version 1.0

• [8] Note of the meeting to discuss TACHOnet/Card issuing – 25-Feb-03

Continued on next page

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 6

Introduction, Continued

Structure of

the document

The first chapter describes the legal framework and the context of work. The second

chapter identifies the different functional and non-functional requirements. A third

chapter analyses the business processes related to card issuing in order to find out

which TACHOnet functionalities are needed, how, when and where. The fourth

chapter describes the Business Object Model in terms of class diagrams and classes

description. The fifth chapter describes the Use-Case model by listing and explaining

the different actors and use cases identified from the requirements and the business

processes.

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 7

Chapter 1: Context

Overview

Introduction

This chapter sums up the legal framework and context of work surrounding the

TACHOnet project.

Contents

This chapter contains the following topics.

Topic See Page

Legal framework 8

Context of Work 10

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 8

Legal framework

Council

Regulations

Council Regulation (EEC) n° 3821/85 provides for the installation and use of in

vehicle recording equipment (the so-called « tachograph ») for the enforcement of

driving hours of professional drivers in the field of road transport ( goods and

passengers).

The aim of that regulation is twofold :

• to ensure fair competition between drivers, hauliers and also with the other

transport modes

• to enhance road safety by avoiding driver’s fatigue and by controlling compliance

with the legislation on speed limiters

The regulation has been amended by Council Regulation (EC) n° 2135/98 which

introduced a new digital recording equipment and personal smart cards for drivers.

The driver card allows for the identification of the drivers when they start their

journey and for the recording of their activities.

A key element of the new regulation is to make sure that a driver holds only one

card.

The issue of cards is the competence of the individual Member State where drivers

have their normal residence.

The competent national authority should be able to check the uniqueness of issue by

its own administration of a card to a particular driver, but such a check should also

take place with the authorities of the other Member States to avoid a driver holding

cards from several Member States.

In practice, this would be difficult, time consuming and bureaucratic without an

appropriate telematic network between the national authorities.

Continued on next page

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 9

Legal framework, Continued

Legal

requirements

for

exchanging

information

• Council Regulation n°3821/85 Art. 19.2§3

- « Member States shall assist each other in applying this Regulation and in checking

compliance therewith.

- Within the framework of this mutual assistance the competent authorities of the

Member States shall regularly send one another all available information

concerning :

. breaches of this regulation committed by non-residents and any penalties imposed

for such breaches,

. penalties imposed by a Member State on its residents for such breaches committed

in other Member States. »

• Council Regulation n°2135/98 Art. 1

- « The competent authorities of the issuing Member State shall, as far as this can be

done, ensure that the applicant does not already hold a valid driver card ; »

Art .1.7.b).(d)

- « … The authority issuing the card shall maintain a register of lost, stolen or

defective cards » Art.1.5.a) 3

- « Loss of the driver card must be reported … to the competent authorities of the

State that issued it and to the competent authorities of the Member State of normal

residence where they are different. » Art.1.9.b)2

- « Where the authorities of the Member State in which the driver has his normal

residence are different from those which issued his card and where the latter are

requested to renew, replace or exchange the driver card, they shall inform the

authorities which issued the old card of the precise reasons for its renewal,

replacement or exchange; » Art.1.9.last §

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 10

Context of Work

Important

characteristics

• Decision No 1720/1999/EC of the European Parliament and of the Council of 12

July 1999 adopted a series of actions and measures in order to ensure

interoperability of and access to trans-European networks for the electronic

interchange of data between administration (IDA).

• The TESTA-II action of IDA programme is currently interconnecting a network

between the National administrations of the Member States and the European

Institutions. This network facilities will be used as a mandatory service for the

future application.

• The future application will be based on an interconnection/message process

between the Member States. No central european database being the consolidation

of the Member State data will exist. A potential central application will not be

necessarily hosted by the European Commission Data Centre. It could be hosted

by complementary services available on TESTA-II network.

• A certain number of already available commercial software products could

probably perform the tasks requested with some limited adaptation. This kind of

option should be evaluated in priority.

• Most of the data transmitted contain personal information. Despite the fact that the

TESTA-II network is a private network not connected to the Internet, strong and

reliable measures have to be taken at application level to ensure the confidentiality,

security and integrity of the data transmitted.

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 11

Chapter 2: Requirements

Overview

Introduction

This chapter describes the different requirements (functional and non-functional).

Contents

This chapter contains the following topics.

Topic See Page

Types of Requirements 12

List of Functional Requirements 15

List of Non-functional Requirements 17

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 12

Types of Requirements

Definition

A requirement is defined as "a condition or capability to which a system must

conform".

Functional requirements specify actions that a system must be able to perform,

without taking physical constraints into consideration. These are often best described

in a use-case model and in use cases. Functional requirements thus specify the input

and output behaviour of a system.

Requirements that are not functional are sometimes called non-functional

requirements. Many requirements are non-functional, and describe only attributes

of the system or attributes of the system environment.

FURPS+

There are a many different kinds of requirements. One way of categorizing them is

described as the FURPS+ model [GRA92], using the acronym FURPS to describe

the major categories of requirements with subcategories as shown below.

• F

unctionality,

• U

sability,

• R

eliability,

• P

erformance and

• S

upportability

The "+" in FURPS+ helps you to also remember to also include such requirements as

• design constraints,

• implementation requirements,

• interface requirements and

• physical requirements.

Functionality

(FUN)

Functional requirements may include:

• feature sets,

• capabilities, and

• security.

Usability

(USA)

Usability requirements may include such sub-categories as:

• human factors,

• aesthetics,

• consistency in the user interface,

• online and context-sensitive help,

• wizards and agents,

• user documentation, and

• training materials.

Continued on next page

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 13

Types of Requirements, Continued

Reliability

(REL)

Reliability requirements to be considered are:

• frequency / severity of failure,

• recoverability,

• predictability,

• accuracy, and

• mean time between failure (MTBF).

Performance

(PER)

A performance requirement imposes conditions on functional requirements. For

example, for a given action, it may specify performance parameters for:

• speed,

• efficiency,

• availability,

• accuracy,

• throughput,

• response time,

• recovery time, or

• resource usage.

Supportability

(SUP)

Supportability requirements may include:

• testability,

• extensibility,

• adaptability,

• maintainability,

• compatibility,

• configurability,

• serviceability,

• installability, or

• localizability (internationalization).

Design

Requirement

(DES)

A design requirement, often called a design constraint, specifies or constrains the

design of a system.

Implemen-

tation

Requirement

(IMP)

An implementation requirement specifies or constrains the coding or construction of

a system. Examples are:

• required standards,

• implementation languages,

• policies for database integrity,

• resource limits, and

• operation environments.

Continued on next page

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 14

Types of Requirements, Continued

Interface

Requirement

(INT)

An interface requirement specifies

• an external item with which a system must interact, or

• constraints on formats, timings, or other factors used by such an interaction.

Physical

Requirement

(HAR)

A physical requirement specifies a physical characteristic that a system must possess;

for example,

• material,

• shape,

• size, and

• weight.

This type of requirement can be used to represent hardware requirements, such as

• the physical network configurations required

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 15

List of Functional Requirements

Introduction

Functional requirements specify actions that a system must be able to perform,

without taking physical constraints into consideration. Functional requirements thus

specify the input and output behaviour of a system.

A list of these functional requirements is given below with an identification and a

short description for each of them.

These functional requirements are best described once translated into use cases (see

Use Case Model

chapter).

List of

functional

requirements

Each identified functional requirement is assigned a unique key “FUN-nn” where nn

is a sequence number identifying the functional requirement. The table hereafter lists

all the functional requirements :

Functional

Requirement

Description

FUN-01 The system must allow a member of the network to send requests

to a particular or all the other members about possible delivery of

a driver’s smart card to a similar person.

FUN-02 The system must allow a member of the network to send a bulk

request on all or a large part of its driver’s smart card holders to a

particular or all members of the network.

FUN-03 The system must allow a member to do statistics on messages

issued and received from/to his system.

FUN-04 The system must provide automatic reply to the sender of the

request through the use of a standard interface to the Members

systems.

FUN-05 The system must track the workflow between senders and related

replies.

FUN-06 The system must be able, in accordance with the rules on delays

for each transaction, to automatically transmit alert messages to

senders/replier/administrator when, f.i. a constraint on delay for

reply is not fulfilled.

FUN-07 The system must allow the administrator to extract statistics of

use, standard delay of reply by member/period, percentage of

unsuccessful transaction,... .

FUN-08 The system must provide the management of user rights and

permissions.

FUN-09 The system must be able to define and manage various type of

messages already in the driver’s smart card holder like pre-

delivery check, stolen/lost cards, renewals, exchanges and

duplicates.

FUN-10 The system must be able to include new members in the network

through simple administrative tasks.

Continued on next page

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 16

List of Functional Requirements, Continued

List of functional requirements (continued)

Functional

Requirement

Description

FUN-11 The system must be highly automatic to relieve the users of as

many repetitive and tedious tasks as possible.

FUN-12 The system must provide at application level a full security

(including non repudiation

) and encryption policy compatible

with the level of security required in such situation.

FUN-13 The system must guarantee that none of the Member of the

network , including the administrator , is technically able to re-

construct a consolidated European database through the use of

the messages exchanged.

The system must be such that none of the Member States of the

network, including the administrator, re-construct a consolidated

European database.

FUN-14 The system must allow a Member State (through its Card Issuing

Authority) to ask for the status of card (lost, stolen,…) to the

corresponding Card Issuing Authority of the Member State

having issued the card.

FUN-15 The system must allow a Member State (through its Card Issuing

Authority) to send card status modification requests (lost,

stolen,…) to the corresponding Card Issuing Authority of the

Member State having issued the card.

FUN-16 The system must allow enforcement authorities (through its Card

Issuing Authority) to ask for driver’s card status (based on either

card number + issuing Member State code or driver’s surname,

first names, date of birth and issuing Member State code) to the

corresponding Card Issuing Authority of the Member State

having issued the card.

FUN-17 The system must allow enforcement authorities (through its Card

Issuing Authority) to ask for workshop card status (based on

workshop card number + issuing Member State code) to the

corresponding Card Issuing Authority of the Member State

having issued the card.

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 17

List of Non-functional Requirements

Introduction

Non-functional requirements describe only attributes of the system or attributes of

the system environment.

Each identified non-functional requirement is assigned a unique key “XXX-nn”

where XXX identifies the type of requirement (e.g. PER for performance

requirement) and nn is a sequence number identifying the non-functional

requirement.

Usability

requirements

The table hereafter lists all the non-functional “usability

” requirements :

Usability

Requirement

Description

USA-01 The system must guide users through an interface based on end

user concepts.

USA-02 The system must be easy to learn and does not obstruct the

thematic understanding of the users.

USA-03 The system must make it easy to correct mistakes.

Reliability

requirements

The table hereafter lists all the non-functional “reliability

” requirements:

Reliability

Requirement

Description

REL-01 The system is to be designed as a robust and dependable

operational system which is tolerant to operator errors and

which will recover cleanly from power cuts or other disasters.

REL-02 The system must function reliably, with few or no interruptions

in its first operational year and fewer still thereafter.

REL-03 The system must give stable and reproducible results.

Continued on next page

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 18

List of Non-functional Requirements, Continued

Performance

requirements

The table hereafter lists all the non-functional “performance

” requirements:

Performance

Requirement

Description

PER-01 The system should be able to cover more than one contact point

per country depending on the administrative organisation

adopted by each country and able to work in a multi

hierarchical environment. This is no longer the case since

everybody agrees upon having a single point of contact per

Member State (even though the Member State is organized with

several Card Issuing Authorities – up to the Member State to

manage its own organisation).

PER-02 There will be no restriction in time or place for the use of the

software built from the specifications produced under this

contract.

PER-03 The system must be able to establish and keep the dialog with

the Members systems despite the various technical

environments and technologies used on their sites.

PER-04 The system will be designed so that background tasks can

continue while the user performs foreground tasks.

PER-05 The system will be used 24x7 by operators under pressure to

produce results rapidly. The system must respond rapidly to

user requests irrespective of any background tasks. Such high-

availability (24x7) is also required from the Member States

systems to ensure acceptable response time (less than 1 minute)

to enforcement authorities requests.

Supportability

requirements

The table hereafter lists all the non-functional “supportability

” requirements:

Supportability

Requirement

Description

SUP-01 The system should be able to support other types of message

structure to cover f.i. a future driving licence network and

correlated activities.

SUP-02 The system must be maintainable and extensible.

SUP-03 The system must be designed so that it can migrate to upgraded

hardware or new versions of the operating systems involved.

SUP-04 The system must be able to migrate to other type of network

than the one proposed by TESTA-II.

SUP-05 The system must provide solutions/rules regarding data

encoding problems such as supporting different character sets,

name truncation rules, name matching in case of misspelling,...

Continued on next page

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 19

List of Non-functional Requirements, Continued

Design

requirements

The table hereafter lists all the non-functional “design

” requirements:

Design

Requirement

Description

DES-01 The system must be designed and documented with the

expectation that its operational lifetime will be many years.

DES-02 Each Member of this network will organise its data about smart

card holders with no constraints or recommendations on

operating system and/or technology used. The system will be

able to dialog with these environments or specify a generic

interface to dialog with the Member’s applications.

Implementation

requirements

The table hereafter lists all the non-functional “implementation” requirements:

Implementation

Requirement

Description

IMP-01 -

Interface

requirements

The table hereafter lists all the non-functional “interface

” requirements:

Interface

Requirement

Description

INT-01 The system must use the network facilities supplied by the

TESTA-II network.

INT-02 The algorithms in the software will be based on existing

techniques and no research will be required to develop new

algorithms under this contract.

INT-03 Most of the functionality of the new software shall depend on

pre-existing or commercially available software.

Physical

requirements

The table hereafter lists all the non-functional “physical

” requirements:

Physical

Requirement

Description

HAR-01 -

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 20

Chapter 3: Analysis of the Business Processes

Overview

Introduction

In order to be able to suggest a system to a customer, one should understand the

customer’s business. Modelling the business helps discovering the business tasks that

an application would support. Use cases will then be derived from this business

model.

However, the goal of this chapter is not to describe in details the different processes

related to the card issuing and the enforcers checks (this is not in the scope of the

TACHOnet project anyway) but to identify which TACHOnet functionalities are

needed and when within these processes.

Therefore, the outlined processes are to be read as examples and does not dictate

how the Member States should handle tachograph card issuing.

Important

The following decisions have been taken (and agreed) during the feasibility study:

• TACHOnet will consider the Member State as having a SPOC CIA (Single Point

Of Contact Card Issuing Authority), even though the Member State is organized

through multiple CIAs managing their tachograph cards data in a common central

data store (it’s up to the Member State to manage the one-to-many relationship).

• For performance reasons (to reduce the amount of messages exchanged), a request

message (and its corresponding response message) could contain several (‘n’)

requests (for several card ids/drivers) instead of a single one.

• Enforcement Authorities may have access to some TACHOnet services through

their National Card Issuing Authority (it’s under the Member State’s responsibility

to grant enforcers access to the TACHOnet system). From the TACHOnet point of

view, enforcers are seen as a Member State (SPOC CIA).

Contents

This chapter contains the following topics.

Topic See Page

Card Issuing & Enforcers Process Hierarchy 21

Administrative tasks 24

System tasks 64

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 21

Section 3.1 - Card Issuing & Enforcers Process Hierarchy

Introduction

Card issuing can be modelled as process groups, including processes, carried out by

a Card Issuing Authority.

The enforcers needs will be modelled as process carried out by Enforcement

Authorities.

Card Issuing

Authority

A Card Issuing Authority (CIA) is an official organism competent for issuing and

managing tachograph cards. A card Issuing Authority may issue and manage

tachograph cards for the Member State it depends on but also for other Member

States not willing to set up such organisation in their own country but willing to have

it “outsourced” by another Member State.

A Member State may also have a single or several Card Issuing Authorities

managing card issuing for his resident drivers. Nevertheless, it has been agreed that

TACHOnet will consider the Member State as having a SPOC CIA (Single Point Of

Contact Card Issuing Authority), even though the Member State is organized through

multiple CIAs managing their tachograph cards data in a common central data store

(it’s up to the Member State to manage the one-to-many relationship).

Enforcement

Authority

During road-side checks, the enforcers want to use TACHOnet to check either the

status of a card (driver or workshop card) or whether a driver does hold a valid card

(when the driver is unable to show his card because it has been presumably lost or

stolen). In both cases, the enforcers want to get the same level of information, i.e.

some card details (card number, status, address where it has been issued, issuing

date, expiry date, last modification date), some driver/workshop details (surname,

first names, birth date, place of birth, driving licence number). Please refer to [6] for

more details.

Beside these functional requirements, high-availability (24x7) is also required from

the central TACHOnet system and the Member States systems (e.g. to process a

TACHOnet request asking for checking against their local database the valididty and

status of a card) to ensure acceptable response time (less than 1 minute) to

enforcement authorities requests.

It has been agreed that enforcers might have access to TACHOnet but through their

local Card Issuing Authority, i.e. TACHOnet consider the Member State Card

Issuing Authority as the SPOC (Single Point Of Contact). Therefore, it’s the Member

State responsibility to grant enforcers access to TACHOnet.

Continued on next page

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 22

Overview, Continued

Process

Hierarchy

Diagram

The different processes related to card issuing can be modelled as follows:

Card issuing

Authority

Administrative

tasks

Check tachogra-

ph card status

Lost/Stolen

card hand in

First issue

of a card

Renewal of

a card

Lost/Stolen ca-

rd declaration

Exchange

of a card

Malfunctioning

card

declaration

Replacement

of a card

Suspended card

declaration

Bulk check of

issued driver

card holders

System tasks

Logging/Monito-

ring Management

Users & access

rights

Management

Statistics

Management

Enforcement

Authority

Check tachogra-

ph card status

Check driver's

issued card

Lost/Stolen ca-

rd declaration

Malfunctioning

card

declaration

Figure 1 – Card Issuing Process Hierarchy

Administrative

tasks

This process group gathers the different processes related to the administrative tasks

carried out by an authorized clerk of the Card Issuing Authority. These can be

summarized as follows:

Administrative tasks Description

First issue of a card This process deals with the issuing of a driver card to a

new driver

Lost/stolen card

declaration

This process deals with the declaration of a lost/stolen

card

Malfunctioning card

declaration

This process deals with the declaration of a

malfunctioning card

Suspended card

declaration

This process deals with the declaration of a suspended

card

Lost/stolen card hand

This process deals with the handing over of a found

lost/stolen card

Renewal of a card This process deals with the issue of a new tachograph

card when an existing card reaches its expiry date, or is

malfunctioning and has been returned to the issuing

authority. Renewal always implies the certainty that two

valid cards do not co-exist.

Continued on next page

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 23

Overview, Continued

Administrative tasks (continued)

Administrative tasks Description

Exchange of a card This process deals with the exchange of an existing valid

driver card for an equivalent driver card for

administrative reasons (e.g. the holder of the valid driver

card has established his normal place of residence in

another Member State).

Replacement of a card This process deals with the issue of a tachograph card in

replacement of an existing card, which has been declared

lost, stolen or malfunctioning and has not been returned

to the issuing authority. Replacement always implies a

risk that two valid cards may co-exist.

Check tachograph card

status

This process deals with the verification of the status of a

tachograph card (driver or workshop) based on its card

number.

Check driver’s issued

card

This process deals with the verification of whether a

particular driver (based on his name, first names, date of

birth,…) does actually hold a valid card. Such process

will be carried out by the enforcers to check, during road-

checks, when a driver is unable to show his card

(pretending it’s lost or stolen), that a driver does actually

hold a valid card issued by a Member State.

Bulk check of issued

cards

This process deals with the verification asked by a

Member State that all or a large part of its driver card

holders are not yet holder of another card in another

country.

System tasks

This process group gathers the different processes related to the system tasks

provided by the TACHOnet project. These tasks, carried out by authorized

administrators, can be summarized as follows:

System tasks Description

Users & access

rights management

This process deals with the definition of the users having

access to the TACHOnet functionalities along as their

access rights to these functionalities.

Statistics

Management

This process deals with the management of different

statistics (e.g. usage,...) around TACHOnet activities.

Logging/Monitoring

Management

This process deals with the management of different

loggings around TACHOnet activities as long as the

monitoring of the central system.

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 24

Section 3.2 - Administrative tasks

Overview

Introduction

This section analyses the different processes related to the administrative tasks

carried out by an authorized clerk of the Card Issuing Authority.

Contents

This section contains the following topics.

Topic See Page

First issue a card 25

Lost/Stolen card declaration 33

Malfunctioning card declaration 37

Suspended card declaration 41

Lost/stolen card hand in 45

Renewal of a card 49

Exchange of a card 50

Replacement of a card 55

Check tachograph card status 56

Check driver’s issued card 60

Bulk check of issued driver card holders 61

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 25

First issue a card

Introduction

This process deals with the issuing of a driver card to a new driver, i.e. a driver who

never asked yet for a driver card (and therefore doesn’t hold any driver card).

Council Regulation (EC) N° 2135/98 mentions:

• Art.14 §3(a): “The driver card shall be issued, at the request of the driver, by the

competent authority of the Member State where the driver has his normal

residence.”

• Art.14 §3(b): “Drivers shall give proof of their place of normal residence by any

appropriate means, such as identity card or any other valid document.”

• Art.14 §3(c): “The competent authorities of the Member State issuing the driver

card [...] may request any additional information or evidence.”

• Art.14 §3(d): “The competent authorities of the issuing Member State shall, as far

as this can be done, ensure that the applicant does not already hold a valid driver

card.”

• Art.14 §4(a): “[...]The driver card may not be valid for more than five years. The

driver may hold one valid driver card only.”

• Art.14 §4(d): “Driver cards issued by Member States shall be mutually

recognized.[...]”

Luxemburg

agreement

During CIWG phase I, Member States have come to an agreement about the use of

the driving license number. This agreement, called the “Luxemburg agreement”, is

described in the CIWG final report [5]. For what TACHOnet is concerns, it has been

decided that a Member State issuing a card for a driver with a foreign driving

license, should warn the Member State having issued the driving license that a

tachograph card (giving its card number) has been issued using the corresponding

driving license number.

Process

description

As shown in Figure 2below, the issuing of a new card triggers processes and events

among 3 different “entities”:

• The Card Issuing Authority (CIA) issuing the card and asking for driver’s issued

cards verification,

• TACHOnet (providing central secure & reliable services for such verification),

• The different Member States performing the verification against their own data

stores.

As mentioned earlier, business process modelling aims only at identifying the

different TACHOnet events and services needed to help Card Issuing Authorities and

Member States exchange information about tachograph cards. Therefore, the

processes described for the Card Issuing Authorities and Member States “entities”

are just drawn as “helpers” to find out TACHOnet services. Only the processes of the

TACHOnet entity are of interest for the scope of the TACHOnet project.

Continued on next page

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 26

First issue a card, Continued

Process

diagram

The issuing of a new card can be modelled as follows:

First issue of a card

Driver card

request

Check driver's

identity

Record the

declaration/re-

quest

Check driver's issued card(s)

Send check

driver's issued

card(s) request

to TCN

Specify

driver's

identification

Wait for TCN

response

TCN response

Log & validate

the TCN

response

Process the TCN response

Drivers list

Driver's

selection

Check card

delivery

No driver

identified

Manage "no

delivery"

Single driver

Driver card

delivery

Deliver

new card

Partial result

???

Send driver

licence & issu-

ed card numbers

Driver licence

& Issued Card

numbers request

Card Issuing Authority

Check driver's

issued card(s)

request

Log & validate

the request

Build the

request to MS

For each Member State (in parallel)

Check driver's

issued card(s)

request

Send check

driver's issued

card(s) request

to MS

Wait for MS

response

MS response

Log & validate

the MS response

Process MS

response checkg

driver's issued

card(s

Send

consolidated T-

CN response che

ck issued cards

Drivers list

Single driver

No driver

identified

Partial result

TACHOnet (TCN)

Check driver's

issued card(s)

request

Log & validate

the request

Process request

check'g

driver's issued

card(s)

MS response

Member States (MS)

Check driver's

issued card(s)

request

Log & validate

the request

Wait for TCN

response

TCN response

Log & validate

the TCN

response

Process the TCN response

???

Error

Invalid driver

licence

Build the

request to MS

Send DL & Card

numbers to

MS having

issued DL

Wait for MS

response

MS response

Log & validate

the MS response

Send final TCN

response

Invalid driver

licence

Error

Member State having issued the driving licence

Log & validate

the request

Process request

DL & Card

numbers

MS response

Driver licence

& Issued Card

numbers request

Driver licence

& Issued Card

numbers request

Driver licence

& Issued Card

numbers request

Not OK

Not found

when consolida-

ted/timeout

Figure 2 – “Issuing of a new card” process

Continued on next page

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 27

First issue a card, Continued

Process steps

The issuing of a new card should follow more or less the following steps:

Step Action

1 The CIA’s clerk should first ask and verify the driver’s identity by any

appropriate means. The driver’s driving license will be used.

2 When the driver is identified, the clerk should record the driver’s request

to prevent a driver from asking a driver card more than once in the same

country or even in different countries at the same time.

3a The clerk should then verify, via TACHOnet, that the driver doesn’t hold

yet any driver card or doesn’t have any card request pending in any

Member State connected to TACHOnet (including the one where the

driver introduces his request) by sending a request to TACHOnet and

waiting for its response (asynchronous).

3b TACHOnet should then log and validate (syntactically) the request, send

in parallel an equivalent request to the different Member States, wait for

the response (asynchronous) from each of these Member States, process

the responses and send a consolidated response back to the initiator of

the request.

3c The different Member States should be ready to receive a request for

checking driver’s issued cards against their own data stores. They should

process the request, send back the response to TACHOnet.

4a If the TACHOnet result is a single driver (matching the given driver

identification criterias) holding yet a card or having a request pending,

the clerk should refuse the request (and follow the procedure for fraud

attempt). Procedure to be discussed by TF1 [8].

4b If the TACHOnet result mentions the driver has not been identified in

any Member States connected to TACHOnet, the clerk may decide to

accept and deliver the card (or perform a new check based on the

driver’s driving license number – step 3a ?)

4c If the TACHOnet result is a partial result, meaning at least one Member

State didn’t answer in time (for any reason such as network problem,

system unavailable,...), what should the clerk do? [8]

5a If the card is delivered to the driver AND if the driving license used to

apply for the card is a foreign one, the CIA’s clerk should then, via

TACHOnet, warn the Member State having issued the driving license

that a tachograph card (giving its number) has been delivered using the

driving license number, by sending a request to TACHOnet and waiting

for its response (asynchronous).

5b TACHOnet should then log and validate (syntactically) the request, send

an equivalent request to the Member State having issued the driving

license number, wait for the response (asynchronous) from this Member

State, process the response and send the response back to the initiator of

the request.

Continued on next page

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 28

First issue a card, Continued

Process steps (continued)

Step Action

6 If the TACHOnet result (in fact the response from the Member State

having issued the driving license) mentions the driving license number

doesn’t exist or that an error occurred (timeout,…), what should the

clerk do? [8]

Anyway, the clerk’s the judge: if he has any doubt about the validity of a request, he

should proceed to a manual intervention (e.g. sending a fax,...).

Identified

TACHOnet

service(s)

This process clearly identifies several services that should be supplied by the

TACHOnet network:

# Services/Functions

1 Receiving, logging, validating a request for checking whether a driver

(based on driver’s identification criteria’s – to be defined later) does already

hold a card or have a request pending somewhere.

2 Sending (and logging) an equivalent request to the different Member States

connected to TACHOnet

3 Receiving, logging and validating responses from these Member States

4 Consolidating the different responses into a single one

5 Sending (and logging) the consolidated response to the initiator of the

request

6 Receiving, logging, validating a request for warning the Member State

having issued a driving license used for issuing a card that a card (giving its

number) has been issued using that driving license number.

7 Sending (and logging) an equivalent request to the Member State having

issued the driving license number.

8 Receiving, logging and validating response from this Member State.

9 Sending (and logging) the received response to the initiator of the request.

10 Receiving, logging and validating a receipt (ACK or NAK) from the initiator

of the request

These identified services (along as requests, responses and receipts data structures)

will be described in more details when translated into use cases in the Use-Case

Model.

Technical issues such as data encoding, name encoding rules, security, network,...

will be analysed in details in [4].

Continued on next page

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 29

First issue a card, Continued

Card request

status

The card request (managed by Card Issuing Authority) should be encoded

immediately after receipt by the administration in charge of processing the request

and delivery. The request may have 2 status [8]:

• Application received

• Processed

From a TACHOnet point of view, what is important to know , when checking

whether a driver does already hold a card, is whether a card has already been

delivered to the driver or whether the driver is in the process of getting one

(application has been submitted and is in progress).

Driver’s

identification

in “check

driver’s

issued cards”

request

message

The driver’s identification criteria for checking driver’s issued cards should be the

following:

• Driver’s surname,

• Driver’s first names,

• Driver’s birth date

• Driver’s place of birth (optional)

• Driver’s driving license number (optional for enforcers)

The driving license will be used as the official document to read the driver’s details

from. Unfortunately, the driver’s driving license number cannot be used as reliable

unique identification (even though it’s required and stored when issuing a card) since

a driver could hold more than one driving license (in different countries), driving

licenses have an expiration date in some countries (and should then be renewed with

no guarantee of keeping the same number),... . Nevertheless, the driver’s driving

license number might be sent (optional) so that Member States willing to check the

validity of the driving license number could do so.

Technical issues such as data encoding, name encoding rules, name matching

algorithm will be analysed in details in [4].

Driver’s

identification

in “check

driver’s

issued cards”

response

message

The responses sent by the different Member States to the driver’s issued cards

request should include the following information (the returned information is the

same one as in the “Check driver’s issued card” process carried out by the enforcers)

about the matched drivers (i.e. yet holding a driver card or having applied for it):

• Code of Member State having issued the card

• Driver’s surname

• Driver’s first names

• Driver’s birth date

• Driver’s birthplace (optional)

• Driver’s driving license number + issued date + status (all optional)

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 30

First issue a card, Continued

Driver’s

identification in

“check driver’s

issued cards”

response

message

(continued)

• Card number

• Card status (valid, stolen, lost,…)

• Address where the card has been issued

• Issue date (date of 1

validity)

• Expiry date

• Last status modification date

The search against local data stores performed by the Member States must deal with

potential driver name misspelling, truncation,... . Technical issues such as data

encoding, name encoding rules, name matching algorithm will be analysed in details

in [4].

Pending

questions

Different questions come to mind when analysing the process and its interactions

with TACHOnet. These questions should be addressed at the beginning of the next

phase (detailed analysis) of the TACHOnet project.

Id Question Addressed to

1 Should TACHOnet also deal with the verification of

other tachograph cards than the driver card (company,

control, workshop)? If so, how can we identify the card

holder (company, control authority, workshop)? What

kind of information should be returned (company info +

list of issued cards,...)?

Answer

Only the driver card and the workshop card.

CIWG TF1

2 In how many days max. should the card issuing

authority deliver the card to the applicant driver? What’s

the timeout value (minutes, hours,…) for processing this

request?

Answer

To be discussed by TF1

CIWG TF1

3 What’s the estimation of the number of to-be-delivered

tachograph cards (per type) per Member State?

Answer

A rough estimation gives about 1600000 issued cards

per year. That gives around 7000 to 15000 driver cards

per day (all Member States included).

CIWG TF2

Continued on next page

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 31

First issue a card, Continued

Pending questions (continued)

Id Question Addressed to

4 What’s the estimation of the number of transactions per

day per Member State (taking into account peak period

at the beginning)?

Answer

A rough estimation gives about 1600000 issued cards

per year. That gives around 7000 to 15000 driver cards

per day (all Member States included).

CIWG TF2

5 Should TACHOnet be able to deal with MPOC CIAs

within a Member State or could it assume to deal with a

SPOC CIA per Member State?

Answer

A SPOC CIA could be assumed.

DG-TREN

6 What should we do if the driving license used for card

issuing has been issued by a foreign country not linked

to TACHOnet?

Answer

To be discussed by TF1

CIWG TF1

7 What if the Member State having issued the driving

license answers the driving license is unknown?

Answer

To be discussed by TF1

CIWG

8 Should TACHOnet provide a basic default “user

interface” (e.g. web-based application) helping Member

States (CIA or enforcers) to send requests to TACHOnet

(e.g. fill in a web form) and view the results (e.g. a web

form displaying the final results)?

Answer

No. Only web services for computing the Phonex search

keys and for US/ascii transliteration will be provided by

TACHOnet.

Getronics

Continued on next page

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 32

First issue a card, Continued

Pending questions (continued)

Id Question Addressed to

9 Should TACHOnet perform latin-2-greek transliteration

when sending the final response to the Greek CIA (from

Latin-encoded responses)? Should TACHOnet perform

greek-2-latin transliteration when sending the final

response to a Latin CIA (from Greek-encoded

response)?

Answer

No. Only web services for computing the Phonex search

keys and for Latin/Greek to US/ascii transliteration will

be provided by TACHOnet. Up to the CIA to use it

CIWG TF1

Getronics

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 33

Lost/Stolen card declaration

Introduction

This process deals with the declaration of a lost or stolen card.

Council Regulation (EC) N° 2135/98 mentions:

• Art.12 §1: “If a card issued to an approved workshop or fitter [...] is stolen or lost,

the authority shall supply a replacement card within five working days of receiving

a detailed request to that effect.”

• Art.14 §4(a): “[...] The issuing authority shall keep records of issued, stolen, lost or

defective cards for a period at least equivalent to their period of validity.”

• Art.14 §4(a): “[...] If the driver card is [...] lost or stolen, the authority shall supply

a replacement card within five working days of receiving a detailed request to that

effect.”

• Art.15 §1: “[...] If the driver card is [...] lost or stolen, the driver shall apply within

seven calendar days for its replacement to the competent authorities of the Member

State in which he has his normal residence.”

• Art.16 §3: “[...] Theft of the driver card shall be the subject of a formal declaration

to the competent authorities of the State where the theft occurred. Loss of the

driver card must be reported in a formal declaration to the competent authorities of

the State that issued it and to the competent authorities of the Member State of

normal residence where they are different.”

Process

description

As shown in Figure 3 below, the lost/stolen card declaration triggers processes and

events among 3 different “entities”:

• The Member State where theft/loss occured (declaring the theft/loss of the card),

• TACHOnet (providing central secure & reliable services for such declaration),

• The Member State having issued the card (recording the theft/loss of the card).

As mentioned earlier, business process modelling aims only at identifying the

different TACHOnet events and services needed to help Member State where

theft/loss occured and Member State having issued the card exchange information

about tachograph cards. Therefore, the processes described for the Member State

where theft/loss occured and Member State having issued the card “entities” are just

drawn as “helpers” to find out TACHOnet services. Only the processes of the

TACHOnet entity are of interest for the scope of the TACHOnet project.

According to [8], only theft should be notified via TACHOnet.

Continued on next page

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 34

Lost/Stolen card declaration, Continued

Process

diagram

The declaration of a lost/stolen card can be modelled as follows:

Lost/Stolen card declaration

Lost/stolen

driver card

declaration

Check driver's

identity

Record the

declaration/re-

quest

Send lost/stol-

en card message

to TCN

TACHOnet (TCN)

Issuing Member State (MS)

Member State where loss/theft occured (MS)

Send TCN respo-

nse lost/stolen

card message

Driver card

unknown

Timeout

Process MS res-

ponse lost/stol

en card message

Lost/Stolen

card request

Wait for TCN

response

TCN response

Log & validate

the TCN

response

Process the TCN response

Replacement

of a card

Timeout

Driver card

unknown

???

Lost/Stolen

card request

Log & validate

the request

Build the

request to MS

Send lost/stol-

en card request

to issuing MS

Wait for MS

response

MS response

Log & validate

the MS response

Lost/Stolen

card request

Lost/Stolen

card request

Log & validate

the request

Process

lost/stolen

card message

MS response

Check tachogra-

ph card status

Check card

status

Wait for check

card status

completion

Check card

status OK

Figure 3 – “Lost/stolen card declaration” process

Process steps

The declaration of a lost/stolen card should follow more or less the following steps:

Step Action

1 The clerk(or the enforcer) should first ask and verify the driver’s identity

by any appropriate means.

2 When the driver is identified, the clerk should record the details of the

declaration (driver’s identity, driver’s card id, Member State having

issued the card,...).

3 The clerk (or the enforcer) should then, via TACHOnet, check the status

of the lost/stolen card by keying in its card number (see “Check

tachograph card status” on page 56 for more details). This is required to

allow the clerk visually check the details of the lost/stolen card prior to

declaring it actually lost/stolen and then to avoid from mistakenly (e.g.

typing error in card number) declaring lost/stolen another card.

Continued on next page

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 35

Lost/Stolen card declaration, Continued

Process steps (continued)

Step Action

4a The clerk should then, via TACHOnet, warn the Member State having

issued the card that one of its issued card has been lost/stolen (so that the

issuing authority shall keep records of it) by sending a request to

TACHOnet and waiting for its response (asynchronous).

4b TACHOnet should then log and validate (syntactically) the request, send

an equivalent request to the Member State having issued the card, wait

for the response (asynchronous) from the Member State having issued

the card, process the response and send a consolidated response back to

the initiator of the request.

4c The Member State having issued the card should be ready to receive a

request for processing lost/stolen card declaration against his own data

store(s). It should process the request, send back the response to

TACHOnet.

5a If the result is positive, the driver should then proceed to the replacement

of his driver’s card (see “Replacement of a card” on page 55 for more

details)

5b If the result is negative (timeout or driver card unknown), what should

the clerk do?

Identified

TACHOnet

service(s)

This process identifies several services that should be supplied by the TACHOnet

network :

# Services/Functions

1 Receiving, logging, validating a request for declaring a lost/stolen card

2 Sending (and logging) an equivalent request to the Member State having

issued the card

3 Receiving, logging and validating response from the Member State having

issued the card

4 Sending (and logging) the consolidated response to the initiator of the request

These identified services (along as requests and responses data structures) will be

described in more details when translated into use cases in the Use-Case Model.

Technical issues such as data encoding, name encoding rules, security, network,...

will be analysed in details in [4].

Continued on next page

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 36

Lost/Stolen card declaration, Continued

Request

message

The message used for declaring lost/stolen cards should at least contain the following

information:

• Code of the Member State having issued the card

• Lost/stolen card number

• Reason for declaring status modification

Pending

questions

Different questions come to mind when analysing the process and its interactions

with TACHOnet. Most of these questions should be addressed by CIWG TF1 [8].

Id Question Addressed to

1 How should the clerk handle a “driver card id unknown”

response?

CIWG TF1

2 How should the clerk handle a “timeout” (no response

within time limit)?

CIWG TF1

3 What are the other types of response such a message could

generate (e.g. driver card already mentioned as stolen,...)?

CIWG TF1

4 What if the driver does not remember his lost/stolen driver

card number?

CIWG TF1

5 How to protect against “false” declarations (e.g. an ill-

disposed person might abusively declare some drivers

having lost their cards to be harmful to a company)?

CIWG TF1

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 37

Malfunctioning card declaration

Introduction

This process deals with the declaration of a malfunctioning card.

Council Regulation (EC) N° 2135/98 mentions:

• Art.12 §1: “If a card issued to an approved workshop or fitter [...] is damaged,

malfunctions [...] , the authority shall supply a replacement card within five

working days of receiving a detailed request to that effect.”

• Art.14 §4(a): “[...] The issuing authority shall keep records of issued, stolen, lost or

defective cards for a period at least equivalent to their period of validity.”

• Art.14 §4(a): “[...] If the driver card is damaged, malfunctions [...], the authority

shall supply a replacement card within five working days of receiving a detailed

request to that effect.”

• Art.15 §1: “[...] If the driver card is damaged, malfunctions [...], the driver shall

apply within seven calendar days for its replacement to the competent authorities

of the Member State in which he has his normal residence.”

• Art.16 §3: “[...] If a driver card is damaged or if it malfunctions, the driver shall

return it to the competent authority of the Member State in which he has his

normal residence.”

Process

description

As shown in Figure 4 below, the malfunctioning card declaration triggers processes

and events among 3 different “entities”:

• The Member State of driver’s normal residence (where the malfunctioning card

declaration is made),

• TACHOnet (providing central secure & reliable services for such declaration),

• The Member State having issued the card (recording the malfunctioning card

declaration).

As mentioned earlier, business process modelling aims only at identifying the

different TACHOnet events and services needed to help Member State of driver’s

normal residence and Member State having issued the card exchange information

about tachograph cards. Therefore, the processes described for the Member State of

driver’s normal residence and Member State having issued the card “entities” are

just drawn as “helpers” to find out TACHOnet services. Only the processes of the

TACHOnet entity are of interest for the scope of the TACHOnet project.

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 38

Malfunctioning card declaration, Continued

Process

diagram

The declaration of a Malfunctioning card can be modelled as follows:

Malfunctioning card declaration

Defective

driver card

declaration

Check driver's

identity

Record the

declaration/re-

quest

Member State of driver's normal residence (MS)

Send defective

card message

to TCN

Issuing Member State (MS)

Process MS res-

ponse defective

card message

Driver card

unknown

Timeout

TACHOnet (TCN)

Process

defective card

message

Defective card

request

Wait for TCN

response

TCN response

Log & validate

the TCN

response

Process the TCN response

Replacement

of a card

???

Timeout

Driver card

unknown

Defective card

request

Log & validate

the request

Build the

request to MS

Send defective

card message

to issuing MS

Defective card

request

Wait for MS

response

MS response

Log & validate

the MS response

Send TCN respo-

nse defective

card message

Defective card

request

Log & validate

the request

MS response

Check tachogra-

ph card status

Check card

status

Wait for check

card status

completion

Check card

status OK

Figure 4 – “Malfunctioning card declaration” process

Process steps

The declaration of a Malfunctioning card should follow more or less the following

steps:

Step Action

1 The clerk (or the enforcer) should first ask and verify the driver’s

identity by any appropriate means.

2 When the driver is identified, the clerk (or the enforcer) should record

the details of the declaration (driver’s identity, driver’s card id, Member

State having issued the card,...). The driver should also hand in his

malfunctioning card to the clerk.

Continued on next page

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 39

Malfunctioning card declaration, Continued

Process steps (continued)

Step Action

3 The clerk (or the enforcer) should then, via TACHOnet, check the status

of the malfunctioning card by keying in its card number (see “Check

tachograph card status” on page 56 for more details). This is required to

allow the clerk (or the enforcer) visually check the details of the

malfunctioning card prior to declaring it actually malfunctioning and

then to avoid from mistakenly (e.g. typing error in card number)

declaring malfunctioning another card. Moreover, such request will

return the internal TACHOnet reference of the actual CIA having issued

the card, which will be passed on in the next request to speed up the

process.

4a The clerk (or the enforcer) should then, via TACHOnet, warn the

Member State having issued the card that one of its issued card has been

identified as malfunctioning and returned (so that the issuing authority

shall keep records of it) by sending a request to TACHOnet and waiting

for its response (asynchronous).

4b TACHOnet should then log and validate (syntactically) the request, send

an equivalent request to the Member State having issued the card, wait

for the response (asynchronous) from the Member State having issued

the card, process the response and send a consolidated response back to

the initiator of the request.

4c The Member State having issued the card should be ready to receive a

request for processing malfunctioning card declaration against his own

data store(s). It should process the request, send back the response to

TACHOnet.

5a If the result is positive, the driver should then proceed to the replacement

of his driver’s card (see “Replacement of a card” on page 55 for more

details)

5b If the result is negative (timeout or driver card unknown), what should

the clerk do?

Continued on next page

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 40

Malfunctioning card declaration, Continued

Identified

TACHOnet

service(s)

This process clearly identifies several services that should be supplied by the

TACHOnet network:

# Services/Functions

1 Receiving, logging, validating a request for declaring a malfunctioning card

2 Sending (and logging) an equivalent request to the Member State having

issued the card

3 Receiving, logging and validating response from the Member State having

issued the card

4 Sending (and logging) the consolidated response to the initiator of the

request

These identified services (along as requests and responses data structures) will be

described in more details when translated into use cases in the Use-Case Model.

Technical issues such as data encoding, name encoding rules, security, network,...

will be analysed in details in [4].

Request

message

The message used for declaring malfunctioning cards should at least contain the

following information:

• Code of the Member State having issued the card

• Malfunctioning card number

• Reason for declaring card status modification

Pending

questions

Different questions come to mind when analysing the process and its interactions

with TACHOnet. Most of these questions should be addressed by CIWG TF1 [8].

Id Question Addressed to

1 How should the clerk handle a “driver card id unknown”

response ?

CIWG TF1

2 How should the clerk handle a “timeout” (no response

within time limit) ?

CIWG TF1

3 What are the other types of response such a message could

generate (e.g. driver card already mentioned as stolen,...) ?

CIWG TF1

4 Should the driver proceed to a renewal or replacement? CIWG TF1

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 41

Suspended card declaration

Introduction

This process deals with the declaration of a suspended card.

Council Regulation (EC) N° 2135/98 mentions:

• Art.14 §4(c): “The driver card [...] may not be withdrawn or suspended [...] unless

the competent authority of a Member State finds that the card has been falsified, or

the driver is using a card of which he is not the holder, or that the card held has

been obtained on the basis of false declarations and/or forged documents. If such a

suspension or withdrawal measures are taken by a Member State other than the

Member State of issue, the former shall return the card to the authorities of the

Member State which issued it and shall indicate the reasons for returning it.”

Process

diagram

The declaration of a suspended card can be modelled as follows:

Suspended card declaration

Suspended card

declaration

Record the

declaration/re-

quest

Member State suspending the card (MS)

Process

suspended card

message

Issuing Member State (MS)

Process MS

response suspe-

nded card msg

TACHOnet (TCN)

Driver card

unknown

Timeout

Send suspended

card message

to TCN

Suspended card

request

Wait for TCN

response

Log & validate

the TCN

response

TCN response

Process the TCN response

???

Timeout

Driver card

unknown

Suspended card

request

Log & validate

the request

Build the

request to MS

Send suspended

card message

to issuing MS

Suspended card

request

Wait for MS

response

MS response

Log & validate

the MS response

Send TCN

response suspe-

nded card msg

Suspended card

request

Log & validate

the request

MS response

Check tachogra-

ph card status

Wait for check

card status

completion

Check card

status OK

Check card

status

Figure 5 – “Suspended card declaration” process

Continued on next page

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 42

Suspended card declaration, Continued

Process

description

As shown in Figure 5 above, the suspended card declaration triggers processes and

events among 3 different “entities”:

• The Member State suspending the card (where the suspended card declaration is

made),

• TACHOnet (providing central secure & reliable services for such declaration),

• The Member State having issued the card (recording the suspended card

declaration).

As mentioned earlier, business process modelling aims only at identifying the

different TACHOnet events and services needed to help Member State suspending

the card and Member State having issued the card exchange information about

tachograph cards. Therefore, the processes described for the Member State

suspending the card and Member State having issued the card “entities” are just

drawn as “helpers” to find out TACHOnet services. Only the processes of the

TACHOnet entity are of interest for the scope of the TACHOnet project.

According to [8], ‘suspend’ is when the card is temporarily taken from the driver e.g.

whilst an investigation takes place, it could later be handed back to the driver.

‘withdraw’ is when the card is not returned to the driver, when the investigation is

complete.

Process steps

The declaration of a suspended card should follow more or less the following steps:

Step Action

1 A representative of the authority suspending the card (e.g. police

officer,...) sends his driver card suspension request to the card issuing

authority of his Member State. Then, the clerk should record the details

of the declaration (requestor’s identity, driver’s identity, driver’s card id,

Member State having issued the card,...). The driver should also have

handed in his driver card to the representative of the authority suspending

it who, in turn, will hand it over to the clerk at the time of this

declaration.

2 The clerk should then, via TACHOnet, check the status of the suspended

card by keying in its card number (see “Check tachograph card status” on

page 56 for more details). This is required to allow the clerk visually

check the details of the suspended card prior to declaring it actually

suspended and then to avoid from mistakenly (e.g. typing error in card

number) declaring suspended another card. Moreover, such request will

return the internal TACHOnet reference of the actual CIA having issued

the card, which will be passed on in the next request to speed up the

process.

3a The clerk should then, via TACHOnet, warn the Member State having

issued the card that one of its issued card has been suspended and for

which reason (so that the issuing authority shall keep records of it) by

sending a request to TACHOnet and waiting its response (asynchronous).

Continued on next page

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 43

Suspended card declaration, Continued

Process steps (continued)

Step Action

3b TACHOnet should then log and validate (syntactically) the request, send

an equivalent request to the Member State having issued the card, wait

for the response (asynchronous) from the Member State having issued

the card, process the response and send a consolidated response back to

the initiator of the request.

3c The Member State having issued the card should be ready to receive a

request for processing suspended card declaration against his own data

store(s). It should process the request, send back the response to

TACHOnet.

4a If the result is positive, the clerk should archive the declaration.

4b If the result is negative (timeout or driver card unknown), what should

the clerk do?

Identified

TACHOnet

service(s)

This process clearly identifies several services that should be supplied by the

TACHOnet network:

# Services/Functions

1 Receiving, logging, validating a request for declaring a suspended card

2 Sending (and logging) an equivalent request to the Member State having

issued the card

3 Receiving, logging and validating response from the Member State having

issued the card

4 Sending (and logging) the consolidated response to the initiator of the

request

These identified services (along as requests and responses data structures) will be

described in more details when translated into use cases in the Use-Case Model.

Technical issues such as data encoding, name encoding rules, security, network,...

will be analysed in details in [4].

Continued on next page

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 44

Suspended card declaration, Continued

Request

message

The message used for declaring suspended cards should at least contain the

following information:

• Code of the Member State having issued the card

• Suspended card number

• Reason for declaring the suspension [see [8])

Pending

questions

Different questions come to mind when analysing the process and its interactions

with TACHOnet. Most of these questions should be addressed by CIWG TF1 [8].

Id Question Addressed to

1 How should the clerk handle a “driver card id unknown”

response ?

CIWG TF1

2 How should the clerk handle a “timeout” (no response

within time limit) ?

CIWG TF1

3 What are the other types of response such a message

could generate (e.g. driver card already mentioned as

stolen,...) ?

CIWG TF1

4 Should the forger be recorded as such to avoid from

issuing him a driver card later ?

CIWG TF1

5 Should the reason(s) of the suspension be listed in the

message? If so, what’s the exhaustive list of suspension

codes?

CIWG TF1

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 45

Lost/stolen card hand in

Introduction

This process deals with the handing over of a more likely lost/stolen card.

Process

diagram

The handing over of a lost/stolen card can be modelled as follows:

Lost/Stolen card hand in

Lost/stolen

card hand in

Record the

declaration/re-

quest

Send card found

message to TCN

Process found

card message

Issuing Member State (MS)

Process MS

response found

card message

Driver card

unknown

Timeout

TACHOnet (TCN)Member State where card handed in (MS)

Card found

request

Wait for TCN

response

TCN response

Log & validate

the TCN

response

Process the TCN response

Timeout

???

Driver card

unknown

Card found

request

Log & validate

the request

Build the

request to MS

Send card found

message to

issuing MS

Card found

request

Wait for MS

response

MS response

Log & validate

the MS response

Send TCN

response found

card message

Card found

request

Log & validate

the request

MS response

Check tachogra-

ph card status

Wait for check

card status

completion

Check card

status OK

Check card

status

Figure 6 – “Lost/stolen card hand in” process

Continued on next page

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 46

Lost/stolen card hand in, Continued

Process

description

As shown in Figure 6 above, the lost/stolen card hand in declaration triggers

processes and events among 3 different “entities”:

• The Member State where the card’s handed over (where the suspended card

declaration is made),

• TACHOnet (providing central secure & reliable services for such declaration),

• The Member State having issued the card (recording the lost/stolen card hand in

declaration).

As mentioned earlier, business process modelling aims only at identifying the

different TACHOnet events and services needed to help Member State where the

card’s handed over and Member State having issued the card exchange information

about tachograph cards. Therefore, the processes described for the Member State

where the card’s handed over and Member State having issued the card “entities”

are just drawn as “helpers” to find out TACHOnet services. Only the processes of the

TACHOnet entity are of interest for the scope of the TACHOnet project.

According to [8], the status of the card will not change even though it has been

handed in.

Process steps

The handing over of a lost/stolen card should follow more or less the following

steps:

Step Action

1 Someone brings back a driver card he found somewhere (more likely lost

or stolen). The clerk should record the details of the declaration (driver’s

identity, driver’s card id, Member State having issued the card,...). The

clerk should also return the driver card to the Member State authority

having issued the card.

2 The clerk should then, via TACHOnet, check the status of the card handed

over by keying in its card number (see “Check tachograph card status” on

page 56 for more details). This is required to allow the clerk visually check

the details of the card prior to declaring it actually handed over and then to

avoid from mistakenly (e.g. typing error in card number) declaring handed

over another card. Moreover, such request will return the internal

TACHOnet reference of the actual CIA having issued the card, which will

be passed on in the next request to speed up the process.

3a The clerk should then, via TACHOnet, warn the Member State having

issued the card that one of its issued card has been found and for which

reason (so that the issuing authority shall keep records of it) by sending a

request to TACHOnet and waiting for its response (asynchronous).

Continued on next page

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 47

Lost/stolen card hand in, Continued

Process steps (continued)

Step Action

3b TACHOnet should then log and validate (syntactically) the request, send in

parallel an equivalent request to the Member State having issued the card,

wait for the response (asynchronous) from the Member State having issued

the card, process the response and send a consolidated response back to the

initiator of the request.

3c The Member State having issued the card should be ready to receive a

request for processing lost/stolen card hand in declaration against his own

data store(s). It should process the request, send back the response to

TACHOnet.

4a If the result is positive, the clerk should archive the declaration.

4b If the result is negative (timeout or driver card unknown), what should the

clerk do?

Identified

TACHOnet

service(s)

This process clearly identifies several services that should be supplied by the

TACHOnet network:

# Services/Functions

1 Receiving, logging, validating a request for declaring a lost/stolen card hand-

2 Sending (and logging) an equivalent request to the Member State having

issued the card

3 Receiving, logging and validating response from the Member State having

issued the card

4 Sending (and logging) the consolidated response to the initiator of the request

These identified services (along as requests and responses data structures) will be

described in more details when translated into use cases in the Use-Case Model.

Technical issues such as data encoding, name encoding rules, security, network,...

will be analysed in details in [4].

Request

message

The message used for declaring lost/stolen card hand in should at least contain the

following information:

• Code of the Member State having issued the card

• found card number

• Reason for declaring card status modification

Continued on next page

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 48

Lost/stolen card hand in, Continued

Pending

questions

Different questions come to mind when analysing the process and its interactions

with TACHOnet. Most of these questions should be addressed by CIWG TF1 [8].

Id Question Addressed to

1 How should the clerk handle a “driver card id unknown”

response?

CIWG TF1

2 How should the clerk handle a “timeout” (no response

within time limit)?

CIWG TF1

3 What are the other types of response such a message

could generate (e.g. driver card already mentioned as

stolen,...)?

CIWG TF1

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 49

Renewal of a card

Introduction

This process deals with the issue of a new tachograph card when an existing card

reaches its expiry date, or is malfunctioning and has been returned to the issuing

authority. Renewal always implies the certainty that two valid cards do not co-exist.

Council Regulation (EC) N° 2135/98 mentions:

• Art.14 §4(a): “[...] In the event of a request for the renewal of a card whose expiry

date is approaching, the authority shall supply a new card before the expiry date

provided that the request was sent to it within the time limits [...]”

• Art.14 §4(e): “When a Member State replaces or exchanges a driver card, the

replacement or exchange, and any subsequent replacement or renewal, shall be

registered in that Member State.”

• Art.15 §1: “[...] Where a driver wishes to renew his driver card, he shall apply to

the competent authorities of the Member State in which he has his normal

residence not later than 15 working days before the expiry date of the card.”

Process

description

According to [8] and since the renewal should always be processed by the Member

State where the driver has his normal residence, which is also the same Member

State having issued the card (otherwise it’s not a renewal but an exchange), the

renewal of a card doesn’t need to be handled via TACHOnet.

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 50

Exchange of a card

Introduction

This process deals with the exchange of an existing valid driver card for an

equivalent driver card for administrative reasons (e.g. the holder of the valid driver

card has established his normal place of residence in another Member State).

Council Regulation (EC) N° 2135/98 mentions:

• Art.14 §4(d): “[...] Where the holder of a valid driver card issued by a Member

State has established his normal place of residence in another Member State, he

may ask for his card to be exchanged for an equivalent driver card; [...]

responsibility of the Member State which carries out the exchange to verify if

necessary whether the card produced is actually still valid. Member States carrying

out an exchange shall return the old card to the authorities of the Member State of

issue and indicate the reasons for so doing.”

• Art.14 §4(e): “When a Member State replaces or exchanges a driver card, the

replacement or exchange, and any subsequent replacement or renewal, shall be

registered in that Member State.”

Process

description

As shown in Figure 7 below, the exchange of a card triggers processes and events

among 3 different “entities”:

• The Member State of driver’s normal residence (where the exchange of card

declaration is made),

• TACHOnet (providing central secure & reliable services for such declaration),

• The Member State having issued the card (recording the exchange of a card).

As mentioned earlier, business process modelling aims only at identifying the

different TACHOnet events and services needed to help Member State of driver’s

normal residence and Member State having issued the card exchange information

about tachograph cards. Therefore, the processes described for the Member State of

driver’s normal residence and Member State having issued the card “entities” are

just drawn as “helpers” to find out TACHOnet services. Only the processes of the

TACHOnet entity are of interest for the scope of the TACHOnet project.

Continued on next page

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 51

Exchange of a card, Continued

Process

diagram

The exchange of a card can be modelled as follows:

Exchange of a card

Exchange

of a card

Check driver's

identity

Check the requ-

est validity

Record the

declaration/re-

quest

Send request

for card

exchange to TCN

Process request

for card

exchange

Member State having issued the card (MS)

TACHOnet (TCN)

Process MS

response card e

xchange request

Not allowed

Driver card

unknown

Timeout

Member State of normal residence (MS)

Driver card ex-

change request

Wait for TCN

response

TCN response

Log & validate

the TCN

response

Process the TCN response

Suspended card

declaration

???

Timeout

Driver card

unknown

Not allowed

Driver card ex-

change request

Log & validate

the request

Build the

request to MS

Send request f-

or card exchang

e to issuing MS

Driver card ex-

change request

Wait for MS

response

MS response

Log & validate

the MS response

Send TCN

response card

exchange

Driver card ex-

change request

Log & validate

the request

MS response

Check tachogra-

ph card status

Wait for check

card status

completion

Check card

status OK

Check card

status

Figure 7 – “Exchange of a card” process

Process steps

The exchange of a card should follow more or less the following steps:

Step Action

1 The clerk should first ask and verify the driver’s identity by any

appropriate means.

2 When the driver is identified, the clerk should record the details of the

request (driver’s identity, driver’s card id, Member State having issued the

card,...).

Continued on next page

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 52

Exchange of a card, Continued

Process steps (continued)

Step Action

3 The clerk should then, via TACHOnet, check the status of the card by

keying in its card number (see “Check tachograph card status” on page 56

for more details). This is required to allow the clerk visually check the

details of the card prior to exchanging it and then to avoid from mistakenly

(e.g. typing error in card number) exchanging another card. Moreover,

such request will return the internal TACHOnet reference of the actual

CIA having issued the card, which will be passed on in the next request to

speed up the process.

3a The clerk should then, via TACHOnet, warn the Member State having

issued the card (should be different than the one of normal residence) that

one of its issued card is in the process of being exchanged (so that the

issuing authority shall keep records of it) by sending a request to

TACHOnet and waiting for its response (asynchronous).

3b TACHOnet should then log and validate (syntactically) the request, send an

equivalent request to the Member State having issued the card, wait for the

response (asynchronous) from the Member State having issued the card,

process the response and send a consolidated response back to the initiator

of the request.

3c The Member State having issued the card should be ready to receive a

request for processing the declaration of the exchange of a card against its

own data store(s). It should process the request, send back the response to

TACHOnet.

4a If the result is positive, the clerk should proceed to the exchange of the

card. At delivery time, the driver should hand in his old card. The clerk

should proceed to the suspension of this card (reason: card exchanged) via

the “Suspended card declaration” process.

According to [8], this doesn’t apply to all countries as some countries will

request return of the old card before issuing the exchanged card. Some

countries will have an over the counter service.

4b If the result is negative (not allowed, timeout or driver card unknown),

what should the clerk do?

Continued on next page

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 53

Exchange of a card, Continued

Identified

TACHOnet

service(s)

This process clearly identifies several services that should be supplied by the

TACHOnet network:

# Services/Functions

1 Receiving, logging, validating a request for an exchange of a card

2 Sending (and logging) an equivalent request to the Member State having

issued the card

3 Receiving, logging and validating response from the Member State having

issued the card

4 Sending (and logging) the consolidated response to the initiator of the request

These identified services (along as requests and responses data structures) will be

described in more details when translated into use cases in the Use-Case Model.

Technical issues such as data encoding, name encoding rules, security, network,...

will be analysed in details in [4].

Request

message

The message used for card exchange should at least contain the following

information:

• Code of the Member State having issued the card

• Number of the card to exchange

• Reason for declaring card status modification.

Pending

questions

Different questions come to mind when analysing the process and its interactions

with TACHOnet. Most of these questions should be addressed by CIWG TF1 [8].

Id Question Addressed to

1 How should the clerk handle a “request not allowed”

response (e.g. stolen card,...)?

CIWG TF1

2 How should the clerk handle a “driver card id unknown”

response?

CIWG TF1

3 How should the clerk handle a “timeout” (no response

within time limit)?

CIWG TF1

4 What are the other types of response such a request could

generate?

CIWG TF1

Continued on next page

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 54

Exchange of a card, Continued

Pending questions (continued)

Id Question Addressed to

5 Should a malfunctioning card be replaced or renewed?

CIWG TF1

6 Is the card exchange process the same for each type of

tachograph card (driver, company, control, workshop)?

CIWG TF1

7 Are the card replacement index and renewal index

unchanged in case of exchange?

CIWG TF1

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 55

Replacement of a card

Introduction

This process deals with the issue of a tachograph card in replacement of an existing

card, which has been declared lost, stolen or malfunctioning and has not been

returned to the issuing authority. Replacement always implies a risk that two valid

cards may co-exist.

Council Regulation (EC) N° 2135/98 mentions:

• Art.12 §1: “If a card issued to an approved workshop or fitter [...] is damaged,

malfunctions [...] , the authority shall supply a replacement card within five

working days of receiving a detailed request to that effect.”

• Art.14 §4(a): “[...] If the driver card is damaged, malfunctions [...], the authority

shall supply a replacement card within five working days of receiving a detailed

request to that effect.”

• Art.14 §4(e): “When a Member State replaces or exchanges a driver card, the

replacement or exchange, and any subsequent replacement or renewal, shall be

registered in that Member State.”

• Art.15 §1: “[...] If the driver card is damaged, malfunctions [...], the driver shall

apply within seven calendar days for its replacement to the competent authorities

of the Member State in which he has his normal residence.”

Process

description

According to [8] and since the replacement should always be processed by the

Member State where the driver has his normal residence, which is also the same

Member State having issued the card (otherwise it’s not a replacement but an

exchange), the replacement of a card doesn’t need to be handled via TACHOnet.

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 56

Check tachograph card status

Introduction

This process deals with the verification of the state of a tachograph card based on its

card number. This process is very useful for enforcement authorities to detect any

theft or forgery. Therefore, such a process should ideally be available 24x7.

Enforcers should be able to check driver cards and workshop cards [6].

This process should also be carried out by CIA to check the owner of a card (based

on its number) prior to declaring it lost or stolen or malfunctioning.

Process

diagram

The verification of a tachograph card can be modelled as follows:

Check tachograph card status

Check card

status

Record the

declaration/re-

quest

Send check card

status request

to TCN

Check card

status request

Wait for TCN

response

TCN response

Log & validate

the TCN

response

Member State Police authority (MS)

Process the TCN response

???

Timeout

Driver card

unknown

Check card

status request

TACHOnet (TCN)

Log & validate

the request

Build the

request to MS

Send check card

status to

issuing MS

Check card

status request

Wait for MS

response

MS response

Log & validate

the MS response

Process MS

response check

card status

Send TCN

response check

card status

Driver card

unknown

Timeout

Member State having issued the card (

Check card

status request

Log & validate

the request

Process check

card status

request

MS response

Figure 8 – “Check tachograph card” process

Continued on next page

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 57

Check tachograph card status, Continued

Process

description

As shown in Figure 8 above, the verification of a tachograph card triggers processes

and events among 3 different “entities”:

• The Member State Enforcement Authority (willing to perform the verification of a

tachograph card). Granting Enforcement Authorities access to TACHOnet is under

the responsibility of each Member State and has to be managed by them

accordingly (should impersonate a Member State’s CIA as only CIAs are managed

as authorized entities),

• TACHOnet (providing central secure & reliable services for such verification),

• The Member State having issued the card (performing the verification against its

own data store).

As mentioned earlier, business process modelling aims only at identifying the

different TACHOnet events and services needed to help Member State of driver’s

normal residence and Member State having issued the card exchange information

about tachograph cards. Therefore, the processes described for the Member State of

driver’s normal residence and Member State having issued the card “entities” are

just drawn as “helpers” to find out TACHOnet services. Only the processes of the

TACHOnet entity are of interest for the scope of the TACHOnet project.

Process steps

The verification of a tachograph card should follow more or less the following steps:

Step Action

1 The authorized enforcer gets connected to the “check tachograph card”

application (typing in his user name and password) and types in the card

number and the issuing member state code (identifying uniquely a

tachograph card) of the tachograph card he’d like to check. Note that the

so-called “check tachograph card” application is the kind of application a

Member State needs to provide to grant Enforcement Authorities access to

TACHOnet (by impersonating a CIA).

2 The application sends, via TACHOnet, the request for checking the given

card to the Member State having issued the card (based on the issuing

member state sign)

3a TACHOnet should then log and validate (syntactically) the request, send in

parallel an equivalent request to the Member State having issued the card

(SPOC), wait for the response (asynchronous) from the Member State

having issued the card, process the response and send a consolidated

response back to the initiator of the request.

3b The Member State having issued the card should be ready to receive a

request for checking the status of a card against its own data store(s). It

should process the request, send back the response to TACHOnet.

Continued on next page

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 58

Check tachograph card status, Continued

Process steps (continued)

Step Action

4a If the result is positive (card detected), the status of the card is returned and

handled accordingly by the police officer.

4b If the result is negative (not allowed, timeout or driver card unknown),

what should the police officer do?

Identified

TACHOnet

service(s)

This process clearly identifies several services that should be supplied by the

TACHOnet network:

# Services/Functions

1 Receiving, logging, validating a request for a checking the status of a card

2 Sending (and logging) an equivalent request to the Member State having

issued the card (SPOC )

3 Receiving, logging and validating response(s) from the Member State having

issued the card

4 Building the final response

5 Sending (and logging) the final response to the initiator of the request

These identified services (along as requests, responses and receipts data structures)

will be described in more details when translated into use cases in the Use-Case

Model. Technical issues such as data encoding, name encoding rules, security,

network,... will be analysed in details in [4].

Request

message

The message used for checking a card should at least contain the following

information:

• Code of the Member State having issued the card

• Number of the card to check

Continued on next page

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 59

Check tachograph card status, Continued

Response

message

The response message to checking a driver card should return the same information

as the one for checking driver’s issued card (see Driver’s identification in “check

driver’s issued cards” response message at page 29).

For a workshop card, the information is more or less similar:

• Card number

• Card status (valid, stolen, lost,…)

• Address where the card has been issued

• Issue date (date of 1

validity)

• Expiry date

• Last status modification date

• Workshop name

• Workshop address

• Surname, first names and date of birth of the individual to who the card was

issued.

Pending

questions

Different questions come to mind when analysing the process and its interactions

with TACHOnet. These questions should be addressed at the beginning of the next

phase (detailed analysis) of the TACHOnet project.

Id Question Addressed to

1 Should TACHOnet provide a basic default “user

interface” (e.g. web-based application) helping Member

States (CIA or enforcers) to send requests to TACHOnet

(e.g. fill in a web form) and view the results (e.g. a web

form displaying the final results)?

Answer

No. Up to the Member State (via CIA application?) to

implement such application.

CIWG TF2

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 60

Check driver’s issued card

Introduction

This process deals with the verification of whether a particular driver (based on his

name, first names, date of birth,…) does actually hold a valid card.

Such process will be carried out by the enforcers during road-checks to check, when

a driver is unable to show his card (pretending it’s lost or stolen), that this driver

does actually hold a valid card issued by a Member State. Therefore, such process

should ideally be available 24x7 [6].

This process will also be carried out by CIA when issuing a new card (see

description at page 25).

Process steps

The process steps are the same as the ones described for checking a tachograph card

status (see page 57), except that the card number in the request is replaced by the

driver’s surname, first names, datye of birth,… .

Request

message

The request message to checking driver’s card should contain the same information

as described in “Driver’s identification in “check driver’s issued cards” request

message” at page 29).

The only difference between CIAs and enforcers usage is that the CIAs requests

should target all Member States whereas the enforcers requests will only target the

Member State having issued the driver’s card (as the driver must prove he owns a

valid card, he should at least tell the enforcers where he did get the card he couldn’t

show). Therefore, the request message should also contain an optional “Issuing

Member State Code” indicating whether to target all Member States (if empty) or a

particular one (if specified).

Response

message

The response message to checking driver’s card should return the same information

as described in “Driver’s identification in “check driver’s issued cards” response

message” at page 29).

Pending

questions

See page 59.

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 61

Bulk check of issued driver card holders

Introduction

This process deals with the verification asked by a Member State that all or a large

part of its driver card holders are not yet holder of another card in another country.

This is for use by those countries that will not be joined to TACHOnet at go live and

will need to carry out a check at a later date [8].

Basically, this process merely consists of performing the same verification as

explained in the “First issue a card” process (check driver’s issued card(s)) but not

only for a single driver but for a bunch of drivers.

Therefore, several aspects such as the size of the request/response, the required

processing time,... will have to be analysed deeper.

Process

diagram

This process can be modelled as follows:

Bulk check of issued driver card holders

Member State requesting the bulk check (MS)

Bulk check

TACHOnet (TCN)

Member States (MS)

Prepare the

Bulk Check req-

uest document

Send Bulk check

request to TCN

Bulk check

request

Bulk check

request

Log & validate

the request

Build the

request to MS

For each Member State (in parallel)

Process MS

response to

Bulk check

Log & validate

the MS response

MS response

Wait for MS

response

Bulk check

request

Send Bulk check

request

document to MS

Wait for TCN

response

TCN response

Log & validate

the TCN

response

Process the TCN

response to

Bulk check

???

Send consolida-

ted TCN respons

e to Bulk check

TCN response

Bulk check

request

Log & validate

the request

For each driver in Bulk check request

Consolidate

the Bulk check

response

Check driver

issued card(s)

Send MS

response to

Bulk check

MS response

consolidated/t-

imeout

All drivers

processed

Figure 9 – “Bulk check of issued driver card holders” process

Continued on next page

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 62

Bulk check of issued driver card holders, Continued

Process

description

As shown in Figure 9 above, the bulk check of issued driver card holders triggers

processes and events among 3 different “entities”:

• The Member State issuing the bulk check (CIA) issuing the card and asking for the

bulk verification,

• TACHOnet (providing central secure & reliable services for such verification),

• The different Member States performing the verification against their own data

stores.

As mentioned earlier, business process modelling aims only at identifying the

different TACHOnet events and services needed to help Card Issuing Authorities and

Member States exchange information about tachograph cards. Therefore, the

processes described for the Card Issuing Authorities and Member States “entities”

are just drawn as “helpers” to find out TACHOnet services. Only the processes of the

TACHOnet entity are of interest for the scope of the TACHOnet project.

Process steps

The verification asked by a Member State that all or a large part of its driver card

holders are not yet holder of another card in another country should follow more or

less the following steps:

Step Action

1 The clerk should ask for the generation of an input file (which structure

will be defined later on) listing the driver card holders (driver surname,

driver first name, driver’s license number, driver’s birthdate,...) to check.

2a The clerk should then verify, via TACHOnet, that its CIA’s drivers don’t

hold yet any driver card or don’t have any card request pending in any

Member State connected to TACHOnet by sending to TACHOnet the

request for checking issued cards for the listed drivers and waiting for its

receipt and then its response (asynchronous).

2b TACHOnet should then log and validate (syntactically) the request, send

in parallel an equivalent request to the different Member States, wait for

the response (asynchronous) from each of these Member States, process

the responses and send a consolidated response (listing each Member

State result for each requested driver card holder) back to the initiator of

the request.

2c The different Member States should be ready to receive a request for

checking drivers’ issued cards against their own data stores. They should

process the request, send back the response to TACHOnet.

3 The clerk should then analyse the consolidated result.

Continued on next page

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 63

Bulk check of issued driver card holders, Continued

Identified

TACHOnet

service(s)

This process clearly identifies several services that should be supplied by the

TACHOnet network:

# Services/Functions

1 Receiving, logging, validating a request for checking whether drivers (based

on drivers’ identification criteria’s – to be defined later) does hold yet a card

or have a request pending somewhere.

2 Sending (and logging) an equivalent request to the different Member States

connected to TACHOnet

3 Receiving, logging and validating responses from these Member States

4 Consolidating the different responses into a single one

5 Sending (and logging) the consolidated response to the initiator of the

request

These identified services (along as requests and responses data structures) will be

described in more details when translated into use cases in the Use-Case Model.

Technical issues such as data encoding, name encoding rules, security, network,...

will be analysed in details in [4].

Pending

questions

Different questions come to mind when analysing the process and its interactions

with TACHOnet. These questions should be addressed at the beginning of the next

phase (detailed analysis) of the TACHOnet project.

Id Question Addressed to

1 What’s the estimation of the number of drivers that

might be included in a bulk check request?

Answer

Max. 1000

CIWG TF2

2 What’s the timeout value for such a request (how long

should TACHOnet wait for receiving responses from the

Member States?)?

Answer

Such requests are to be considered as batch requests

(more than a single request) and should then be

processed over night (with a timeout of several hours) to

avoid from disturbing online requests.

CIWG TF2

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 64

Section 3.3 - System tasks

Overview

Introduction

This process group gathers the different processes related to the system tasks

provided by the TACHOnet project and carried out by authorized administrators.

Contents

This section contains the following topics.

Topic See Page

Users & access rights management 65

Statistics management 70

Logging & Monitoring management 73

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 65

Users & access rights management

Introduction

This process deals with the definition of the users having access to the TACHOnet

functionalities along as their access rights to these functionalities.

What’s a

TACHOnet

user?

TACHOnet aims at providing Member States (through their Card Issuing Authorities

– CIAs) with secure and reliable services for exchanging information about

tachograph cards.

Figure 10 sums up the different types of users TACHOnet will manage. These are

CIA, CIA administrator and TCN administrator.

EURO Domain

TACHOnet

Services

Country A Local Domain

CIA

Admin

Country B Local Domain

CIA

TC N

Admin

CIA

Admin

Figure 10 – TACHOnet users

Please refer to [4] for more technical details about architecture, security and network

issues.

Continued on next page

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 66

Users & access rights management, Continued

What’s a CIA

user type?

As you might see in Figure 10, TACHOnet considers a whole CIA as a single user

(the CIA administrator excepted). TACHOnet does not manage each CIA users (e.g.

the clerks performing administrative tasks). These latter ones have to be managed

accordingly by each Member State’s CIA under their own responsibility. From the

TACHOnet viewpoint, the CIA as a whole is a single user and will be defined

accordingly (a single digital certificate will be delivered for a CIA,...). Therefore,

enforcers are also considered as CIA users who should then be managed by each

Member State (TACHOnet only have a SPOC CIA).

A CIA-typed user will be granted the rights for carrying out any of the administrative

tasks (see

Administrative tasks for more details).

As mentioned earlier (see “Card Issuing Authority” definition), a Member State may

have a single or several Card Issuing Authorities managing card issuing for his

resident drivers. Nevertheless, it has been agreed that TACHOnet will consider the

Member State as having a SPOC CIA (Single Point Of Contact Card Issuing

Authority), even though the Member State is organized through multiple CIAs

managing their tachograph cards data in a common central data store (it’s up to the

Member State to manage the one-to-many relationship).

What’s a CIA

Administrator

user type?

A CIA Administrator user type stands for the interface between TACHOnet and a

CIA regarding system tasks (user management, statistics, logging,...). A CIA

Administrator may only manage a single CIA. But a CIA may be managed by one or

more CIA Administrators (but at least one).

From the TACHOnet viewpoint, the CIA Administrator is a single user and will be

defined accordingly (a single digital certificate will be delivered for a CIA

Administrator,...).

A CIA Administrator-typed user will be granted the rights for carrying out any of the

system tasks (see System tasks for more details).

What’s a TCN

Administrator

user type?

The TCN (TACHOnet) Administrator is in charge of administering the whole

TACHOnet services in terms of configuration, performance, logging, tracking,... .

The TCN Administrator is not related to any CIA and works for the Trusted Third

Party company hosting and managing the TACHOnet services.

Continued on next page

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 67

Users & access rights management, Continued

Process

diagram

This process group can be modelled as follows:

Users & access rights Management

TACHOnet (TCN)

Add new CIA

Modify CIA

Remove CIA

Modify CIA

Admin

Add a new CIA

Modify an

existing CIA

Remove an

existing CIA

Modify an exis-

ting CIA Admin

Add new CIA

Admin

Add a new

CIA Admin

Remove CIA

Admin

Remove an exis-

ting CIA Admin

Figure 11 – “Users & access rights management” process

Process

description

As shown in Figure 11 above, different processes have been identified for users &

access rights management:

Process Description

Add a new CIA This process deals with the TACHOnet definition of a new

Member State Card Issuing Authority CIA-typed user.

Modify CIA

parameters

This process deals with the modification of some parameters

(IP address,...) of an existing CIA-typed user.

Remove CIA This process deals with the removal of an existing CIA-typed

user.

Add CIA

Admin

This process deals with the TACHOnet definition of a new CIA

Administrator-typed user.

Modify CIA

Admin

This process deals with the modification of some parameters of

an existing CIA Administrator -typed user.

Continued on next page

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 68

Users & access rights management, Continued

Process description (continued)

Process Description

Remove CIA

Admin

This process deals with the removal of an existing CIA

Administrator -typed user.

Important note

These processes raise some important issues regarding procedures and policies

(operational, audit, security,…) that should be put in place in order to address some

questions like:

• How to join in?

• How to define an administrator?

• How to exclude a Member State?

• How to make the system evolve?

• …

Such processes will be carried out manually according sound procedures defined and

approved by a kind of TACHOnet User Group (see below).

TACHOnet

User Group

The TCN User Group (or Management Board) would consist of a representative of

each Member State using the TACHOnet system and some representatives of the

European Commission (ideally from the DG TREN’s Inland Transport Directorate)

in order to define and manage operational and security procedures (who may be in,

how to join in,…) as well as the evolution of the system.

Defining the structure and the roles of such a group is beyond the scope of this

document but its setup is of prime importance for the success of the whole project.

Such a group (or board) should obviously be set up prior to deploying the

TACHOnet system.

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 69

Users & access rights management, Continued

Pending

questions

Different questions come to mind when analysing the process and its interactions

with TACHOnet. Most of these questions should be addressed by CIWG TF2 [8].

Id Question Addressed to

1 Which authority will be granted the rights for adding or

removing a CIA-typed user?

Answer

The DG TREN Inland Transport Directorate

DG TREN

2 What will be the procedure(s) for adding, modifying,

removing a Member State (and its corresponding

administrator)?

CIWG TF2

3 How long should TACHOnet keep logging and tracking

info for a removed user?

CIWG TF2

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 70

Statistics management

Introduction

This process deals with the management of different statistics (e.g. usage,...) around

TACHOnet activities.

Statistics,

what’s in a

word?

Statistics are valuable data for evaluating the usage of a system, its relative

performance,... . Therefore, TACHOnet will automatically generate, on a weekly,

monthly and/or yearly basis, two different types of statistics report depending on the

target user(s):

Target user type Statistics report type

CIA

Administrator

A first report will be generated for each CIA (and sent to their

corresponding CIA Administrator). It will contain info about:

• Number of requests/receipts/responses sent by CIA to

TACHOnet (globally + per type of request/response + per

time slices)

• Number of requests/receipts/responses sent by TACHOnet

to CIA (globally + per type of request/response + per time

slices)

• Average time for sending receipt to request/response (+

slowest/fastest time) per type of request/response

• Average time for sending response to request (+

slowest/fastest time) per type of request

• Average size of requests/receipts/responses (+

smallest/highest) per type of request/response

• % of fully completed requests sent by CIA to TACHOnet

(per type of request)

• % of fully completed requests sent by TACHOnet to CIA

(per type of request)

• % of failed requests sent by CIA to TACHOnet (per type of

failure and request)

• % of failed requests sent by TACHOnet to CIA (per type of

failure and request)

• Others needful info are welcome...

Important: All the information provided to a CIA only deals

with transactions involving that CIA.

TCN

Administrator

A second report (DB-based) will be generated for TACHOnet

internal purposes. It will contain info about:

• More or less the same info as above but including all CIAs

• Servers availability, performance,...

• DB availability, performance, volume,...

• Others needful info are welcome...

Continued on next page

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 71

Statistics management, Continued

Process

diagram

This process group can be modelled as follows:

Statistics Management

TACHOnet (TCN)

Timer event

For each Member State (in parallel)

Generate MS

statistics

MS Statistics

document

Timer event

Generate global

TCN statistics

Figure 12 – “Statistics management” process

Process

description

As shown in Figure 12, two different processes have been identified:

Process Description

Generate CIA statistics This process aims at generating usage statistics report

(#requests, #responses, processing meantime,...) for

each CIA user (only with its related data) defined in

TACHOnet and to make this report available (for

browsing via a secure Web interface) to the

corresponding CIA Administrator.

Generate global TCN

statistics

This process aims at generating some statistics info

(usage per CIA, peak time, performance, failure rate,...)

for TACHOnet internal purposes (for browsing via a

secure Web interface), i.e. not aimed at being

distributed to Member States

Continued on next page

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 72

Statistics management, Continued

Identified

TACHOnet

service(s)

This process clearly identifies several services that should be supplied by the

TACHOnet network:

# Services/Functions

1 Generate a statistics report for each Member State CIA on a weekly, monthly

and yearly basis and make this report available (for browsing via a secure

Web interface) to each corresponding CIA Administrator.

2 Generate global TACHOnet statistics info (for browsing via a secure Web

interface) for TACHOnet internal purposes on a weekly, monthly and yearly

basis

These identified services (along as requests, responses and receipts data structures)

will be described in more details when translated into use cases in the Use-Case

Model. Technical issues such as data encoding, name encoding rules, security,

network,... will be analysed in details in [4].

Pending

questions

Different questions come to mind when analysing the process and its interactions

with TACHOnet. Most of these questions should be addressed by CIWG TF2 [8].

Id Question Addressed to

1 What are the other types of statistics that should be

generated (if any)?

CIWG TF2

2 How long should TACHOnet keep track of statistics

info?

CIWG TF2

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 73

Logging & Monitoring management

Introduction

This process deals with the management of different loggings around TACHOnet

activities. Logging information is of major importance to keep track of the different

transactions carried out by TACHOnet and to be able to generate statistics about

these transactions. This process deals also with the constant monitoring of the

system.

Process

diagram

This process group can be modelled as follows:

Logging/Monitoring Management

TACHOnet (TCN)

MS response

MS Request

Log the message

Check transact-

ion request

Transaction

info

Log & validate

the request

Process the

Check transact-

ion request

Monitor the

system

Figure 13 – “Logging management” process

Process

description

As shown in Figure 13, different processes have been identified:

Process Description

Log the message This process aims at logging each sent/received

message.

Monitor the system This process aims at monitoring the TACHOnet

system.

Continued on next page

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 74

Logging & Monitoring management, Continued

Process description (continued)

Process Description

Process the “Check

transaction” request

The “check transaction” request aims at checking

(against the tracking database) whether a transaction

has effectively been carried out by TACHOnet (when

and with which result). This request is useful to provide

evidence of the (non) execution of a transaction in case

of disputation or impeachment.

The “Check transaction” request will be handled

manually through a procedure defined and approved by

a kind of TCN User Group (or Management Board), as

already explained in the frame of Users & access rights

management.

Pending

questions

Different questions come to mind when analysing the process and its interactions

with TACHOnet. Most of these questions should be addressed by CIWG TF1 [8].

Id Question Addressed to

1 Is the full logging of every message still needful (non-

repudiation is no longer a requirement)? Anyway, some

logging are still foreseen for monitoring and statistics

purposes.

CIWG TF2

2 If so, what are the procedures to put in place in order to

provide someone with detailed info about logging

activities?

CIWG TF2

3 What is the procedure to handle the “Check transaction”

request?

CIWG TF2

4 How long should TACHOnet keep track of the

transactions?

CIWG TF2

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 75

Chapter 4: Business Object Model

Overview

Introduction

The business object model aims at understanding the customer’s language that is

associated with his business. This model reflects the particular part of the user

domain which is relevant for the project.

Contents

This chapter contains the following topics.

Topic See Page

Class Diagrams 76

Classes 82

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 76

Section 4.1 - Class Diagrams

Overview

Introduction

This section lists all the class diagrams together with a textual description for each

one of them stating their goal.

Contents

This section contains the following topics.

Topic See Page

Local Business Object Model 77

Tachograph cards 79

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 77

Local Business Object Model

Introduction

The Local Business Object Model diagram gives an overview of the different entities

related to card issuing and their relationships between them. A more detailed

description is given for each entity (class) in the Classes section.

Diagram

The different entities related to card issuing can be modelled as follows:

Member State

Card Issuer

Card Issuing Authority

Tachograph Card [Tachograph cards]

{abstract}

Card Type

Driver

Driver Card [Tachograph cards]

Company Card [Tachograph cards]

Control Card [Tachograph cards]

Workshop Card [Tachograph cards]

Control Authority

Workshop

Vehicles Owner Company

TACHOnet Services

Enforcement Authority

Trusted third party

TACHOnet Administrator

Card Issuing Administrator

TCN Card Issuing Services TCN System Services

1..*

works for

1..* 1..*

uses services

Card Issuing Authority Services

1..*

manages

1 1

may hold

1 *

may hold

1 *

may hold

1 *

may hold

has normal

residence

is registered

1..*

hosts & manages

1..*

works for

might use

1..*

uses

1..*

works for

1..*

uses

Figure 14 – Local Business Object Model

Continued on next page

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 78

Local Business Object Model, Continued

Description

TACHOnet Services represents the services that, for instance, Card Issuing Services

will use to check card issuing information between Member States. TCN Card

Issuing Services represents the administrative tasks as described on page 24. TCN

System Services represents the system tasks as described on page 64.

Trusted Third Party stands for a company or organisation that will act as the

trusted “manager” of the TACHOnet services in terms of hosting, configuration,

administration,... .

TACHOnet Administrator represents someone working for the trusted third party

and in charge of administering the TACHOnet services.

Card Issuing Services represents the services that a Card Issuing Authority

provides to a Member State. A Card Issuing Authority may provide its services to

several Member States. A Member State may use the services provided by one or

several Card Issuing Authorities.

Card Issuing Authority represents an authority that’s authorized to issue and

manage tachograph cards (see Tachograph cards on page 79 for more details about

types of cards).

Card Issuer represents someone working for a Card Issuing Authority and in charge

of performing administrative tasks related to card issuing (TCN Card Issuing

Services).

Card Issuing Administrator represents someone working for a Card Issuing

Authority and in charge of performing system tasks related to TACHOnet (TCN

System Services)

Member State represents a Member State that shall take the necessary measures to

ensure they are able to issue driver cards. To do so, a Member State uses the services

provided by a Card Issuing Authority.

Enforcement Authority stands for one or several authorities (like police authority)

that might use some of the TCN Card Issuing Services (under the responsibility of

the Member State to which the Enforcement Authority belongs).

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 79

Tachograph cards

Introduction

This map aims at defining what are tachograph cards.

Diagram

The different types of tachograph cards can be modelled as follows:

Tachograph cards

Tachograph Card

{abstract}

CardNumber

ExpiryDate

IssuingAuthorityName

IssuingMemberStateName

IssuingMemberStateSign

NationalNumber

StartOfValidityDate

Card Type

Driver Card

DriverAddress

DriverBirthDate

DriverBirthPlace

DriverFirstName

DriverPicture

DriverSignature

DriverSurname

DrivingLicenseDuplicataNumber

DrivingLicenseNumber

Control Card

CardHolderSignature

ControlBodyAddress

ControlBodyName

ControllerFirstName

ControllerPicture

ControllerSurname

Workshop Card

CardHolderFirstName

CardHolderSignature

CardHolderSurname

WorkshopAddress

WorkshopName

Company Card

CardHolderFirstName

CardHolderSignature

CardHolderSurname

CompanyAddress

CompanyName

Driver Control Authority

Vehicles Owner Company

Workshop

may hold

Figure 15 – Tachograph cards

Tachograph

card

A tachograph card is a smart card intended for use with a recording equipment (total

equipment intended for installation in road vehicles to show, record and store

automatically or semi-automatically details of the movement of such vehicles and of

certain work periods of their drivers). Tachograph cards allow for identification by

the recording equipment of the identity (or identity group) of the cardholder and

allow for data transfer and storage. Tachograph cards are of 4 different types which

definition is given below.

Driver card

The driver card is a tachograph card issued by the authorities of a Member State to a

particular driver. The driver card identifies the driver and allows for storage of driver

activity data.

A driver may hold one and only one driver card.

Continued on next page

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 80

Tachograph cards, Continued

Company

card

The Company card is a tachograph card issued by the authorities of a Member State

to the owner or holder of vehicles fitted with recording equipment.

The Company card identifies the company and allows for displaying, downloading

and printing of the data stored in the recording equipment which has been locked by

this company.

A Vehicles Owner Company may hold several company cards.

Control card

The Control card is a tachograph card issued by the authorities of a Member State to

a national competent control authority.

The Control card identifies the control body and possibly the control officer and

allows for getting access to the data stored in the data memory or in the driver cards

for reading, printing and/or downloading.

A Control Authority may hold several Control cards.

Workshop

card

The Workshop card is a tachograph card issued by the authorities of a Member State

to a recording equipment manufacturer, a fitter, a vehicle manufacturer or workshop,

approved by that Member State.

The Workshop card identifies the cardholder and allows for testing, calibration

and/or downloading of the recoding equipment

A Workshop company may hold several Workshop cards.

Pending

questions

The following questions come to mind:

Id Question Addressed to

1 Is the tachograph cards model (Figure 15) still valid?

CIWG

Continued on next page

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 81

Tachograph cards, Continued

Community

Model

Tachograph

cards

Visual representation of the different types of tachograph cards is given below:

TARJETA DEL CONDUCTOR

FØRERKORT

FAHRERKARTE

ΚΑΡΤΑ Ο ∆ Η Γ ΟΨ

DRIVER CARD

CARTE DE CONDUCTEUR

CÁRTA TIOMÁNAÍ

CARTA DEL CONDUCENTE

BESTUURDERSKAART

CARTÃO DE CONDUTOR

KULJETTAJAKORTTILLA

FÖRARKORT

NAME OF AUTHORITY AND ADDRESS

DRIVER CARD MEMBER STATE

4a. 4b.

4c.

(4d.)

5a.

5b.

(8.)

Please return to:

1. Surname 2. First name(s)3. Birth date

4a. Date of start of validity of card

4b. Administrative expiry date of card

4c. Issuing authority

(4d.) No for national administrative purposes

5a. Driving license number 5b. Card number

6. Photograph

7. Signature (8.) Address

COMMUNITY MODEL TACHOGRAPH CARDS

FRONT REVERSE

TARJETA DE CONTROL

KONTROLKORT

KONTROLLKARTE

ΚΑΡΤΑ ΕΛΕΓΧΟΥ

CONTROL CARD

CARTE DE CONTROLEUR

CÁRTA STIÚRTHA

CARTA DI CONTROLLO

CONTROLEKAART

CARTÃO DE CONTROLO

VALVONTAKORTTILLA

KONTROLLKORT

(6.)

NAME OF AUTHORITY AND ADDRESS

CONTROL CARD MEMBER STATE

(2.)

(3.)

4a. (4b.)

4c.

(4d.)

5b.

(7.)

Please return to:

1. Control Body (2.) Surname (3.) First name(s)

4a. Date of start of validity of card

(4b.) Administrative expiry date of card

4c. Issuing authority

(4d.) No for national administrative purposes

5b. Card number

(6.) Photograph

(7.) Signature 8. Address

TARJETA DEL CENTRO DE ENSAYO

VÆRKSTEDSKORT

WERKSTATTKARTE

ΚΑΡΤΑ ΚΕΝΤΡΟΥ ∆ΟΚΙΜΩΝ

WORKSHOP CARD

CARTE D'ATELIER

CÁRTA CEARDLAINNE

CARTA DEL CENTRO DI PROVA

CONTROLESTATIONKAART

CARTÃO DO CENTRO DE ENSAIO

TESTAUSASEMAKORTTILLA

VERKSTADSKORT

NAME OF AUTHORITY AND ADDRESS

WORKSHOP CARD MEMBER STATE

(2.)

(3.)

4a. 4b.

4c.

(4d.)

5b.

(7.)

Please return to:

1. Workshop Name (2.) Surname (3.) First name(s)

4a. Date of start of validity of card

4b. Administrative expiry date of card

4c. Issuing authority

(4d.) No for national administrative purposes

5b. Card number

(7.) Signature 8. Address

TARJETA DE LA EMPRESA

VIRKSOMHEDSKORT

UNTERNEHMENSKARTE

ΚΑΡΤΑ ΕΠΙΧΕΙΡΗΣΗΣ

COMPANY CARD

CARTE D'ENTREPRISE

CÁRTA COMHLACHTA

CARTA DELL'AZIENDA

BEDRIJFSKAART

CARTÃO DE EMPRESA

YRITYSKORTTILLA

FÖRETAGSKORT

NAME OF AUTHORITY AND ADDRESS

COMPANY CARD MEMBER STATE

(2.)

(3.)

4a. 4b.

4c.

(4d.)

5b.

(7.)

Please return to:

1. Company Name (2.) Surname (3.) First name(s)

4a. Date of start of validity of card

4b. Administrative expiry date of card

4c. Issuing authority

(4d.) No for national administrative purposes

5b. Card number

(7.) Signature 8. Address

A ABB

Figure 16 – Community Model Tachograph cards

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 82

Section 4.2 - Classes

Overview

Introduction

This section lists all classes of the Business Object Model by name. A textual

description is provided for each class.

Contents

This section contains the following topics.

Topic See Page

Class <Tachograph card> 83

Class <Driver card> 85

Class <Company card> 86

Class <Control card> 87

Class <Workshop card> 88

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 83

Class <Tachograph card>

Description

This abstract class models the tachograph card and all the information available on

that card (mandatory or optional).

A tachograph card is a smart card intended for use with a recording equipment (total

equipment intended for installation in road vehicles to show, record and store

automatically or semi-automatically details of the movement of such vehicles and of

certain work periods of their drivers). Tachograph cards allow for identification by

the recording equipment of the identity (or identity group) of the cardholder and

allow for data transfer and storage.

There are 4 different types of tachograph cards:

• driver card,

• control card,

• workshop card,

• company card.

Association

statements

Each Tachograph Card:

• manages Is related to only one Card Issuing Authority.

Continued on next page

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 84

Class <Tachograph card>, Continued

Properties

The Tachograph card exposes the following properties:

Property Description

CardNumber The card number is a 16 alpha-numerical character

that uniquely identifies a tachograph card within the

Member State issuing it). A card is therefore

uniquely identified by the code of the issuing

Member State and the card number.

The 14th alpha-numerical character of a card

number (the card consecutive index) is used to

differentiate the different cards issued to a company,

a workshop or a control body entitled to be issued

several tachograph cards. The company, workshop

or control body is uniquely identified by the 13 first

characters of the card number. Its original value

(first card issuing) shall be 0.

The 15th alpha-numerical character of a card

number (the card replacement index) is incremented

by 1 each time a tachograph card is replaced (in the

order 0,...,9, A,...,Z). Its original value (first card

issuing) shall be 0. In case of renewal, its value shall

be reset to 0.

The 16th alpha-numerical character of a card

number (the card renewal index) is incremented by 1

each time a tachograph card is renewed (in the order

0,...,9, A,...,Z). Its original value (first card issuing)

shall be 0.

ExpiryDate Administrative expiry date of card in dd/mm/yyyy

or dd.mm.yyyy format.

IssuingAuthorityName Name of the issuing authority.

IssuingMemberStateName The name of the Member State issuing the card

(optional)

IssuingMemberStateSign The distinguishing sign of the Member State issuing

the card (B, K, D, GR, E, F, IRL, I, L, NL, A, P,

FIN, S, UK).

This is MANDATORY.

NationalNumber National card number for administrative purposes

(optional).

StartOfValidityDate Date of start of validity of card in dd/mm/yyyy or

dd.mm.yyyy format.

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 85

Class <Driver card>

Description

This class models the driver card which is a tachograph card issued by the authorities

of a Member State to a particular driver.

The driver card identifies the driver and allows for storage of driver activity data.

The driver card is white

Association

statements

Each Driver Card:

• Inherits from Tachograph Card

• may hold Is related to only one Driver.

Properties

The Driver card exposes the following properties (beside the ones exposed by his

parent class):

Property Description

DriverAddress Normal place of residence or postal address

of the card holder (optional)

DriverBirthDate Birth date of the driver in dd/mm/yyyy or

dd.mm.yyyy format

DriverBirthPlace Place of birth of the driver

DriverFirstName First name(s) of the driver

DriverPicture Photograh of the driver

DriverSignature Signature of the driver

DriverSurname Surname of the driver

DrivingLicenseDuplicataNumber Driving license duplicata number at the date

of issue of the driver card (if any)

DrivingLicenseNumber Driving license number at the date of issue

of the driver card

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 86

Class <Company card>

Description

This class models the Company card which is a tachograph card issued by the

authorities of a Member State to the owner or holder of vehicles fitted with recording

equipment.

The Company card identifies the company and allows for displaying, downloading

and printing of the data stored in the recording equipment which has been locked by

this company.

The Company card is yellow.

Association

statements

Each Company Card:

• Inherits from Tachograph Card

• may hold Is related to only one Vehicles Owner Company.

Properties

The Company card exposes the following properties (beside the ones exposed by his

parent class):

Property Description

CardHolderFirstName First name(s) of the card holder (if applicable)

CardHolderSignature Signature of the holder (optional)

CardHolderSurname Card holder surname (if applicable)

CompanyAddress Postal address of the company

CompanyName Company name

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 87

Class <Control card>

Description

This class models the Control card which is a tachograph card issued by the

authorities of a Member State to a national competent control authority.

The Control card identifies the control body and possibly the control officer and

allows for getting access to the data stored in the data memory or in the driver cards

for reading, printing and/or downloading.

The Company card is blue.

Association

statements

Each Control Card:

• Inherits from Tachograph Card

• may hold Is related to only one Control Authority.

Properties

The Control card exposes the following properties (beside the ones exposed by his

parent class):

Property Description

CardHolderSignature Signature of the holder (optional)

ControlBodyAddress Postal address of control body

ControlBodyName Control body name

ControllerFirstName First name(s) of the controller (if applicable)

ControllerPicture Photograph of the controller (if applicable)

ControllerSurname Surname of the controller (if applicable)

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 88

Class <Workshop card>

Description

This class models the Workshop card which is a tachograph card issued by the

authorities of a Member State to a recording equipment manufacturer, a fitter, a

vehicle manufacturer or workshop, approved by that Member State.

The Workshop card identifies the cardholder and allows for testing, calibration

and/or downloading of the recoding equipment.

The Workshop card is red

Association

statements

Each Workshop Card:

• Inherits from Tachograph Card

• may hold Is related to only one Workshop.

Properties

The Workshop card exposes the following properties (beside the ones exposed by his

parent class):

Property Description

CardHolderFirstName First name(s) of the card holder (if applicable)

CardHolderSignature Signature of the holder (optional)

CardHolderSurname Card holder surname (if applicable)

WorkshopAddress Postal address of the workshop

WorkshopName Workshop name

TACHOnet - DG TREN

Global Business Analysis – Version 01_30

31.01.2006 - Page 89

Chapter 5: Use-Case Model

Overview

Introduction

This chapter describes the use-case model comprehensively, in terms of how the

model is structured into packages and what use cases and actors are in the model.

The proposed use case model only deals with the TACHOnet system and does not

include use cases related to the Card Issuing Authority processes (beyond the scope

of this study).