EUROPEAN COMMISSION - Cassandra deliverables... · Cassandra Common assessment and analysis of risk in global supply chains Deliverable No. D3.4 – Cassandra Deliverable Title Cassandra

EUROPEAN COMMISSION

SEVENTH FRAMEWORK PROGRAMME

THEME Monitoring and tracking of shipping containers SECURITY

FP7-SEC-2010-3.2-1 GA No. 261795

Cassandra

Common assessment and analysis of risk in global supply chains

Deliverable No. D3.4 – Cassandra

Deliverable Title Cassandra – D3.4 - Report – Single

Window Specification

Dissemination level Public

Written By Task 360 Team 15-05-2013

Checked by ATOS Origin 28-05-2013

Approved by Mrs Heather Griffioen-Young / TNO 03-07-2013

Issue date 30 July 2013

30-07-2013-Cassandra D3.4 – CASSANDRA - Single Window Specification [Public]

Page | 2

Executive summary

The main objective of the CASSANDRA project is the improvement of visibility for both businesses and government in international trade, through tracking and monitoring of the containerized cargos. To achieve this goal, CASSANDRA proposes the integration of information systems from the supply chain traders’ and government authorities’ in order to allow the flow of supply chain data among them. Therefore, the CASSANDRA project investigates the feasibility of this integration in order to propose a single connection between businesses’ IT systems and the existing government portals which can serve various government purposes at the same time. The goal of this approach is to improve the risk assessment procedures by allowing government authorities to capture supply chain data from the source directly.

To this extent, current deliverable presents the CASSANDRA approach towards an International Trade Single Window, also called the CASSANDRA Global Virtual Pipeline, which will serve as the virtual platform allowing international trade data capture from government authorities (National Single Windows) in order to elaborate risk intelligence at both national and international levels. The CASSANDRA Global Virtual Pipeline fosters some aspects of the Single Window as proposed by various standardization bodies and enhances the concept with the “piggybacking” principle and the seamless integrated data pipeline concept. The piggybacking enables authorized parties to piggy back directly on traders’ (upstream) data, while the seamless integrated data pipeline provides the underlying platform that enables integration of the IT systems. Thus, CASSANDRA views data pipeline as an extension of the Single Window providing the proper mechanism to enable government authorities to pull supply chain data from the business systems (data sources) in order to organize and perform their control and inspection procedures.

This deliverable focuses on the specification of the CASSANDRA Global Virtual Pipeline and the CASSANDRA Single Pipeline Access Point (SPAP), and presents the specification issues and design principles that should underpin such an approach. The CASSANDRA Single Pipeline Access Point (SPAP) allows government authorities to have access to the virtual data pipeline formed by the data from the CASSANDRA Hubs. The approach depends heavily on the various aspects of the integration issues such as data integration, process integration and so on. The proposed solution takes into consideration and built on top of international standards and specification guidelines as proposed by the international standardization committees. Currently, this deliverable takes into account the data capture interface which allows government authorities can pull (retrieve) data from the traders’ systems.


Page | 3

Document History

Deliverable Title: WP Deliverable number:

Single Window Specification WP3 T360 D3.4

Lead Beneficiary INTRASOFT International

Authors Org

INTRASOFT International

Contributing Authors Org

DCA

HMRC

PORTIC

TUD

GMV

Portbase

Portic

Doc. History Version Comments Date Authorised by

v0.1 Release for discussion with WP300 leader and Partners

2013/03/21

v0.2 Updated version 2013/05/28

V0.3 Updated versionn 2013/07/03

Classification PU

Number of pages: 88


Page | 4

Index

Executive summary ................................................................................................................................. 2

Document History .................................................................................................................................... 3

Index ........................................................................................................................................................ 4

List of Figures .......................................................................................................................................... 6

Acronyms ................................................................................................................................................. 8

1 Introduction .................................................................................................................................... 10

1.1 Scope of the Deliverable ....................................................................................................... 11

1.2 Structure of the Deliverable ................................................................................................... 11

2 Single Window Concept ................................................................................................................ 13

2.1 Definitions of Single Window ................................................................................................. 13

2.2 A Detailed View of the Single Window Features ................................................................... 14

2.2.1 Single Window Models .................................................................................................. 17

2.2.2 Single Window Evolution Plan ....................................................................................... 19

2.2.3 Benefits of Single Window ............................................................................................. 22

2.3 Single window Implementation Frameworks ......................................................................... 23

2.3.1 SWIF .............................................................................................................................. 23

2.3.2 ITAIDE – Information Technology for Adoption and Intelligent Design for e-Government 27

2.4 Single window Implementations ............................................................................................ 28

2.4.1 United States ................................................................................................................. 29

2.4.2 Sweden .......................................................................................................................... 30

2.4.3 Finland ........................................................................................................................... 31

2.4.4 Germany ........................................................................................................................ 32

2.4.5 Guatemala ..................................................................................................................... 33

2.4.6 Hong Kong ..................................................................................................................... 34

2.4.7 Senegal .......................................................................................................................... 37

2.4.8 Singapore ...................................................................................................................... 38

2.4.9 Malaysia ......................................................................................................................... 39

2.4.10 Mauritius ........................................................................................................................ 40

2.4.11 ASEAN Single Window .................................................................................................. 40

2.4.12 Netherlands ................................................................................................................... 42

3 Relationship of Data Pipeline concept with the Single Window Concept for International Supply Chain ..................................................................................................................................................... 43

3.1 Brief description of Current (AS-IS) Situation ........................................................................ 43

3.2 Seamless Integrated Data Pipeline ....................................................................................... 45

4 CASSANDRA Global Virtual Pipeline and SPAP Specification .................................................... 49

4.1 Purpose ................................................................................................................................. 49

4.2 Conceptual View of CASSANDRA Proposed Solutions ........................................................ 49

4.3 CASSANDRA Backbone ....................................................................................................... 52

4.4 Proposed CASSANDRA Global Virtual Pipeline and CASSANDRA SPAP .......................... 52


Page | 5

4.4.1 CASSANDRA Hubs ....................................................................................................... 53

4.4.2 Business Process Analysis ............................................................................................ 56

4.4.3 Data Interoperability Standards and Specifications....................................................... 59

4.4.4 Service-Oriented Architecture (SOA) ............................................................................ 68

4.4.5 Security Aspects ............................................................................................................ 68

4.5 Benefits of CASSANDRA Global Virtual Pipeline.................................................................. 69

4.5.1 Benefits for Businesses ................................................................................................. 69

4.5.2 Benefits for Government Authorities.............................................................................. 70

5 CASSANDRA Global Virtual Pipeline Architecture ....................................................................... 72

5.1 CASSANDRA Pipeline Configuration .................................................................................... 72

5.1.1 CASSANDRA Interfaces ............................................................................................... 74

5.1.2 Single Pipeline Access Point (SPAP) ............................................................................ 74

5.1.3 Service Process Engine ................................................................................................ 74

5.1.4 Security Services ........................................................................................................... 75

5.1.5 User Management ......................................................................................................... 75

5.1.6 Data Services ................................................................................................................ 75

5.1.7 Service Manager and Service Registry ......................................................................... 75

5.1.8 Monitoring & Logging ..................................................................................................... 76

5.1.9 Profile Management ...................................................................................................... 76

5.1.10 CASSANDRA Adapter and CASSANDRA External Adapter ........................................ 76

5.1.11 CASSANDRA Hubs ....................................................................................................... 76

5.2 Example of Data Capture Business Process Specification ................................................... 76

6 Points of concern ........................................................................................................................... 80

6.1 Legal Issues........................................................................................................................... 80

6.2 Other concerns ...................................................................................................................... 81

7 Conclusions and Future Considerations ....................................................................................... 83

8 References .................................................................................................................................... 84

9 Disclaimer and acknowledgement ................................................................................................. 88

9.1 Disclaimer .............................................................................................................................. 88

9.2 Confidentiality ........................................................................................................................ 88

9.3 Acknowledgement ................................................................................................................. 88


Page | 6

List of Figures

Figure 2-1: Single Authority Model [1] ................................................................................................... 17

Figure 2-2: Single Automated System [1] .............................................................................................. 18

Figure 2-3: Single Automated System (Interfaced) [1] .......................................................................... 18

Figure 2-4: Automated Information Transaction System [1] .................................................................. 18

Figure 2-5: Single Window Evolution Plans .......................................................................................... 19

Figure 2-6: Ten Critical Components for Single Window Development [18, p. 22] ............................... 24

Figure 2-7: Phases and Steps of Business Process Analysis Guide to Simplify Trade Procedures (visualization of steps defined in [24]) ................................................................................................... 25

Figure 2-8: ITAIDE I3 Framework [28] .................................................................................................. 28

Figure 2-9 - The ITDS ............................................................................................................................ 30

Figure 2-10 – The Swedish Single Window .......................................................................................... 31

Figure 2-11 – The Guatemalan Single Window .................................................................................... 34

Figure 2-12 – Hong Kong’s Single Window Operational Model ............................................................ 36

Figure 2-13 – ASEAN Single Window ................................................................................................... 41

Figure 3-1: Value web of roles for sea transport (Source: CASSANDRA, Integration architecture) ..... 43

Figure 3-2: Current Customs and International Trade Systems [34]..................................................... 44

Figure 3-3 – Import Business process example .................................................................................... 45

Figure 3-4: Future Customs and International Trade Systems ............................................................ 46

Figure 3-5: Data Sharing and Data Capture in Cassandra ................................................................... 48

Figure 3-6: Interfaces of the target CASSANDRA integration architecture [37] .................................... 48

Figure 4-1 – Conceptual View of CASSANDRA Global Virtual Pipeline ............................................... 50

Figure 4-2: UN/CEFACT Supply Chain Model Recommendation 18 [50] ............................................. 56

Figure 4-3: Extended Buy-Ship-Pay Model ........................................................................................... 57

Figure 4-4: "Prepare for Export" Business Transaction [52], [53] ......................................................... 58

Figure 4-5: UNLK Hierarchical System ................................................................................................. 61

Figure 4-6: UNeDocs Data Model [59] .................................................................................................. 63

Figure 4-7: WCO Data Model Components [11] ................................................................................... 64

Figure 5-1: CASSANDRA Global Virtual Pipeline Architecture ............................................................. 73


Page | 7

Figure 5-2: Process Model of Data Capture (BPMN) ............................................................................ 78

Figure 5-3: Process Model of Hubs Communication (BPMN) ............................................................... 79


Page | 8

Acronyms

ACE Automated Commercial Environment

APEC Asian Pacific Economic Cooperation

ASEAN Association of South East Asian Nations

ASW ASEAN Single Window

B2B Business-to-Business

B2G Business-to-Government

BCS Business Community System

BPMN Business Process Modeling Notation

CBP Customs and Border Protection

ECOWAS Economic Community of West African States

ECS Export Control systems

EDI Electronic Data Interchange

EPCIS EPC Information Services

EPCSA European Port Community Systems Association

G2G Government-to-Government

GFPT Global Facilitation Partnership for Transport and Trade

ICAO International Civil Aviation Organization

ICC International Chamber of Commerce

ICS Import Control System

IMO International Maritime Organization

ITAIDE Information Technology for Adoption and Intelligent Design for e-Government

ITDS International Trade Data System

KPI Key Performance Indicator

LL Living Lab

NSW National Single Window

OGA Other Government Agency

PCS Port Control System


Page | 9

SLA Service Level Agreement

SOA Service Oriented Architecture

SPAP Single Pipeline Access Point

SW Single Window

SWIF Single Window Implementation Framework

UML Unified Modeling Language

UN/CEFACT United Nations Centre for Trade Facilitation and Electronic Business

UNECE United Nations Economic Commission of Europe

UNCITRAL United Nations Commission on International Trade Law

UNCTAD United Nations Conference on Trade and Development

WCO World Customs Organization

WTO World Trade Organization

XSD XML Schema


Page | 10

1 Introduction

Supply chain visibility has always been a key objective for both businesses and government agencies. From the business perspective, the goal of visibility is to make data available to all stakeholders including the end customers and also turning that data into intelligence to be used for better business decision-making. Businesses views supply chain visibility as the mean towards improving their performance, reducing costs, which will eventually lead to higher business growth, and higher profits. From the government perspective, the goal is to improve agencies’ procedures concerning control and supervision at cross-border flows. In order to achieve this, government authorities, and particularly Customs, need to know exactly what the content of a container is, and even examine it (as Agricultural inspection, Veterinary inspection, Controllers of drugs & pharmaceuticals) in case the container had to cross the borders. Thus, government agencies can use tracking information from the supply chain to their supervision tasks. As the trading environment is highly versatile, government agencies/authorities have to adapt their operations to these changes and deal with new security challenges which can be managed with better, more accurate and real time data stemming directly from the supply chain.

A great number of government authorities are involved in the international trade and most of them still operate with paper-based declarations and additional documents. So, traders are obliged to prepare and submit an enormous set of documents in which most of the time the data required may be duplicate or ambiguous or traders may need to visit the agencies to submit the appropriate declarations. Even if the government authorities have invested into an IT system, the problem still remains as the data models supported by these systems are different. Thus, reusability of electronic forms and in general, automation and alignment of the IT systems and their business processes, cannot be easily achieved. So, paper-based procedures eliminate the change for achieving efficient share of information whenever it is required.

The CASSANDRA project addresses the need for supply chain visibility in the scope of integrating the visibility requirements of business and government. To this extent, CASSANDRA focuses on the integration of information systems in the global supply chain. This integration will enable the gathering and aggregation of existing information from the IT systems operated by the stakeholders into meaningful data units that can facilitate the risk analysis processes carried out by both government authorities and businesses. The goal is to achieve secure international trade (improve container security) through monitoring and tracking, and to enable government authorities to retrieve data directly from the business traders in the supply chain. The approach proposed in CASSANDRA aims at improving risk management and assessment procedures by provided those with accurate (upstream) data directly from the supply chain and so supervision agencies will focus only to high risk containers/cargos.

The purpose of this deliverable in the context of overall vision of the CASSANDRA project is to supplement the Single Window concept through the seamless transfer of international trade data in order to improve the risk assessment procedures both at a national as well as at the international level. The Single Window concept was introduced by UN/CEFACT as a mean to provide a single point of access and submission to all stakeholders [1]. In the context of the CASSANDRA project, the Single Window concept is supplemented with the data pipeline concept in order to enable a global data pipeline for global supply (value) chains. It is also enhanced with the “piggybacking” principle in order to elaborate the data-pull principle where data can be pulled from the IT systems and not pushed. In CASSANDRA context, the government authorities and National Single Windows via a single point would be able to access and pull available data from the data pipeline in the context of single window operational needs. Based on the above, the CASSANDRA Global Virtual Pipeline and the CASSANDRA Single Pipeline Access Point (SPAP) are proposed. The CASSANDRA Global Virtual Pipeline is the virtual pipeline where data sources are integrated in order to be queried with data, while the CASSANDRA Single Pipeline Access Point (SPAP) serves as a single entry point to the CASSANDRA pipeline and it can be used by the government authorities to retrieve upstream data from the data sources (CASSANDRA Hubs) through CASSANDRA pipeline.

The proposed approach focuses on providing on time data with a high degree of accuracy into the risk assessment procedures by developing a data capturing concept that offers data with higher quality. To achieve this, government authorities’ could extract meaningful data from the data sources. The overall


Page | 11

goal of the proposed solution is to improve supply chain visibility, efficiency of trade compliance and effectiveness of border control and supervision.

1.1 Scope of the Deliverable

This deliverable is part of the Work package 300 (Task 360) and it aims at investigating and proposing a solution for integrating governmental agencies with companies’ platforms and their dashboards in order to allow visibility of data. To this extent, the CASSANDRA introduces the CASSANDRA Single Pipeline Access Point which serves as a single access point to the data pipeline (hereafter mentioned as “SPAP” as an abbreviation) and forms the technological basis of the aforementioned problem. The CASSANDRA SPAP enables various National Single Windows (NSW) and government authorities/agencies to consult supply chain data for piggy-backing purposes. This deliverable supplements the Single Window concept with the principles of piggy-banking and data-pull mechanisms enabled by the data pipeline.

The purpose of this deliverable is to define the SPAP in the context of CASSNDRA project and the CASSANDRA Global Virtual Pipeline. The proposed concept extends the traditional Single Window implementations. It is based on the data pipeline concept and the integration of various National Single Windows with this pipeline. Thus, this deliverable introduces the SPAP concept by identifying its key features, its context, the stakeholders and various implementation and evolutionary models.

The work in this deliverable contributes mainly to the second and third objective of the CASSANDRA project by proposing the solution towards achieving system integration between all interested partners in a supply chain. In brief, the second research objective focuses on the system integration for risk assessment purposes between all businesses in a supply chain, while the third objective focuses on data integration among supply chain partners and government authorities through adoption of new information architectures such as the principles of SOA.

1.2 Structure of the Deliverable

This report is a deliverable of WP3 (Task 360) and its goal is to specify the CASSANDRA Single Pipeline Access Point in the context of CASSANDRA project. The deliverable is organized as follows:

Chapter 1 provides a generic introduction as well as some information about the scope of this deliverable in terms of the CASSANDRA Global Virtual Pipeline goals.

Chapter 2 describes the Single Window concept by providing some background information such as implementation guidelines and frameworks, as well as by providing information for existing Single Window implementations following literature review. The aim of this chapter is to introduce the concept of Single Window by presenting the various definitions as proposed by several standardization bodies (or committees) in order to identify the business and technical requirements pinpoint a Single Window system. Furthermore, it presents the evolution of the Single Window systems across the globe and the requirements that the CASSANDRA Global Virtual Pipeline must offer in order to propose the roadmap to these systems for the next phase, which is the International Trade Single Window.

Chapter 3 describes the relationship of the data pipeline concept, which is fundamental for CASSANDRA project, with the Single Window concept for International Supply chain. Initially, the chapter covers the “”AS-IS” situation of the international supply chain, including regulation and government authorities, in order to present to the reader the complexity of business processes as well as the demands for the submission of a large volume of data through the submission of documents. This chapter describes the proposed solution of the CASSANDRA project towards an International Trade Single Window, which can be achieved through the CASSANDRA Global Virtual Pipeline. The latter elaborates the concept of the data pipeline with the “piggy-back” and the “data-pull” principles.


Page | 12

Chapter 4 defines the conceptual view of the CASSANDRA Global Virtual Pipeline for International Supply Chain which is proposed in the context of CASSANDRA project. To this extent, Chapter 4 describes the network of participants that forms the CASSANDRA pipeline by describing the participants’ (CASSANDRA Hubs) in terms of their roles and their underlying systems. This chapter also discusses the integration issues constituting the integration platform which will allow the collaboration and interoperation of the integrated systems.

Chapter 5 presents the design principles of the CASSANDRA Global Virtual Pipeline and the CASSANDRA SPAP. The aim of this chapter is to present to the reader the potential services that will constitute them. These services is a minimal set that is required to enable the integration of both the supply chain partners’ IT systems as well as the National Single Windows and other government authorities’ IT systems. Furthermore, the chapter presents the Data Capture interface through a business process model that depicts the interactions among CASSANDRA Hubs and CASSANDRA services as message exchanges. The goal of this business process model is to serve as a contract across the CASSANDRA and the partners’ IT systems that wish to integrate and share information.

Chapter 6 states some point of concerns for the implementation and enforcement of the CASSANDRA Global Virtual Pipeline.

Finally, Chapter 7 concludes this deliverable by summarizing the design issues and architecture principles that will guide the next generation of such systems. It also presents some future challenges and considerations over the CASSANRA pipeline.


Page | 13

2 Single Window Concept

This chapter introduces the concept of Single Window and it presents the various definitions proposed by several standardization bodies as well as by business communities and even by funded projects. The main goal of this chapter is to familiarize the reader with the concept and provide an overview of the basic features of the Single Window in order to present the CASSANDRA Global Virtual Pipeline and the CASSANDRA SPAP which are elaborated by this deliverable.

To this extent, this Chapter presents the various definitions proposed by standardization bodies and other institutions in order to identify the key characteristics as well as the various Single Window adoption approaches in order to clarify the diversity of the Single Windows Forms (models) based on their design and implementation context. Also, it provides a brief description of the most well-known implementation frameworks that we adopt in current work and finally, we study some cases that integrate Single Window in their systems and have proven the necessity of elaborating Single Window in their systems.

2.1 Definitions of Single Window

As described in the Introductory Chapter, Single Window is a well-known term in the international trade with the aim to control the movement of goods across national borders and means of transport. Considerable efforts have been undertaken to define and describe the concepts that pinpoint the Single Window. Most of the times, the proposed definitions supplement each other. Thus, standardization bodies (committees) and other international organizations, such as UNECE, UNCTAD, WCO, IMO, ICAO and the ICC, focus of providing support, business and technical details in order to promote interoperability between IT systems of collaborating parties within and out of the supply chain.

The most widely acknowledged definition has been provided by the UN/CEFACT through the Recommendation 33 of UN/CEFACT [1, p. 2]. The Recommendation 33 defines Single Window “as a facility that allows parties involved in trade and transport to lodge standardized information and documents with a single entry point to fulfil all import, export, and transit-related regulatory requirements .If information is electronic, then individual data elements should only be submitted once”. Through this definition, basic aspects of Single Window have been pinpointed: electronic documents, single entry point, single submission point, information exchange interactions between traders, government agencies with an emphasis on the customs procedures; import, export and transit.

Although the UN/CEFACT Recommendation 33 and the accompanied guidelines focus on the technological details of Single Window, the WCO views Single Window as a sociotechnical system. Thus, WCO, through their published Compendium, defines Single Window as [2, p. 72]: “an approach to service delivery under which, the service provider offers a bundle of related services “under one roof” to make it convenient for the consumers to access and utilize these services. By organizing the location of service outlets, information for accessing services and interactions with regulatory agencies from the user’s point of view, the Single Window approach helps to reduce the costs and effort of both the provider and the consumer leading to favourable outcomes for both parties.” The definition provided by WCO has as a foundation the definition from the UC/CEFACT as discussed above.

