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
WP400
Living Labs
Deliverable No. D4.2
Deliverable Title Cassandra – WP400 – Final report of Living Lab 2
Dissemination level Public
Written By Marcus Engler (ISL) 01-05-2014
Checked by Bram Klievink (TUD) 15-05-2014
Approved by Heather Griffioen-Young / TNO 20-05-2014
Page | 2
Overview of contributors
Below persons, in random order, have contributed to this deliverable or the Living Lab Europe to USA via Bremerhaven in general.
Name Organization
Renate Bartholomäus-Lüthge Senator für Wirtschaft, Arbeit und Häfen
Gunther Klein Datenbank Bremische Häfen
Sebastian Seidel DHL Ocean Secure
Roman Balog Kühne + Nagel
Eric Geerts Descartes
Maddy Duhamel Descartes
Karen van Pelt Descartes
Ziv Baida IBM Netherlands
Panagiotis Loukakos Intrasoft
Huib Aldewereld Delft University of Technology
Bram Klievink Delft University of Technology
Rainer Müller ISL
Page | 3
List of Abbreviations and Definitions
10+2 10 + 2 Regulation by US Authorities
AMS Advanced Manifest System by US Authorities CBP Customs and Border Protection
CSD Container security device CSI Container Security Initiative D&B Dun & Bradstreet
DBH Datenbank Bremische Häfen
DG / DC Dangerous Goods / Dangerous Cargo DHL Deutsche Handels-Logistik
DHS Department of Homeland Security ENS Entry Summary Declaration FCL Full Container Load FF Freight Forwarder
HBH Hanseatisch Bremisches Hafenamt ISF Importer Security Filing
ISPS International Ship and Port Security Code K+N Kühne + Nagel
LCL Less than Container Load
LL Living Lab
PCS Port Community System POD Port of Discharge POL Port of Loading RBA Risk Based Approach SBA Systems Based Approach
SWH /SWAH Senator für Wirtschaft, Arbeit und Häfen US / USA United States of America
Page | 4
Executive Summary
This CASSANDRA LL2 final deliverable contains all information regarding the CASSANDRA Living Lab Europe – USA via Bremerhaven including information from two intermediate reports (CASSANDRA D4.21 and D4.22) about the very same Living Lab handed in during runtime of the Living Lab.
CASSANDRA Living Lab 2 shows in a practical way how to improve security and visibility of transatlantic supply chains embedded in the overall CASSANDRA ideas and structure. The enhanced security concepts combine technological, organisational and operational measures also in line with governmental supply chain security programmes such as AEO or C-TPAT. Mechanical and electronic devices such as HS-Seals, e-Seals or advanced monitoring systems can be used to physically secure container transport whereas associated data may use digital watermarks to verify information sources or encryption methods as protection against manipulation.
The aim of CASSANDRA is to demonstrate methods for enhancing supply chain security beyond state-of-the-art by integrating existing data management systems to create a Data Pipeline and introduce a Risk-Based Approach across entire logistics chains and is totally in-line with the proposed Multilayer Approach. These types of approach have also been advocated in government publications from the beginning of the project such as the Joint Statement on supply-chain security (EU and US, July 2011) and National Strategy for Global Supply Chain Security (US, Jan. 2012).
In General the Living Lab was organized and executed during the runtime of the CASSANDRA project. This living lab is centered around the 6 Use Cases, each representing specific obstacles stakeholders face at daily work. This is derived from the high-tech environment US transports are embedded and the used levels of abstraction to pinpoint single problems.
The used process for the successful LL2 can be summarized as follows: The LL started with discussions among the partners to get a common understanding about the objectives and steps to be taken. This was mainly done in the CASSSANDRA WP3. The first part was to create a white paper to inform parties not involved in the consortium about the project in general and this living lab in particular. These parties (EU and US Authorities, Shippers) were informed, involved and Use Cases showing the current obstacles in US trades created. The Use Cases were then used as the content for demonstration, discussion and evaluation of the LL. All this information was passed to LL2 partners responsible for creating demonstration systems such as the business and the customs dashboard, not as the goal in itself but as a system of systems needed for discussion and evaluation of general CASSANDRA ideas in an environment which is dominated by technical solutions as a proof of security to fight attacks to countries as a whole. These discussions were done when the visualisation systems were in a final stage late in the project.
During runtime 3 reports were created, which were the MS4 report and two LL2 intermediate reports. These two are not part of the initial DoW but were seen to be useful for reporting purposes due to postponement of this report by DoW amendment.
The consortium partners in LL2 are the two freight forwarders Kühne + Nagel from Vienna, Austria (K+N) and Deutsche Handels-Logistik (DHL) from Bonn, Germany. Data is collected in the CASSANDRA backbone hub, processed and visualised in a Business Dashboard by The Descartes Systems Group Inc. (Descartes) from Lier, Belgium. The relevant Port Community System for all Ports in Bremen and Bremerhaven in charge (Bremer Hafentelematik (BHT)) is run by the Datenbank Bremische Häfen (dbh) located in Bremen, Germany. Additional visualization of Customs Data is provided by IBM, NL and Intrasoft, GR. LL2 is organised by the Institute of Shipping Economics and Logistics (ISL), Bremen, Germany with the political and procedural support by the Senator für Wirtschaft, Arbeit und Häfen, (Senator for Economy Labour and Ports), SWH, Bremen, Germany.
Page | 5
Index
1 Introduction ... 7
1.1 Background of the project ... 7
1.2 Objective and scope ... 7
1.3 Stakeholders and their issues ... 7
1.3.1 Authorities ... 7
1.3.2 Private Sector... 8
1.3.3 Participants in US trade ... 8
1.4 Brief reading guide ... 8
2 CASSANDRA concepts put to practice ... 9
2.1 Introduction to the CASSANDRA concepts ... 9
2.1.1 Data Sharing ... 9
2.1.2 Risk Based Assessment ... 9
2.2 Putting the concepts to practice in Living Lab 2 ... 9
2.2.1 Data Sharing ... 9
2.2.2 Risk Based Assessment ...10
2.2.3 Additional data ...10
2.2.4 Container Security Devices ...10
3 Approach/methodology...11
3.1 The Living Labs approach ...11
3.1.1 Preparation ...11
3.1.2 Technical realisation...12
3.1.3 Risk assessment ...12
3.1.4 Pilot and evaluation ...13
3.2 The process followed ...13
3.3 Data Analysis Procedures and creation of a Data Dictionary ...14
3.4 Collection of transport information ...14
3.5 US Customs advanced information ...14
3.6 Authorities involved in LL2 ...15
3.6.1 German Customs ...15
3.6.2 Hanseatisch Bremisches Hafenamt ...15
3.6.3 US Customs Authorities ...15
4 Trade lanes configurations ...16
4.1 Living Lab 2: The Kühne + Nagel trade lane ...16
4.1.1 As-Is situation...16
4.1.2 During pilot phase ...18
Page | 6
4.2 Living Lab 2: The DHL trade lane ...20
4.2.1 As-Is situation...20
4.2.2 During pilot phase ...23
4.2.3 Use by parties and (expected) benefits ...23
4.3 LL2 Trade lanes: common information ...24
4.3.1 Mapping of interactions with government ...24
4.3.2 Demonstration plan ...25
4.3.3 The LL2 Use Cases...26
5 Results and evaluation ...37
5.1 Reflection ...37
5.1.1 Reflection on the process ...37
5.1.2 Reflection on the results ...37
5.2 Use Case results and evaluation ...38
5.2.1 Use Case 1: Early Data Completion Check ...38
5.2.2 Use Case 2: Port Authorities RBA ...38
5.2.3 Use Case 3 and 4: Customs additional data ...38
5.2.4 Use Case 5: Customs system based approach ...39
5.2.5 Use Case 6: Early Events forwarding ...39
5.3 Changes at the trade lane configuration ...39
5.4 The involvement of US Authorities ...40
5.4.1 Involvement of Customs in an earlier project ...40
5.4.2 Involvement of US Customs Authorities ...40
5.5 Workshops with German Customs Authorities ...40
5.6 Further data analysis ...41
Appendix A –Activity Log ...42
Appendix B –Decision Log ...50
Appendix C –The CASSANDRA LL2 Data Dictionary ...57
Appendix D –US Initiatives effective in foreign countries ...61
Page | 7
1
Introduction
1.1
Background of the project
The EU-funded project CASSANDRA aims in general to help make container security more efficient and effective. This is accomplished by taking care of current and additional visibility needs of private business and government agencies (Customs and other authorities mainly) in the international containerised cargo flow.
For operation purposes a sophisticated data sharing concept between public government agencies and private business companies is developed which improves the supply chain visibility, the efficiency of trade compliance and effectiveness of border control and supervision by combining E-Freight and E-Customs.
1.2
Objective and scope
Containerised cargo flows increased during the past years and will increase further in the future. This has an impact on security, businesses and government who might struggle to find efficient and effective means to ensure full supply chain control and security for each and every container. Thus a large number of research studies have been produced to investigate today’s and future supply chain dependencies, vulnerabilities and resilience. CASSANDRA integrates many of them and goes beyond by covering main transport routes worldwide, such as the Import from Asia to Europe and the Export from Europe to the US.
CASSANDRA Living Lab 2 (LL2) investigates the usability of the general CASSANDRA ideas to build a system of systems in cargo flows towards the US with a start in the EU, via Bremerhaven in Germany. As a special characteristic of US trade – independent from the Port of Loading outside the US –an advanced information system (ISF) is in place that announces each container heading for the US coast (unloaded or transshipped). Therefore the CASSANDRA ideas and solutions are tested against an existing pre-declaration system with two freight forwarders systems in place.
1.3
Stakeholders and their issues
The implementation of the concepts and innovations of CASSANDRA provides enhanced safety, security and trade lane visibility for legitimate trade facilitated by Customs. LL2 identified three groups of stakeholders: Governmental authorities and private companies with transport as core business. The third group is part of the second: private companies offering US transports as part of their business.
1.3.1 Authorities
Governmental authorities like Customs and other authorities could use more data and data of better quality provided by the data pipeline for their own risk analysis without actively requiring more information from other sources. Consequently, the workload will be reduced and enable authorities to concentrate on high-risk consignments.
The extra data also provide redundancy in two ways: If data are not provided by a system as usual, necessary data could be retrieved from other sources. Furthermore, if data on the same consignment are provided by different sources they could be checked automatically for abnormalities or even contradicting data.
These two examples plus a very broad overview of data resulting from earlier transports found their way into LL2 Demonstration:
- Additional/Double party data (e.g. about Consignor and Consignee) is issued by a private trustable company.
- An RBA which checks different sources of information to result in alerts towards officers in charge
Page | 8
- The Systems Based Approach offering a large amount of information of earlier transports similar to a transport in focus.
1.3.2 Private Sector
All parties involved in container transport and handling, including shippers, are able to predict transport milestones (e.g. cargo arrival) by analysing received events and to identify emerging problems. In detail, logistic parties will be informed on the current status of a transport and are able to react to deviations at an early stage. This ability to react immediately to transport variations beyond one’s control enhances the reliability of each company. A benefit resulting from the discussions is the forwarding of transport status directly from the source of information (e.g. a terminal) to the Customer (e.g. Freight Forwarder).
1.3.3 Participants in US trade
Generally speaking, companies currently engaging in trade with the US have to fulfill many requirements resulting from laws for enhanced security. These requirements could also be met by a data completion check without human interaction. Specifically, this automated check enables business parties to test if data required to be sent in advance to US authorities are complete, quality assured, without poor contents and timely.
Since this information is very sensitive to its contents and timely guidelines, an automated examination including raising alerts in case a transport might be endangered is one solution to support this group of stakeholders. Non-compliance to the US rules might endanger the business of the company.
1.4
Brief reading guide
The next chapters in this document have following content:
Chapter 2 refers to the CASSANDRA concepts and how these were turned into practice in this living lab.
Chapter 3 is about the general CASSANDRA approach and about the application this LL. Chapter 4 describes the LL2 trade lanes and the use cases in theory and practice.
Chapter 5 informs about results and evaluation.
The Appendix is about meetings and decisions and shows the full data dictionary as used in LL2.
Page | 9
2
CASSANDRA concepts put to practice
2.1
Introduction to the CASSANDRA concepts
The basic concepts in the CASSANDRA project to realise the goals are Data Sharing and Risk assessment. Both are discussed in more detail in the deliverables of WP100 (background and requirements), WP200 (the Risk Based Approach), and WP300 (IT architecture).
2.1.1 Data Sharing
The CASSANDRA data sharing concept is the general basis for the exchange of accurate, reliable and timely data with all participants and stakeholders of a container transport. Data sharing is executed between relevant business partners whereas involved governmental organisations participate by so-called ‘piggy-backing’ on this information. Piggy-backing means information between business partners is exchanged and governmental organisations (e.g. Customs) also have insight into the data and can re-use it for risk assessment and supervision purposes. The information exchanged needs also to be visualised by dashboards according to individual needs of the partner involved.
The data-sharing concept is realised by granting access to information at the origin of the data. This idea includes many issues regarding the mechanism how to retrieve data, about data security and parties entitled to use the data.
2.1.2 Risk Based Assessment
The second CASSANDRA objective is the risk based assessment (RBA). This objective is twofold: businesses are interested in early detection of operational obstacles, upcoming bottlenecks and possible disruptions of each single transport to safeguard the business. Governmental agencies are in charge of observing (national or supra-national) safety and security standards as defined in various laws and regulations.
2.2
Putting the concepts to practice in Living Lab 2
In LL2 both basic concepts of CASSSANDRA are realised differently than initial LL2 plans due to budget restrictions and arrangements made outside LL2 influence.
2.2.1 Data Sharing
The data sharing in LL2 is realised according to WP300 arrangements. This concept involves using a repository that receives and stores all information instead of live data retrieval. In the end the data sharing concept was realised as a data feed from the origin of data towards a repository where data are stored and can be retrieved by eligible software programmes – the dashboards in CASSANDRA.
For LL2 the data feed is implemented by sending information in regular intervals from the freight forwarder to the repository. The data are stored and a request for additional information is made towards the PCS in Bremerhaven. As soon as additional information about a container in question is available inside the PCS this event is sent to the repository for storage. Some shipments have added ‘Container Security Devices’ which record the position and state of the container and forward the information to a specific database, which then forwards these data to the CASSANDRA repository for display purposes.
Data retrieval for Business or Customs is made available by a Business Dashboard and a Customs Dashboard. The latter also retrieves additional information from Dun & Bradstreet D&B about single participants at the trade lane. In addition, for one of the use cases information generated by the PCS is propagated back to the Freight Forwarder for information reasons.
Page | 10
2.2.2 Risk Based Assessment
An RBA concept as used by LL2 is realised with the CASSANDRA repository as well. It contains a separate section which checks incoming data for information which might hint to a safety or a security problem in the data.
For the RBA in LL2 the CASSANDRA partner Descartes basically introduced two different types of these inspecting technologies. The first idea, taken from current actual practice, is checking data from the same or different sources against each other when information arrives. An alert is raised and forwarded if conflicting information is found in the data. The easiest way is to check simple flags (a one character field containing either a Yes or a No value) against each other. The second idea implemented in the CASSANDRA Business Dashboard is verifying information against an additional database for certain words indicating special circumstances for transports. The example in this case is that Dangerous Cargo information is extracted from the text field of contents in the data delivered to the repository. If a single word inside the database is matched against one of the words the text field, an indication for DG is given and visualised. If additionally the given DG-flag reports no dangerous cargo, an alert is raised and forwarded.
2.2.3 Additional data
Apart from these concepts, additional information for daily use is always an issue for governmental organisations. Private entities require information to fulfil their part of the supply chain and generate added value. The necessary information is pre-defined and additional information is rather unexpected and does not lead to faster results. This is totally in contrast to most of the governmental agencies that have no information apart from what was forwarded due to mandatory regulations, such as the European Export declaration for export purposes. The content of the forwarded data fulfils in most of the transports the needs of authorities, but since each transport differs from each other transport, the data are not sufficient to answer each question an authorised officer might have in mind. In these cases it comes down to a time-consuming request for the additional information, to be forwarded for each singe case. But because officers should not waste time doing constant information requests, the idea to offer more data for any one container arose. In these cases the additional effort is to have a view into an alternative system for additional data. This information is restricted to authorised users only.
2.2.4 Container Security Devices
Another interesting concept to be examined is the use of Container Security Devices (CSDs). These highly sophisticated electronic devices are small boxes attached to a container after it is loaded, locked and sealed. These boxes enable a continuous surveillance of the transport route by receiving GPS location information, tampering with the container using sensors, surveillance of temperature and other applications if needed and deemed necessary. The actual parameters to be transmitted are cargo-dependant, e.g. marble does not need temperature surveillance.
In one of the LL2 trade lanes such devices are used for various reasons, one of them is to deliver additional information to the CASSANDRA data pipeline. Subsequently this information can be analysed and checked against other information delivered to authorities and private parties involved in the transport.
Page | 11
3
Approach/methodology
3.1
The Living Labs approach
A Living Lab is defined as a “gathering of public-private partnerships in which businesses, researchers, authorities, and citizens work together for the creation, validation, and test of new services, business ideas, markets, and technologies in real-life contexts”. 1 Continuity, openness and empowerment of the actors are three of the key principles that Bergvall-Kåreborn et al. (2009) identified with respect to Living Labs.
To implement the right concepts in each Living Lab and to coordinate the whole process properly, a short Living Lab approach handbook was written for the CASSANDRA Living Labs. The handbook consists of four steps. This handbook included the following steps, which will be described in more detail in the following sections:
Figure 3.1 4 Steps of the Living Lab Handbook
The activities in the preparation stage needed to determine how the Cassandra concepts, developed in WP200 and WP300, could be translated and applied to the specific Living Lab trade lane. The exact implementation of the concepts will be very trade lane specific although the evaluation work package describes the end benefit of the use cases in generic terms.
3.1.1 Preparation
The goal of the preparation stage was: To define who will be involved in what way and give input to possibilities for a Cassandra technical solution. For this stage, four activities were prescribed:
Figure 3.2 Preparation stage of the LL Handbook
To set-up a demonstration and at the same time get a good understanding of the Cassandra concepts that can be implemented, the trade lanes must be selected and described in detail. The trade lanes were chosen in close cooperation with the two freight forwarders that are part of the consortium and are participants in this Living Lab. The freight forwarders had to
1
Bergvall-Kåreborn, B., M. Holst, and A. Ståhlbröst, Concept Design with a Living Lab Approach, in 42nd Hawaii International Conference on System Sciences (HICSS)2009.
1. Preparation 2. Technical realisation 3. Risk assessment 4. Pilot and evaluation 1. Preparation
1a) Identifying trade lanes 1b) Commitment of external parties
1c) Involvement of authorities 1d) IT mapping 1e) Data requirements
2. Technical realisation 3. Risk assessment 4. Pilot and evaluation
Page | 12
identify trade lanes that would include cooperating customers and partners, as permission from these parties was essential when using their data.
An important part is the cooperation of actors in the supply chain that were outside the consortium, as innovations cross into various process steps and thereby can affect these actors as well. The entire supply chain is effected and being tested within a living lab. This includes suppliers, freight forwarders, customs officials, and end customers or consignees. The primary actors were the signed partners in the project. However, contacts must also be made with other parties involved to determine cooperation and feasibility of implementing concepts within the living lab. Where needed, an informed consent letter was signed to guarantee data confidentiality in the project and get official consent. An example of the letter of consent can be found in deliverable D9.5 ‘Ethics report’.
An assessment of data requirements and availability was needed to make sure that the trade lane had all the necessary partners involved/committed, and would thus be able to capture a sufficient set of data elements to test the Cassandra concepts. It was accepted upfront that it would be unlikely to capture all data elements in the pipeline in any of the trade lanes.
3.1.2 Technical realisation
The goal of the technical realisation stage was: To define how the Cassandra technical solution will look for the trade lane, build the technical solution, release and maintain. For this stage, four activities were prescribed:
Figure 3.3 Technical realisation stage of the LL Handbook
The design of the pipeline needed to fit with the as-is architecture in each trade lane as was mentioned earlier, but also the various pipeline configurations that are possible needed to be reflected in the Living Lab as a whole. As soon as the configuration was chosen, detailed designs could be created that specified how the pipeline would be developed exactly. In doing this, choices needed to be made for the phasing of the solutions or for the data capture.
3.1.3 Risk assessment
The goal of the risk assessment stage was: To investigate the risk assessment methodology in business and align this with assessment of authorities, design a new methodology for both business and authority, implement and maintain. For this stage, five activities were prescribed:
Figure 3.4 Risk assessment stage of the LL Handbook
1. Preparation
2. Technical realisation
2a) Design pipeline solution 2b) Build pipeline solution
2c) Going ‘live’
2d) Continuous adaptation (based on evaluation) 3. Risk assessment 4. Pilot and evaluation 1. Preparation 2. Technical realisation 3. Risk assessment
3a) Risk assessment of businesses (RBSCM) 3b) Piggy backing (RBGS)
3c) Design pipeline-enabling control measures 3d) Implement control measures 3e) Continuous adaptation, if needed
4. Pilot and evaluation
Page | 13
3.1.4 Pilot and evaluation
The goal of the pilot and evaluation stage was: To identify business opportunities and improvements, in order to implement and evaluate them. For this stage, four activities were prescribed:
Figure 3.5 Pilot and evaluation stage of the LL Handbook
The activities in this stage were executed, where possible and needed, together with WP500. This resulted in an overview of possible use cases that described clear practical benefits for the participants. Based on these and various evaluation sessions during the pilot phase, some additional requirements were identified and implemented. These could include improvements for the technical realisation and for the control measures. Also performance issues were solved.
In the next section, the actual process followed in LL2 is described.
3.2
The process followed
The freight forwarders (FFs) K+N and DHL searched for adequate consignors as a starting point for the trade lanes in LL2. Both found a customer with good data integration into the FF system and without foreseeable obstacles when performing the demonstration.
Both consignors reserved the right to stay anonymous to most project partners, not letting anyone know about their participation in the project since US trade is a market with short termed business today: rates for transports are in some cases negotiated for three months without knowing if containers are really placed. The latter is based on two reasons: first – the consignor might find another freight forwarder with more suitable conditions and second the on-going budget discussions in the US. This also reflects on economy and imports as we learned in the project even in the healthcare environment.
Two data sources were used for each trade lane: the freight forwarder’s system in which the consignor places transport information directly (system to system data exchange) and the PCS in charge.
Upstream data beyond the Freight Forwarder is not recorded in the two LL2 trade lanes: containers are packed, closed and sealed at the manufacturer’s site where the transport starts. Delivery of semi-finished products, packing material and the manufacturing process is not in scope of the Living Lab.
The LL2 trade lanes used are already well organised and in good technical conditions due to following given conditions:
- By employing large third party logistics providers the consignor of the cargo sends required transport information directly from his system to the K+N or DHL system;
- The K+N or DHL systems are available worldwide at each branch office with local characteristics (e.g. EU branches with access to EU Customs systems);
1. Preparation 2. Technical realisation 3. Risk assessment
4. Pilot and evaluation
4a) Identify business opportunities / models
4b) Identify requirements from 4a 4c) Identify requirements from 2d and
3e 4d) Demonstrate 4e) Continuous loop
Page | 14
- US authorities require declarations of the contents of each transported container at least 24 hours before the vessel leaves the last port of loading. This rule enables a possible refusal of singe containers to enter US territory.
- The customs perspective identified for EU (export) Customs is not very complicated: private entities like to export goods for profit and have to obey existing laws. As soon as declarations and container conditions are sound, Customs Authorities often do not place additional burdens. Basically the same was learned from the US Authorities based in Germany: the better the data quality of a single consignment, the less time is spent on additional checks.
Having all information recorded, a structured analysis of each stakeholder’s need in conjunction with the project aims and partners capabilities in order to receive the best performance at the demonstration.
3.3
Data Analysis Procedures and creation of a Data Dictionary
In LL2 a joint database for both trade lanes through different companies was intended to have a comparable data set, easing all later steps and enabling the utilization of each use case in each trade lane.
A data dictionary was created, taking into account this database concept as well as the givens about existing data exchanges from shipper to Freight Forwarder, the common EU Export declaration for all exports in question, the existing US regulation about advanced data to be sent, and the common use of the PCS in the Federal State of Bremen.
The intention resulting from T310 was to have all information needed in the LL on a single sheet to be clear what information is needed from whom and is to be used for which use case. With the detailed information on single-data needs or requirements gained from the individual stakeholders, the data dictionary for LL2 (see Appendix C) was created. This approach provided a deep insight into real requirements: different parties identify the same information using different names even though it may have the same content. This is due to different views on the data and different software developing companies.
With the data dictionary the input from the freight forwarders was visualised and analysed and led partly to the creation of use cases and for each use case to the original needs a use case should cover for demonstration. This part could be seen in Chapter 4.3.3.
3.4
Collection of transport information
Data in this Living Lab to be presented to the data pipeline are collected by following sources due to the nature of the container transport: from both Freight Forwarders in LL2 and from the PCS in the port of loading. There is no need to involve parties other than those identified because, for the trade lanes, all data are already collected by the FFs from the shippers involved. This process is due to the obligation to forward advanced information to US Authorities.
3.5
US Customs advanced information
In US trade, regulations from US Authorities are in place which could be called ‘customs pre-clearance’ or ‘pushing out the borders’. Completely independent from Customs on the export side, information to US authorities must be sent 24 hours in advance before a container is loaded in the last port of loading. This procedure is mandatory for cargo unloaded in US ports or transshipped. The information to be sent is regulated by US Authorities.
Non-compliance with this regulation is likely to result in US border patrol or the Navy stopping the container vessel on the high sea. This could have severe consequences such as all vessels belonging to a certain vessel owner could be banned from entering US ports or even US territory, or the company could get black-listed. This has never happened since each vessel operating company makes sure each container on board complies with this regulation. The regulation contains exact requirements regarding what data are to be
Page | 15
transferred (CBP Form 1302) and which path an operating company is to take to send information to US Customs and Border Protection.
EU authorities lodged a similar rule named ENS which works slightly different top the 10+2 rule but has the same aims: detecting unwanted goods before goods are loaded on board a vessel.
3.6
Authorities involved in LL2
In LL2 no federal German authority involved in transports from Europe to the US was a partner in CASSANDRA. Thus actions were taken in order to discuss with several authorities, obtain their opinions about CASSANDRA and learn about daily obstacles regarding their duties. The information received was used to create the LL2 use cases. Appendix A shows the main meetings held whereas Appendix B contains the relevant decisions.
3.6.1 German Customs
Germany employs currently more than one Customs authority, in contrast to many other countries. German Customs (federal, subordinate to the minister of finance) is responsible for taxes, duties and security, but has several independent subdivisions, CASSANDRA LL2 made contact with two of them.
3.6.1.1 German Customs on an inspection and control level
The first contact made regarding LL2 aims in the port area of Bremerhaven was national customs. This subdivision is responsible for daily container clearance at the EU border for import and export containers.
3.6.1.2 German Customs on a terrorism targeting level
Germany employs two different Customs targeting offices, both legally independent. The aims of the Bundesfinanzdirektion West (BFD-West) are financial risks whereas the Zollkriminalamt (ZKA) is responsible for terrorism detection, both organisations act according to information given to the national Atlas System. For CASSANDRA a meeting with the latter of both authorities was held.
3.6.2 Hanseatisch Bremisches Hafenamt
The state governmental agency Hanseatisch Bremisches Hafenamt (HBH, the Bremen state port authority) is responsible for the safety of all Bremen and Bremerhaven port areas, e.g. implementing and surveillance of the ISPS-code and surveillance of transports containing dangerous cargo. In the Bremen Port Areas this authority has the same right as German Customs Authorities to stop containers in order to request additional data, for internal inspections etc. But exchanging data between these authorities is strictly forbidden since Customs Authorities follow the federal laws of the ministry of finance whereas HBH is ruled by state laws.
3.6.3 US Customs Authorities
Due to the nature of LL2, US customs is involved even if container transport is followed from an EU perspective: as soon as the vessel leaves the port of loading, EU Customs attention is completed. The US enacted various rules to follow in order to import goods into the US, which was the reason to involve the authorities across the Atlantic.
Several approaches were made to involve US Authorities in the CASSANDRA Project, discussions were held with CSI officers located in Bremerhaven. Since US Authorities work on the same rules and laws word wide, this subdivision face the same obstacles at daily work as most other divisions. The output of the discussion with CSI Officers led to create a LL2 Use Case representing US perspective.
Page | 16
4
Trade lanes and Use Cases
4.1
Living Lab 2: The Kühne + Nagel trade lane
For the CASSANDRA project, the freight forwarder K+N has identified one trade lane. This is an FCL (full container load) export trade lane from Austria (AT) to the US, transporting pharmaceutical products.
The pre-transport is done using a truck from the manufacturer’s site in Graz, AT to the port of loading in Bremerhaven, Germany (DE). The ocean transport is done using various deep-sea carriers. Port of Discharge is located in New York followed by a train transport to Chicago, Illinois (IL) and a final leg accomplished by a truck to Schaumburg, IL to the premises of the final consignee.
4.1.1 As-Is situation
1. Selection and mapping of trade lane in layered model
Trade lane 1: The K+N FCL – Graz, AT to Schaumburg, IL, US
Figure 4.1 - FCL trade lane for K+N, overview
Characteristics of the container flow on this trade lane are summarized in the table below.
Table 4.1 - FCL trade lane for K+N, characteristics
2. Parties/stakeholders involved
Involved parties and role in this trade lane are summarized in the table below. Transport operators in the US were not contacted since transport information after a vessel left the EU was not considered relevant for CASSANDRA.
Table 4.2 FCL trade lane for K+N, involved parties
Product type Pharmaceutical products
FCL/LCL FCL
Applicable Incoterm Confidential
Estimated volume (containers /yr) 50
Consortium partners External parties External parties of interest Kühne + Nagel Consignor (contacted by
K+N)
US Customs authorities Datenbank Bremische
Häfen
German Customs office in the port of loading
US Customs in the port of discharge
HBH / SWH German Customs
Criminological Office
Container Security Initiative authorities
US personnel in the port of loading (CSI)
PCS in the port of discharge Transport operators in the US (train/hub/truck)
Page | 17
3. Mapping of current IT systems
Figure 4.2 – IT Map of K+N FCL trade lane
4. Data mapping
The data mapping relevant for the CASSSANDRA demonstration is as follows: the consignor inputs the transport information directly to the DHL system named ‘LOGIS Ocean’. When the transport from the manufacturer’s site is due, the truck pre-transport and the deep sea transport are instructed, a port order is sent to the PCS in the port of loading. The export declaration is issued by the FF to the German Customs data system named ATLAS. In due time according to US AMS regulations the FF sends relevant information to US Authorities using an approved US Customs data broker.
Page | 18
5. Design of pipeline configuration
The configuration of the pipeline in the K+N FCL trade lane is shown in Figure 4. below. It shows the data feed from Shipper to Freight Forwarder and onwards to the CASSANDRA Backbone Hub as well as the additional status data sent by dbh in order to enhance the content for each container.
Figure 4.4 – Pipeline configuration for K+N FCL trade lane
4.1.2 During pilot phase
The pilot phase started in March 2013, at which time the final versions of the Business Dashboard and the repository (namely the CASSANDRA Backbone Hub) were available (iteration 7) and data were fed into them. The Customs Dashboard was already available before this date but could be tested with the final data input towards the repository in March 2013.
4.1.3 Use by parties and (expected) benefits
Organisation / role Interests Advantages of CASSANDRA
Shipper Reach consignee in time with unchanged content
Improved working capital (reduce stocks throughout the supply chain, improved cash flows)
Increase product integrity and monitoring of quality Monitoring of legal compliance
Forwarder Transport is executed as planned and agreed with shipper.
Improved efficiency of Customs process, possibilities for pre-clearance and green lanes
Improved agility to respond to disruptions during transport
Page | 19 Administrative benefits
Improved Customer binding Customs / authorities Contents are
according to declaration and untouched between sealing and presentation to customs.
Improved efficiency of risk analyses and Customs processes
Improved intelligence to reduce fraud, smuggle, theft and other risks
Port Authorities Contents are according to declaration and stored safely.
Improved data quality
Improved efficiency of risk analyses and Port Authority processes
Page | 20
4.2
Living Lab 2: The DHL trade lane
In Living Lab 2, the freight forwarder DHL identified one trade lane. This is an FCL (full container load) export trade lane from Germany to the US. This trade lane with about four containers per week runs from the premises of the manufacturer located in Frankfurt/Main (DE) with a truck-pre-transport via the Port of Bremerhaven to Port of Charleston (US) and onwards to the consignee using a truck.
4.2.1 As-Is situation
1. Selection and mapping of trade lane in layered model
Trade lane 1: DHL FCL – Frankfurt, DE to Forest Park, GA, US
Figure 4.5 – FCL trade lane for DHL, overview
Characteristics of the container flow on this trade lane are summarized in the table below.
Table 4.4 – FCL trade lane for K+N, characteristics
2. Parties/stakeholders involved
Involved parties and their role for this trade lane are summarized in the table below. Transport operators in the US were not contacted since transport information after a vessel left the EU was in scope as the emphasis was on the export part of the trade lane.
Table 4.5 FCL trade lane for DHL, involved parties
Product type Pharmaceutical products
FCL/LCL FCL
Applicable Incoterm Confidential
Estimated volume (containers /yr) 200
Consortium partners External parties External parties of interest Kühne + Nagel Consignor (contacted by
K+N)
US Customs authorities Datenbank Bremische
Häfen
German Customs office in the port of loading
US Customs in the port of discharge
HBH / SWH German Customs
Criminological Office
Container Security Initiative authorities
US personnel in the port of loading (CSI)
PCS in the port of discharge Transport operators in the US (train/hub/truck)
Page | 21
3. Mapping of current IT systems
Figure 4.6 – IT Map of DHL trade lane
4. Data mapping
The data mapping relevant for the CASSSANDRA demonstration is as follows: the consignor inputs the transport information directly to the DHL system named ‘LOGIS Ocean’. When the transport from the manufacturer’s site is due, the truck pre-transport and the deep sea transport are instructed, a port order is sent to the PCS in the port of loading. The export declaration is issued by the FF to the German Customs data system named ATLAS. In due time according to US AMS regulations the FF sends relevant information to US Authorities using an approved US Customs data broker.
If a CSD is used, these data are not currently imported into a database as seen above. The information is provided using a separated system at the moment. These data are is included in the CASSANDRA system of systems as shown later.
Page | 22 Figure 4.7 – Data Mapping of DHL FCL trade lane
5. Design of pipeline configuration
The configuration of the pipeline in the DHL FCL trade lane is shown in Figure 4. below. It shows the data feed from Shipper to Freight Forwarder and onwards to the CASSANDRA Backbone Hub as well as the additional status data sent by dbh in order to enhance the content for each container.
Page | 23
6. Description of the RBA and process/organisational innovations
In this trade lane one of the innovations was the use of a CSD. This device enables information forwarding from the container to the transport operator in charge of the exact position and state of the container. These devices could help in cargo transport monitoring for business and authorities:
Innovations for business
Business may check for transport disruptions, tampering with a container and internal status (e.g. temperature).
Innovations for authorities
The authorities may check for transport route and tampering with a container from the last loading station to the port.
4.2.2 During pilot phase
The pilot phase started in March 2013, at which time the final version of the Business Dashboard and the repository (namely the CASSANDRA Backbone Hub) were available (Iteration 7) and data were fed into them. The Customs Dashboard was already available before this date but could be tested with the final data until the end of the project.
4.2.3 Use by parties and (expected) benefits
Organisation / role Interests Advantages of CASSANDRA
Shipper Reach consignee in time with unchanged content
Improved working capital (reduce stocks throughout the supply chain, improved cash flows)
Increase product integrity and monitoring of quality Monitoring of legal compliance
Forwarder Transport is executed as planned and agreed with shipper.
Improved efficiency of Customs process, possibilities for pre-clearance and green lanes
Improved agility to respond to disruptions during transport
Administrative benefits Improved Customer binding Customs / authorities Contents are
according to declaration and untouched between sealing and presentation to customs.
Improved efficiency of risk analyses and Customs processes
Improved intelligence to reduce fraud, smuggle, theft and other risks
CSD data
Port Authorities Contents are according to declaration and stored safely.
Improved data quality incl. CSD data
Improved efficiency of risk analyses and Port Authority processes
Page | 24
4.3
LL2 Trade lanes: common information
In LL2 the mapping of interaction with government and the use cases applicable to the trade lane is identical for both trade lanes due to the regulations for EU Customs and US advance information.
4.3.1 Mapping of interactions with government
There are three interactions with different governmental agencies needed for a single container transport of this kind:
a. German Customs Authorities
The EU Customs Declaration is issued to the national customs authority where the cargo leaves the EU. This is done via the German ATLAS-system. This information is available for three legally independent German Customs branches:
1. The Customs Office in the port of loading (Bremerhaven in our case) responsible for the port area with physical checks if needed. This Authority has the right to perform internal searches if paper based information is inadequate or missing. The next two authorities named may inform this authority about incoherencies found, but cannot order further investigation;
2. The Zollkriminalamt (ZKA) based in Cologne, is home to Germany’s customs investigation service, the main task of which is to prosecute and prevent organized and more serious customs crime. In terms of cargo ZKA is responsible for the WCO-based risk analysis, using in the future a system named PARIS located in Weiden/Oberpfalz. In other words, ZKA is responsible to fight terrorism;
3. An agency subordinated to Federal Ministry of Finance, responsible for West – Germany, located in Münster is responsible for Germany’s Customs Risk Based Analysis with respect to financial risks (e.g. laundering of money) using a system named ZORA.
The German Customs Authorities, which helped create the use cases, widely appreciate the idea of being in the position of being offered additional data without the need to request the information. An additional data request takes additional time while the container in charge languishes in the yard and the requested data are in a state between checked and being checked. Additional data could help reduce the amount of containers in this state thus helping customs officers concentrate on high-risk consignments.
b. Bremen Port Authorities
The Hanseatisch Bremisches Hafenamt (HBH, the Bremen state port authority) is responsible for the safety of all Bremen and Bremerhaven port areas, e.g. implementing the ISPS-code and surveillance of all transports containing dangerous cargo. This authority has the same right as German Customs Authorities to stop containers for internal inspections etc., but with a different mandate and different aims. Exchanging data between these authorities is strictly forbidden by German Financial Law.
This authority receives the needed information indirectly from the freight forwarder as follows: the freight forwarder places an order with the carrier, who forwards this information to the PCS in Bremen/Bremerhaven. If this information contains the Dangerous Cargo Flag, information is forwarded to the system of HBH for inspection purposes.
In this use case the risk assessment is the vital demonstration part. The data available for a single consignment are to be used to scan for hints referring to Dangerous Goods. This could be done outside the data system HBH usually uses. All HBH needs is a container number. In
Page | 25
the case of reasonable suspicion, HBH has the duty by law to perform additional inspection either on a paper basis (requesting documents) or by requesting an internal search.
c. US Customs Authorities
Borders of the United States of America are secured by the authority named CBP, which is subordinate to the DHS. The US established a system which might be called ‘pushing out the borders’, which enables US Authorities to check paper-based information of all cargo heading to the US. The information about container contents must be sent a minimum of 24 hours before the vessel leaves the port of loading. This information is called the Importer Security Filing. US Authorities reserve the right to prohibit the import or transshipment of single containers. To facilitate direct interaction between US and foreign (e.g. German) Customs Officers, the Container Security Initiative (CSI) has US Customs Authorities personnel located in foreign ports (e.g. Bremerhaven).
These officers reported about daily issues. The ideas of being supported with additional data without having to demand the information and using formatted information instead of single address text fields were welcomed. Such an additional data demand takes additional effort while the container in question remains in the port area and the associated data is between being deemed acceptable and being tagged for further examination. Additional information could support lowering the number of consignments in this situation thus helping CSI officers to concentrate on high risk containers.
4.3.2 Demonstration plan
1. Idea and demonstration purpose
In LL2 each use case described in the next chapter can be demonstrated with each trade lane. Employing two trade lanes where the same use cases are applied and finally evaluated, allows us to replicate the situation with two individual large Freight Forwarders of trade from Europe to US. All results will be verified against each other and business benefits will be exchanged between companies.
2. How Use Cases fit with the trade lanes
Each Use Case was developed independently of the trade lane with the primary stakeholder, thus each LL2 use case fits into this trade lane. The LL2 Use Cases base upon the conceptual Use Cases as described in D1.2 (CAS-C-7, CAS-C-8, CAS-C-9). A general overview describing which use case is applied in the LL2 data exchange landscape can be found below followed by a brief overview of each use case in LL2 including the relevant part of the data dictionary. For a full overview of the data dictionary please refer to Appendix C.
Page | 26 Figure 4.9 – Applicability of Use Cases in LL2 data exchange landscape
4.3.3 The LL2 Use Cases
a. Use Case 1: The Early Data Completion Check
Every consignment sent to or via a US port must be declared with US Customs using the advanced manifest rule regulations. This information may be sent only once (e.g. corrections are not allowed) and must be on schedule, contents must be of a certain quality, the term ‘Said to Contain’ or STC is not allowed, the sender must possess and forward detailed and precise goods descriptions. These checks are in many cases performed by large Freight Forwarders at the time data are due. Incorrect or missing data must be corrected or included at this time to avoid a potentially severe delay in container transport. Due to time and language differences, weekends, and different bank holidays in different countries, necessary information cannot always be retrieved at the time data are urgently needed. This use case is about having an enlarged and automated data check before the data are due, in order to reserve enough time for corrective actions without delaying the container transport. Shippers and Freight Forwarders in charge of delivering the information to US governmental agencies stated the need for such functionality during LL2 discussions.
For this use case the information needed for US authorities was checked against the data contents available from Shippers and Freight Forwarders in the data dictionary. Basically all 10 data fields (from the 10+2 regulation) the shipper must deliver are part of this type of investigation.
This Use Case is an example of issues specific to US trade. Even if regulations are not mandatory for companies based outside the US, the threat of being out of business if they fail to comply with these regulations makes companies perform the tasks. This issue applies to each freight forwarder, thus the idea of having automated systems to comply with regulations is welcome.
The table below shows the single fields of requested data from US authorities on the right hand side, whereas the CASSANDRA data sources are on the left hand side. The data
Page | 27
requested should be checked for accuracy, correctness, coherence and alignment. This is to be done in time to enable corrections or checking with initial data providers.
Page | 28
b. Use Case 2: The Port Authorities RBA
In CASSANDRA authorities other than National Customs Authorities are often named as ‘other authorities’. Due to Germany’s federal system, the five different and independent State Port Authorities at the North and Baltic Seas (west to east: Lower Saxony, Bremen, Hamburg, Schleswig-Holstein, and Mecklenburg-Western Pomerania) all have a vital part in cargo transport: the individual port Authority (Hanseatic City of Bremen Port Authority for LL2, HBH) is responsible for the safety of Dangerous Goods (DG) transported, handled and stored in respective port areas. HBH is obliged by Bremen state law to check DG cargo for the goods themselves, for the safety of the transport (e.g. boxes used and lashing inside a container), correct outside labelling, etc. This obligation implies HBH has the same right to stop and inspect containers internally as Customs Authorities. Currently HBH receives a limited data set on all containers in the relevant port areas. In detail, HBH receives information on containers which are flagged as containers containing dangerous goods (DG) from the PCS. Consequently, information on containers not being flagged is not received independently if these containers do contain DG or not.
In order to identify containers containing DG a set of risk rules has been defined to support the decision process on identifying relevant containers. The CASSANDRA RBA approach is defined that risk assessment by private companies provides itself with all relevant operational information and supports government security risk assessment as much as possible. One of the Living Lab 2 realised a working approach for business and government. Two important aspects were covered:
• Alignment of risk assessment methodologies of both groups in order to make optimal use of the piggy-backing principle.
• Providing reliable data as needed for the risk assessment to all parties on time. This part of CASSANDRA is realised by using the additional information brought to the data pipeline. The information about dangerous goods is sent a second time allowing cross checks.
The approach is accepted by all involved parties but also requires a change in Germany’s Financial and Bremen Port Law.
The tables on the next page show the data source on the left side, whereas the two columns on the right show today’s data view – the data already available to HBH and the additional use case data. The latter are data not available today for this authority but highly appreciated for further information to fulfil the tasks.
Page | 29 Table 4.8 – Data of Data Dictionary for Use Case 2
Page | 30
c. Use Case 3: German Customs additional data
Customs have to perform the task of border control regarding goods and declarations, issue permissions for import and export, and fix and collect taxes and a few other duties. During the LL2 meetings with customs authorities one disadvantage regarding customs declarations was unveiled: each company issuing a declaration forwards a single set of data according to laws in effect. The Customs Authorities in charge of the border control have some of their own knowledge since trade lanes often take the same route but additional information is desirable, thus providing customs more accuracy in making their own decisions.
Discussion confirmed CASSANDRA’s idea of forwarding more information in greater detail than requested by law. In US trade there is the US AMS as named earlier. These data are not visible for German Customs at all, but are highly desirable as well as the additional information already defined. Having two sets of data on the same transport to cross check information or have a look in the second data set if the primary data set is unclear.
The additional information German Customs would appreciate was found using the data dictionary as shown in the table below.
The idea to forward information from one customs authority to another and vice versa by courtesy of the freight forwarder using the CASSANDRA Pipeline and visualization systems was developed and appreciated by both German Customs Authorities.
The tables below show milestones and data needed. The data source is on the left side, whereas the two columns on the right show today’s view – data already available to German Customs and the additional use case data. The latter are data not available today for this authority but highly appreciated for further information to fulfil examination tasks.
Page | 31 Table 4.11 – Data Fields of Data Dictionary for Use Case 3
Page | 32
d. Use Case 4: US Customs additional data
Currently, US Customs Authorities receive the advanced information on goods entering the territory even before a container is loaded on board a vessel in the POL. This procedure gives CBP the chance to stop every single container from being moved towards the US. The information on cargo to be imported in the US occurs in three steps according to US law: AMS, ISF and Import declaration data. The first two data sets are vital to support the customs clearance.
The relevant data contents for these declarations are defined for worldwide data forwarding to the US by authorities on the administrative level, not decided by people doing day-to-day work on inspections.
The discussion with CSI showed that certain data fields containing information on Manufacturer, Buyer, Seller and the like contain information in one single text field disregarding parts of addresses to be given separately, e.g. Country, State, Zip code, or Town as individual data.
An independent identifier for a company or a company as part of a cooperate group is missing, since naming of companies in one free-text field suffers from personal habits: the employees in charge of issuing the advanced information towards US authorities insert the complete name including liabilities and special characters included in the name, others write abbreviations, disregarding liabilities or special characters, use different upper/lowercase formats than the original name and many further permutations. If all this is included in one single large free-text field a search for the single entities becomes very complicated even when using modern computer support. The single text field for a company’s residence is in fact part of the AMS regulation issued by US authorities. The additional and separated information CSI personnel would appreciate could be made available from the data dictionary.
The idea to forward information from one customs authority to another and vice versa by courtesy of the freight forwarder using the CASSANDRA Pipeline and visualization systems was developed and appreciated by personnel of CSI Mission Germany located in Bremerhaven.
The table on the next page shows data and milestones to be used in this use case. The data source is on the left, the two columns on the right show today’s view – data already available to US Customs in advance due to regulations in place and the additional use case data. The latter are data not available today for this authority but highly appreciated for further information to fulfil the tasks. Remarkable is the fact that parties are required by AMS to supply name and address as a text field. Depending on writing habits and characteristics, abbreviations used and special characters used in a single country, the information could be more confusing than clarifying as intended.
Page | 33 Table 4.12 – Part of Data Dictionary for Use Case 4
Page | 34
e. Use Case 5: The Customs System Based Approach
Discussion with German and US Customs authorities and some EU and US publications on a system based approach offer further data inclusion for data based inspections. Data of the same (in terms of goods, trade lane, participating companies and operators) or similar finished transport should be available at the time a new transport is registered with customs. The SBA shows customs control officers if there were problems with similar transports occurring around the same time. Also more emphasis could be put on consignments running for the first time. At the same time, transport routes with data offered by mobile devices attached to a container might be included showing the exact route and status of a container, as well as status information from earlier handling areas, e.g. the exact road gate in date at EU POL shown at US Import Customs. The data dictionary helped to get a complete view on all data available for this use case.
All participants in the LL2-discussions with Customs and other Authorities admit the system based approach is very valuable for each party’s individual work. The performance of certain individual tasks may be performed with less time and effort than today. In other cases less manpower and less use of equipment (e.g. x-ray scanning devices) is occupied by specific operations. A test case to verify the CASSANDRA RBA ideas is seen as a good chance to evaluate the system from an Authorities point of view for daily use.
Page | 35
Use Case 6: The Early Events forwarding
Until now, large companies established information transfer which includes the forwarding of status messages. The messages have the opposite direction than order forwarding: a FF sends an order to the carrier for a certain container transport. The carrier returns information on events that have occurred, e.g. ‘container was loaded onto vessel’. These events are forwarded between parties usually having a firm contract, not between parties without contracts but involved in the same transport. An example for a firm contract between parties is the freight forwarder who orders the deep sea transport with the ocean carrier whereas the company operating the truck pre-transport and the container terminal in the port of loading do not have a contract but cargo and liability are handed over at this interface.
The events forwarding is from a carriers view not his core business, it is done because the customer requests it and it is executed by the carrier when results are assured, e.g. when a load on vessel event was received and the vessel left the harbour area. By waiting for the ‘vessel leaves harbour’ – event the delay of information forwarding might take up to several hours: modern terminal operating systems (TOS) having a front end system on board moving assets (Gantry Cranes, Van Carriers) informing the driver about the next task, and returning status messages with data transported via radio.
The TOS forwards this information instantly to the PCS to inform all other parties about a ‘container load on vessel’. This information now dwells for hours (e.g. from first loaded container on a vessel until confirmed vessel departure) in the carrier’s database to be forwarded to his customer, which in this case is the freight forwarder. The freight forwarder likes to inform his customer as early as possible about this event and does not like to wait for the carrier’s confirmation.
This background created the idea to forward the ‘container load on vessel’ and other messages from PCS to the freight forwarder, enabling the FF to inform his customer upon request with unconfirmed information. The case in which a container is unloaded after a load on vessel is minimal to non-existent thus negligible.
The amount of data to be checked for completeness and timely data forward was discovered using the data dictionary.
A sample of characteristics using deep sea transport is described by this use case. The idea of receiving data for information purposes is appreciated by Freight Forwarders in order to inform Customers and bind them.
The tables below show the CASSANDRA data source information on the left hand and the individual data fields of interest to be forwarded on the right. Since much information is already known by the Freight Forwarder, the milestones (what happened when) are the most interesting details for Freight Forwarders and Shippers.
Page | 36 Table 4.14 – Milestones of Data Dictionary for Use Case 6