The WCO definition supplements the UC/CEFACT because the latter emphasizes on the IT aspects of Single Window because it views the system as the mean for submitting standardized information with a single body serves only as one of the conceptual underpinnings. An issue with this definition is that the Single Window concept may be wrongly perceived as a large scale IT application developed and managed exclusively by Government and its respective authorities. The WCO has introduced a new term for Single Window, the Single Window Environment, and clarifies over the misinterpretation problem by viewing Single Window “as a network of co-operating facilities that is bound by trust and a set of agreed interface specifications in which trade has seamless access to regulatory services delivered through electronic means” [3, p. 20]. The WCO supplements UN/CEFACT definition as it views Single Window environment as a cross-border, intelligent facility.


Page | 14

The Global Facilitation Partnership for Transport and Trade (GFPT, a World Bank partner) adopts the UN/CEFACT Recommendation 33 in order to promote the use of single window for cross-border crossings, and particularly, in road crossings [4].

The UNECE defines Single Window Environment “as a system that allows traders to lodge information with a single body to fulfil all import or export-related regulatory requirements. In practical terms, a ‘Single Window’ environment provides one entrance (either physical or electronic) for the submission and handling of all data and documents related to the release and clearance of an international transaction. This entry point is managed by one agency which informs the appropriate agencies and/or performs combined controls” [5, p. 2].

In Europe, the Taxation and Customs Union (TAXUD) forces towards a paperless (electronic) Customs environment including the concept of Single Window. To this extend, two pieces of legislation, the Electronic Customs Decision [6] (Article 4) and the Modernised Community Customs Code (MCC) [7] refer to SW. According to Recital 7 of the Modernized Customs Code, the term Single Window “refers to a single electronic entrance point at which authorised operators could submit the information required by customs and other agencies involved in frontier control, such as police, border guards, veterinary and environmental authorities”. According to the proposed Electronic Customs Decision and Article 4 (3), the Single Window will allow for the “seamless flow of data between economic operators and customs administrations, between customs authorities and the Commission, and between customs administrations and other administrations and agencies, and enabling economic operators to submit all information required for import or export clearance to customs, even if it is required bynon-customs legislation”.

The European Port Community Systems Association (EPCSA) promotes the implementation of Single Window in Europe by aligning Port Community Systems (PCS) with National Single Window (NSW) development. EPCSA refers to Single Window as a “complex community undertaking which facilitates trade” [8, p. 1]. EPCSA’s definition builds on top of the other definitions we have presented earlier but the importance of EPCSA’s work is that it enforces interactions between the ports’ stakeholders (Port Community Systems) with the National Single Window concept.

The Association of Southeast Asian Nations (ASEAN) views a Single Window as “the environment where national Single Windows operate and integrate. Functions and roles of a National Single Window are based on a single submission of data and information, of a single and synchronous processing of data and information and a single decision making for customs release and clearance. A

single decision‐making is uniformly interpreted as a single point of decision for the release of cargoes by the Customs on the basis of decision taken by line ministries and communicated timely to the Customs” [9, p. 10]. The ASEAN community succeeds in synchronizing and integrating their National Single Windows in order to secure the timely release of shipments. The focus has been the customs processes.

No matter the definition for single window, it is apparent that the Single Window concept is a crucial part of the organizations’ and authorities’ strategy towards effectiveness in trade facilitation and security. Its main goal is to facilitate trading and increase national competitiveness by replacing the current paper based trading environment to a more paperless and e-document environment.

2.2 A Detailed View of the Single Window Features

In the previous section, we presented the various definitions of the Single Window concept as proposed by several standardization, and not only, committees in order to extract the key features (characteristics) of the Single Window. In general, Single Window aims at expediting and simplifying information flows between trade and government authorities, and bring meaningful gains to all parties involved in cross-border trade. Thus, a Single Window has been described as simply a system, a concept, process or environment that enables individuals, businesses and Government organizations to submit information to, or through, a single point of access, now normally electronic. Based on the definitions, the following characteristics are presented by a Single Window.


Page | 15

Single entry

This feature implies one single point of access and it is also named as “guichet unique” or “one-stop shop”. It should not be confused with the concept of gateway as the Single Window is merely a network of co-operating facilitates. The “single entry” feature, supplemented with the “single submission” feature, denotes the fact that traders’ do not need to submit their data separately for each government agency but submission of data is only performed once. However, a Single Window system does not only offer a single point of access to various government agencies’ IT systems. But, it offers a set of shared services and exhibits an intelligence that differentiates it from data switches and from gateways [2]. Examples of shared services may include orchestration of inter-agency business processes which is exposed as a single (business-) service to users.

Single Submission

This feature implies one time submission of data and relevant information to customs and other government agencies through the single entry point. As described above, this feature implies that the traders’ submit their data only once through the single entry point. After submission, the data is available to any authorized user or to other government agencies which require them in order to perform their procedures. However, the “one-time submission” feature does not refer to a single transmission data as the data can be transmitted multiple times allowing traders to incrementally submit data [3]. Thus, single submission depends on the following principles; incremental submission of data and reusability of data. The “Incremental submission of data” submission of incremental data is required in order to reflect a change or progression in the transaction. The “reusability of data” refers to the fact that the submitted data can be reused by the other government agencies if it is required.

Paper-less environment

The ultimate goal of the Single Window concept is to move from paper-based systems to paperless environments where required information will be inserted, maintained and shared in an electronic form. The basis of a paperless system is the identification of the required documents/forms/licences is important and the data that these documents requires, and their standardization.

Standardized documents and data

Standardizing the information of the data flows is an important step in the development of the SW as it is the key point in linking the difference agencies as well as the different countries together (achieving cross-border management). Thus, many international standards have been proposed such as UN Trade Data Elements Directory (UNTDED) [10], WCO Data model (customs data requirements) [11], Core Components (UNeDocs data model for trade and transport data requirements) [12]. Thus, an important aspect of SW is the data harmonization and the enforcement of a shared master data model which is composed of harmonized and standardized data sets.

Sharing of Information (information dissemination)

Important information (e.g., customs declarations, permits and certificates) is maintained in electronic format and it is shared to the appropriate partner/agency whenever the latest requires it. In order to achieve this, not only standardization of information is required but the appropriate interfaces and message exchange should be defined in order to align the IT systems of the involved parties. However, this sharing of information is protected by a legal framework that provides privacy, confidentiality and security in the exchange of information [13].

Coordination of controls and inspections

The “coordination of controls and inspections” feature is enabled through the sharing of information as the data submitted through the Single Window can be reused for risk management and assessment processes. Coordination can been achieved as a result of the business process analysis and re-engineering based on international standards.


Page | 16

Online Reporting Capability

Single Window enables the creations and dissemination of various reports based on the submitted data eliminating the need to contact the various agencies to retrieve the necessary data. Thus, Single Window becomes the source of trade related government information.

Business Model & Lead Agency

Various business and functional models can be used for the design of a Single Window which can be applied at a regional, national or international level. A key point in the success of a Single Window system is the establishment of a strong lead agency, which can be a governmental organisation, private entry (e.g., Chamber of Commerce), or public-private partnership. This lead agency is manages the Single Window and it responsible for promoting the benefits of the Single Window system. Lead agency along with strong political support and the appropriate project-centric organisation and resources, are the elements required for a Single Window project to succeed [8]. For example, the lead agency for Korea is the Ministry of Knowledge Economy and the lead agency for Singapore is the “Trade Development Board” [14].

Payment of duties and other charges

UN/CEFACT Recommendation 33 recognizes one more feature that Single Window provides; the payment of duties, As Recommendation 33 mostly refers to a Regulatory Single Window where the central player is the Customs, payment of duties is its ultimate procedure.

Apart from the identified features, a Single Window encompasses various stakeholders. These stakeholders have been identified in [15] and they are:

Importers, exporters (consignors and consignees);

Trade professionals (freight forwarders, customs brokers and shipping agents);

Shipping companies, airlines, road, rail and inland waterways, duty free zones, dry ports and

multimodal cargo depot, and dry ports;

Ports and airports, container terminals, bulk terminals, port gate operations and local port road

and rail transport;

Customs and other government agencies: These typically include all agencies that have a

trade compliance responsibility, licensing, permit issuing and/or inspection responsibilities, tax

and bonds collection etc.

The variety of the participants in a Single Window Ecosystem denotes the various types of Single Window design and implementation as it will be described in Section 2.2.2.Neverthless, these stakeholders can be further divided into the following three (3) groups [15]:

Government and its various compliance agencies

Port, logistics and transport communities;

Traders and their trade professionals (customs brokers, freight forwards and shipping agents).

Single window is designed to benefit all these stakeholders in a different manner. Government authorities are benefited such a higher efficiency of government towards trade, more effective deployment of resources, better risk management and revenue collection. Furthermore, Single Window benefits Traders such as decrease of the time needed for movement clearance, more effective deployment of their resources and increased transparency [1].

Single window has positive impact to the other communities related to the supply chain (ports, logistic operators etc.) [15]. It offers reliable information on timing of goods movement, allowing accurate scheduling, allocation of resources and improved accuracy of information provided to clients. Moreover, it provides the ability to accurately schedule goods collection and discharge times and


Page | 17

locations. In addition, single window makes the process more stable and standardize. This characteristic allows the stakeholders and government organizations automate their processes and to better monitor their effectiveness. Except data collection, single window facilitates trading by automating document preparation and fulfilment processes, which are related to the arrival, import, export and release of the movements from ports, airports, customs and other places. This result accelerates the trading process and causes significant reduce of costs for all the participants of the supply chain. In addition single window is linked with banking systems facilitating payment process. An important part of single window is the risk management system that is used. Such systems help the authorities to scrutinize only those lodgements, which raise automatic alerts, or flags. An effective risk management system can reduce the proportion of physical inspections to a small percentage of total consignments, thus providing efficiencies, economies and time saving to traders and authorities [15].

2.2.1 Single Window Models

The UN/CEFACT Recommendation 33 presents three different models that have been followed by countries and other authorities towards establishment of a Single Window. These models differ with respect to systems integration or Single Window’s responsibility and functionality (services). These models are; the Single Authority Model, the Single Automated System and the Automated Information Transaction System.

In the Single Authority Model, a single authority serves as a single entry point and collects the data from the traders and disseminates them to all authorities that need them. The model implies both paper-based as well as electronic data for information exchange. This model is also known as “lead agency” model and typically, the single authority refers to one central government authority or agency. For example, the Swedish Single Window’s authority is the Swedish Customs, while in Finland, the lead agency is the Finish Maritime Administration and it used to be the Finish Ministry of Telecommunications.

Figure 2-1: Single Authority Model [1]

In the Single Automated System, an automated information system serves as a central processing hub which collects, integrates stores and disseminates information while coordinating a group of integrated systems. The automated system can support centralized processing of information through the integration of external systems, or can support decentralized information processing by sending the data to the responsible system, which can be achieved through well-defined interfaces to the external systems, or both. Examples of such approaches is the Germany’s DAKOSY, Singapore’s and Mauritius’ TradeNet.


Page | 18

Figure 2-2: Single Automated System [1]

Figure 2-3: Single Automated System (Interfaced) [1]

In the Automated Information Transaction System,, an automated information system serves as a transaction hub which enables integration of all authorities. The automated information system allows traders to prepare and submit their declarations and/or permits electronically to various authorities in a single application.

Figure 2-4: Automated Information Transaction System [1]


Page | 19

The UN/CEFACT Recommendation 33 focuses on the Regulatory form of a Single Window. A Regulatory Single Window enables the B2G and G2B interactions in terms of the electronic submission of declarations and other related regulatory documents and data which are required to enable the cross-border trade.

However, CASSANDRA enables Regulatory Single Windows to capture supply chain data from pipeline. This concept is presented in Chapter 3. The approach is based on aspects introduced in a paper prepared by members of the Single Window Symposium Organizing Committee in May 2006 which concluded that two major Single Window models are currently being implemented [13] [16]. The first is a regulatory convergence model, generally driven by Customs, which focuses on the harmonization of procedures, electronic messages and data for submission and sharing by Customs and other government agencies. The second model is focused more on trade logistics and tends to be driven by trade/business interests. It revolves around the process and procedures and data related to the operation of ports and similar facilities, but also involves some Customs processes. Some Single Window facilities cover both the regulatory convergence and trade logistics issues. While the dynamics of each model are quite different, the basic concept of data standardization and process simplification is the same and the same issues of data standards and interoperability emerge.

2.2.2 Single Window Evolution Plan

From the Single Window models presented previously, there is not a standard one to be followed. Furthermore, each implementation of a Single Window depends on the needs of the community that it serves. This section presents some Single Windows models which have been proposed taking into account the operators/stakeholders in contrast to the ones presented in section 2.2.1 which focus on the integration details of the systems. The distinction of these models depends on the operators/stakeholders that the SW refers to and to the conditions and requirements. These models depend on the ones presented in [17], [18] and [19].

Typically, the participants taking part in the trade defines the extent of the Single Window. Thus, several variations in the design and implementation exist. These variations are described as levels of the evolutionary plan of Single Window and they are presented in the following sub-sections [18]. This evolutionary plan is depicted in Figure 2-5.

Figure 2-5: Single Window Evolution Plans


Page | 20

2.2.2.1 Paperless Customs

The Paperless Customs e-Customs, also known as “Integrated Customs Systems”, correspond to the first level towards Single Window adoption and the term is used to refer to customs automation. These systems elaborates the paperless customs declarations concept and they allow traders to submit the declarations electronically, usually through Value Added Networks (VAN) without requiring physical visits to customs locations and any submission of paper-based documents later. These systems support the entire clearance process and their functionality is augmented with other Customs duties such as the electronic risk assessment and risk-based inspection strategies, online duty payment, electronic container loading list associated with declarations, and initial support of the information exchange between Customs and terminal operators.

The development of these systems is essential for the establishment of a Single Window in a national base. These systems contribute to trade facilitation as it allows an initial integration of stakeholders, minimize the demand for human being contact, allows for transparent and uniform processing and all together lead to faster processing.

These automated systems or EDI facilities have been developed to and operated based on the national needs and requirements. Although there was a degree of data harmonization among countries which are members of a community, such as EU and the SAD model, most of the customs’ systems have been developed in fragmented manner which lead to the adoption of a multitude of forms, data elements and electronic templates resulting in a non-uniform, non-standard usage and handling of information.

2.2.2.2 Regulatory Single Window

After the paperless Customs system, the next step is its integration with other government agencies. This integration allows information exchange between government authorities and agencies for the issuance of permits and certificates electronically. The goal is to move towards a Regulatory Single Window which will allow traders to submit their export and import data only once and then the regulatory system will transmit these to the other authorities in order to obtain the required permits and certificates.

However, most regulatory systems do not allow for this single entry point but they have been developed to serve as a national G2G e-document exchange hub with multiple electronic data entry windows for each of the application forms required by the agencies. Thus, traders still need to submit their data separately across government agencies.

So, the goal is to move to a Regulatory Single Window as a single entry point and in order to achieve this, a gradual integration of the government agencies in necessary by prioritizing them based on their involvement to the trade and the restrictions and delays that they pose.

2.2.2.3 Port Community System

A widely accepted definition of a Port Community System (PCS) has been provided by the European Port Community Systems Association (EPSCA) and it is the following [8]:

Is a neutral and open electronic platform enabling intelligent and secure exchange of information

between public and private stakeholders in order to improve the competitive position of the sea

and air ports’ communities;

Optimises, manages and automates port and logistics efficient processes through a single

submission of data and connecting transport and logistics chains.


Page | 21

In brief, a PCS is an electronic platform that integrates various organizations that belong to a specific community (a seaport or an airport community) and its goal is to facilitate the exchange of information and underlying processes within the logistic chain of all modes (air, sea, inland water, rail, road). That is why a PCS is considered as a highly integrated system and the service offerings are specific to its target group. The vision of PCS is to connect all the participants’ systems into a community system where it would be possible to track and trace cargo from arrival to departure and vice versa.

The service offerings of a PCS support its target group specifically. Thus, the stakeholders vary from private companies to public or government authorities such as shipping agencies, freight forwarders, terminal operators, customs brokers, Customs, Port Authorities (coastguard, veterinary offices).

Typically, a PCS supports export and import declarations, transhipment, consolidations, hazardous cargo, and maritime statistics reporting.

The importance of the PCS is that it serves as the backbone of a National Single Window and it must be viewed as the latter’s integral part. A PCS can serve as a bridge to other SW services such as Customs, ICS, NCST, Transit, and so on. Furthermore, as we are going to discuss in the next section, PCS introduces the B2B interactions to National Single Windows by connecting commercial and regulatory operators together.

In literature, some authors differentiate Port Community Systems from the Port Single Window (PSW)

in order to distinguish the type of interactions dominating in them. In particular, they use the term PSW

in order to refer to B2G interactions, while they use the term PCS to refer to B2B interactions [20]. The

aim of PSW is to provide local level information to authorities on a port level, while PCS enables

message exchanges of commercial and logistic nature in a port community [20].

2.2.2.4 Fully Integrated Single Window (National Single Window)

The “National Single Window” is one of the forms that come closer to the actual scope of the Single Window concept. The National Single Window has a broader context than the previous forms as its spectrum covers the business and legal entities in the supply chain/trade community including government authorities and agencies. The ultimate National Single Window would be the one that interconnects all government departments, customs, PCS (maritime, air, road, rail, inland waterway transport systems, port and terminal operators, freight forwarders, customs brokers, shipping agents), banks, insurance companies and so on.

The National Single Window is a country-(nation-) wide facility providing services to all these parties. In particular, the National Single Window serves as the single entry point allowing for a single submission of standardized information which is required to fulfil all export, import and transit-related regulatory requirements [17]. A typical usage of this form is that it provides a single decision-making for customs release and clearance.

The National Single Window mandates that all government agencies must be connected and be part of the system. For example, one of the earlier attempts of a country wide Single Window took place in Singapore where the system integrates 3 government agencies.

It is obvious that National Single Windows concerns Business-to-Government (B2G) and Government-to-Government (G2G) interactions. However, with the inclusion of PCS or with its extension of its services in order to offer Business-to-Business(B2B) services, such as commercial documents (purchases/sales orders), packaging list, advanced shipment notice, trade-financing instruments (letter of credit, bill of landings),will lead to an extended form of a National Single Window.

The establishment of a National Single Window facilitates the harmonization and standardization of information as well as the automation of the various processes for the international trade. National Single Window achieves the necessary integration of regulatory agencies and the private sector.


Page | 22

2.2.2.5 Regional Single Window

The “Regional Single Window” extends the National Single Window form as it comprises of several integrated National Single Windows enabling trading across regions. This form eliminates the need for peer-to-peer communication among countries allowing countries to integrate into a single regional portal.

Attempts to establish Regional Single Windows has been undertaken by European Union, the Asian Pacific Economic Cooperation (APEC), the Economic Community of West African States (ECOWAS), the Eurasian Economic Community(EurAsEC) [21], and the Association of South Each Asian Nations (ASEAN).

In particular, European Union focuses on optimizing trade efficiency of cross-borders within the European Union, while an example of a Regional Single Window has been elaborated, the ASEAN Single Window, which integrates 10 National Single Windows of the ASEAN member states.

On the other, APEC focuses on the implementation of an end-to-end supply chain track and trace system in order to facilitate regulators through their work of tracking dangerous codes from source to the ultimate end user. Finally, the ECOWAS concentrates its activities to track and prevent any illegal activities such as hijacking and smuggling, and in general to track anything that could lead into national revenue loss.

2.2.2.6 International (Global) Single Window

The “International (Global) Single Window” can be considered as an extended form of the Regional Single Window. The International Single Window consists of and interconnects all possible Regional Single Windows, National Single Windows, and Local Single Windows such as PCS.

The vision of an International Single Window is to support trade among nations, the international supply chain, and provide all the features of the Single Concept. This form can only be achieved if all the previous form has been implemented and the trade has moved and operates to a paperless environment through integration of all underlying systems.

An initial attempt is identified in the private sector, and the Bolero International [22] which operates a fully electronic supply chain platform allowing exchange of electronic documents between partners including government authorities and agencies. However, Bolero’s solution is not actual an International Single Window as it is not connect various forms of SWs and it is governed mainly by private sector.

2.2.3 Benefits of Single Window

The Single Window environment offers several benefits to its stakeholders. The establishment of the Single Window requires reengineering of most business processes and the business documents that concern them. Reengineering will lead to business process optimizations and in case of business documents or business objects that flow within processes across systems, the latter will be transformed in order to comply with international styles.

Regarding government authorities, Single Window offers them the possibility to require and obtain accurate data at any time. This will lead to transparency and integrity of procedures. The processes become more effective and there could be a better allocation of resources among processes and tasks. Furthermore, security can be enhanced on the basis of better risk assessment eliminating any evidence of corruption within and across agencies.


Page | 23

Moreover, Single Window can enable the creation of risk profiles for the traders. These risk profiles could then direct the control and supervision processes which will only performed on high risk profiles. Overall, Customs and other authorities will speed up and simplify the clearance procedures at the border which will eventually promote trade facilitation.

Regarding private sector businesses, Single Window offers them the possibility to reduce administrative costs by reducing required time to prepare documents and other delays. It also provides greater transparency on the government procedures and means for the efficient deployment of resources. Furthermore, customs clearance is optimized in terms of time which leads to faster release of goods. Optimization to the borders processes is feasible. Also, it will help them to be compliant not only to customs procedures but to other regulations.

In terms of the business processes, supporting the Single Window concept and integrating other systems through it, can lead to optimizations to traders’ business processes in order to comply with data models and allow for more efficient deployment of resources.

To sum up, the adoption of a Single Window environment can automate most of the data exchanges between government agencies (G2G) and between private sector and government agencies (B2G). It allows traders to fulfill all import, export and transit-related regulatory requirement through one interface. This can lead to minimization of the time and cost for export/import and improved collaboration between border agencies through coordinating them and probably will lead to joint inspections. This is achieved through the improved business processes and consequently, improved services to business through coordination of the government operations as well as through timely access to more accurate data. Furthermore, with data harmonization and re-engineering of business processes, it enforces compliance towards international legal and secure frameworks.

2.3 Single window Implementation Frameworks

The implementation of Single Windows depends on specific frameworks which provide the steps and the guidelines for implementing such a solution. This section presents two of these frameworks. These recommended frameworks provide a holistic and architecture frameworks to support policy managers and the various stakeholders for their planning and management of the SW implementations.

2.3.1 SWIF

The most acknowledged framework for developing a Single Window is the Single Window

Implementation Framework (SWIF). The SWIF provides a strategic and holistic framework and it has

been proposed as the “framework that guides policy managers in the process of initiating, setting up,

and managing the implementation of a Single Window” [23, p. 5]

The SWIF framework proposes the incremental implementation of a Single Window. The reason for

this is that not all supply chain stakeholders are at the same level to accept and operate effectively this

application. In addition, the impact of this change is not the same for every participant. Single window

implementation is not a pure IT project as it has already mentioned. It requires the redesign of

processes, which involves many non-IT issues (e.g. procedural, legal). As a result, the incremental

implementation and the assessment of the readiness of each participant to join the single window

platform are important in order to build an effective system.

SWIF adopts an enterprise architecture approach as methodological framework to handle the various

aspects of Single Window implementation. SWIF decomposes Single Window implementation

challenges into ten (10) major components [23, 18]:

1) Stakeholders’ viewpoints, needs, and requirements;

2) Motivation and stakeholder collaboration;


Page | 24

3) Visions, goals, objectives, strategies, value propositions, master plan;

4) Business process analysis and simplification;

5) Data Harmonization and e-Documents;

6) Application architecture (service functions);

7) Technical Architecture including standards and interoperability;

8) Implementation and operation governance;

9) Legal framework; and

10) IT Infrastructure and Solutions.

Figure 2-6: Ten Critical Components for Single Window Development [18, p. 22]

According to SWIF [23], the following five activity areas are key and essential for the successful

implementation of a Single Window considering that it differs from traditional information system

implementation simply due to the nature of the system:

1) stakeholder management and interagency collaboration;

2) business process analysis;

3) data analysis and harmonization;

4) interoperability;

5) Realization of the legal framework.

2.3.1.1 Stakeholder management and interagency collaboration

Since the preliminary phase of SW implementation, a political will is very important for the Single

Window implementation. A concrete plan with clearly defined goals should also be created. In

addition, this key activity area includes the identification and analysis of Single Window stakeholders,

their roles, and their engagement in the Single Window implementation. Finally, it is very important to

establish a collaborative environment among the stakeholders [23].

The purpose of SW is to treat the government as a ‘black box’ by realizing one ‘window’ to

communicate with the government. When a trader needs to communicate something to the

government it should not be bothered anymore with the question to which government agency the


Page | 25

message needs to be sent. Furthermore, messages from government agencies that can be bundled

because they are identical in nature or are of the same type should be send as one integrated

message only instead of sending related messages from different government agencies on several

points in time. The latter can be exemplified by related messages from different regulatory authorities

stating that controls are going to be performed on a container of goods that has been declared for

export. An extension to the Single Window, the Extended Single Window, aims at contributing to

integrated border management at the back-office side of government by aligning the possible

inspections from the different inspection agencies. One of the most problematic issues for companies

is the lack of coordination between the various inspections. Hence, it can happen that a container for

export is selected by various agencies for inspection, but that there is a considerable time period

between these inspections, causing significant delays in the transport of the goods.

2.3.1.2 Business process analysis

The implementation of Single Window requires changing current processes, redesigning or improving

flows and implementing new services that will cover the needs. In order to implement these changes

effectively, it is very important to perform a business process analysis and study the current processes

in detail in order to recommend improvements. In this way, a better understanding of the current

situation (AS-IS) will be gained and the recommendations and simplifications will be proposed for the

target situation (TO-BE). Furthermore, business process analysis allows all parties involved to gain a

better understanding about the documentary, procedural and operational aspects of international trade

transactions. In particular, it informs how business processes are carried out, how business processes

relate to one another, who is responsible for them, what documents, rules, and regulations are

involved, and how this information flows. Finally, possible issues and other restrictions should be

identified for consideration.

According the Guide to Business Process Analysis to Simplify Trade Procedures [24], the business

process analysis consist of the following 3 phases. Each phase consists of 2 steps and each step

defines a number of proposed activities. Figure 2-7 visualises those steps defined in [24].

Figure 2-7: Phases and Steps of Business Process Analysis Guide to Simplify Trade Procedures (visualization of steps defined in [24])

Phase 1: Scope setting

• Step 1 - Define the project scope

• Step 2 - Develop a work plan and secure resources

Phase 2: Data collection and process documentation

• Step 3 - Acquire background information

• Step 4 - Conduct interviews and document captured data

Phase 3: Process analysis and recommendations development

• Step 5 - Analyze the “as-is” processes and identify bottlenecks

• Step 6 - Develop and propose recommendations


Page | 26

In the final phase of the activity, recommendations for the business process improvement are

proposed. Those recommendations might include simplification of procedures, process automation,

etc. [24, 18].

2.3.1.3 Data harmonization

Data harmonization “is an act of reconciling the definition and representation formats of data elements in a domain of interest. It entails a set of activities that improves the consistency in the use of data elements in terms of their meaning and representation format. Through data harmonization, a set of core data elements (data elements expressed using different vocabularies but with identical meaning) can be extracted.” [25, p. 6]

Data harmonisation is an iterative process [26, 25]. The role of data harmonization in international level is the same with national level. It will help to accelerate trading process increase the interoperability between the systems and will decrease transactional costs. Another benefit of data harmonization is that it improves the quality and accuracy of the data exchanged or shared among the participants of the single window. Each Single Window has to adopt a set of common rules that govern data elements names, their meaning, their representations, and the structure of electronic messages.

The selection of a data model is very important prior any data harmonisation. As it is proposed in SWIF [23] and UNNExT Data Harmonization and Modelling Guide for Single Window Environment [25], the criteria that should be considered for the selection of data model are Comprehensiveness and compliance with internationally accepted standards for electronic data exchange.

According to UNECE Recommendation No. 34 [26], data harmonization involved four (4) steps; capture, define, analyse, and reconcile. Similarly, the UNNExT Data Harmonization and Modelling Guide for Single Window Environment [25] defines the following five (5) steps are proposed for data harmonisation:

Step 1: Capture Data Requirements of Business Documents Identified through

Business Processes Analysis: collects various business documents and data requirements

as analysed during the Business Processes Analysis activity.

Step 2: Define Data in Each Document and Define the Semantic of the Data and the Data

Formats: concerns the analysis and definition (including type, format, etc.) of data elements

of each individual business document.

Step 3: Analyse Data Elements across Various Documents and Organize them in a

Comparable Manner: analysis of data elements across various business documents of same

category and identification of same data items across the documents.

Step 4: Map Data Elements to Reference Data Model: map compiled data elements to the

Reference Data Model (e.g. WCO Data Model).

Step 5: Obtain the Structure of an Electronic Document: define the structure of electronic

documents (e.g. XML schemas) for data exchange.

Steps 1, 2, and 3 develop a simplified, standardized and harmonized data set for cross border trade. The Steps 4 and 5 explain the mapping of the data set to a reference data model [25].

2.3.1.4 Interoperability

Interoperability is the key concept of a Single Window implementation as it enables the data and information sharing among systems as well as their collaboration through process coordination. Thus, interoperability has been categorized into the following groups:


Page | 27

1. Process/operational interoperability: streamline business process across IT systems in

order to allow their collaboration.

2. Information/semantic interoperability: ensure seamless sharing of data across systems. To

achieve this, a common definition of individual data elements, a common structure for complex

data elements and a common structure of individual electronic messages are needed.

3. Technical interoperability: ensures connectivity of systems through the support of common

technical communication protocols. Technical interoperability focuses on the services.

4. Presentation interoperability: ensures a common look and feel approach through a common

portal-like solution.

5. Application interoperability: ensures the seamless integration of all Single Window sub-

systems and ensure identical functionalities are sharable among latter.

2.3.1.5 Realization of a Legal Framework

Finally, SWIF focuses on the Legal Framework in order to identify as a set of measures that address legal issues related to national and cross-border exchange of trade data which is required for Single Window operations. The goal of this SWIF activity area is the realization of the legal framework (RLF) through identification and implementation of this set of measures. SWIF proposes a set of RLF steps as the core towards establishment of the Legal Framework.

1. Assessment of the current legal environment

2. Establishment of supporting international legal environment

3. Establishment of supporting national legal environment

4. Establishment of organizational agreements

It must be noted that the actions within this activity area should be undertaken through early phases of the Single Window implementation life cycle (e.g. Preliminary phase of the TOGAF architecture) [27].

The establishment of the necessary legal framework involves the identification of laws and legal

restrictions concerning data submission and data exchange as well as legalization of electronic

documents. Furthermore, security issues are also identified and established through the legal

framework.

2.3.2 ITAIDE – Information Technology for Adoption and Intelligent Design for e-Government

The ITAIDE is a European-funded FP6 Integration project which proposed an implementation

framework for e-Solutions for Trade Facilitation (e-STIF or I3 Framework). The I3 framework extends

the SWIF framework, which was presented in the previous section, and Figure 2-8 depicts the

proposed aspects. The I3 framework extends the concept of Single Window by introducing the

concept of “trusted trader” and “trusted trader network”.

In brief, the I3 proposes a layered framework where each level enables the next one and the whole

framework depends on the IT innovation which enables the end-to-end control and transparency of the

physical and information flows. The term “end-to-end information transparency” refers to the capability

of the government authorities to have access to specific traders’ information regarding a shipment

based on specific agreements.

The I3 Framework depends on the concepts of the “trusted trader” and the “trusted trader network”. A

“trusted trader’ is the trader who has been granted the “trusted trader status” from the government.

This status does not only denote that the trader is known to authorities but that it exposes the proper


Page | 28

IT capabilities through redesign of its internal processes which are compliant with international and

national legislation. The “trusted trade networks” are networks of supply chains or interconnected

trusted traders which can lead to trade acceleration because of the trade simplification privileges that

the trusted traders relish.

Figure 2-8: ITAIDE I3 Framework [28]

The “IT-Related innovations” refer to the tracking and monitoring capabilities (e.g., seals for reporting

position, temperature and exposure to light) which can provide details regarding a shipment.

The I3 Framework proposes 4 critical capabilities that are enabled by the application of IT-Related

Innovations. These capabilities are; real-time monitoring which enables real time monitoring and

logging; information sharing which enables the electronic information exchange among trading parties

and authorities regarding shipments; process control which enables the documentation and evaluation

of processes based on control standards; and partner collaboration which refers to the joint capability

to develop end-to-end control and transparency.

2.4 Single window Implementations

Single Window concept has been implemented by several countries and organizations around the world in different ways. In this chapter, some implementations of the Single Window concept are presented.


Page | 29

2.4.1 United States

The USA has established the International Trade Data System (ITDS) that allows traders to submit

standard data only once and the system processes and distributes the data to the agencies that have

an interest in the transaction [1].

The system intends to reduce the burden of paper reporting between the traders and Authorities. The

necessary data are electronically collected and distributed to the appropriate agencies, enabling them

to process those data electronically. The data are submitted only once in the system. ITDS additionally

enhances agencies’ ability to identify risky cargo, persons, and conveyances, to collect more accurate,

complete and timely trade data. Furthermore the system accelerates cargo processing. Every agency

that requires documentation for clearing or licensing the importation and exportation of cargo is

obliged to participate in ITDS.

ITDS is not a separate system, it has been implemented as a facet of the Automated Commercial

Environment (ACE) project. The International Trade Data System (ITDS) is the process through which

the data needs of all Government agencies with a role in the admissibility of cargo and trade

facilitation will be incorporated into ACE [29].

Currently, 48 agencies, including Customs and Border Protection CBP, participate in the ITDS project.

Fundamentally, the ITDS project (Figure 2-9) is about data interchange and has the following

characteristics [30]:

Agencies agree to standardize their data requirements, eliminating duplicative reporting

requirements,

Standardized data are transmitted to CBP by traders and stored in the “ACE Data

Warehouse,”

CBP transmits relevant data to appropriate agencies, or agencies obtain the data through a

web-based interface, the ACE Portal, and

Agencies with a border control function provide information, operational instructions, or advice

to CBP via ACE.

2.4.1.1 The Automated Commercial Environment (ACE)

The Automated Commercial Environment (ACE) is a system being developed by U.S. Customs and

Border Protection (CBP) to automate and consolidate border processing. The Automated Commercial

Environment will be the centralized access point that connects Customs and Border Protection, the

trade community, and other government agencies. The purposes of ACE are to streamline business

processes, facilitate growth in trade, ensure cargo security, provide the tools to monitor the movement

of individuals and materials into and out of the country, and foster participation in global commerce.

To build on existing infrastructure, ACE will use the International Trade Data Systems (ITDS) to share

electronic international trade and transportation data with Participating Government Agencies (PGAs)

of the federal government. Through ITDS efforts, ACE will provide a “Single Window” for collecting

and sharing trade data with agencies that are responsible for ensuring the compliance of imported and

exported cargo with U.S. laws.


Page | 30

Figure 2-9 - The ITDS

2.4.2 Sweden

The Swedish Single Window was one of the first attempts to implement the Single Window concept.

The single window in an early structure was firstly established in 1989.

In the UN/CEFACT Recommendation 33 [1] the Swedish single window structure is characterized as

“Single authority” Figure 2-10 since Swedish customs coordinate and are responsible for its

functionality. Swedish Customs is responsible for monitoring all international and national legislation

related to border-crossing. As a result they are the logical interface between the Business community

and other public services.

Information is gathered by Swedish Customs on behalf of more than 30 different authorities (import

VAT, trade statistics, monitoring of licenses, pets, weapons etc.

Swedish Customs Single Window solutions are available using different technologies such as:

EDIFACT

Internet


Page | 31

Mobile solutions

The system aims to provide its services to all the stake holders of the supply chain in order to facilitate the trade and the movement of goods. The stakeholders that may use the system are:

Swedish importers, exporters and brokers.

National Board of Taxation.

Statistics Sweden.

National Board of Agriculture.

National Board of Trade.

European Union.

There are 164 services offered free of charge to these users and cover all the ordinary customs services. Additionally It provides to opportunity to issue electronically import licenses, collection of duties and taxes, electronic declaration of pets, firearms weapons etc.

Figure 2-10 – The Swedish Single Window

2.4.3 Finland

At the beginning of the 1990s there could be up to 7 different forms to fill in, on arrival of a ship into a Finnish port. The 80-90 % of the content was the same, only the layout was incompatible. The content was rather basic, containing information on identification, expected time of arrival (ETA) or expected time of departure (ETD), cargo and dangerous goods (DG) details on a statistical level. Thus, there was a lot of work done which was felt to be largely unnecessary and expensive. The first task was to try to convince the different authorities that reform was urgently needed and to realise one common paper form. A cost savings estimate was produced showing a theoretical saving of a few 100,000€* on a national level. The electronic notice transfer was not even contemplated initially! The process started in 1991, but the first electronic system was set up in 1993-94. It was set up on an IBM mainframe and RB2 database and dumb terminals. The present PortNet system is up and running since 2000, which replaced the old mainframe based system. We are now building the new PortNet 2 (perhaps it should have been called PortNet 3), to come into production in 2007. PortNet is a national maritime traffic database, not a port community system (operating within one port only). The user logs on to the system using the given user name and password and may provide the information using an Internet browser (https://) or file transfer (XML or UN/EDIFACT) using dedicated data communication. The access is restricted by the user management system into user profiles. Agents only have access to their own data, port authorities have access only to data within their own


Page | 32

port, and governmental authorities have access to all information. The Border Guard, however, only use read-only access. Hence all the data is available to everybody within the limits of his prescribed user profile. Timetable data is open to use without any restrictions. The business profile has never been depicted really, although everybody involved knows how it works. This is a tool for the ship agent to give all his formal notices to authorities at the same time, using a single window. It is also a tool for authorities, and all that are involved, to track what is going on in the maritime traffic. Finally this is a tool to enable anybody to update information regarding ETA and ETD timetables. 2.4.3.1 SW Services

The user (normally the ship agent or terminal operator) can give the following notices and get the following information:

Port arrival notice, containing ship id, ETA, destination port, previous port(s), detailed

dangerous cargo notice, cargo notice (initially on a statistical level, going in the direction of a

general cargo declaration, accepted by the customs office) passenger list, ship provisions;

Port departure notice, similar to the above but less complete at this time;

Issuing a single common customs reference number for the ship call, valid throughout the

whole duration of the visit;

List of exemption for line ships that have a contract with a local ship waste handling company;

A request to the port to allow some particular Dangerous Goods (DG) into port and as a

response the decision from that port on that matter;

International Ship and Port Facility Security Code (ISPS) notice (security notice, prescribed

by the International Maritime Organization (IMO));

Terminal notice regarding containers;

Ship database, with relevant basic information on all ships that have visited Finland before;

A restricted set of the International Maritime Dangerous Goods (IMDG) code database;

UN LOCODE database, including port areas;

Database on id and contact data on all agents using the system;

Database on id and contact data for ports;

To order port services, like towing, water electricity, telephone (a very little used feature);

Six IMO FAL forms produced automatically from the information are available.

2.4.4 Germany

The urgent need to speed up the flow of information within the harbor of Hamburg was the major motivating factor to establish SW. A group of liner agents, forwarders and quay operators set up a working group to discuss a possible solution. This group agreed that:

Efficient organization of transportation needs early information;

Information exchange using EDI:

o Information exchange using EDI;

o avoids errors due to double typing;

o saves time and money;

Flow of information within the harbor was too slow and too expensive.


Page | 33

2.4.4.1 SW Services

DAKOSY AG operates as a full service provider, offering both pure EDI and SW-applications with EDI-modules. All documents needed during the transport can be exchanged via the network of DAKOSY. DAKOSY’s IT Services include:

Backup Services

Disaster Management

Networks and Communications

Outsourcing

Internet Services

Data Centre Services

2.4.5 Guatemala

The SW was created by the Governmental Agreement 790-86. There were no previously established systems. It was created to satisfy the needs of the Guatemalan exporters. Previous experience was gained from South American models but they have established their own model. It was implemented in two steps:

Step 1: Unification of documents, review of export processes and physical location of entities in a single window facility. Step 2: Implementation of an electronic system to facilitate export processes and to replace manual processes.

Any change to this process is previously implemented in a pilot project with some chosen exporters. Currently, SW provides the following benefits:

SW is available 365 days a year, 24 hours a day;

Support and assistance for exporters in specific problems;

To reduce costs and time through efficiency;

All specific information is available on line to exporters through a website;

Exporters can obtain export documentation electronically in their own facilities.

2.4.5.1 SW Users and Operational Model

The main clients of the SW are the following:

Companies with high volume of exports;

Companies physically located in remote regions of the country;

Companies with high volume of transactions per day;

Producers who need several types of documents for exports.

Also, the following public and private agencies are involved in the SW facility:

Non Traditional Products Exporters Association –AGEXPRONT;

Ministry of Economy –MINECO;

Guatemala Customs Administration –SAT;

Officinal de Regimens de Perfeccionamiento Activo –OPA;

Textile Commission VESTEX;

Ministry of Agriculture –MAGA;


Page | 34

Protected Areas Counsel –CONAP;

Forestry Institute –INAB;

Chamber of Commerce;

Chamber of Industry;

Centro de Trámites de Exportación –CENTREX;

El Salvador Customs General Administration DGRA;

Honduras Customs General Administration DEI;

Guatemalan banks.

Figure 2-11 – The Guatemalan Single Window

2.4.6 Hong Kong

As a Single Window to the Hong Kong Special Administrative Region (HKSAR) Government for the HK trading community, Tradelink Electronic Commerce Limited (Tradelink) began production operations in 1997 to process specified Government trade documents (e.g. trade declarations, dutiable commodity permit, certificate of origin, production notification, restrained textile export license, electronic manifest) electronically, as an exclusive service provider appointed by the HKSAR Government. The HKSAR Government enhanced the Import / Export Ordinance to provide for digitally signed electronic submissions. Today, Tradelink processes over 18 million documents annually and has over 53,000 customers the bulk of the HK trading and logistics community. To further strengthen the role of Hong Kong as the preferred international and regional transportation and logistics hub, the HKSAR Government wished to expand the Single Window Business-to-Government concept to be a Single Window for any commercial organization to all their trading, logistics, financial business partners as well as Government. The Digital Trade and Transportation Network (DTTN) is the name


Page | 35

of this expanded Single Window initiative. One of the top priority initiatives to achieve this objective is to establish a DTTN to reduce inefficiencies arising from the “digital gap” and to facilitate data sharing amongst the trade and logistics industry stakeholders. Comprehensive analysis on DTTN was conducted in 2002 and a consultancy report (DTTN Report) was published in November the same year. With reference to the suggestions proposed in the DTTN Report, the HKSAR Government invited experienced solutions providers to submit proposals on establishing the DTTN for Hong Kong. Tradelink was endorsed by the HKSAR Government in 2003 to develop and operate the DTTN. After a comprehensive exercise of planning and preparation, the system development work was formally commenced in 2004. With the aim to assure a neutral and community focused DTTN operating framework, the “Digital Trade and Transportation Network Limited” (“DTTN Ltd”), which is jointly owned by Tradelink, the HKSAR Government and industry associations, was incorporated in 2004. DTTN Ltd will take up the remaining development work and the subsequent operations of the DTTN that will be formally launched in 2006. System development work of the DTTN is now close to completion and comprehensive system testing will soon commence. With the aim to demonstrate the value and benefit of the DTTN, DTTN Ltd is now actively inviting companies to join a Pilot Program, which is scheduled for launch by the end of 2005. This Pilot Program is also an important first step in establishing a mass of users, which is, in turn, fundamental to the success of the DTTN and therefore, attaining its objective of improving Hong Kong’s competitiveness. 2.4.6.1 Services

The DTTN is a neutral, open, secure, non-exclusive, transparent state-of the art electronic platform that provides the any-to-any document exchange services to the trade; logistics and finance industries to facilitate information flow and enhance efficiency. The initial DTTN services support and optimize the major trade and logistics processes covering import and export between the Pearl River Delta region (PRD), including Hong Kong, and overseas via ocean, air, truck, rail or river. Over 80 major documents related to trade, logistics and finance for both import and export business processes are supported by the DTTN infrastructure. The following website displays a list of documents currently

supported by the DTTN: http://www.hkdttn.com/standards/english/dttnxmldocumentstructures.html

The volume projection stated in the DTTN Report published in November 2002:

Millions unless otherwise stated

2.4.6.2 Operational Model

The DTTN is a platform that provides interconnection among the trade, logistics and finance industries to facilitate information flow and enhance efficiency. It will facilitate the Business Process Interconnect (BPI) requirements of industry and provide a platform to promote development of new business opportunities. The existence of a common and shared user platform with defined standards and

http://www.hkdttn.com/standards/english/dttnxmldocumentstructures.html


Page | 36

protocols will attract existing suppliers and spawn the development of new businesses such as logistics software development and value added services, which will contribute to economic development. The DTTN environment can be illustrated as structured into three layers as shown in the below diagram. Layers 1 and 2 are the core elements of the DTTN. They lay the foundation of the DTTN and provide an environment conducive to the continued growth of the third layer – the value-added services. Collectively, layers 1, 2 and 3 form the DTTN.

Figure 2-12 – Hong Kong’s Single Window Operational Model

The DTTN includes nine major communities:

Buyers / importers

Sellers / exporters

Freight forwarders including third party logistics service providers

Carriers (ocean, river, road, rail and air) including express integrators

Terminals

Government and its agencies

Banks and financial institutions

Insurance companies

Inspection agencies

These industry stakeholders are involved at different stages in the trade chain and they are closely related to one another. The DTTN will co-exist with and complement offerings provided by the various Application Service Providers (ASPs), Internet Service Providers (ISPs), and the global service providers and will help to promote a greater take up of e-business in the region to the ultimate benefit of the commercial sectors.


Page | 37

2.4.7 Senegal

The Senegalese Single Window, called ORBUS, was established in order to achieve the following objectives:

Reduction of customs clearance time-limits;

Reduction of customs clearance costs;

Improve quality of the service offered to importers and exporters;

Elimination of red tape.

The Ministry of Commerce started the project in early 1996. In 2001 the project moved to the Ministry of Finance. In 2002, GIE GAINDE 2000 was created in order to finalize the project and to run the system. Some stakeholders were already equipped with their own system (e.g. Banks, insurance companies, inspection, customs) others were not. For those who were not equipped, we provided them with ORBUS interface as their new system (hardware and software were offered to public stakeholders. For private stakeholders, only software was offered). We provided those who were equipped, with an open interface that they can use by creating an electronic link to their system to proceed 100% electronically. It is also possible for them to use the interface as a standalone application and to manually feed data into their system. The two situations currently exist. In early 1996, during the study phase, Senegalese experts visited Singapore to learn from their single window experience, since it was the only existing operational model in the world. We were impressed by what we saw of SNS (Singapore Network Services). There was a high level of organization and coordination. Considering that our context was different, we finally decided to build our system from our ground realities. So we can say that the Senegalese model is an original one. The project was driven by the department of Commerce as a component of a Trade Point project. The first step was to decide about the “WHAT”. Also, the government decided that it would be a virtual one. The second step was to agree on an operational model, which involved discussion with all stakeholders. This has taken a long time because the needs were disparate and the necessity to preserve all the prerogatives was crucial. The third step was to design and develop the system. At each step, there is a need for a validation with the concerned stakeholder. Proximity management is critical because, from the time you start the project, rules and people are changing. Fourth and further steps were the following:

Test (internal and external)

Training

Pilot phase

Parallel run

Total run

During the development phase the project was driven by Trade Point, training required was mostly related to “Trade Facilitation” and “Information System Management”. During the GAINDE 2000 phase (deployment phase) the same requirements remain. There is also the need of having helpdesk assistance and people highly qualified in IT infrastructure. The project was long in Senegal because of the 3 years intermission. So, we can consider that the project started in 1996 and ended in 2004 with 3 years of interruption. 2.4.7.1 Operational Model

The ORBUS 2000 System is designed to facilitate foreign trade procedures through electronic exchanges among the different stakeholders. The system is built on a technological infrastructure and provides a set of services. The Facilitation Centre (i.e. the Key point of the ORBUS System) is in charge of coordinating the ORBUS operations and the monitoring of the system’s performance. The Centre has been set up to carry out three main functions:


Page | 38

Serve as the back office of the ORBUS System;

Manage the traders who do not have direct access to the system;

Certify the ORBUS printouts to be submitted to non-automated Customs Stations.

2.4.8 Singapore

After a period of economic issues in the mid 80’s, the Singapore government decided to streamline the processes involved in the regulatory framework of trade permit approvals to further strengthen the already established trade hub status of Singapore and to improve external trade. Special committees comprising high powered government officials and business leaders were set up to ensure sufficient backing was given to use technology to support the re-engineering and improvement of the trade regulatory framework and processes. In fact, the then Minister of Trade and Industry, Brigadier General Lee Hsien Loong (now the Prime Minister of Singapore) chaired the review committees for approval of the plans and implementations. Starting with the trade process involving a few government agencies in 1989, today, the Singapore TradeNet® System provides the trading community with an electronic means of submitting trade documentations to all relevant government authorities (Singapore Customs and the Controlling agencies) for their processing, through a single electronic window (SEW). Within 10 minutes after submission of the permit application, traders will receive an electronic response, be it approval or rejection, from the relevant authorities, with details on the approval conditions or reasons for rejection. TradeNet® was established with the key objectives to:

Reduce the cost of trade documentation;

Reduce delays in turnaround time for trade documentation;

Increase authorities’ processing efficiencies with streamlined process flow;

Attract foreign direct investment as a result of operational efficiency and transparency.

The world’s first nationwide electronic trade documentation system TradeNet® has been recognized as a great contribution to Singapore’s pro-business environment, bringing about increases in efficiency and lowering business costs for the Singapore trading community with the innovative use of IT. TradeNet® was launched on 1 Jan 1989. It was recognized by the government that the introduction of the TradeNet® will bring about many benefits to the Singapore Trading community and hence to the economy as a whole. The high cost savings, greater efficiency and shorter turnaround time derived from TradeNet® made Singapore a much more competitive trading hub. The TradeNet® system has been in operation and serving the Singapore Trading community since 1989. 100% of the trade declarations are submitted electronically via the SEW TradeNet® system. Government had also mandated the electronic submission of trade declarations. Today, TradeNet® is the world’s first nationwide electronic trade clearance system. It processes some 9 million trade permit applications per year, of which 90% are processed within 10 minutes and some 70,000 Certificates of Origin yearly. 2.4.8.1 Services

The TradeNet® system allows the application, submission, receiving, processing and returning of response to trade declarations submitted. It covers the import (dutiable/GST/non dutiable/warehousing/free trade zone), export (GST/non-dutiable) and Transhipment declarations. For Importers/Exporters/Freight Forwarders, among others, the major services include:

User and company registration

Receipt and intelligent routing of user submitted permit and Certificate of Origin (CO)

applications from the Trade Net® Front-End software to the Singapore Customs (SC) and the

Controlling Agencies (CA) for their processing;

Syntax checks on the message structure;


Page | 39

Code table validations of the received applications against the code tables (e.g., Product

Codes, Harmonized System Codes etc);

Automated permit processing based on the rules and criteria of Singapore Customs and the

CAs;

Web enquiry facilities to:

o Check the status of their TradeNet® permit applications;

o Enquire & download code tables (e.g. Port code, Country,etc.);

Automated billing and direct bank account debit facility on the statutory and processing fees

incurred;

24x7 Call Centre Support.

For Controlling Agencies (CA) and Singapore Customs (SC), the major services provided under TradeNet® include:

Automated and online processing (i.e. to allow manual intervention, approve, reject some

selected types of applications) of permit application;

Online enquiry and downloading of TradeNet® permit applications;

Online maintenance of the CAs and SC code tables (e.g. Product codes, Trader, License,

Establishment codes, etc);

Interconnectivities with the CA in-house systems for the file transfer and reporting functions for

transferring and uploading of the CA controlled permit information and databases (e.g., trader,

declarant and license information);

Generation of ad hoc and periodic statistics reports.

To TradeNet® Cert of Origin (CO) Officers:

Automatic and online processing of user submitted permit application;

Online enquiry and printing of TradeNet® permit applications / certificates

Online maintenance of the CO code tables.

To other Users such as the Port of Singapore Authority:

Extraction cum provision of interconnectivities with the user in-house system for transfer of

TradeNet® permit information to PSA;

Provision of interconnectivities for exchange of information between PSA & SC such as data

for Manifest Reconciliation.

The TradeNet® system handles approximately 30,000 permit applications per day, amounting to some 9 million transactions a year. 100% of the total Trade Permit applications are processed by the TradeNet® system. The Singapore Government has mandated the electronic submission of Trade Permit Application. The TradeNet® system is used by approximately 2,500 companies with 8,000 users. 2.4.9 Malaysia

The establishment of the Single Window (SW) provides more value-added and integrated services to the customers so that common data from various applications can be re-used to enhance efficiency. First service started in 2002 The SW service is being incorporated by stages:

eLogistics – running

ePermit – running


Page | 40

Cross-Border Exchange Service – pilot phase

Order Fulfilment Service – to be piloted

Other – Dagang Net Technologies (DNT) have acquired business process management

software and we will continue to integrate “upstream” and “downstream” data and processes.

Ultimately, Dagang Net will integrate all products to create a seamless environment, to provide users with a single filing, multiple submission platform. Currently, the following products are integrated with the Electronic Declaration Systems:

ePermit

eLogistics

Cross-border Declaration Exchange Service

Order Fulfilment Service

Because of the many challenges in Malaysia (e.g.: various forms, government legacy systems), Dagang Net, a private sector company, lead the initiative of SW by establishing a “single point” where data from one application to an authority/recipient can be re-used by other applications to subsequent authorities/recipients.

2.4.9.1 Services

SW allows the user to file an application and reuse the information for submission to other authorities. Documents involved are Import/Export Permit, Advance Shipping Notice, and Overseas Export Declaration to be reused for preparation/submission of import/export declaration to Customs Authorities. Currently, approximately 1000 transactions are handled per month (ePermit) and 200 users (ePermit).

2.4.10 Mauritius

Mauritius single window is called TRADENET [31] and it is a joint venture between the private and public sector. This is not usual since the majority of such applications are funded and controlled by government authorities. The most important services offered are the following:

Submission, processing and approval of declarations to Customs within a 15-minute

timeframe

Access to air and sea cargo manifests, ships’ arrivals and departures, movement of

containers, etc.

Notice of release of consignments

Processing and approval of import and export permits

Payment of duties fees & taxes by electronic means because the system is connected

with banking systems.

About 400 private and public organizations are connected to the system. All customs related documents are submitted in EDI format.

2.4.11 ASEAN Single Window

The ASW is a system of systems. Its purpose is to synchronize and integrate the national single windows of 10 Asian countries for expediting customs release and clearance. The countries that consist of ASW are Brunei, Cambodia, Indonesia, Lao PDR, Malaysia, Myanmar, Philippines, Singapore, Thailand and Viet Nam.


Page | 41

According to the agreement signed by the ASEAN Economic Ministers in the 11th ASEAN Summit, Kuala Lumpur, December 2005 [9] the ASEAN Single Window is defined as “the environment where national Single Windows operate and integrate. Functions and roles of a National Single Window are based on a single submission of data and information, of a single and synchronous processing of data and information and a single decision making for customs release and clearance. A single decision-making is uniformly interpreted as a single point of decision for the release of cargoes by the Customs on the basis of decisions taken by line ministries and communicated timely to the Customs.”

Figure 2-13 – ASEAN Single Window

The ASEAN Single Window tries to facilitate operational linkages and procedures, to enable a seamless flow of regulatory information and to establish effective and efficient channels of information among line ministries and government agencies at national level. Improving the intra-agency cooperation and collaboration of government regulatory authorities, plays an important role in streamlining management and clearance procedures and practices. In addition reduces the time that is needed in order data and information to be dispatched to the users of the system.

National Single Windows (NSW) are systems, which enable for each country, a Single Submission of data and information, a Single and Synchronous processing of data and information and a Single Decision-making for customs release and clearance of cargo. ASW connects all the participating National Single Windows. It wants to promote regional integration of all the members of ASEAN community. The system operates in a more global environment in order to enhance trade efficiency and competitiveness. The system intends to provide better competitiveness for international transactions of regional economies through the following action:

Standardization of trade related data and information as appropriate;

Standardization and alignment of documents and formalities to international standards

and conventions;

Simplification and standardization of the business flow of processes related to cargo

clearance; and

Development of a suitable legal framework.

National single windows which are participating in the ASEAN Single Window are operating in six major areas. These areas are:

Customs.

Other Government Agencies (OGAs).


Page | 42

Banking and Insurance Agency.

Transport Community.

Trading Community.

An important goal of ASEAN Single Window is to reduce the average time of shipment clearing to 30 minutes. Currently it can take up to five days [32].

2.4.12 Netherlands

In particular the Customs Administration of the Netherlands is one of the forerunners in implementing the Single Window. Already in 1986 several cross border documentary obligations where one hand integrated in the customs processes and in the customs declaration procedures and IT-systems.

It’s almost 30 years that integrated within the customs declaration, the value declaration, statistics declaration, vat at import and all EU own recourses are integrated. At export even the application for agriculture refunds were integrated in the customs declaration since then. Over many years, agriculture certificates, other’s departments’ financial deposits, economical licenses and procedure around those, were implemented in the customs system. Towards trade these are all parts of creation of a single window, more and more government obligations are integrated within one procedure.

Since 100% of customs communication is done via IT, the Netherlands has one central technical portal, Digipoort, for all digital communication with any government agency. Step by step further integrations were and are made by aligning processes of different agencies to the customs procedures. Within the Netherlands a government wide group, Steering Group Single Window, in which also trade representatives take part, take all necessary measures to complete the single window.


Page | 43

3 Relationship of Data Pipeline concept with the Single Window Concept for International Supply Chain

This chapter presents the relationship between the data pipeline and the Single Window. To this extent, the current situation in international trade will be presented to pinpoint the problems and to highlight over the various declarations/documents which need to be submitted. Then, the data pipeline concept is described as well as the basic principles underpinning this concept. Finally, the CASSANDRA Global Virtual Pipeline is presented.

3.1 Brief description of Current (AS-IS) Situation

The current situation in the supply chain is quite complex and it has to be understood prior to the introduction of CASSANDRA pipeline concept. There are several roles that are performed by the actors of the supply chain. An example is presented below for sea transport depicting the actors’ interactions during the process with several ways (Figure 3-1). In the last decade, there is an increased volume of trading in global supply chains. Consequently, the informational systems that have been created in order to support the supply chain process have been enlarged increasing complexity. The increased complexity raised also the risks for all the stakeholders of the supply. As a result, the ability to handle data efficiently and swiftly has become a key element in international competitiveness, especially in international supply chains. Information exchange for global logistics supply chains is currently mainly implemented using a declaration-based approach in which data is bilaterally pushed between traders and authorities. As the movement processes along the supply chain other stakeholders take responsibility for it and are obliged to report an action relating to it (for example, loading, departure, arrival, discharge) or submit a declaration (for example, export, transit, import) to border agencies within their jurisdiction. This increases the administration burden and the time for the movement clearance.

Figure 3-1: Value web of roles for sea transport (Source: CASSANDRA, Integration architecture)

Documents that are required in international and national trade are: Import permits, export permits, customs declarations, enquiry, order, dispatch advice, collection order, payment order, documentary credit, forwarding instructions, forwarder's invoice, goods receipt, air waybill, road consignment note, rail consignment note, railway manifest bill of lading, freight invoice, sea/air/land cargo manifest, cargo clearance, export license, export details, exchange control doc., phytosanitary certificate, veterinary certificate, certificate of origin, certificate of pesticide, consular invoice, dangerous goods declaration,


Page | 44

import license, customs delivery note, TIR carnet, AEO related information, foreign trade licenses, duties and taxes payment confirmation, etc. [33].

Customs mainly focus on the goods arriving in the country and so, and in order to perform inspections and pre-arrival risk analysis, they exploit the data from the sea or air manifest, while the use the data from the submitted Customs declaration in order to calculate and collect the duties and provide statistics. Discrepancies are investigated by inspecting the goods with the ones as declared in the manifest. But manifests usually contain the minimum set of information and are focusing on agent-to-agent. Furthermore, import manifests, which are considered as summary declarations, are prepared by carriers, who they are not responsible for preparing the cargo and so, they do not actual know what is packed. Particularly for EU legislation, the carrier is responsible for submitting the declaration. Figure 3-2 depicts the current state of customs and international trade systems.

Nowadays, most of the commercial data originating from the consignor after agreement with the consignee as well as those generated during the logistics operations performed by a third-party are separated from the data submitted to Customs. Furthermore, Customs’ exporting data and importing data are differentiated as explained below. As a result, there is a high possibility of mismatching data.

Figure 3-2: Current Customs and International Trade Systems [34]

Customs receive the information by the traders according to the regulatory requirements. Most of the participants in the process do not really know what is really being carried inside the containers. In addition, the data that the authorities have do not allow them to perform a proper risk analysis, capable to face all the dangers that arise in the supply chain. Another important characteristic of the global supply chains is that each actor has implemented its own IT system in order to perform its tasks during the process. Sometimes the same stakeholder implements different IT systems in order to perform different roles in the supply chain or face all the requirements successfully. This diversity of systems causes integration problems since it is not always possible these systems to communicate each other. The interoperability between these systems is very low. In addition, it is not easy to monitor and verify the compliance with national rules and regulations. Traders face a set of duplicative

Contract of

Sale, Invoice

and

Payment

Current Customs and International Trade Systems

Consignor or

Exporter

Consignee or

Importer

Container/Carrier

Manifest

Customs Export declaration (with

overvalued invoices for recovery of tax)

Risk Assessment for admissibility and compliance

Post Export

Assurance

by

Customs

Post

Clearance

Assurance

by

Customs

Freight

Forwarder or

3PL

Freight

Forwarder or

3PL

Data

rela

ting t

o th

e g

ood

s and

the

pe

op

leD

ata

rela

ting t

o c

arr

iage

EU

Regulation

Country B

Port 1 Port 2CARGO

3rd Country

Regulation

Country A

CARGO

Customs Declaration for Home Use or

Regimes (undervalued for duty purposes)

Fiscal and Statistics Collection

CARGO

Contracts of Carriage

House Way Bill

Shipping Note

Packing List

Letter of Credit

Freight Account

InsuranceHandling Fees

Carriers Receipts

Vessel Booking

Import Summary Declaration

(manifest data)

Import Control System safety and security

summary declaration from Carrier


Bill of Lading

Contract of

Sale, Invoice

and

Payment

Contract of

Sale, Invoice

and

Payment

Current Customs and International Trade Systems

Consignor or

Exporter

Consignee or

Importer

Container/Carrier

Manifest







Post Export

Assurance

by

Customs

Post Export

Assurance

by

Customs

Post

Clearance

Assurance

by

Customs

Post

Clearance

Assurance

by

Customs

Freight

Forwarder or

3PL

Freight

Forwarder or

3PL

Data

rela

ting t

o th

e g

ood

s and

the

pe

op

leD

ata

rela

ting t

o c

arr

iage

Data

rela

ting t

o th

e g

ood

s and

the

pe

op

leD

ata

rela

ting t

o c

arr

iage

EU

Regulation

Country B

EU

Regulation

Country BCountry B

Port 1 Port 2Port 1 Port 2CARGOCARGO

3rd Country

Regulation

Country A

3rd Country

Regulation

Country ACountry A

CARGOCARGO







CARGOCARGO

Contracts of Carriage

House Way Bill

Shipping Note

Packing List

Letter of Credit

Freight Account

InsuranceHandling Fees

Carriers Receipts

Vessel Booking


(manifest data)


(manifest data)







Bill of Lading


Page | 45

and redundant reporting requirements, forms, systems, data sets, data models, and messages. As a result, there is a continuous bilateral communication between the authorities and the other participants of the supply chain where business documents are exchanged using paper or electronic formats.

The use of different formats result to the creation of different interfaces by all the participants of the supply chain process. These interfaces usually are not the same for all the countries either considering the information required or the used technology. This leads to a high administrative burden and financial costs for all the supply chain participants. Moreover, in case new declarations and procedures would be introduced for sharing the missing data, an even tighter coupling of traders and authorities would result, and the administrative burden would even further be increased.

Figure 3-3 shows an example of the current process business process. The reader can easily observe the mass message and data exchange between the Importer, the authorities, and the Carrier.

Figure 3-3 – Import Business process example

In addition, we observe that even in case those countries have implemented Single Window applications there is little or no information exchange between these National Single Window systems or between Authorities which do not have a Single Window system for their area of jurisdiction with other authorities which have. So are forced to liaise with them via telephone and email, which is inefficient and time consuming. Important information is often received very late or missed altogether. Similar problems occur between authorities in neighbouring countries [35].

Seamless, electronic data pipeline between traders, Government authorities and other stakeholders of the supply chain would enable the data sharing for various business needs. In addition, it will facilitate the flow and the accessibility of information during the supply chain process. It will ensure harmonization and visibility and the creation of a level commercial playing field with the greatest predictability possible. UN/CEFACT, WCO, and GS1 are organizations that have proposed standards for data exchange in logistics supply chains. These standards help to improve data harmonization they will facilitate the linkage between the systems of the supply chain and national Single Window applications.

3.2 Seamless Integrated Data Pipeline


Page | 46

The data pipeline concept for facilitating the operations in the supply chain was introduced by Hesketh with the vision to contribute to a more reliable and secure trade environment [34]. The goal of the data pipeline is to allow government agencies and other trusted (authorized) parties to have access to the same and reliable data. Thus, it was proposed that reliability of data can be achieved by capturing data from the source and using this data throughout the supply chain. The flow of data can take from any place to any destination. Figure 3-4 depicts a seamless integrated data pipeline.

The data pipeline concept is based on two principles; the “piggy-backing” principle and the synchronization points that determine when the data should be available to parties [36]. Before data pipeline, the economic operators had to submit (push) several obligatory documents to a variety of government agencies and to other parties in the supply chain. However, the data pipeline facilitates the government agencies procedures through allowing them to pull the required data from existing information systems of companies instead of mandating economic operators to send (push) documents with filtered information. In other words, authorities or any other authorized party can “piggy-back” on the information collected by the companies’ information systems rather than gathering documents. This situation allows government agencies to obtain data at any time regardless of the moment of border-crossing.

Figure 3-4: Future Customs and International Trade Systems 1

On the other hand, the synchronization points in the data pipeline describes the time when the data are shared and available to the rest of the supply chain stakeholders. In [36], two synchronization points have been distinguished; the “Sales Agreement” point and the “Completion of the Consignment” point. The first one corresponds to the point where the buyer and seller reached an agreement and a purchase order and contract of sale have been completed, while the second (CPP) corresponds just

1 http://www.cassandra-project.eu/articles/data-sharing.html

http://www.cassandra-project.eu/articles/data-sharing.html


Page | 47

before the completed consignment is dispatched. Data pipeline allows incremental submission of data, e.g., data from the start of transportation, or during transportation and so on.

As we have described in the previous chapter, the adoption of the Single Window concept would lead to improved import and export services at the national level (import, export, transit procedures). However, accommodating the data pipeline concept with the Single Window could provide the appropriate facility for extending a Single Window services beyond national borders and their integration with the Global Virtual Pipeline.

The CASSANDRA project is based on the “piggy back” principle to enable authorized parties to piggy back on trader (upstream) data and so, it adopts the seamless integrated data pipeline as a starting point for its integration architecture. The CASSANDRA Backbone [37] connects supply chain partners with customs through the integration of their systems which is achieved with the definition of suitable interfaces. Figure 3-6 depicts the interfaces developed to support the connectivity of actors. The solution proposed by CASSANDRA replaces declaration systems with real-time monitoring of goods flows. Chapter 4 presents the proposed features of the Cassandra Virtual Pipeline and Figure 4-1 illustrates the CASSANDRA Global Virtual Pipeline and the CASSANDRA Single Pipeline Entry Point (SPAP).

One of the various transformation employed by the CASSANDRA approach is the change from a “data-push” method to “data-pull” method. In the data-push method, the traders’ have to submit the appropriate data to the appropriate government agencies through the submission of declarations and other documents. The “data-pull” method allows government authorities (and National Single Windows) to retrieve business data from the business systems. This mechanism is subject to various security issues as we are going to describe in the following chapters.

The CASSANDRA project focuses on two business process activities from the global supply chain, the data sharing among traders and the data capturing by authorities as depicted in Figure 3-5. In terms of data sharing, CASSANDRA focuses on the information and data exchange among supply chain business partners. CASSANDRA will utilize the existing data share infrastructure established between traders in order to reuse the data they exchange. In terms of data capturing, CASSANDRA focuses on the information and data exchange between supply chain (business) partners and government authorities. Several techniques exist that can be used to allow data capturing within the CASSANDRA Global Virtual Pipeline (e.g., submit data-data push, data pull, publish/subscribe). For CASSANDRA, the data pull mechanism will be used. Authorities can use a pull mechanism to retrieve data made available by traders. They are able to aggregate this data and can analyze it further based on their risk assessment protocols. To overcome the current major shortcoming, which is the fact that the authorities do not have sufficient information for a proper end-to-end risk analysis, the pulling of consolidation (packing) data is also included. Moreover, most traders have already designed and developed their systems in order to support data and information exchanges among their IT systems. Thus, the challenge is to achieve integration of all the systems in a decentralized manner.

To this extent, CASSANDRA adopts the interface specification among IT systems which implement open standard as depicted in Figure 3-6.


Page | 48

Figure 3-5: Data Sharing and Data Capture in Cassandra

Figure 3-6: Interfaces of the target CASSANDRA integration architecture [37]

authority authority

Seamless integrated data pipeline

shippercarrier

consigneestevedore

liner agent

forwarderproducer

dispatcher

receiver

Data sharing

Da

ta c

ap

turin

g


Page | 49

4 CASSANDRA Global Virtual Pipeline and SPAP Specification

This chapter specifies the steps towards the integration of Government Authorities and National Single Window with Data Pipeline by adopting the concepts of the CASSANDRA Global Virtual Pipeline and the CASSANDRA Single Pipeline Access Point that are proposed in the CASSANDRA project. Traditional Single Window Concept has been extensively discussed in section 2. The CASSANDRA Global Virtual Pipeline defined here is based on the “Seamless integrated data pipeline” concept and the CASSANDRA Backbone of CASSANDRA project.

Therefore, this chapter presents the business and technical requirements in order to establish the CASSANDRA Global Virtual Pipeline and the CASSANDRA Single Pipeline Access Point. These requirements are further elaborated, and frameworks and solutions are proposed to meet each requirement. The goal of this chapter is to present the interoperability issues and solutions that the CASSANDRA project must face in order to support the various heterogeneous systems. Moreover, the security aspects are also discussed in order to prevent unauthorized usage of data.

4.1 Purpose

CASSANDRA project’s main goal is to improve supply chain visibility and business execution as well as the efficiency and effectiveness for government supervision. Data sharing and a new approach towards risk assessment will facilitate this goal. The new data sharing concept of “Data Pipeline”, which enables the combination of existing information sources in supply chains, improves visibility and thus also assessment of risks by both business and government. [38]

As it is mentioned in CASSANDRA Compendium, “A major problem of Single Window is that it focuses on the border processes, which are only one part of an international supply chain process. In developed economies a regulatory Single Window based on the principle of Business to Government and Government to Government data exchange is unlikely to have a significant impact on the efficiency of national trade. The concept of a centralized Single Window operation is now being questioned.” [39, p. 105]. It is also stated that: “Even where the Single Window has been adapted to the situation of developing countries and emerging economies and has increased efficiency of national cross border trade, difficulties of interoperability with developed economy systems means that a new generation of supply chain data management initiatives are called for.” [39, p. 105]

Finally, it is stated that CASSANDRA data pipeline can be considered as an innovative approach for the next generation of Single Window. [39] In this context, the CASSANDRA Virtual Pipeline defined here is built on the “Seamless integrated data pipeline” concept and CASSANDRA Backbone of CASSANDRA project and it aims to facilitate the “smart” supply chains as described by [36]. The integration of data sources across the supply chain is considered that supports the development of a paperless environment in trade [39].

4.2 Conceptual View of CASSANDRA Proposed Solutions

In this chapter, the basic characteristics of the CASSANDRA proposed solutions are presented concerning the CASSANDRA Single Pipeline Access Point and the CASSANDRA Global Virtual Pipeline. The services and the architecture will be discussed in Chapter 5 below. A conceptual view of the proposed CASSANDRA solutions is depicted Figure 4-1.


Page | 50

Figure 4-1 – Conceptual View of CASSANDRA Global Virtual Pipeline


Page | 51

The CASSANDRA Global Virtual Pipeline should allow the integration of the National Single Windows and other IT systems owned by government authorities with the supply chains enablers IT systems (or visibility systems), such as Port Community Systems or other systems which are considered the data sources. The CASSANDRA Pipeline is the virtual mean that allows the parties involved in the international supply chain to share data and enable the re-use of this data from authorised parties through the provision of a set of services for better visibility and efficiency in supply chains. Obviously, the services offered by the Virtual Pipeline and the access to data will be based on the authorisations and the roles of the parties. In addition, the security of data provided by the stakeholders in the data pipeline shall be ensured. For this purpose, security requirements and measures shall be defined and applied to pipeline. The security aspects of CASSANDRA Virtual Pipeline are mentioned in section 4.4.5.

The CASSANDRA approach will take into consideration the the UN /CEFACT Recommendation 35 which establishes a legal framework for an International Trade Single Window. The following requirements are considered as prerequisite for allowing international trade [40].

Legal basis for implementing a Single Window facility

SW facility structure and organization

Data Protection

Authority to access and share data between government agencies

Identification, authentication, and authorization

Data quality issues

Liability issues (obligations and responsibility)

Arbitration and dispute resolution

Electronic documents

Electronic archiving

Intellectual property rights and database ownership

Competition

The CASSANDRA Global Virtual Pipeline aims at offering a high level of interoperability among the heterogeneous systems which should be integrated in the CASSANDRA Backbone. The CASSANDRA Pipeline aims at reducing the costs of integration among various systems through applying standard-based connection mechanisms (e.g., Web services, adapters), and should support various messaging paradigms such as synchronous request/response, asynchronous request/response, asynchronous publish one-many, asynchronous publish one-one. Moreover, CASSANDRA Global Virtual Pipeline implies the existence of suitable data transformations to facilitate data exchange among systems allowing data to be digested by various systems.

To achieve the above, the CASSANDRA Pipeline will investigate and propose the suitable tools and standards to protect data. Data protection refers to secure access through proper credentials and to the mechanisms to be employed to ensure the integrity and accuracy. So, access and security protocols are investigated in order to propose the proper mechanisms for identification, authorization and authentication. Another issue that CASSANDRA pipeline focuses on is the privacy of data in terms of privacy and confidentiality of personal and business data. It should be noted that the CASSANDRA Pipeline is actually a virtual pipeline and thus, it should not be considered as a central data storage point. The pipeline does not store any data.

The CASSANDRA solutions will adopt a Service-Oriented Architecture (SOA). Designing the pipeline following the SOA principles will enable a web-based global virtual pipeline environment to integrate widely disparate systems and applications and to use multiple implementation platforms. Hence, using the SOA integration approach provides a flexible integration model [17]. Additionally, SOA will offer reusability of services and it will enable an autonomous and configurable environment for global virtual pipeline. The decomposition of data pipeline architecture in more manageable components is feasible with the adoption of SOA.


Page | 52

The CASSANDRA Global Virtual Pipeline will be a virtual platform that implements standardised interfaces for communication, connectivity, transformation, portability and security. It must support the communication, mediation, transformation, and integration technologies required by those services and should be capable of a distributed geographical deployment.

4.3 CASSANDRA Backbone

In the context of the CASSANDRA project, the CASSANDRA Backbone has been established in order to demonstrate the data capture of (upstream) data in a limited number of trade lanes. The CASSANDRA Backbone has been introduced in [37].

In brief, it consists of the business systems and the customs dashboard. The business systems are systems that share data, including traders’ standalone systems; while customs dashboards are integrated to the business systems under their regimes in order to retrieve data. The customs dashboards are integrated with one or more declaration systems where the latter can trigger the dashboard causing the data retrieval from the pipeline. The CASSANDRA Backbone supports also the CPP synchronization (as discussed in Section 3.2) for container consolidation.

The CASSANDRA Backbone does not enforce the existence and application of an integration platform from a specific solution provider but it is an open system forming a network of logistics nodes connected through unified interfaces. The data sources of the CASSANDRA Backbone are the Port Communities Systems (PCS), the Business Community Systems (BCS) and traders systems which are able to interface in the countries its operates. It is constructed as a hybrid solution which means that it is established by GS1 (EPCIS), BCSs, PCSs and trader systems. These CASSANDRA Hubs will be presented in Section 4.4.1.

4.4 Proposed CASSANDRA Global Virtual Pipeline and CASSANDRA SPAP

As it was described in previous chapters, many countries and businesses have adopted the Single Window concept through adapting it to their national requirements and needs in order to facilitate trading. However, most of them do not address the needs of the international supply chains. The CASSANDRA project focuses on the integration of various heterogeneous data sources across the supply chain allowing capturing of data as soon as possible in the chain even before the goods are containerized and loaded on the international transport mode. The collection of information will take place not only on the flow of goods but also on the structure of the chain [39].

The first step towards this concept will be realized by the development of the CASSANDRA data pipeline, customs dashboards and business dashboards. The CASSANDRA pipeline and SPAP intend to adopt some characteristics from the existing single window concepts and will add new ones that will cover the special features of the supply chain. Even though this document describes the CASSANDRA Pipeline, the implementation details are out of scope. However, some characteristics and benefits of the concept are demonstrated in CASSANDRA project activities.

The following list summarizes the requirements of the CASSANDRA Global Virtual Pipeline:

The proposed solution should integrate information requirements of all participants in the

international trade transactions and it should provide an end-to-end solution.

The CASSANDRA Single Pipeline Access Point (SPAP) will integrate National Single

Windows and other government authorities’ IT systems which will allow the data capturing

for the CASSANDRA virtual pipeline.

The CASSANDRA solution should support various heterogeneous systems (location

independent systems) and should ensure data exchange (information sharing) through

standard communication protocols.


Page | 53

The CASSANDRA should enforce data protection (privacy of data) and confidentiality as well

as it should ensure integrity and accuracy of data. Furthermore, the CASSANDRA should

apply the proper mechanisms to secure the access to data. This means that data should be

protected and proper authorization mechanisms should be applied.

The CASSANDRA should specify when and how data may be shared and under what

circumstances and with what organizations. A multi-level access control model should be

defined to limit as well as enable access to data.

The SWIF framework could be used for proposed CASSANDRA solution. Since this document mainly focuses on the data capture interface of CASSANDRA, the main focus is on the connection of Government Authorities IT systems, Portals and National Single Windows with the CASSANDRA Global Virtual Pipeline via the SPAP. In brief, the steps towards establishing this connection require various steps towards providing a unified and standardized approach of integration of the underlying IT systems.

As a first step, the analysis of business processes that are performed in the supply chain is required because this enables to identify simplifications of processes, to enable understanding of supply chain interactions and business information exchanges (or business objects) In addition, the application of piggy-backing principle should also be considered in the business process analysis

Based on the set of business documents that is formulated during business process analysis, the next step is to simplify the data required by eliminating the unnecessary and redundant data. Then, these data should be aligned to a regional or an international data set. A typical outcome of such a procedure is a list of documents, a set of data dictionaries, a standard data set and a set of message implementation Guidelines. These documents should be aligned with regulations and standards in order to establish a common data set of documents. Data dictionaries correspond to the documents’ list and contain details for each document such as document title, the document purpose, the name of the document owner and the specifications of each data element corresponding to the document.

After the data harmonization, the next step is to define the message exchange format for these documents. The message exchanges should be enforced by interoperable languages such as XML which allows interconnection of the IT systems.

In order to promote interoperability and scalability of CASSANDRA virtual pipeline, the approach to follow is the adoption of the Service-oriented Architecture principles. To this extent, based on the analysis of business processes and the requirements, a set of services are identified. For this set of services, their specifications have to be addressed taking into consideration the communication protocols that have been identified as well as the message exchanges that have been required in a previous phase. Service specifications will entail the service descriptions, contracts & policies, execution context, visibility, outcome and interactions. Thus, identification of the services that the systems should offer in order to enable the data pulling mechanism is mandatory.

The next sections are going to present the above issues in greater detail.

4.4.1 CASSANDRA Hubs

This section provides a high level view of the participants that form the CASSANDRA network service ecosystem and will enable the CASSANDRA Virtual Pipeline. The nodes in a CASSANDRA logical topology are assigned with a role as explained below. The roles imply a set of characteristics for the participant. Thus, the following three potential data suppliers have been identified for business systems [37].


Page | 54

A. Data Sources

The data sources of the CASSANDRA Global Virtual Pipeline are the Business Community Systems (BCSs), the Port Community Systems (PCSs), the GS1-EPCIS business networks, and the IT systems of an individual trader.

1. Business Community System (BCS):

A Business Community System (BCS) refers to IT systems which support the community formed by various players involved in the supply chain. These systems are owned by supply chain stakeholders. Sometimes, the term BCS is used to refer to the integration the IT systems of several traders, but also it may be used to refer to an actual IT system provided to the business traders and which offer a set of value-added services to the serving community,

BCS is also known as a Supply Chain Visibility Platform, Logistics Supply Chain Networks, or Global Trade Networks. The difference of these systems depends on the service offerings and the business role of the integrated partners. One of the main characteristics of a BCS is the trust that a stakeholder has to the system, trust regarding data protection and confidentiality.

Other examples of BCS examples include TradeXchange [41], EastPort Technology and GT Nexus [42]. Most of the times, the services of a BCS is provided by a third party service provider who acquires fees for the transaction (or for the subscription). However, public-private synergies have driven the design and implementation of these platforms. Such platforms will be presented in the Port Community Systems section as the latter is considered as a specialization of a BCS.

2. GS1-EPCIS

The EPCIS (EPC Information Services) is an EPCglobal standard which defines interfaces that enable the sharing of EPC-related data within and across enterprises [43]. The EPCIS has been proposed for inter-organizational data exchange for trace and track purposes. The EPICS is actually a framework consisting of an abstract data model, standard interfaces to enable EPC-related data to be captured and queried using a defined set of service operations, and associated EPC-related data standards [44]. The abstract data model defines the generic structure of the EPCIS data, while the standard interface enables the interaction of the EPCIS clients. Thus, EPCIS provides a standard interface for storage and access of EPC-related data that can be read and written by authorized parties. The EPCS is extensible so, businesses can extend it in order to meet industry-specific requirements and specifications.

In brief, EPCIS depends on the notion of a RFID tag which contains the electronic product code (EPC) that globally identifies the item. A RFID tag is scanned by readers which send the information to the EPC middleware [45]. The EPCIS repository is employed by the EPC middleware in order to filter, store, and access the EPC-related data. An Object Name Service is used to identify where the data is stored and then the event data are retrieved from the EPCIS repository of the parties involved. However, access to the EPCIS server is query to authorizations and authentications mechanisms. Descartes is an example of a GS1 compliant software solution.

3. Port Community System (PCS)

Another actor participating in the CASSANDRA Virtual Pipeline is the “Port Community Systems” (PCSs). In [46], a "Port Community System" (PCS) is defined as a “computerized


Page | 55

system that simplifies information exchanges between non-public authorities in a port”. A more detailed description has been provided by the EPCSA in [47], where a PCS is defined as:

“… an electronic platform which connects the multiple systems operated by a variety of organizations that make up a seaport, airport or inland port community. It is shared in the sense that it is set up, organized and used by firms in the same sector – in this case, a port community.

Is a neutral and open electronic platform enabling intelligent and secure exchange of

information between public and private stakeholders in order to improve the efficiency and

competitive position of the sea and airports’ communities

Optimizes, manages and automates smooth port and logistics processes through a single

submission of data and by connecting transport and logistics chains.”

As highlighted in the definitions, a PCS supports both B2B and B2G interactions and thus, it connects supply chains partners in the ports’ business communities (stakeholders of the logistic chains) with Customs and clearance authorities. The aim of a PCS is improving efficiency at all stages of the process of manifesting, through vessel discharge and loading, customs clearance, port health formalities and delivery in and out of the terminal.

The reason that gives rise to the existence of a PCS is the fact that Ports have been identified as major bottleneck for the international trade and transport. So, efforts have been undertaken to eliminate the paper-based documents required for the execution of the procedures and apply an electronic system with the responsibility to share data to Customs (e.g., export and import procedures), the PCS. Thus, the PCS is responsible for collecting important data from supply chain partners and disseminate them to the government, enabling the data exchange between a business community and the government. Examples of data sharing includes customs declarations, import/export declarations of container and general or bulk cargo, status information, tracking and tracing the whole logistics chain, processing of dangerous goods, etc. Most of the times, the data exchanges are EDI-based.

Apart from the dissemination of proper data for the fulfillment of Customs and clearance procedures, a PCS provides several business services such as B2B logistics procedures (container and cargo handling) and some PCS provide limited support to rail, barge and trucks services.

Several PCS have been developed throughout the world and the most acknowledged are: Portbase (Rotterdam, Amsterdam), DAKOSY (Hamburg, Germany), PORTIC (Barcelona, Spain), SOGET (Le Havre, France), APCS (Antwerp, Belgium), MCP (Felixstowe, UK), dbh (Bremen, Germany), TradeLink (Hong Kong), Portnet (Singapore). Most PCSs applies subscription fees or transactions fees to its stakeholders.

The PCS offers a great deal of benefits to its stakeholders. It removes the inefficiencies in port business processes and improves data exchange which leads to elimination of delays of cargo movements as well as the elimination of links between private and public sector through atomization and reduction of paperwork. This contributes to reduction of the administrative burden and operational costs. Furthermore, a PCS integrates and achieves compliance with national and EU Directives.

Apart from the stakeholders presented above, CASSANDRA Virtual Pipeline also encapsulates the traders’ individual systems.

B. Government Authorities - National Single Windows:


Page | 56

Most of the times, the term National Single Window refers to the Regulatory Single Window that we have described in Section 2.2.2.4. To summarize, a NSW refers to a countrywide facility providing services and interconnecting the supply chain partners with the government authorities. The NSW serves as a single entry point allowing for a single submission of standardized information which is required to fulfil all export, import and transit-related regulatory requirement [17], while enables coordination and collaboration among parties and their IT systems.

4.4.2 Business Process Analysis

As mentioned in Section 2.3.1.2, business process analysis is essential for Single Window implementation. Business process analysis refers to the study of existing business processes within an organization or across organizations with the aim of improving them. In particular, business process analysis analyses business processes and identifies the actors (or roles), the activities that must be performed as well as their sequencing flow, the business objects or business documents that the processes need or generate or alter during the process flow, the business rules and/or regulation that govern these processes, and the relationships in terms of interactions across business processes. Business process analysis is an important task as it is the tool that helps analysts to identify bottlenecks and problematic areas and in general, pinpoints the areas of improvements. Typically, the analysis of business processes depends on the construction of the corresponding business process models using modelling languages and notations such as BPMN [48] and UML [49].

Business processes have significant impact on the performance of the overall business and the outcome of such a procedure is; the simplification of business processes, the simplification of business documents, the alignment of processes (their interactions & documents) with international standards, and the automation of transactions through the electronic documents which will lead to the establishment of paperless systems.

In the context of the CASSANDRA project, business process analysis must focus on the collaboration of the various participants by analysing the interactions and supporting material among their business processes and their supporting systems. The analysis of business processes must cover business processes from the supply chain as well as to those supporting the government authorities’ responsibilities. To this extent, the functionality supported by the pipeline must be identified in order to identify the business processes that will support it. Based on the identified business processes, the proper interaction models must be constructed based on the guidelines proposed by international standards. For example, the supply chain processes may be designed to conform to the UN/CEFACT international supply chain model. This supply chain model categorizes the processes into three groups: buy-ship-pay as illustrated in Figure 4-2.

Figure 4-2: UN/CEFACT Supply Chain Model Recommendation 18 [50]

The Figure 4-3 analyzes the business collaborations of the “ship” business process as it combines the Customs procedures as well [51].


Page | 57

Figure 4-3: Extended Buy-Ship-Pay Model

For example, the business transaction for “Prepare for Export” is depicted in Figure 4-4 as a UML Activity diagram.


Page | 58

Figure 4-4: "Prepare for Export" Business Transaction [52], [53]

Standardized business process models as the one depicted in Figure 4-4 will help the harmonization of business processes which will contribute towards the process interoperability. Apart from the business process re-engineering process, the standardized business process models will help towards the identification of the business documents that are exchanged among partners. These business documents will further be refined as we are going to discuss in data harmonization.


Page | 59

4.4.3 Data Interoperability Standards and Specifications

The success of the CASSANDRA project depends heavily on the integration of the traders and government authorities’ systems. One aspect of the system integration relies on the ability to exchange messages in a format that the systems can understand and manage (semantic interoperability). This implies a common data reference model which will be the logical model of the information used in cross border trade. This common data model will be the cross border data reference model and will serve as the basis of the specifications regarding the electronic documents. In order to identify the elements of such a data reference model, we need to investigate and analyze the variety of data models used by systems as well as the documents (both paper-less and paper-based). Moreover, we need to elaborate on current standards and specifications in order to agree on specific elements to be included in the CASSANDRA ontology. This ontology will serves as a basis to generate common data models which will be expressed in terms of XML and EDI to allow interoperability among systems.

The process discussed above is also known as Data Harmonization. Data harmonization is defined as the act of reconciling the definition and representation formats of data elements in a domain of interest [25]. Through data harmonization, a set of core data elements (data elements expressed using different vocabularies but with identical meaning) can be extracted. Description of each core data element inclusive of its definition and representation format can then be formalized [25].The goal of data harmonization is to eliminate redundancies, duplications and ambiguity in data. The goal of the data harmonization process must be a set of standardized data requirements and a set of standardized messages. The outcomes of the data simplification is the definition of the national requirements, the mapping of these document requirements to international standards and the simplification of the data requirements across documents through comparison of the trade requirements to international standards (e.g., UN/TED-ISO 7273, WCO Data Model, ECE/CEFACT Recommendations). The outcome of the document harmonization is the alignment of documents to international standards (e.g., UNLK), the usage of international accepted codes for trade data (UN Code list recommendations), and the number of the documents is reduced (standards: UN Layout Key, ECE/CEFACT recommendations, WCO, IATA). The definition of the common data model will later contribute to the specification of message exchanges. Typically, data models that have been introduced for International Trade should be developed based on the UN/CEFACT Core Component Technical Specification (CCTS) [54] because the latter provides a methodology to describe the semantic and the logical structure of trade information.

The CASSANDRA approach towards data harmonization proposes that the activities should take into consideration both paper-based trade documents and the electronic data documents. The goal is to investigate the standards and specifications from both supply chain and government agencies in terms of document codes, document elements, and document layout. Also, we have to investigate inconsistencies with trade documents as well as to identify the trade documents that were used as a basis of their definition. The CASSANDRA consortium is working on this issue and the outcome will be a CASSANDRA ontology which will serve as the common data model.

The scope of the data harmonization in the Single Window context covers all documents needed for the support of the international supply chain as a whole. During the data harmonization process, the standards and specifications from the most prominent standard bodies and committees will be considered. These committees are: Kyoto Convention (goods declaration), CMR (road), EU (SAD), International Chamber of Shipping, IATA (air), CIM Convention (international rail), UNCTAD(GSP Certificate), FIATA (forwarding instructions).The data model which will be constructed as a result of the data harmonization should therefore be compliant with international standards which support the semantic interoperability.

The following sections present the most acknowledged data models and documents in international supply chains. These specifications and standards are presented in this section because they have been extensively used throughout the integration processes carried by various countries. Also, these standards form the framework towards establishing the data integration that is required in the


Page | 60

CASSANDRA Global Virtual Pipeline. A list of key instruments for border management modernization is described in [55].

4.4.3.1 United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT)

UN/CEFACT aims at facilitating national and international transactions between businesses and administrative organizations. To this extent, UN/CEFACT works on the simplification and harmonization of processes, procedures and information flows.

UN/CEFACT publishes a set of recommendations that guide the definition and implementation of trade documents and procedures. Some of the most import recommendations present a specific set of code lists that can be globally used. Codelists are language independent and proposes a uniform representation. They have been widely used in various paper-based and electronic applications

4.4.3.1.1 Core Component Technical Specification (CCTS)

The Core Component Technical Specification defines a meta-model and rules necessary for describing the structure and contents of the conceptual and logical data models and information exchange models [56]. It supports the creation or restructuring of business specifications in order to promote semantic interoperability.

UN/CEFACT has developed a library of CCTS core components covering the international supply chain (B2B, B2G and G2G) and this library is maintained and published by UN/CEFACT. It is called the UN/CEFACT Core Component Library (CCL) and it is available from the UN/CEFACT website free of charge.

4.4.3.2 UNECE - United Nations Economic Commission for Europe

4.4.3.2.1 United Nations Layout Key - UNLK (ISO 6422)

The UNLK standard is the lead standard for trade documents simplification and it is considered as a precondition towards establishment of the electronic document despite the fact that it was introduced to design the paper-based documents. It was developed by the UNECE in the 1960s and published jointly with the UNECE as Recommendation No1 in 1973 and in 1981 [57].

The UNLK provides an international model form, the Master Form, for designing a trade document in terms of content and layout. It defines a master layout design from which other trade documents can be derived. UNLK incorporates agreed specifications on paper size, margins, sheet for design of a form and presentation of data. It also guides to use the same data and information in the same place and the usage of same format regardless of the paper’s size. Besides the rules for the physical document layout, UNLK also provides a semantic description to its data through UNTDED-ISO 7372 and rules for the modification of the standard layout key.

Furthermore, UNLK is based on a hierarchical system of design which distinct over the international standard forms and national standard forms as depicted in Figure 4-5. In terms of the standard or prescribed form, the exact layout and data elements depend on international agreements or conventions which provide a little or no possibility for deviation.


Page | 61

Figure 4-5: UNLK Hierarchical System

The following terms is used to describe the hierarchical UNLK system.

International Sector Layout Key: optional intergovernmental or non-governmental standards

which serve as a basis layout common to special application or sector that can be extended.

International Standard Form: internationally established forms which are most of the times

mandatory and do not allow for deviations in design.

National Layout Key: national recommended standards which direct the layout of any further

nationally required data elements with a view to establish national aligned series of trade

element.

National Masters: nationally recommended standards which take into account relevant

specialized and sectorial layout data elements. They serve as a basis for aligned series of

trade documents.

National Standard Form: nationally standardized forms which are adapted to the needs of a

country, which are based on both national layout keys/masters.

Company masters and forms: Masters established by individual companies using the one-

run methods for completion of trade documents.

Several international sectorial documents are based on the UNLK [58]. For example the regulatory document such as the Single Administrative Document (SAD, EU), Certificate of Origin (WCO Kyoto Convention), Dangerous Goods Declaration (UNECE), Dispatch Note for Post parcels (World Post Convention) and so on. Also the following transport documents are based on the UNLK: Standard Bill of Lading (International Chamber of Shipping), Universal Air Waybill (IATA), the IMO Standardized Forms (FAL 1-7), etc.

UNLK must be considered as an intelligent integrated set of international standards (UN/CEFACT, ISO) that are the foundation for the flow of information in trade transactions. These standards are: the ISO Country Code: Code for Representation of Names of Countries: (Recommendation 3, ISO 3166); the United Nations Code for Trade and Transport Locations (UN/LOCODE, Recommendation 16); Facilitation Measures related to International Trade Procedures (Recommendation 18); UN/CEFACT Recommendation no. 3 - use of ISO Country Codes in documents; UN/CEFACT Recommendation no. 5 – use of INCOTERMS; UN/CEFACT Recommendation no. 7 – use of numerical representation of dates and time; UN/CEFACT Recommendation no. 9 – use of alphabetic


Page | 62

Code for Currencies; UN/CEFACT Recommendation no. 16 – use of codes for ports and other locations; UN/CEFACT Recommendation no. 19 – use of codes for modes of transport; UN/CEFACT Recommendation no. 20 – use of codes for unit of measures.

The UNLK defines the following forms categories (form families):

1. Trade Documents – Quotation, Order, Invoice etc.

2. Materials Management Documents – Despatch Advice, Pick List, Packing List etc.

3. Transport Documents – Bill of Lading, Shipping Instructions etc

4. Customs and OGA Documents – Export, Import, Transit Declarations, Cargo Reports etc.

5. Other Regulatory Documents – Cert of Origin, DGN etc.

4.4.3.2.2 UNeDocs

UNeDocs is a UNECE project initiated at 2000 with the aim at analyzing the documentary issues of the supply chain [12]. UNeDocs has developed a framework for digital paper for trade. UNeDocs vision is to harmonize and standardize international (cross-border) trade related data through the definition of a cross domain data model using the standards of UN/CEFACT. So, UNeDocs focuses on the alignment of data across Cross-Border Trade, Transport, International Payments, Customs and other regulatory documents. UNeDocs supports:

The harmonization of national data requirements

The development of electronic equivalents of paper documents (paperless trade)

Cross-border data exchange.

To this extent, UNeDocs delivers UN/CEFACT Data Models, Core Documents and methodologies. UNeDocs enforces a single data modeling approach for electronic documents, which are equivalent to paper documents, for structured electronic documents (UN/EDIFACT, Cargoimp, XML) and for process driven messages (Figure 4-6). UNeDocs data model is a superset of data elements used within the international purchase and supply chain, thus any user requirement can be easily tailored and remain aligned.

UNeDocs is based on the concept of the master document and so, it provides a generic Master Data model for the master document. Every specific document data model (such as Invoice or Goods Processing) is a simplification of this Master Document Data Model and so, each trade document will be derived from this Master Document. A Master Document ensures that all the data will be submitted through a single submission.

UNeDocs aims to facilitate international trade by providing a migration path towards paperless trade. The UNeDocs Core Component Data Model is mapped to the UNTDED and provides implementation standards including EDIFACT, XML and aligned paper document layouts. This means that the data model allows users to produce documents in paper, EDI or XML format.


Page | 63

Figure 4-6: UNeDocs Data Model [59]

For each document structure, the following are provided:

Approved, existing, new or customized Document Structures (message assembly) (a class

diagram and a document structure)

UN Layout Key Document & Box Completion Guidelines

Approved existing, new or customized XML Schema

UN/EDIFACT message implementation guide

Other syntax mapping (where required), e.g., CARGOIMP message types or X12 etc. (EDI);

RosettaNet, GS1, CIDX/

The UNeDocs fits into the Buy-Ship-Pay process which is the proposed International Trade Reference Model. As a result, the scope of the data elements introduced by UNeDocs is a superset of data elements used within the international purchase and supply chain. UNeDocs have been employed to the following Single Windows: Thailand, Malaysia, UK, Asean. For example, UNeDocsUK is a national implementation of the Buy-Ship-Pay Data Model and based on the 18 documents it delivers: UN Layout Key aligned paper documents, Box Completion Guidelines, EDI Message Implementation Guidelines, and XML Implementation Guidelines (including schemas).

UNeDocs is based on an existing set of standards which are; UNCEFACT Trade Reference Model for the International Purchase and Supply Chain (TBG14); UNCEFACT Unified Modelling Methodology - UMM (TMG/BP); UNCEFACT Core Components Technical Specification - CCTS (TMG/CC); UNCEFACT Core Component Library (TBG17); United Nations Trade Data Elements Directory (UNTDED); UNCEFACT XML Naming and Design Rules (ATG2); UNCEFACT UN/EDIFACT Directory (ATG1); United Nations Layout Key (UNLK) – UN/ECE Rec. 1

It is predicated that UNeDocs will deliver the electronic successor of the paper-based UN Layout Key while next versions of UNeDocs will accommodate data requirements from Customs and OGA.


Page | 64

4.4.3.3 World Customs Organization Data Model

4.4.3.3.1 WCO Data Model

The WCO introduces the WCO Data Model (DM) in order to standardize and simplify data requirements of the Customs and related government agencies. The WCO Data Model does not capture any national data requirements and contains a set of information (data elements) that is standardized, based on globally accepted norms. The Data Model has been developed for the specific requirements of Customs and until now it covers B2G and G2G message exchanges in terms of data submitted by traders and transporters for clearing goods across borders. The WCO Data Model is the outcome of the data harmonization process regarding cross-border regulation. It is based on the Revised Kyoto Convention which requires customs administration to request minimal data to ensure compliance with customs laws. Furthermore, it is built on top of the following recommendations and ISO standards: No3, No5, No9, No16, No17, No19, No20, No21, ISO 3166 (Country code), Currency code (ISO 4217), Dates, times, periods of time (ISO 8601), Trade Data Elements (UNTDED - ISO 7372).

WCO has been working heavily on the concept of Single Window and they have developed harmonization guidelines to enable developers to achieve data harmonization through the definition of internationally standardized data sets. These profiles are forms, templates or other regulatory documents that are produced automatically by the system. That’s why the recommendation of using the WCO Data Model is to create profiles based on the national needs, laws and regulations. The contribution of the WCO Data Model to the Single Window concept is two-fold: it contributes to the “Harmonized eForms/Electronic Messages” and to the “Common Data Model”.

The third version (v3.3) of the WCO Data Model incorporates the Single Window concept and the whole-of-government cross-border regulatory approach and so it defines a set of data and data structures including requirements for cross-border regulatory agencies controlling import, export and transit.

Figure 4-7: WCO Data Model Components [11]

The WCO Data Model consists of several components as depicted in figure Figure 4-7. The data dictionary is organized as the data set for Export, Import, Transit, Conveyance and Response. The WCO Data Model also contains several use-case diagrams and activity diagrams as illustrative examples of the customs business processes. UML class diagrams have been defined to define the information flows from the authorities/agencies. All these models can be used as reference models


Page | 65

during the development of the automated systems. Finally the WCO Data Model contains standardized electronic messages along with detailed implementation guidelines and other supporting documentation.

The WCO Data Model encompasses the WCO SAFE Framework of Standards (SAFE FOS) and to this extent, it contains the data structures enabling the advance electronic reporting under SAFE FOS. Furthermore, the WCO DM takes into account the requirements of the International Maritime Organization (IMO FAL), (Safety of Life at Sea) SOLAS Conventions, and the International Ship and Port Facility Security Code (ISPS Code) concerning the cargo and security reporting obligations. Also, it covers the International Civil Aviation Organization (ICAO) for airline declarations. Except from the support of other specifications, the WCO Data Model recommends the use of several international conventions such as: HS Convention for the Harmonized Commodity Description, the TIR Convention for the transport of goods in road vehicles, including containerized cargo that moves across one or more frontiers. Also, Data Model v3.3 includes the mapping between WCO DM’s CITES permits definition in the Single Window Environment and the e-permitting subset of the GOVCBR UN/EDIFACT message.

The most prominent outcome of the WCO Data Model is that it offers a common platform for regulatory data across government agencies enabling their systems to exchange information. It enables the single submission of data to the authorities (message GOVCBR) which can be used later for the risk analysis procedures. The idea behind the creation of the message GOVCBR was to allow the single submission of data or one piece of information to be submitted only once to the cross-border regulatory agencies. To achieve this, GOVCBR message structure provides the same underlying structure to be used by cross border government agencies at different stages of cross-border trade & transport flows. In other words, GOVCBR allows different cross-border regulatory agencies to work with the same superset of information that GOVCBR offers and also allows them to create and specify electronic messages from the same structure.

4.4.3.3.2 WCO SAFE Framework

The SAFE Framework, which is also known as the Framework of Standards to Secure and Facilitate Global Trade, aims at enforcing security in the international trade. It is a set of voluntary standards covering all areas of Customs Control [60]. The SAFE is based on advanced electronic cargo information.

The SAFE Framework is organized into two pillars; the first pillar deals with the customs-to-customs network arrangement and the second pillar focuses on the customs-to-business partnership. The first pillar denotes that global trade requires a global network to maximize the security and facilitation of the supply chains.

The core elements of the SAFE Framework are the following:

Harmonize advanced electronic cargo information requirements on import, export and transit

declarations;

Common Risk management approach for screen containerized cargo to identify potential

security threats

Inspection of high-risk cargo at port of departure

Establishment of AEO status and AEO processes (identify secure business partners).

The key concept within the SAFE Framework is the Authorized Economic Operator (AEO) which is the essence of the customs-to-business relationships. AEOs usually participate in simplified and rapid release procedures on the provision of minimum information. A trader can be granted an AEO status if he can prove that he has high quality internal services. WCO published guidelines to enable the AEO support [61].


Page | 66

The SAFE Framework established the following eleven (11) standards: Advance Electronic Information (to identify high-risk shipments); Common targeting criteria and compatible communication; Risk management systems; Outbound Security inspections at request of counterpart; Modern inspection equipment; Employee Integrity; Cargo Inspection Authority; Integrated Supply Chain Management; High-Risk Cargo / container; Performance measures (steering instrument) and Security assessments.

The SAFE Framework is cited in the US security regulation and to the new EU Customs legislation.

4.4.3.4 UNTDED – ISO 7372 – United Nations Trade Data Elements Directory

The United Nations Trade Data Elements Directory (UNTDED) offers a standard list for trade elements which can be used for data exchange in international trade. UNTDED version 2005 is another joint standard with ISO which is known as the official ISO Standard ISO 7372 [10]. The UNTDED ISO 7372 provides the semantic information of the data used by the UNLK. To this extent, it provides a dictionary of all the UNLK “headings” that fill the UNLK’s boxes of a form and offers an international accepted start repository for the semantic of trade data elements used in the international trade. Also, UNTED is considered an integral part of all the standards defined for the electronic trade documents such as UN/CEFACT Core Component Library (CCL) and UN/EDIFACT.

For the definition of a UNTDED element, the following elements are defined: a data element identifier in the form of a four-digit number, a data element name and a description with the definition of the data element to aid for the data-value that must provide for this element, and finally, a specification of the character representation of the data-value, with indication of space (in number of characters) available and location in aligned forms, and of field lengths where such have been established in particular interchange protocols.

UNTDED provides an internationally accepted standard repository for the semantic of trade data elements used in international trade. UNTDED definitions describe information from the point of view of a business expert, such as a trader or a Government official. The definition data in an aligned form using the UNTDED provides a very useful basis for developing electronic specifications of this information in a later step.

4.4.3.5 GS1

GS1 is a not-for-profit organization dealing with the development of global standards and specifications for the management of the supply chain across sectors [62]. The suite of standards proposed by GS1 covers aspects such as identification, capturing and sharing of information.

In particular, GS1 proposes the following GS1 Identification Keys:

Barcodes: enables the electronic reading from business processes and a barcode is a

number used to identify goods, services, assets and locations worldwide.

eCom: focus on the provision of standardized and predictable structure of the electronic

business messages (XML Standards, EANCOM standard and eCOM message transport

protocols).

GINC: it stands for Global Identification Number for Consignment.

GLN: it stands for the Global Location Number. GLN is used to identify a location. Locations

in GLN refer to physical locations (e.g., warehouse) or to a legal entity (e.g., company,

customer, a function which takes place within a legal entity. The GLN is used for electronic


Page | 67

messaging between customers and suppliers and it can be used in conjunction with a bar

code or GS1 EPC tag.

GTIN: it stands for the Global Trade Item Number. The GTIN is used as an identifier for

trade items.

GDSN: it stands for Global Data Synchronization Network. The GDSN is supported by the

GLN and the Global Trade Item Number (GTIN) and it depends on the concept of

interoperable data pools for the exchange of supply chain information in a standardized

fomr

GSIN: it stands for Global Shipment Identification Number.

GEPIR: it stands for Global Electronic Party Information Register.

SSCC: it stands for the Serial Shipping Container Code.

GS1 EPCGlobal: global standards for RFID object tags

4.4.3.6 E-Freight Ontology

The e-Freight is a research and development project co-funded by the European Commission under the 7th Framework Programme, with the aim at providing IT Capabilities supporting EU freight transport stakeholders through the provision of an e-Freight Platform which supports the design, development, deployment and maintenance of the e-Freight Solutions. The goal is to enable different transport stakeholders to establish efficiently e-Freight compliant solutions running in their own operating environments.

More specifically the e-Freight platform aims to facilitate improved interoperability between freight transport applications through standardization of freight transport models, (Web) services and a

domain specific ontology. The domain specific ontology will serve as a common language and it captures the freight domain concepts while making the e-Freight knowledge independent from architectures and specific software solutions.

The e-Freight ontology has been derived based on the following data models: European and national regulations and directives, WCO Customs Data Model (incl. Single Administrative Document- SAD), EMSA SafeSeaNet (IMO FAL Forms and Ballast Waste and Security), Transport documents, Waybills and Bills of Landing (incl. CMR, CIM, FIATA), GS1 BMS, OASIS UBL 2.0 (including UN/CEFACT Core Components and FREIGHTWISE Models) [63].

4.4.3.7 Towards Semantic Interoperability in CASSANDRA Global Virtual Pipeline

The CASSANDRA’s success depends not only on the process integration of systems but also on the semantic interoperability. Semantic interoperability is crucial as data will be fetched by different heterogeneous IT systems where the semantics and structure of data will differ. Thus, it is essential to transform all this data according to a common/shared data model and vice versa. The data harmonization process will provide us with the basics of achieving this common data model.

As we have presented in this section, there are several international standards proposed in order to define documents requirements as well as electronic document representations and data models that are used for specifying the messages’ structures. These standards aims at providing a common consensus towards all the data and information that are needed during the international trade.

The CASSANDRA project carries out the data harmonization activity in order to specify a CASSANDRA Ontology which will provide the common data model. The outcome of this activity will take into consideration the standards that we have presented in this section.


Page | 68

4.4.4 Service-Oriented Architecture (SOA)

Service-oriented architecture (a.k.a. SOA) is an architecture style for designing software systems. SOA depends on the notion of service which refers to an autonomous loosely coupled unit of functionality defined based on standardized interface. SOA is more a client/server design paradigm where a service is published in order to be invoked by several service consumers (or service requesters). SOA has been proposed in order to solve the interoperability issues rising from the heterogeneous network protocols, hardware platforms, operating systems or application formats and so on.

Thus, SOA does not define the API for the service but rather a service is defined through its interface, its contract and its actual implementation (business logic). The service contract describes the message types, constraints and descriptions, while the service interface describes the set of operations offered by the service and it is considered as platform-independent. The service interface can be published and discovered by the service consumers. The ability to invoke a service over network dynamically through its interface allows a service to be reused by various applications and in different context. This implies the services can be composed by various services.

The success of the CASSANRA Global Virtual Pipeline is based on the capability to support the integration of the established systems and their ability to interoperate. To this extent, SOA can serve as the architectural style and thus CASSANDRA pipeline will adopt the SOA principles. SOA enables the integration of disparate systems and their applications through the definition of interfaces which serve as wrappers to existing functionality. SOA will provide us with scalable and maintainable architecture allowing the integration of the disparate systems. Integration of system is feasible through the provision of the standard connections. Furthermore, SOA allows IT systems to adapt easily in order to support new needs and therefore is allows the reuse of the existing systems.

4.4.5 Security Aspects

A big challenge towards adoption of a global virtual pipeline system which envisions the interconnection of IT systems throughout the world is the ability to protect unlawful and/or unauthorized access to data and services. There are several security issues that must be managed and dealt with in order to establish and enforce a secure global pipeline. Thus, the security requirements of the CASSANDRA Global Virtual Pipeline are:

Confidentiality: it must assure that the access to the information is restricted to only the

authorized services/users.

Integrity: it must assure that data cannot be modified once they are shared or captured by

partners

Authorization/Authentication: it must assure the identity of a user and it must ensure that the

user has the right privileges to use a service or to view its data.

Message transmission: it must assure that messages are traceable and that their delivery is

guaranteed.

The security issues in CASSANDRA pipeline spans to data transfer security, application security and document security. Sufficient emphasis needs to be put on implementing technical features that address the relevant security issues. The above requirements must be handled properly through the enforcement of suitable security services such as the ones presented in Section 5.1.4. Except from the security services that the pipeline will offer, other security issues such as document security (data authenticity and data protection) must be handled. Although security aspect is the research subject of another WP’s deliverable within the CASSANDRA project, the following section provides an overview and considerations over the data protection and access issues within the CASSANDRA Pipeline.


Page | 69

4.4.5.1 Data Protection and Access

The data exposed or transferred through the pipeline may contain supply chain data, trade-sensitive data, confidential business information and possibly information related to security. Also, they may refer to trade information about traders and companies or private data for banks, insurers and other parties. Data protection refers to the enablement of the proper mechanism to ensure the access, integrity and accuracy of transferred/captured data. Thus, data protection is main business requirement of the CASSANDRA Pipeline which must ensure the proper facilitation of security and protocol accesses, and the enforcement of mechanisms such as identification, authorization and authentication are crucial.

The goal of the CASSANDRA Virtual Pipeline is to collect and use upstream data (and not only) for legislative purposes and it must protect this data from misuse while respecting certain rights.

There are several aspects of data protection that should be considered such as the identification of data that must secure and the security measures to be implemented or adopted to protect the data and information. In order to cope with these issues, it is mandatory to establish secure authentication protocols which will restrict access to personal and confidential information to those who need such access to the pipeline. Furthermore, monitoring solutions should be applied in order to allow audit trail through monitoring of these systems for unauthorized use or access and ensure that users do not perform illegal actions regarding data.

All the above issues emphasize on the privacy of data (protection of personal data, proprietary company data and confidential trade data). So, the processing of these data must be in compliance with the international trade data protection laws. Such data privacy and trade confidentiality laws have been established by the EU [64]and APEC [65].

Another issue important to the CASSANDRA Pipeline is the access rights to these data. Privacy or confidentiality laws in some countries prohibit the sharing of certain types of information between government organizations except when permitted by the law. Probably, such information exchanges should be established by national laws. National legislations should ensure that the collection and/or transmission of data must be treated with confidentiality and must be sufficiently protected, while granting certain right to natural or legal persons to whom the information pertains. Thus, user rights should be assigned on case-to-case basis and each user type has different rights to either add or review data placed into the SW system. For example, users will have the right to access information regarding their activities and responsibilities and also any data made available to the public within the system.

4.5 Benefits of CASSANDRA Global Virtual Pipeline

This section describes the benefits that business traders and government authorities can gain through the adoption of the CASSANDRA proposed solutions.

4.5.1 Benefits for Businesses

The CASSANDRA Global Virtual Pipeline will offer many benefits to businesses. The following list summarizes the major benefits of adopting the CASSANDRA Global Virtual Pipeline.

Improved working capital (reduce stocks throughout the supply chain, improved cash flows)

Increase product integrity and monitoring of quality

Monitoring of legal compliance

Better weight control

Improved efficiency of Customs process, possibilities for pre-clearance and green lanes

Improved agility to respond to disruptions during transport

Administrative benefits

Improved planning


Page | 70

Reduction of waiting times

Improved usage of transport capacity (more trips, higher degree of loading)

Improved usage of equipment and stacking capacity

If the CASSANDRA Pipeline functions as a focal point for the access to updated information on current trade rules, regulations and compliance requirements, it will lower the administrative costs of trade transactions and encourage greater trader compliance. As the CASSANDRA Pipeline enables government authorities to have access to supply chain (upstream) data, it allows them to better align their control procedures, which eventually lead to faster clearance and release times speeding up the supply chain.

In addition, the improved transparency and increased predictability can further reduce the potential for corrupt behaviour from both the public and private sector.

4.5.2 Benefits for Government Authorities

Governments and trade have established an extensive range of agency-specific and country specific regulatory and operational requirements for international trade with little coordination amongst each other, either at the national or international level. As a result, traders are faced with a set of duplicative and redundant reporting requirements, forms, systems, data sets, data models, and messages. Governments and trade have had to develop and maintain different systems to meet these redundant and duplicative requirements. This adds enormous costs to all parties, in terms of fiscal resources, timeliness and accuracy of data. This lack of coordination has become a more prominent issue in recent years with the requirements for faster information delivery, often in advance of shipping, for security and other purposes, and the expanding requirements of data standardization in international supply chains. The ability to handle data efficiently and swiftly has become a key element in international competitiveness, especially in international supply chains.

The International Trade Single Window has been proposed in order to overcome this complex system of data submission and regulatory control. Single Window solutions offer the possibility of creating seamless, electronic processes between trade and Government but also between the relevant government agencies. This facilitates submission of information for various purposes and ensures harmonization and transparency, i.e. the creation of a level playing field with the greatest predictability possible. Furthermore, electronic processes must be considered more secure, from both the perspective of an economic operator and from governmental level, since integrity and harmonization is then improved. For example, the use of ICT results in less opportunity for individual officers to infringe the process of decision making in various situations.

The adoption of the CASSANDRA Global Virtual Pipeline and the CASSANDRA Single Pipeline Access Point (SPAP) can offer many benefits to the government authorities. A seamless integrated pipeline enables the application of piggybacking principle by Government Authorities through the access of supply chain data via the SPAP. Such an approach will lead to increased efficiency. A pipeline concept, the next generation Single Window based on a total trade transaction model would commence receiving data about an impending transaction at the earliest possible time, any amendments to the data would only need be updated in one place, agencies that have the legal right to receive and/or view the data could do so, data inconsistencies and human re-keying errors would be reduced, whole of government risk assessments could be undertaken, the progress of the transaction could be fully monitored with a single point of response for the trader resulting in faster release and clearance.

A transaction history would also be maintained for reuse and statistical purposes. The effort in dealing with government agencies would be reduced and in some cases this reduction would be significant.

International data exchanges further enhance the single window’s capabilities and benefits.


Page | 71

Another benefit is the stability a standard data set provides. The intent is to deliver the known maximum set of data that a trader may have to provide. Governments should not require any information outside of the standard data set. It is important to note that most of the data is conditional based on mode of transport, type of transaction, commodity and country of origin/dissemination. Traders will never be required to submit the entire data set. This provides a stable base for Single Window investment.

These advantages also apply to traders and service providers. They can increase the quality of data provided to the Customs authorities and to their customers. Obstacles in trade are reduced and they can focus on the core business.


Page | 72

5 CASSANDRA Global Virtual Pipeline Architecture

The CASSANDRA Global Virtual Pipeline and the CASSANDRA Single Pipeline Access Point is a collection of value-added services offered to the participants of the supply chain. It should be mentioned that the supply chain process includes various supply chain actors with different needs. As a result, there are different kinds of services that the pipeline has to offer in order to satisfy the needs of all the participants. For this reason, the active participation of the supply chain stakeholders is mandatory during the designing process. The services to be offered should cover the stakeholder’s needs.

5.1 CASSANDRA Pipeline Configuration

As we have already stated, the CASSANDRA Global Virtual Pipeline Configuration is designed by adopting the SOA principles in order to provide a decentralized system that components and functionalities will be offered (published) as business services. The key design point of the CASSANDRA Pipeline is to avoid point-to-point communication between the IT systems but to enable integration of the all the business systems into the pipeline.

The aim of the CASSANDRA pipeline is to decouple different applications from any communication or knowledge requirements regarding the other systems except this of the CASSANDRA Pipeline. The contract between a system and the pipeline is the ‘canonical’ message format. The term ‘canonical’ message format is used to refer to a consistent data format, based on the consolidated data model derived from the data harmonization process, with which the systems integrated to the pipeline can communicate with each other.

This section presents the services that compose the CASSANDRA Pipeline including the UI services, business services, security services, data services and the various registries that are needed to support the underlying services.


Page | 73

Figure 5-1: CASSANDRA Global Virtual Pipeline Architecture


Page | 74

5.1.1 CASSANDRA Interfaces

The CASSANDRA project proposes a set of interfaces to be offered to the CASSANDRA participants and that the CASSANDRA Backbone will support. These interfaces are:

Data capture: refers to the sharing of data between government authorities and supply chain

partners.

Data sharing: refers to the sharing of data between the supply chain partners (business

actor) during the regular business transactions.

Logistics services: refers to the business activities provided or required by a business actor.

Configuration and Management: refers to a set of supporting services (e.g., IT security

service) that enable the interconnection of the business actors.

These four interfaces provide the interfacing architecture of the CASSANDRA Global Virtual Pipeline. In the context of this document, only the ‘Data Capture’ and ‘Configuration and Management’ are concerned. Particularly, the proposed CASSANDRA Single Pipeline Access Point (SPAP), which connects government authorities with the traders through the virtual pipeline, utilizes the data capture interface.

5.1.2 Single Pipeline Access Point (SPAP)

The Single Pipeline Access Point (SPAP) is actually the interface of the National Single Windows and the government authorities to the virtual pipeline. Therefore, SPAP integrates the two concepts and so it serves as the single point (access) of the government authorities. In addition, SPAP could offer UI services to authenticated and authorised Officers in order to submit queries and capture data from pipeline through the data capture interface.

5.1.2.1 Pre-defined Queries Repository

The data capture interface allows government authorities and their IT systems to communicate with the CASSANDRA Hubs in order to retrieve the data from the supply chain. To achieve this interaction, the CASSANDRA Virtual Pipeline will allow users to submit their queries by filling in the query parameters of predefined queries.

Thus the pre-defined Queries Repository is a repository that the predefined queries are stored. These predefined queries are corresponding to processes which are executed by the process engine in order to retrieve the results of the request. When a query is requested and depending on the complexity of the query, a number of activities/tasks with specific sequence should be performed and this should be orchestrated according to the defined process for this query. The activities/tasks might involve interaction with hubs or invocation of internal processing services (e.g. data fusion).

Also, the repository contains the query definitions which are metadata which define query’s parameters such as resulting document type, list of query’s definitions etc.

A service-based interface is provided which retrieves a query and its query definitions in order to fill up the correct query parameters.

5.1.3 Service Process Engine

This is the process execution engine which has the responsibility to execute the process corresponding to a particular predefined query. It acts as the mediation between the CASSANDRA Hubs and the government authority (user or IT system) that requests data capturing. The process engine is responsible for the coordination of services of the process corresponding to the predefined queries and to provide compensation services as well as tracking these services. Furthermore, the process engine supports processes which can be triggered by external events or are triggered periodically. The process engine’s functionality will be implemented as an orchestration model in order to support the queries. Example of such a process will be presented in Section 5.2.


Page | 75

5.1.4 Security Services

The security services addresses the security aspects and challenges of the SOA application systems. The security services aim to provide a basis for interoperability among multiple services and data within the heterogeneous partners’ environment. The security services are applied at both the infrastructure-layer as well as at the application-level.

Thus, security at the CASSANDRA pipeline will involve authentication and authorization mechanisms, as well as message confidentiality and integrity. Authentication service will enforce the identity check of all the service consumers, while authorization service will grant the access right to resources. All messages should be protected.

Under this category of services, there are several security tools that are offered either as atomic or as composite services. Examples of atomic security services are encryption, signature and time-stamp services. Other complex services such as authentication depend on these atomic services. Thus, XML Encryption, SAML (enables exchange of security information between security domains), XACML (for authorization) and XML-Signature as well as the WS-* standards from the Web services stack will be adopted for the Web services, such as WS-Security, WS-Policy (non-repudiation, security compliance), WS-SecurityPolicy (authentication, security assertions embedded into WS-Policy), WS-Reliable Messaging, WS-Trust, etc.

Furthermore, a compliance service can be used to verify the inbound/outbound messages with the security policy required by the target service endpoint (e.g., type of tokens, encryption and signature algorithms). For example, policies are defined based on the WS-Policy [66]. To this extent, the Security Services will retrieve the security policy from the policy repository. The security requirements will be retrieved from this policy and invokes other security services that are needed in order to fulfil the security requirements. Except from the Policy Registry, there may be a PKI repository that holds keys and certificates.

Other security services can be the auditing service as we will discuss in Section 5.1.8.

Finally, it is worth noting that the various security standards to be adopted for the security services should be analysed and defined at the time of implementation.

5.1.5 User Management

The User Management service is a SOA component service and it is used to provide user management functions. The user management service can be configured to authenticate users. In addition, the User Management service can enable the authorisation level of each user. For instance, users might have different authorisations per query type.

5.1.6 Data Services

The data services are supported services of the CASSANDRA pipeline and can be invoked for compliance reasons such as for performing message validation. To this extent, a validation service will be offered to the CASSANDRA Hubs is order to be invoked by the latter either independently or incorporated in their business process in order to validate messages against the common shared data model of the CASSANDRA ontology.

5.1.7 Service Manager and Service Registry

The CASSANDRA Service Registry is used to store the services published by the CASSANDRA Hubs and provides facilities to publish and discover services. The Service Manager is responsible for retrieving the right services from the repository as well as any metadata. The services were published by the CASSANDRA Hubs.


Page | 76

5.1.8 Monitoring & Logging

The services under the monitoring and logging umbrella allows for monitoring all business events as well as events produces by the various components within the data pipeline in order to use these data for auditing purposes as well as for dispute purposes.

5.1.9 Profile Management

The Profile Management services allows for the registration of business profiles. This registry will serve the logistics and data sharing services which however is out of the scope of the current deliverable.

5.1.10 CASSANDRA Adapter and CASSANDRA External Adapter

The CASSANDRA Adapter and the CASSANDRA External Adapter are utilized in order to perform any data and protocol conversion that may be required. The CASSANDRA Adapter is required for handling the communication with CASSANDRA Hubs according to the interface specifications of CASSANDRA backbone. While a CASSANDRA External Adapter is required per communication with external sources for implementing a specific interface with an external system.

5.1.11 CASSANDRA Hubs

The CASSANDRA Hubs are the nodes that participate in the CASSANDRA Backbone. These CASSANDRA Hubs are considered the data sources of the CASSANDRA Pipeline and corresponds to the IT systems of the participating business entities.

5.1.11.1 CASSANDRA Hub Adapters

The CASSANDRA Hub Adapters are required for interfacing CASSANDRA Hubs with the CASSANDRA Pipeline (via CASSANDRA Adapter). Thus, a CASSANDRA Hub Adapter addresses any message transformation, routing and protocol conversion required for the communication of CASSANDRA Hub with the Pipeline. The CASSANDRA Adapters are considered as part of the data sources’ IT Systems (CASSANDRA Hubs) and this design decision allows the Cassandra system to be quite scalable. Adapter can have more capabilities such as error handling, enforcement of security policies, etc. A CASSANDRA Hub’s transformation process depends on the CASSANDRA Ontology in order to perform any transformations among the data that flow within the pipeline as messages and the data model supported by the CASSANDRA Hub internally.

5.2 Example of Data Capture Business Process Specification

This section presents an example for the data capture interface offered by the CASSANDRA pipeline. The following figures demonstrate the service operations and sequence flow of the various services that all together define the CASSANDRA Pipeline. The business process model is based on the BPMN notation.

The BPMN models are created based on the following conventions:

Human actors are depicted as pools. Communication is depicted with message flows.

Services are also depicted as pools. Communication between services are depicted with

message flow

The Figure 5-2 depicts the data capture interface and the possible sequence of interactions across external as well as internal actors.

The role “Government Authority” and “Cassandra Hub” are considered as external roles of the CASSANDRA pipeline and they are depicted as black boxes, thus no internal process model is depicted. The Government Authority may represent a human or an automated IT system under the government jurisdiction. In any case, the Government Authority initiates the process by sending the appropriate request through, in this case, the user interface of SPAP (role: SPAP). The SPAP, which


Page | 77

corresponds to the Single Pipeline Access Point as described in section 5.1.2, enables the authenticated and authorised user to select a query in order to retrieve data from the pipeline. At this stage, the SPAP accepts the request (query message) and forwards it to the process engine.

The process engine instantiates the corresponding process that handles the specific query type. Below, some activities of the process are described. Upon arrival, the process engine validates the message using the Data Service. If the request is invalid, it returns an error message to SPAP. Otherwise, the process engine communicates with the Service Manager in order to retrieve the service interfaces (and URLs) and construct the topology based on the query. Moreover, the Service Manager applies any policies that may exist for the invocation of a service.

Upon the receipt of the Service Manager’s answer, the process engine queries the CASSANDRA Hubs (reusable process: Process CASSANDRA Hub Data Capture Exchange). The process model of the sub-process is depicted in Figure 5-3 and will be explained later. When all the CASSANDRA Hubs have responded, the process engine invokes the data fusion service (especially when each Hub provides specific data elements of the requested query). When the data fusion service responds, the response is forwarded to the Government Authority via the SPAP user-interface.

The reusable process “Process CASSANDRA Hub Data Capture Exchange”, which is depicted in Figure 5-3, handles the interactions between the process engine and the CASSANDRA Hubs. The Pipeline (process engine) forwards the request to the CASSANDRA Hub. The communication is performed via the adapters. The CASSANDRA Adapter communicates with the CASSANDRA Hub Adapter via the agreed CASSANDRA Interface specifications and based on the exposed CASSANDRA Hub service published in Service Registry. A response it is expected by the CASSANDRA Hub. Although it is considered that it is the responsibility of CASSANDRA Hub to respond based on the agreed specifications, an indicative process is presented for the CASSANDRA Hub Adapter to show some steps that could be performed by this component. The CASSANDRA Hub Adapter validates the message request and upon acceptance, it transforms this according to the data model which is supported by the underlying IT system (the specification schemas could be used for that purpose) and then forwards the message to the system. Upon system’s response, the CASSANDRA Hub Adapter needs to transform the message again back to the CASSANDRA data model and forwards the message to the CASSANDRA Adapter which in turn, forwards the message to the process engine.


Page | 78

Figure 5-2: Process Model of Data Capture (BPMN)


Page | 79

Figure 5-3: Process Model of Hubs Communication (BPMN)


Page | 80

6 Points of concern

This chapter identifies and discusses over a set of legal issues concerning the adoption of the

CASSANDRA Global Virtual Pipeline in the future. Most of these legal issues have already been

reported during the implementation of most of the existing Single Window solutions. Despite these

obstacles, all countries which implemented Single Window, declare that it helped them to facilitate

trading and decrease their functional costs. The benefits and revenues generally outweigh the

establishment/operational costs. This chapter focuses on the legal issues regarding an International

Trade Single Window and more specifically the application of the concept of pipeline and the piggy

backing principle.

While the primary objective is the single submission of data, establishing a pipeline concept, next

generation Single Window necessitates a major rationalization of the current approach and

requirements, and especially the reuse (and elimination of duplication) of existing data wherever

possible. This is an iterative process of regulatory convergence and elimination of unnecessary

procedures along with increased efficiency and visibility in the commercial and logistics processes.

Many regulatory and commercial obstacles hinder the development of the pipeline concept, next

generational single window. Information technology presents an opportunity not a constraint.

Commercial parties and government departments are reluctant to share data or to reveal the extent of

inefficiencies in their internal processes and procedures. Entities are also wary of embracing change

and moving from something they know, albeit inefficient, to something they don’t know.

6.1 Legal Issues

Single window is a structure, which is installed between different organizations in the same or different

countries. These organizations are usually governed by different legal frameworks. As a result, it is

important to have a formal agreement between the parties involved in the creation and operation of

the single window that defines the different roles and responsibilities [67].

The first attempt towards presentation of the legal issues of an International Single Window was

performed by Pugliatti [68]. Pugliatti presented a useful division of the legal frameworks that could be

considered for that purpose. These legal frameworks are the following:

National e-Commerce Legislation: it concerns a framework that governs the business to

government (B2G) and Government to Business (G2B) transactions. It allows all the economic

operators to exchange information in a stable and harmonized environment. Such a national

e-commerce legislation can be based on the UNCITRAL framework, which is the core legal

body of the United Nations system in the field of international trade law .

National Single window Legislation: According to Recommendation 35 [40], it is important

to distinguish between national and regional (or transnational) Single Windows. Where a

national Single Window is established, attention is primarily paid to the legal regime of the

state concerned, including the international agreements binding the state. At this level the

issues of data protection, data quality, liability, user authorization and data sharing among

government authorities are addressed. It is determined which governmental agencies may

request information from and provide data to the Single Window. Governments establish

regulations regarding the use of data, such as retention, confidentiality, redistribution or

sharing. In addition KPIs and SLAs are established between the national participants of the

Single Window.

Cross border Single Window Legislation: The third level is the legal framework for

exchanging information between government agencies across borders. At this level, there are


Page | 81

many agreements signed between countries that arrange the issues that may occur during the

operation of single window.

Additionally, ‘ownership’ and ‘liability’ are legal issues to must be also taken into consideration when establishing the legal framework. Ownership concerns who will be responsible for any infrastructure, availability of CASSANDRA pipelines’ services, administration, and confidentiality of data, etc. The ownership is a very import topic of discussion for the Single Window implementation. An organisation should undertake the role for the operation of Single Window and this ownership. Furthermore, the ‘ownership’ concept should be examined more as it may involve some will claim intellectual rights over the data that flow within the pipeline.

On the other hand, ‘liability’ is related to the legal responsibility of supplied data in the pipeline and consequently in CASSANDRA Global Virtual Pipeline. A main question is whether this data can be used as evidence in any particular jurisdiction, and how liabilities can be enforced [68]. Pugliatti states that “the legal instrument that carries liability and that can be used as evidence is the ‘declaration message’ submitted to an NSW which contains a reference to the data and, unlike the ‘flow-through’ model, no electronic document is being passed from one government agency to another across borders thus mutual recognition of electronic customs declarations is not necessary.” [68, p. 15]

It is apparent that the ‘legal framework’ or ‘convention’, ‘ownership’ and ‘liability’ shall be carefully analysed and defined in the context of implementation of CASSANDRA Global Virtual Pipeline since it is closely related to its successful operation. Also, the business model that is going to be followed for the enactment of the CASSANDRA pipeline must be careful considered as it influence all the above legal issues. It is worth noting that security aspects such confidentiality and privacy of data are also included in this assessment, though they are also discussed in section 4.4.5. Thus, a legal framework is necessary to permit access to data, where such access is authorized by law or regulation, and ensure the integrity of data. Furthermore, it must be assured that there will be no dissemination of trade (business confidential) data across National Single Windows or government authorities. Also, data and privacy laws differ across countries and thus, cross-border legislation is essential in order to establish a common international framework.

6.2 Other concerns

As mentioned in section 2.3.1.1, Stakeholder management and interagency collaboration is a key

activity in Single Window implementation. It is worth noting that implementation of such Single Window

might conclude to some changes or simplifications of supply chain process following business process

analysis. Therefore, a political will is very important. In addition, the roles of stakeholders of Single

Window must be defined and be engaged.

Another important factor for data pipeline and CASSANDRA Global Virtual Pipeline is the consensus

building and networking. It is essential to find suitable ways in which the different interests between

the parties are aligned, and viable business models and institutional arrangements are established

[36]. Trust is very important to be established between the organizations that use Single Window. This

can be achieved by mutual agreements that clearly define the processes that shall be followed. Lack

of trust definitely reduces the effectiveness of Single Window.

The difficulty not only lies in single window legislation, this is just legislation on the use of IT, a

common technical entry point and sharing of data between different agencies.

Much more difficult will be to align the legislation that is behind all obligations to carry out formalities

towards government agencies. Many different legislation applies on cross border traffic of goods, each

holding own procedures, forms and formats i.e. data structures. For a single window that serves trade

to a maximum in reducing legal burdens and documentary obligations, all cross border legislation


Page | 82

must be aligned, no data should be asked double and if possible integrated as much as possible

within one obligation or formality.


Page | 83

7 Conclusions and Future Considerations

International supply chains face nowadays an increasingly competitive environment, with new product safety regulations, and intense border security concerns. The supply chain traders are forced to comply with these requirements, something that requires additional investment both money and time. Consequently, the need for traders to comply with all procedural, regulatory, and documentary requirements rapidly, accurately, while at the same time reduce costs, has a vital importance in order to survive and gain a competitive advantage. On the other hand, the various government authorities, which are involved during the transportation and clearance of goods, have to balance between the limited resources that they own and their resource demanding procedures such as the risk assessment process for security purposes.

Therefore, the CASSANDRA project aims at contributing to both supply chain traders and government authorities by proposing a solution for improving the supply chain visibility and business processes’ efficiency and effectiveness by enabling the access to meaningful and accurate data from supply chain. The CASSANDRA consortium works on establishing the requirements as well as proposing the underlying technology and information gathering mechanisms in order to achieve the objective. Thus, CASSANDRA proposes the CASSANDRA Global Virtual Pipeline and the ‘data-sharing’ concept as the mean for achieving integration of the businesses’ and government’ information systems in a global supply chain which enables the data capturing and sharing among these systems.

To this extent, the goal of this deliverable is to investigate Government systems and National Single Windows could connect with CASSANDRA Global Virtual Pipeline in order to capture from the pipeline data provided by businesses in the context of supply chain visibility. It demonstrates the technical possibility to create a Single Pipeline Access Point (SPAP) for business to government communication for consolidated supply chain data as the basis for their risk analysis. Indicatively, the proposed solution improves the supply chain visibility, enables better risk analysis procedures while speed up the various business processes. The CASSANDRA Global Virtual Pipeline is enabled through the integration of existing information systems and applying the piggybacking principle through data pulling. The government authorities can capture data from the data pipeline while the latter can facilitate traders through their data sharing. Current work on the CASSANDRA Pipeline specification focuses on the data capture interface.

This deliverable presented the conceptual architecture of the proposed ‘Single Pipeline Access Point (SPAP)’ and CASSANDRA Global Virtual pipeline for implementing the data capture interface of CASSANDRA by presenting the services that constitute it. The conceptual architecture adopts the principles of the SOA technological design style in order to allow a scalable and flexible integration platform. Also, this deliverable focused on the different aspects of the integration such as data integration, process integration, protocol integration, and so on. For this reason, it discussed over several integration issues. For example, considering the data integration, CASSANDRA proposed to achieve it through the definition of a global CASSANDRA ontology which will be used during the interactions among systems. Moreover, this ontology would also serve as the basis for any semantic transformation required between the parties. For all the design issues, the CASSANDRA project will apply the international standards proposed by international standardization committees.

The work performed during this deliverable would be extended in the future to add the data sharing interface which will allow traders to interact and conduct business through the CASSANDRA pipeline. Also, the support of the logistics interface would be considered. A simplified version of the proposed concept will be demonstrated through the CASSANDRA Living Labs. For example, the CASSANDRA SPAP is realized by the Customs Dashboards where government authorities can submit a fixed query in order to retrieve data.


Page | 84

8 References

[1] UN/CEFACT, “Recommendation No. 33 Recommendation and Guidelines on establishing a Single Window,” 2005. [Online]. Available: http://www.unece.org/fileadmin/DAM/cefact/recommendations/rec33/rec33_trd352e.pdf.

[2] WCO, “How to Build a Single Window Environment - Volume 2: Professional Practice Guide,” [Online]. Available: http://www.wcoomd.org/en/topics/facilitation/activities-and-programmes/single-window/~/media/861FFA93206B41D8BE754371ADA7A112.ashx. [Accessed 29 May 2013].

[3] WCO, “How to Build a Single Window Environment - Volume 1: The Executive Guide,” [Online]. Available: http://www.wcoomd.org/en/topics/facilitation/activities-and-programmes/single-window/~/media/252D1BF37A814526BF5BFFEAB7F13692.ashx. [Accessed 29 May 2013].

[4] GFPT, “Global Facilitation Partnership for Transport and Trade,” [Online]. Available: http://www.gfptt.org/.

[5] UNECE, “The Single Window Concept ... Enhancing the efficient exchange of information between trade and government,” April 2003. [Online]. Available: http://ec.europa.eu/taxation_customs/resources/documents/customs/policy_issues/e-customs_initiative/ind_projects/swannexv.pdf.

[6] TAXUD, “Electronic Customs Decision,” Taxation and Customs Union, 26 January 2008. [Online]. Available: http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2008:023:0021:0026:EN:PDF.

[7] TAXUD Taxations and Customs Union, “Modernised Customs Code,” 4 June 2008. [Online]. Available: http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2008:145:0001:0064:EN:PDF.

[8] EPCSA, “The role of Port Community Systems in the development of the Single Window,” European Port Community Systems Association EEIG, no. 15, 2011.

[9] AFIT, “ASEAN Single Window,” October 2007. [Online]. Available: http://www.cicc.or.jp/japanese/kouenkai/pdf_ppt/pastfile/h19/afit/presentation_2.pdf.

[10] I. O. f. S. United Stations, “UNTDED 2005 ISO 7372:2055, Vol.1 - Data Elements,” 2005. [Online]. Available: http://www.unece.org/fileadmin/DAM/trade/untdid/UNTDED2005.pdf.

[11] WCO, “WCO Data Model,” [Online]. Available: http://www.wcoomd.org/en/topics/facilitation/resources/~/media/70998C307D3C47C996DB047B664B92AE.ashx.

[12] UNECE, “UNeDocs Overview,” [Online]. Available: http://www.unece.org/fileadmin/DAM/cefact/forum_grps/tbg/tbg2_edocs/docs/tbg2_presentation.pdf.

[13] G. Diepens, M. Dill, B. Nolle, J. Olarenshaw, S. Probert, M. Wicktor, G. Lewis, M. Pikart and T. Butterly, “Single Window Common Standards and Interoperability,” in UN/CEFACT Symposium on Single Window Standards and Interoperability, Geneva, 2006.

[14] CrimsonLogic, “Stakeholder Coordination for Single Window Environment - An integrated Trade Facilitation Strategy for Greece,” 19-20 July 2012. [Online]. Available: https://www.google.gr/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CC4QFjAA&url=http%3A%2F%2Fwww.mindev.gov.gr%2Fwp-content%2Fuploads%2F2012%2F06%2FJonathan-Koh_Stakeholders-Coord-Mechanism1.pptx&ei=5ozSUeHUOeih0QWUyICICg&usg=AFQjCNFx5XPkjpexDmb_.

[15] ESCWA, Key Factors in Establishing Single Windows for Handling Import/Export Procedures and Formalities: Trade Facilitation and the Single Window, New York, United States, 2011.

[16] UNECE, “Single Window Repository,” [Online]. Available: http://www.unece.org/cefact/single_window/welcome.html.

[17] J. K. T. Tsen, “Ten Years of Single Window Impelementation: Lessons Learned for the future,” in Global Trade Facilitation Conference, 2011.

[18] UNESCAP, “Single Window Planning and Implementation Guide,” 2012. [Online]. Available:


Page | 85

http://www.unescap.org/tid/unnext/tools/implement-guide.pdf.

[19] UNECE, “Implement the Single Window Vision – Single Window Evolution and Master Plan-,” Februart 2013. [Online]. Available: http://www.icdt-oic.org/RS_67/Doc/UNECE%20II.pdf.

[20] SKEMA, FP7 Project, “e-Maritime - Inventory of Port Single Windows and Port Community Systems,” [Online]. Available: https://www.google.gr/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCwQFjAA&url=http%3A%2F%2Fwww.efreightproject.eu%2Fknowledge%2FDownloadFile.aspx%3FtableName%3DtblSubjectArticles%26field%3DPDF%2520Filename%26idField%3DsubjectArticleID%26id%3D23.

[21] “EurAsEC, Eurasian Economic Community,” [Online]. Available: http://www.eurasian-ec.com/index.htm.

[22] “Bolero International,” [Online]. Available: http://www.bolero.net/en/home.aspx.

[23] E. van Stijn, T. Phuaphanthong, S. Kerotho, S. Pikart, W. Hofman and Y.-H. Tan, “Single Window Implementation Framework,” 2011. [Online]. Available: http://www.unece.org/fileadmin/DAM/cefact/publica/SWImplementationFramework.pdf.

[24] UNNExt, UNESCAP and UNECE, “Business Process Analysis Guide to Simplify Trade Procedures,” December 2009. [Online]. Available: http://www.unescap.org/tid/publication/tipub2558.pdf.

[25] UNNExt, UNESCAP and UNECE, “Data Harmonization and Modelling Guide for Single Window Environment,” 2012. [Online]. Available: http://www.unescap.org/tid/publication/tipub2619.pdf.

[26] UNECE, “Recommendation No. 34: Data Simplification and Standardization for International Trade first edition, adopted by the UN/CEFACT,” 2010. [Online]. Available: http://www.unece.org/fileadmin/DAM/cefact/recommendations/rec34/ECE_TRADE_400_DataSimplificationand_Rec34E.pdf. [Accessed 29 May 2013].

[27] TOGAF, “TOGAF Architecture Development Method (ADM) Chapter 5,” [Online]. Available: http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap05.html.

[28] E. van Stijn, T. Phuaphanthong, S. Keretho, M. Pikart, W. Hofman and Y.-H. Tan, “An Implementation Framework for e-Solutions for Trade Facilitation,” in Accelarating Global Supply Chains with IT-Innovation, Berlin Heidelberg, Springer-Verlag, 2011.

[29] CBP.gov, “ACE Capabilities,” [Online]. Available: http://www.cbp.gov/xp/cgov/trade/automated/modernization/ace/toolkit/.

[30] ITDS, “Report on Internation Trade Data System,” December 2011. [Online]. Available: http://www.itds.gov/linkhandler/itds/toolbox/library/resource_documents/2011_itds_report.ctt/2011_itds_report.pdf.

[31] Mauritius Network Services, [Online]. Available: http://mns.mu/tradenet-trade-facilitation.php.

[32] ASW, “Technical Guide of Asean Single Window and National Single Windows Implementation,” March 2006. [Online]. Available: http://css.escwa.org.lb/edgd/1476/TechnicalGuideofASEANSW.pdf.

[33] R. Sharma, “Document simplification and international Logistics,” [Online]. Available: http://www.unescap.org/tid/projects/tfsw_sharma.pd.

[34] D. Hesketh, “Weaknesses in the supply chain: who packed the box?,” World Customs Journal, vol. 4, no. 2, pp. 3-20, September 2010.

[35] e-Freight Project, “D3.2 - Reference Solutions for Next Generation National Single Windows,” 20 November 2011. [Online]. Available: http://www.efreightproject.eu/uploadfiles/e-Freight%20D3.2%20Reference%20Solutions%20for%20Next%20Generation%20National%20Single%20Windows.pdf.

[36] E. van Stijn, D. Hesketh, Y.-H. Tan, B. Klievink, S. Overbeek, F. Heijmann, M. Pikart and T. Butterly, “The Data Pipeline,” in Global Trade Facilitation Conference 2011, 2011.

[37] CASSANDRA, “D3.2.2 Interfaces v2,” 2013. [Online]. Available: http://www.cassandra-project.eu/userdata/file/Public%20deliverables/Cassandra%20D3.2.2%20-%20FINAL%20-%20Interfaces%20v2.pdf.


Page | 86

[38] CASSANDRA, FP7 Project, [Online]. Available: http://www.cassandra-project.eu/mainmenu/about-cassandra.html.

[39] CASSANDRA, CASSANDRA Compendium (D1.1), J. Hintsa and K. Uronen, Eds., 2012.

[40] UNECE, “Recommendation No. 35: Establishing a Legal Framework for International Trade Single Window,” December 2010. [Online]. Available: http://www.unece.org/fileadmin/DAM/cefact/recommendations/rec35/Rec35_ECE_TRADE_401_EstablishingLegalFrameworkforSingleWindow_E.pdf.

[41] “TradeXchange,” CrimsonLogic, [Online]. Available: https://www.tradexchange.gov.sg/tradexchange/default.portal.

[42] “GT Nexus Supply Chain Visibility,” GT Nexus, Inc, [Online]. Available: http://www.gtnexus.com/products-solutions/supply-chain-visibility/.

[43] GS1, “EPCIS (EPC Information Services),” 21 September 2007. [Online]. Available: http://www.gs1.org/gsmp/kc/epcglobal/epcis/epcis_1_0_1-standard-20070921.pdf.

[44] GS1, “The GS1 System Architecture,” 23 March 2013. [Online]. Available: http://www.gs1.org/docs/gsmp/architecture/GS1_System_Architecture.pdf.

[45] GS1, “ICOM: An Integrated View on Communicating Business Data,” 05 January 2011. [Online]. Available: http://www.gs1.org/docs/gsmp/architecture/GS1_ICOM.pdf.

[46] I. M. O. IMO, “Guidelines for Setting Up a Single Window System in Maritime Transport,” 9 November 2001. [Online]. Available: http://www.imo.org/blast/blastDataHelper.asp?data_id=30924&filename=36.pdf.

[47] EPCSA, European Port Community Systems Association, “How to develop a Port Community System,” 14 December 2011. [Online]. Available: http://www.epcsa.eu/content/download/123/618/EPCSA%20GUIDE%20web.pdf.

[48] OMG, “Business Process Modeling Notation (BPMN),” [Online]. Available: http://www.omg.org/spec/BPMN/2.0/PDF/.

[49] OMG, “Unified Modeling Language,” [Online]. Available: http://www.omg.org/spec/UML/2.4.1/.

[50] UNECE, “Recommendation 18: Facilitation Measures Related to International Trade Procedures,” [Online]. Available: http://www.unece.org/fileadmin/DAM/cefact/recommendations/rec18/rec18_ecetrd271e.pdf.

[51] TBG14, “Buy-Ship-Pay Modeling Guidelines,” 16 February 2008. [Online]. Available: https://www.google.gr/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&cad=rja&ved=0CEQQFjAC&url=http%3A%2F%2Fwww.uncefactforum.org%2FTBG%2FTBG14%2FTBG14%2520Documents%2FBUY-SHIP-PAY%2520modeling%2520guidlines_V-08b.doc&ei=D3_NUbmdOYnP0QWKnoB4&usg=AFQjCNFQCdVsPmr.

[52] UNECE, “TPWG-TBG14 Security Modeling,” 29-30 September 2003. [Online]. Available: https://www.google.gr/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCwQFjAA&url=http%3A%2F%2Fwww.unece.org%2Ftrade%2Fsecurity_conf03%2Fdocs%2Fsecurity%2520modelling.ppt&ei=Zd_TUeK5MIn6sgbiAg&usg=AFQjCNEcHuN-NdTWy7BcvN4L8u_BTMx3sQ&sig2=iKuabJQ-ExJ.

[53] UN/CEFACT/TBG-Internation Trade Procedures and Business Process Analysis Groups, “Reference Model of the International Supply Chain with special reference to Trade Facilitation and Trade Security,” 12 November 2003. [Online].

[54] UN/CEFACT, “Core Component Technical Specification (CCTS),” [Online]. Available: http://www.unece.org/cefact/codesfortrade/CCTS_index.htm.

[55] G. McLinden, E. Fanta, D. Widdowson and T. Doyle, “Annex 11A Key International instruments for border management modernization,” in Border Management Modernization, World Bank Publication, 2010, p. 390.

[56] UN/CEFACT, “Core Component Technical Specification (CCTS),” 29 September 2009. [Online]. Available: http://www.unece.org/fileadmin/DAM/cefact/codesfortrade/CCTS/CCTS-Version3.pdf.

[57] UNECE, “United Nations Layout Key for Trade Documents,” March 1981. [Online]. Available: http://www.unece.org/fileadmin/DAM/cefact/recommendations/rec01/rec01_ecetrd137.pdf.


Page | 87

[58] UNCTAD, “Technical Note No. 13: Simplification of Trade Documentation using International Standards,” 29 March 2006. [Online]. Available: http://r0.unctad.org/ttl/technical-notes/TN13_Document%20Simplification.pdf.

[59] UN/CEFACT, “UNeDocs Application and Implementation Guide,” [Online]. Available: http://xml.fido.gov/presentations/gefeg2/UNeDocsGuide.pdf.

[60] WCO, “Safe Framework of Standards to Secure and Facilitate Global Trade,” June 2007. [Online]. Available: http://ec.europa.eu/taxation_customs/resources/documents/customs/policy_issues/customs_security/normes_wco_en.pdf.

[61] WCO, “AEO Implementation Guidance,” May 2010. [Online]. Available: http://www.wcoomd.org/en/topics/facilitation/instrument-and-tools/tools/~/media/4448CE5B00DB422FA89A29AA447A4F22.ashx.

[62] “GS1,” [Online]. Available: http://www.gs1.org.

[63] e-Freight Project, “D2.3 - The e-Freight Ontology,” 12 June 2012. [Online]. Available: http://www.efreightproject.eu/uploadfiles/e-Freight%20D2.3%20e-Freight%20Ontology.pdf.

[64] “European Union (EU) Data Protection Act,” [Online]. Available: http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:en:NOT.

[65] APEC, “Privacy Framework,” 2005. [Online]. Available: http://www.apec.org/Groups/Committee-on-Trade-and-Investment/~/media/Files/Groups/ECSG/05_ecsg_privacyframewk.ashx.

[66] W3C, “Web Services Policy (WS-Policy),” 04 September 2007. [Online]. Available: http://www.w3.org/TR/ws-policy/.

[67] B. Schermer, July 2007. [Online]. Available: www.uncitral.org/pdf/english/congress/Schermer.pdf.

[68] L. Pugliatti, “Cloud single window: legal implications of a new model of cross-border single window,” World Customs Journal, vol. 5, no. 2, September 2011.

[69] UN/EDIFACT, “IFTMCS Message Type,” [Online]. Available: http://www.unece.org/trade/untdid/d01a/trmd/iftmcs_c.htm.

[70] B. Rukanova, Z. Baida, J. Liu, E. Van Stijn, Y. Tan, W. Hofman, R. Wigard and F. Van Ipenburg, “Beer Living Lab – Intelligent Data Sharing,” in Accelerating Global Supply Chains with IT Innovation: ITAIDE Tools and Methods, Springer Verlag, 2011, pp. 37-54.


Page | 88

9 Disclaimer and acknowledgement

9.1 Disclaimer

Use of any knowledge, information or data contained in this document shall be at the user's sole risk. Neither the CASSANDRA Consortium nor any of its members, their officers, employees or agents accept shall be liable or responsible, in negligence or otherwise, for any loss, damage or expense whatever sustained by any person as a result of the use, in any manner or form, of any knowledge, information or data contained in this document, or due to any inaccuracy, omission or error therein contained.

The European Commission shall not in any way be liable or responsible for the use of any such knowledge, information or data, or of the consequences thereof.

9.2 Confidentiality

PU = Public

PP = Restricted to other programme participants (including the Commission Services).

RE = Restricted to a group specified by the consortium (including the Commission Services).

CO = Confidential, only for members of the consortium (including the Commission Services).

Confidential:

The document is for use of the GA No. 261795 Contractors within the CASSANDRA Consortium, and

shall not be used or disclosed to third parties without the unanimous agreement within the

CASSANDRA PMC and subsequent EC approval since document classification is part of the EC

Grant Agreement.

Any executive summary specifically intended for publication may however be made known to the

public by the author and/or the Coordinator.

9.3 Acknowledgement

This deliverable results from the CASSANDRA project, which is supported by funding 7th Framework Programme of the European Commission (FP7; SEC-2010.3.2-1) under grant agreement no. 261795. The CASSANDRA project addresses the visibility needs of business and government in the international flow of containerized cargo. It does so by developing a data-sharing concept that allows an extended assessment of risks by both business and government, thereby enabling enhanced supply chain visibility and cost-efficient and effective security enhancement. Ideas and opinions expressed by the [author(s) / reviewer(s) do not necessarily represent those of all partners.