EUROPEAN COMMISSION DG RTD

Transcription

1 EUROPEAN COMMISSION DG RTD SEVENTH FRAMEWORK PROGRAMME THEME Monitoring and tracking of shipping containers SECURITY FP7-SEC GA No CASSANDRA Common assessment and analysis of risk in global supply chains Deliverable No. Deliverable Title D3.6 Cassandra CASSANDRA IT synthesis and integration Final draft Dissemination level [PU] Written By Checked by Wout Hofman (TNO), Huib Aldewereld (TUD) Yaohua Tan Approved by Heather Griffioen 31/5/2014 Issue date 31/5/2014

2 Index 1 Introduction The CASSANDRA project IT in the CASSANDRA project Goal of this document Approach and structure of this document CASSANDRA IT vision A paradigm shift The vision Requirements to the data pipeline Requirement 1: liability and data sharing Requirement 2: commercially sensitive data Requirement 3: upstream data access Requirement 4: prohibited data exchange amongst authorities Requirement 5: open standards Realizing the architecture Components of the architecture Post Cassandra status of the architecture IT Roadmap Phase 1: post Cassandra situation Phase 2: Backbone Infrastructure Phase 3: Trader Interoperability Phase 4: Secure Trade with Smart Risk Analysis Action plan Stakeholders from an IT perspective IT Strategy options Action Lines Disclaimer and acknowledgement Disclaimer Confidentiality...22 Annex 1 Technical evaluation Terms of Evaluation Explanations Software Evaluation Testing Unit testing Integration Testing Inspection Verification and Validation Testing...26 Page 2

3 1.2 Analysis of User Requirements Risk Assessment Protocols Analysis of Required Resources System Quality KPI Data Quality KPI Data Elements LL1 Customs Dashboard Stakeholders Evaluations Intrasoft UK Customs Administration Netherlands Customs Administration Living Lab Results Summary of Most Important Comments/Findings from Evaluation Results LL2 Business Dashboard Stakeholders Evaluations Freight Forwarder Living Lab Results LL3 Barcelona Trade Lade Business Dashboard Stakeholders Evaluations Portic Living Lab Results LL3 Setubal Trade Lade Business & Customs Dashboard Stakeholders Evaluations GMV APSS Portuguese Customs Administration Living Lab Results...76 Page 3

4 1 Introduction 1.1 The CASSANDRA project The CASSANDRA project aimed to make container security more efficient and effective. The project addressed the visibility needs of both business and government in the international flow of containerized cargo by developing a data sharing concept that allows an extended assessment of risks by both these parties. The CASSANDRA concept improves supply chain visibility, efficiency of trade compliance and effectiveness of border control and supervision by combining E-Freight and E- Customs. CASSANDRA bulit on previous EC FP7 projects INTEGRITY, SMART-CM and ITAIDE. 1.2 IT in the CASSANDRA project To meet the project goals as stated in Section 1.1, an agreed upon IT vision complemented with an IT architecture was developed. The architecture and a number of components of the architecture were developed in WP300 of the project and implemented and validated in trade lanes of Living Labs in WP400. The IT vision is the result of the evaluation of the development, implementation, and validation and thus serves as an evaluation of IT within the project. 1.3 Goal of this document The IT Vision is an evaluation of the experience gained during the CASSANDRA project. It presents the optimal approach for realizing the data pipeline from an IT perspective. Realization of this optimal approach depends on current and future policies of customs, supply and logistic chain operators, and IT Service and Solution Providers. A potential IT Roadmap is given in which the IT vision can be realized. Since CASSANDRA did not address all aspects of the IT vision and did realize all components, there is still further research and validation in Living Labs to be performed. These aspects, in the context of policies of all stakeholders, are also described in this document. 1.4 Approach and structure of this document This document presents the IT vision and achievements of the EU FP7 SEC Cassandra project. The structure of this document is: - Section 2: IT vision and components for constructing the data pipeline. - Section 3: IT roadmap for realizing the vision and components - Section 4: Action plan for all stakeholder groups The technical evaluation (D5.1) is annex to this document. Page 4

5 2 CASSANDRA IT vision This section presents the Cassandra IT Vision for constructing a data pipeline. This vision is based on technical capabilities, independent of customs, business, and IT policies of stakeholders involved in the data pipeline. The vision, however, needs to be embedded in policies. First of all, the paradigm underlying the vision is presented. Second, based on this paradigm, the vision is given with reference to potential policies, whereas thirdly, requirements that have to be supported by the underlying architecture are described. Finally, the solutions supporting the requirements are broken down into individual components that can be provided by IT service and solution providers (in the near future, based on business models of those providers). 2.1 A paradigm shift The current paradigm of data sharing in Business-to-Business (B2B) and Business-to-Government (B2G) is the messaging paradigm. A sender pushes data to a recipient in the context of a business transaction, e.g. transport of a container and discharging a container in B2B relations, and requiring permissions to move goods by submitting declarations or providing ENS data to customs authorities. In B2B relations, a sender specifies which data are pushed to that recipient, whereas in B2G relations an authority specifies the data required. The message paradigm has brought many improvements, e.g. data quality is improved by avoiding retyping, cost reduction by reducing errors and retyping of data, and process improvements by receiving data in an earlier stage enabling better planning. The messaging paradigm encompasses implementation of access policies by message specification, the so-called (Message) Implementation Guides ((M)IGs). These guides are subsets of (open) standards. The downside of these guides is: - Time-consuming: development and implementing of Implementation Guides need a lot of coordination between business relations and thus is time-consuming. - Closed systems: Implementation Guides all differ (slightly), although based on the same (open) standard, e.g. each national customs authority has its own guides for B2G that are all (sometimes only slightly) different. - High costs: development, implementation, and maintenance costs are high since many different Implementation Guides have to be supported. - Lack of adoption by Small and Medium-sized Enterprises (SMEs): SMEs often don t have the expertise and funding to implement all different guides. There have been different technical developments to address these aspects, e.g. a Service Oriented Architecture with web services on an IT system providing access to data in that system and an Event Driven Architecture with data changes indicated to potential recipients by events 1, that are mostly not implemented in B2B and B2G relations. Cassandra proposes a resource paradigm according to the Semantic Web 2 combined with the Internet of Things (IoT) in which sensors/actuators like Container Security Devices (CSDs) interface with IT systems. A resource paradigm especially addresses a dynamic configuration of a large number of resources, e.g. a large number of sensors and individuals with mobile devices acting as sensors (IoT). Applying the paradigm to global businesses and governments implies that each stakeholder like a trader or customs authority is a resource: - Goals and requirements: each stakeholder publishes its information requirements supporting business requirements. - Separation of Concerns: access policies are specified independent of a data sharing structure allowing a stakeholder to implement a common agreed upon data structure once and having full flexibility to decide with whom particular data are shared. 1 2 These events are so-called information events signaling a change in data, e.g. a change in temperature setting of a container, and have to be distinguished from physical events like discharge of a container from a vessel. Berners-Lee et.al, The Semantic Web, Scientific American, Page 5

6 In the resource paradigm, development, implementation, and maintenance costs are mostly on maintenance of access policies. This maintenance is, however, completely decoupled from business relations, although in the case of customs access policies, traders will have to implement new policies. Having one common standard for data sharing allows IT service and solution providers to develop applications running on smart devices for SMEs. 2.2 The vision The Cassandra Data pipeline is about B2B and B2G data sharing, from a location of origin to the final destination of products. Many traders participate in a logistics network constituting a great many (global) pipelines, taking different perspectives like a buy-sell relationship or inventory replenishment. A large number of these traders have their particular IT system(s), either COTS (Commercial Off The Shelf), internally developed and/or supported by interoperability services of external providers like Port or Business Community Systems. Particularly, Small and Medium sized Enterprises (SMEs) lack IT systems, but may be forced by their customers to utilize some sort of community system. Trader IT systems store and/or duplicate data based on the message paradigm (see above), they are not always able to share data electronically since many (different types of) documents are still obligatory alongside logistic chains, leading to inconsistencies, errors, and lots of manual interventions in logistics. Data in these systems is not always complete, since not all parties electronically handle data or even complete data forms (see 'who packed the box' 3 ), and not all shipment data are available to all traders in logistics chains (see Rotterdam Rules 4 ). These aspects of data duplication, retyping, etc. lead to (a relative) low data quality (incomplete, inconsistent, non-volatile) in declarations with an impact on customs risk analysis. Electronic data sharing amongst traders is expected to improve data quality of logistic chains or trade lanes composing the pipeline and thus risk analysis. It is also expected to increase visibility thus contributing to supply chain predictability without increasing the administrative burden. In the Cassandra IT vision, customs and other authorities are able to access relevant data available in IT systems of all participating enterprises (piggy backing based on the resource paradigm). To be able to piggy back on trader data, authorities need to have information on goods flows and parties involved in logistic chains or trade lanes. Currently, authorities have (inter)national laws supported by declarations like ENS and other governance instrument like horizontal supervision and System Based Auditing. Applying the resource paradigm potentially leads to other authority policies based with innovative mechanisms to retrieve or receive sufficient information, namely: - Mining Shared Data. Customs authorities constantly monitor traders registered in their domain based on the electronic data they share with other traders, according to full trader interoperability in the Cassandra vision. By mining data shared amongst, especially those relevant to buy-sell, inventory replenishment, etc., customs is aware of any future logistics flows at an early stage. In principle, a trader always stores the data, thus providing better quality data whilst it is more volatile. Customs will also be able to generate events to their peer authorities as part of mutual recognition, also for logistic service providers like forwarders. - Publish/subscribe to events. Foreign traders, i.e. buyers, sellers, shippers, consignees, and logistics enterprises, generate events to the proper authorities at origin, transit, and destination, e.g. packaging, container stuffing/stripping, loading/discharge, etc. ENS declarations are also examples of such events, but they already contain data and cover only part of logistics chains. Mining shared data can also generate foreign trader names that will be generating events or a potential source of additional data for risk assessment. - Collecting upstream data. Events received from foreign traders are a basis for collecting upstream data. International and national data governance policies specify authorities access rights, based on national identity schemes linked to AEO (Authorized Economic Operator), EORI, or other identification schemes and supported by international standards. 3 Heshkett, D., Weakness in the supply chain: who packed the box?, WCO Journal, volume 4, issue 2, Page 6

7 Cassandra Evaluation by Dutch Customs Authority (DCA) shows they will apply upstream data collection with a customs dashboard as part of dual filing (Cassandra D5.2). There are many advantages to this vision. The administrative burden of traders could decrease, whilst customs still receives all required data, which is of a higher quality (see Cassandra D4.1). Customs declaration systems could be replaced by the described mechanisms and customs can subscribe to events generated by traders that particular products are to arrive, allowing them to optimize their internal handling upon arrival and reduce costs. Implementation of this vision requires: - Data governance policies. Internationally agreed upon data governance policies with intervention mechanisms like IT security, open standards, and mechanisms for data sharing need to be specified. Publish/subscribe mechanisms can be part of these data governance policies. WCO and EC/DG Taxud are potential candidates for developing and managing these policies. - Organizational embedding. Data governance policies and their interventions can be embedded in existing mutual recognition agreements, the AEO and EORI databases can act as a trader registry. Business-government interaction protocols (Cassandra D2.3) need to be clearly specified in terms of data access policies, upstream data access, and feedback by customs based on a classification of traders like AEO. - Technical embedding national gateways and endpoints. National gateways could serve as endpoints for a customs authority supporting data governance policies and interventions. - Data collection solutions. To support mining of shared data and process events, authorities can implement data collection solutions. These solutions can feed existing risk engines. - Trader interoperability and logging. Traders need to exchange data electronically, log the data they share, implement data management functionality that is able to generate events, and provide access to the data based on (inter)national data governance policies. Say a large Dutch retailer orders his products in China. By mining shared data, Dutch customs collects data of future shipment of products from China, including names of producers. At that particular moment, a custom authority may not perform any risk analysis, but is already informed of the original shipper and producers. At a later stage, Dutch customs receives an event from the Chinese gateway generated on behalf of a forwarder that particular goods are going to be shipped in containers. Upon receiving this event, customs accesses the data of that forwarder via the Chinese gateway, retrieves the name of the pre-carrier, shipping line, stuffing center, port of loading and port of discharge. These names are links to new data sources for customs, e.g. the stuffing center is queried for additional stuffing data, that can be linked to producers and one or more buyers, one of which is our retailer. Having the producer s name, data of the producer can be assessed to determine the exact relation to a buyer. Now a complete chain can be established and analyzed in more detail according to customs risk rules. Thus, customs reconstructs a commercial network ( parties involved ) and at the same time the physical packaging of products, stuffing in containers, etc. ( goods flows ). The example illustrates how the ideas underpinning the vision can be applied in a practical setting. The organizational model still needs to be elaborated and different implementation models are for further research. 2.3 Requirements to the data pipeline A prerequisite for adoption of the Cassandra Pipeline concept are trust and vested interests of all stakeholders involved. A certain level of trust is required in order for customs authorities around the globe to assess trader data. Vested interests refer to investments in existing IT solutions, interfaces between heterogeneous systems and (open) standards. Trust and vested interests are important requirements for the adoption of a technical solution. These requirements lead to particular solutions; one global solution is not feasible. This chapter presents several data sharing requirements relevant to the adoption of the envisaged technical solution. Whereas the next pages clarify the requirements, the following table presents an overview of the requirements and proposed solutions. Data pipeline requirements Corresponding solution Page 7

8 Liability: Carrier s liability is increased through visibility Commercially sensitive data: Freight Forwarders fear of being bypassed when sharing commercially sensitive source data Upstream data access: how to access upstream data. Legal prohibited data exchange: sharing of data between Authorities is not allowed (Open) standards: different implementation guides for Business-to- Business (B2B) and Business-to- Government (B2G) interoperability in supply - and logistics chains Cassandra Security Architecture (Cassandra Deliverable D3.3): restrict access to the data in the Cassandra Pipeline based on distributed identity schemes and access policies so carriers can continue to avoid legal responsibility and each actor is able to access his particular data Data governance: each stakeholder is able to restrict access to commercial data in the Cassandra Pipeline for other partners downstream in the supply chain, although authorities are able to enforce their access rights Endpoint: a trader provides an endpoint at which authorities can retrieve data. The endpoint can have all data of a particular trade lane ( Pipeline Endpoint ) or all data of a trader acting in one or more trade lanes ( Trader Endpoint ) Endpoint: the Cassandra Pipeline provides data from the source via an endpoint to multiple partners and authorities downstream in supply chains which diminishes the need for data exchange between Authorities Seamless interoperability: piggy backing on trader data requires transformation configured by common semantics between logistic standards and standards of authorities Before clarifying these requirements and their solutions, a generic requirement to the Pipeline will be discussed. All solutions to other requirements need to address the generic requirements Requirement 1: liability and data sharing Supply chains originate in a process between buyer and seller or inventory replenishment in which products are shipped from consignor to consignee according to agreed delivery conditions (Incoterms). These Incoterms specify responsibility and thus liability. Consignors delegate sea transport of FCL / LCL containers to shipping lines who ensure that goods are delivered to consignees (carrier haulage) or can be picked up in the port (merchant haulage). The goods description on Manifests and ENSs produced by shipping lines (or their agents) can be used for control purposes by Customs, but does not carry data on the actual content of a container. To avoid full liability and thus risk any claims, shipping lines often add pre-printed clauses to Manifests / ENS such as particulars furnished by shipper, quantity, quality, etc. unknown or said to contain. This is understandable; they are often unable to verify which goods they have received from consignors due to e.g. sealed or locked containers and therefore avoid legal responsibility and thus liability altogether. There is also a safety issue to consider: once shipping lines or carriers know the content of a container, these containers are vulnerable to theft. Overall the incentive for Carriers to avoid legal responsibility is rather large since it poses financial advantages in terms of preventing claims for cargo loss as well as relatively low insurance fees. Furthermore, avoiding responsibility ensures that Carriers cannot be held accountable by Customs when illegal goods are found in containers on their ships. Hence, a key requirement is to assure that actors like carriers and stevedores, who perform physical operations, do not know the actual content of a container. Message based interfaces that support this requirement, are already implemented by for instance Port Community Systems. Security mechanisms are an intervention that can support this requirement. Page 8

9 As explained in detail in Cassandra Project Deliverable 3.31 (2012b), the Cassandra Security Framework defines effective ways to securely enable data sharing between supply chain partners through the Cassandra Pipeline. Using identities managed by national authorities and protocols to authenticate those identities, access to particular data in the Cassandra Pipeline can be restricted for certain supply chain partners, distinguishing for example between commercial data and transport data Requirement 2: commercially sensitive data Many partners in the international supply chain are dependent on the quality of the data they receive. At present supply chain data provided by Carriers to Customs / Port Authorities are often of relatively low quality resulting in authorities frequently not knowing which goods are passing by. As mentioned before, a principal objective of the Cassandra Pipeline is to increase international supply chain data quality by obtaining data from the source enabling governments and businesses to conduct higher quality risk analyses. The best party to provide quality information about the goods being transported is the original seller or another actor that packed the box. In other words, a consignor or the freight forwarder packing the box should provide high quality source data for the Cassandra authorities. Freight forwarders are not easily inclined to share source data with customs and other traders because these data can be commercially sensitive resulting in freight forwarders potentially being bypassed by partners further up the supply chain once these partners know who originally produced the goods. The Cassandra Project Deliverable 1.2, in which freight forwarders indicated a moderate lack of trust between supply chain parties as a barrier to data and risk sharing, supports this aspect of commercial sensitivity of data. Hence, a key requirement for the Cassandra Pipeline is that freight forwarders control sharing of source data through the data pipeline, thus preventing the risk of being bypassed Requirement 3: upstream data access Customs authorities are able to retrieve data from foreign traders in various ways. They can legally enforce traders to provide all relevant shipping details including container stuffing and packing lists within an ENS. It requires an extension of the ENS with mechanisms that prevent liability of a trader passing on these details and needs to adhere to rules of commercial sensitivity (not all traders are to derive the commercial networks). Utilizing the ENS implies that a data set is gradually completed, where IT security mechanisms including key management procedures and encryption mechanisms need to be installed. Only a customs authority would be able to access only those data in an ENS that are relevant for their risk analysis. Another method would be that customs authorities agree on which data traders under their regime can make accessible to foreign authorities. A simple rule could be that Dutch customs can only access data on goods flows to the Netherlands from a foreign trader. The data that can be accessed by such an authority can be expressed in a (semantic) standard, thus supporting various data sharing implementation mechanisms. A national authority may override these international data governance policies with local rules and provide controlled access to trader data. This approach prevents complex IT security mechanisms supporting liability and commercial sensitivity requirements and strictly separates the public and private domain Requirement 4: prohibited data exchange amongst authorities Another data sharing issue revolves around desired data pathways between authorities that are prohibited by law. The port of Bremen provides an example as explained by Cassandra Project Deliverable 4.21 (use case 2, 2013). Due to Germany s federal system, the Hansestadt Bremisches Hafenamt Port Authority (HBH) is responsible for the safety of the whole Bremen port area. As such, HBH is obliged by state law to inspect container transports that potentially contain dangerous cargo, e.g. by checking the goods themselves, the safety of transport or whether labels are correct. Although HBH has the same right to inspect containers as German Customs, HBH relies on different supply chain data. Each authority uses their own systems with different data; Customs receives data used for customs purposes (tariff definition, checks for embargos, etc.) whereas HBH receives initial transport data send by Carriers. The Cassandra project deliverable 4.21 (use case 2, 2013) demonstrates that in Bremen an exchange of data from one authority to another could be beneficial for enhancing risk based analyses, yet due to various laws the desired data pathways between these authorities are forbidden. Hence, for Page 9

10 authorities an issue at stake is that legislation can prohibit data that is delivered for a certain purpose to a certain authority to be shared with other authorities, thereby obstructing desired data exchange between authorities in the international supply chain. Overall, a key requirement is that each authority has its data access profile for piggy backing on trader data. The data access profile not only specifies the data required by an authority, but also the role of a trader that should provide the data Requirement 5: open standards There are many different (open) standards implemented by stakeholders according the message paradigm, both in B2B and B2G relations. This section discusses some of the important ones. Figure 1 shows the application area of Implementation Guides based on different (open) standards. Although these implementation guides are based on open standards, they are all different, e.g. standards for B2G interface with a customs authority will differ for each (EU) country, even if they are based on the same (open) standards. Most often, EDI (Electronic Data Interchange) implementation guides of these open standards are textual documents and need manual interpretation, whereas the application of XML (extensible Markup Language) leads to different XSDs with embedded semantics. The figure shows a network of stakeholders for both outgoing and incoming cargo (see also Cassandra Deliverable D3.1). Depending on conditions like Incoterms and carrier/merchant haulage, the network constitutes different chain configurations. The blue symbols in the figure represent the physical activities, like transport (arrows) and warehousing (triangle). As the figure shows, the following open standards are relevant in this network of stakeholders: - UN/Cefact IFTM** standards (International Freight and Transport Messages), a set of EDI messages (so-called United Nations Standard Messages or UNSMs) for global logistics. Large forwarders, carriers, shipping lines, and port authorities produce implementation guides with this message set. Implementation guides for one port community cannot be used in another port community. Open standards applied in one port cannot be applied in another port. Another example is that open standards for interoperability with their customers differ per forwarder. - Specific implementation guides of UN/Cefact standards are developed for declarations to port authorities by shipping lines and their agents, the so-called Protect standards. EU port authorities commonly implement the Protect standards. Page 10

11 - Different UN/Cefact standards are used in a buy-sell relationship based on profiles provided by GS1. GS1 also develops profiles of the UBL (Uniform Business Language) standards for the buysell-(national) logistics processes. The XSDs for logistics provided by UBL (version 2.1) are based on the so-called Common Framework, a data structure for logistics developed in various EU FP7 efreight projects. Again, UBL profiles represent different implementation guides of the same open standard, e.g. in individual and groups of retailers, although UN/Cefact IFTM** implementation guides are mostly used for port hinterland logistics. - Whereas current electronic B2G interfaces could be based on different implementation guides of UN/Cefact standards like the Customs Declaration message, World Customs Organizations has a data model for B2G interaction. Each (customs) authority receives an information package of relevant parts of the WCO standards that is the basis for developing their B2G interactions, e.g. their particular XSDs for customs declarations. Thus, the WCO data model and all its components can be localized based on information packages provided by WCO to an authority, leading to different implementations by that authority. Common semantics is one of the basic issues in these implementation guides. Since piggy backing implies utilization of logistics data by authorities, common semantics need to specify at least logistics objects like packages, containers, and transport means and logistic services representing operations and events concerning those objects. Two semantic models have this common semantics encapsulated, namely the WCO data model and the efreight Common Framework, however, each in a different way, from a different perspective, and for a different purpose. These models focus on providing consistent implementation guides for their specific application area. Furthermore, the technology used to represent these models is closed: it is difficult to share these models without utilizing the same toolset as used for developing these models. To address the latter issues, Cassandra has developed a logistics core ontology represented by an open standard (OWL: Ontology Web Language). The ontology can be imported in different tools that support OWL and can be the basis for localization to national customs - or community requirements. Cassandra also proved the feasibility of producing XSDs from the ontology for data sharing Realizing the architecture Components of the architecture The previous section identifies a number of solutions that have to be supported by components in the IT architecture supporting the vision, e.g. data governance and seamless interoperability. The following list of components constitutes such an IT architecture: Component Function Potential provider Semantic model Trader profile Access policy Semantics in B2B/B2G interaction protocols supporting various technical solutions and protocols like required for security and peer-topeer implementations. The model serves as an instrument for configuring various transformations, enables traders to specify their profile, and is the basis for access policies. Information requirements of a trader to support his business. Profiles include not only semantics, but also syntactical representation for data sharing and supported communication protocols. These are all configuration files of a Trader or Pipeline Endpoint. Access rules for data sharing, expressed in a common semantic model. Standardization body IT Service Provider Community System Trader Trader Authority 5 The ontology is developed both in EU FP7 Cassandra and EU FP7 icargo. Cassandra D3.22 provides details on the ontology, whereas icargo Deliverables provide additional information.. Page 11

12 Interoperability managing tool Data Governance Dashboard Trader Connection Configuration Trader Registry Certification Registry Trader Endpoint Pipeline Endpoint National Gateway Visibility Dashboard(s) A tool to develop and maintain a semantic model, its semantic mappings and links with other semantic models, and its semantic representation. Functionality for traders to specify their trader profiles and traders and customs/authorities to specify their access profiles. Functionality to integrate trader back office system(s) with a trader endpoint. The component should support configuration of data transformations with open standards, etc. Registries of traders with their reference to their profile. Functionality for (nationally) managing (trader) identities supporting the Cassandra security protocols Functionality supporting a trader in sharing data in supply chains (B2B) and providing data to authorities (B2). Functionality supporting a trader in providing trade lane data to authorities (B2G). Authority Gateway providing access to trader data by foreign authorities according security protocols and access policies. Visualization of goods flow within the boundaries of access policies. IT Solution Provider IT Service Provider Community System IT solutions provider (COTS or open source) Trader Authority IT Service or Solution Provider Community System Authority Trader IT Service or Solution Provider Community System IT Service Provider Community System Authority Trader Authority IT Service Provider Community System These components are of different natures, e.g. the semantic model, trader profile, and access policies are data structures and can be shared electronically with open standards. The other components are all software components. A semantic model can be used in different ways as an instrument for interoperability. An IT Service Provider or Community System like a Port Community System (PCS) can use such model for integration of different standards in their domain, thus providing one integration endpoint to a trader. It does not (yet) seem feasible that a standardization body will develop such a model or adopt any models developed in EU funded projects like the Cassandra project. Either models are already available (e.g. WCO data model) or standards according the messaging paradigm are provided (e.g. OASIS UBL and UN/Cefact standards) Post Cassandra status of the architecture Both stable interface specifications based on a semantic model and customs visibility dashboards interfacing with a limited number of Pipeline Endpoints have been the focus of the Cassandra project. With respect to semantics (Cassandra D3.22), an ontology is produced incorporating the data requirements for customs dashboards. Whereas it was the expectation at the start of the project that a Cassandra semantic model would be a solution to all B2B and B2G interfaces, it is considered to Page 12

13 provide functionality for transformation between various implementation guides (see also section 2.3 of this document). There are three versions of these customs dashboards (Cassandra D5.1); one of them has been evaluated in practical settings by DCA and HMRC (Cassandra D4.1). The customs dashboard also accessed data of Duns & Bradstreet, however, the data provided by a Pipeline Endpoint did not always contain a useful identification (Cassandra D5.1). Each of these customs dashboard has different implementations of the interface (Cassandra D3.22) to a Pipeline Endpoint, thus they are incompatible (Cassandra D5.1). Although all interfaces use web service technology, the web service and the resulting IFTMCS based XSD differ per implementation. Descartes, GS1 Hong Kong, Portic, and the PCS of the Setubal Port Authority provide Pipeline Endpoint functionality, whereas Descartes and GS1 Hong Kong also provided a business dashboard. In general, all stakeholders have evaluated these dashboards positively (Cassandra 4.1, 4.2, 4.3, and 5.1), with the exception of HMRC. They expected an implementation of a push interface by the Pipeline Endpoints based on the WCO GOVCBR message and receive notifications of new data in the customs dashboard interface. All data would thus be duplicated from a Pipeline Endpoint to the customs dashboard. The Cassandra Customs Dashboard utilizes an IFTMCS implementation guide based on customs data requirements formulated in the Customs Code (Cassandra D3.22) with Pipeline Endpoints. These interfaces have been implemented differently for the different customs dashboards (Cassandra D5.1). It has been shown that migration to a WCO GOVCBR implementation guide is feasible (Cassandra D5.1). A Proof of Concept of the Cassandra Security Architecture is realized illustrating how the security protocols for data sharing across national domains can be implemented. The Proof of Concept contains national gateways interfacing with a central certification registry. Furthermore, a Proof of Concept of a Trader Registry is developed by Atos as part of the project (Cassandra D3.23 GOODS component). Many of the other components are available on the market, either as open source, COTS, or as a service. However, they are not yet fully integrated supporting a process flow enabling traders and authorities to gradually realize the Cassandra IT vision. Page 13

14 3 IT Roadmap The IT vision will not occur over time and further research is still necessary. Table 1 presents an overview of proposed phases in the IT roadmap that will be described in more detail in this section. Issues like harmonization of interfaces for B2B integration are part of this discussion. The basic innovation is in Phase 3 where seamless interoperability between traders is able to support data mining by customs based on access policies (Section 2.1), and Phase 4 where authorities collect data shared between traders, combined with events and publish/subscribe mechanisms based on data governance policies and the Cassandra security architecture. Table 1. The IT Roadmap phases - overview. Phase Name Description Components Phase 1 Post Cassandra situation A basic infrastructure of a limited number of pipeline endpoints to support controlled experiments Pipeline Endpoints Visibility dashboards Phase 2 Backbone Infrastructure Upstream data retrieval to easily implemented additional controlled experiments based on pipeline endpoints with standard interfaces to dashboards and addressing data governance and security Semantic model Access profile Data Governance Dashboard Trader Registry Certification Registry National Gateway(s) Phase 3 Trader Interoperability Piggy backing on trader data with improved quality and completeness by implementing seamless interoperability. Trader Profile Interoperability Managing Tool Trader Connection Configuration Trader Endpoint Phase 4 Secure Trade Based on Smart Risk Analysis Risk analysis by monitoring complete and high quality data shared amongst traders. Upgrade of Visibility Dashboard(s) Upgrade Trader and Pipeline Endpoint Access policy update The previous table introduces the concept of pipeline endpoint : any IT solution that provides access to pipeline data to customs. The number of pipeline endpoints gradually increases from Phases 1 to Phase 1: post Cassandra situation The first phase is the result of the controlled experiments in Living Labs (LLs) for retrieval of additional container targeting data in a so-called customs and business dashboard. Besides testing different technical solutions and configurations, the main objective is to discover whether it (a) has additional value for business resulting in a business case for an infrastructure and (b) leads to improved data quality for customs. The technical solutions for interfacing to customs are based on a push mechanism to share data via community systems (BCSs and PCSs) like Descartes, Portic, DBH, and the system of Portuguese ports that operate as pipeline endpoints. In another experimental setting, an EPCIS server functions as a registry to access data in trader systems (the Seacon trade lane). Customs authorities participating in the experiment can access data via their dashboard interfacing with a web service (REST interface). In the Spanish and Portuguese trade lanes the interface to pipeline endpoints is provided by PCS, whereas the Dutch, German, and UK Living Labs have implemented a push mechanism. Thus, the exchange between different Cassandra pipeline endpoints has been demonstrated with a limited number of pipeline endpoints, proving only interoperability to a dashboard. No consensus has Page 14

15 been reached among IT providers to use one single mechanism for interconnectivity and speeding up the activation process, providing scalability to other trade lanes. Source data has been accessed via these pipeline endpoints. Semantics of the interfaces between a pipeline endpoint and a dashboard is based on customs data requirements. These are mapped to EDI (Electronic Data Interchange) segments taken from the IFTMCS message for implementing a push mechanism. As these data requirements are also part of the WCO data model and the same segments are used in the GOVCBR message, support of the latter structure between a community system and a dashboard is easy to implement. Thus, several pipeline endpoints have been created interfacing with several business and customs dashboards. Each interface between a pipeline endpoint and a dashboard is different, thus preventing a large scale implementation. 3.2 Phase 2: Backbone Infrastructure The second phase offers an infrastructure that can be easily extended with new experiments, e.g. (1) new trade lanes and (2) new customs authorities. It should be easy for traders to link into the Backbone (see Cassandra Deliverable D3.1) and provide additional data to customs authorities via this backbone. However, it also should be easy for new community systems or IT service providers to become part of the Backbone, based on standards for interface to customs, thus enabling organic growth of the backbone. Each new entrant to the backbone acts as a pipeline endpoint for one or more traders. Constructing the Backbone Infrastructure requires a number of issues to be solved. The first is the selection between a push and a pull method for data collection from a pipeline endpoint for a particular authority with its dashboard. To create a market for a customs dashboard and a of pipeline endpoints (see Deliverable 7.5 on exploitation), one uniform mechanism (push or pull) with a standard is the best solution. In view of realizing the Cassandra IT vision, a pull interface is proposed (see Cassandra Deliverable 3.1). Another issue relates to customs access to the pipeline endpoints that compose the Backbone Infrastructure. There has to be a trader registry utilizing a particular pipeline endpoint solution and IT security mechanisms need to be in place. Current IT security mechanisms are minimal and only based on dashboard access. These need to be extended with mechanisms like single sign-on, which are feasible with a limited number of pipeline endpoints, but extending towards the Cassandra security architecture (Cassandra Deliverable D3.3) needs to be considered. With respect to registries, the following feasible solutions need to be evaluated before this phase is entered: - Public domain registries. One (or more) Registries governed by authorities registering available pipeline endpoints. In case each authority has a Registry, pipeline endpoints need to register in each Registry. Traders either register with one of the pipeline endpoints or participate as a pipeline endpoint themselves. - Private domain registries. One (or more) Registries governed by pipeline endpoints and each customs authority interfacing with only one pipeline endpoint (or national gateway, see Section 2.1), e.g. a community system. The pipeline endpoints must have a query federation mechanism to retrieve additional data from foreign traders or traders in pipeline push data to these endpoints. This adds complexity, since potentially a trader in a country enforces trading relations in other countries to utilize a particular pipeline endpoint, which implies that foreign traders need to connect to several pipeline endpoints. Furthermore, commercial providers of pipeline endpoints gather commercially sensitive data, which might prevent traders from utilizing those endpoints. A third issue is to reduce the number of queries for data collection, since an authority has no knowledge of a pipeline endpoint used by a trader. There are several solutions, e.g. - Public domain Aggregated Data Registries (ADSs) with event generation. One (or more) aggregated data registries governed by authorities with identifications to physical objects like containers, vessels, and packages linked to one or more pipeline endpoints. To retrieve data from a proper pipeline endpoint, an ADS is consulted. These ADSs are fed by events generated by a Page 15

16 pipeline endpoint. It is assumed that each of these pipeline endpoints has still retrieved all pipeline data in some way, so ADSs do need to synchronize their data. - Private domain ADSs. An alternative is to implement one (or more) ADS(s) governed by pipeline endpoints in the private domain. Each authority links to one or more ADSs that contain relevant links to data. Again, commercially sensitive data is gathered in these ADSs, which is a barrier for trader acceptance. - Trader Link evaluation. Use a dereferencing based on trader names in data retrieved from a pipeline endpoint in combination with a registry for identifying pipeline endpoints (this is called on the fly dereferencing in linked open data literature). In this case, the links need to be stored by pipeline endpoints. The requirements of data ownership and liability still need to be addressed in this phase. Furthermore, the experimental phase must provide clear business cases for traders and customs authorities to participate and BCSs to develop a business model. 3.3 Phase 3: Trader Interoperability In the previous phases, traders can also participate in the backbone by providing their pipeline endpoint or can use a commercial or community pipeline endpoint to act on their behalf. Trader interoperability is not a prerequisite, since commercial pipeline endpoint providers can provide services for transformation of data into the required formats. However, large enterprises will have their own IT solutions with all relevant data and most probably would like to implement continuous Systems Based Auditing themselves as it most probably affects more than one of their IT systems that contain all data. Basically, two challenges need to be addressed. The first is separating semantics, syntax, and access policies for data sharing to support creation of Trader Profiles and Access Policies. Data transformation facilities need to be provided between different standards (see the requirement of standards). To allow for large scale implementation of electronic data sharing between traders, the objective is that each trader configures its system only once and integrates his internal IT systems with an endpoint, e.g. a Pipeline or Trader Endpoint. The semantic model is used to generate various transformations to other standards. It cannot be expected that there will be one global model for trade and logistics; there are already different models (see before). The objective is to create semantic mappings 6 between different models. Governance of this semantic model (networked ontology) and semantic mappings yet needs to be explored; each community system can also provide this type of service. The second challenge in large scale adoption of trader interoperability is embedded in the previous challenge, namely seamless interoperability. This challenge needs to address how a trader can formulate its information requirements, publish them, and share data accordingly. Potential solutions are in specifying the aforementioned Trader Profile, extending the concept of Registries to match customer goals to profiles, and developing Trader Endpoint. In this particular challenge, registries with trader identifications need to be distinguished from registries containing trader profiles. A registry with trader identifications can be part of the security architecture in the public domain, but registries with trader profiles need to be in the private domain. These latter registries also provide matching between a customer s goal and provider capability, e.g. the requirement to ship products from the far east to Europe is matched with capabilities of forwarders able to arrange this transport. 3.4 Phase 4: Secure Trade with Smart Risk Analysis Secure Trade based on seamless interoperability provides high quality data to authorities for Smart Risk Analysis of all logistics chains stemming from, going to or passing its area. This is in fact the tobe situation, in which each authority crawls data of traders registered with a public domain Registry, receiving events of foreign traders, and cross-validating chain data with external sources representing people, entities and historic data. Each customs authority has a complete data set of all goods 6 The concept of Semantic Mapping or Ontology Matching is taken from developments in the Semantic Web. Page 16

17 movements in its area, collecting data from foreign traders upon receiving events generated by those traders. Trader and Pipeline Endpoint systems require an upgrade to generate events and implement logs and audit trails for data shared by messages amongst traders 7. These endpoints also need to implement customs access profiles and have to be registered as trader endpoints in the public registry. Visibility dashboards have to be upgraded to handle events generated by foreign traders and support data collection from registered trader endpoints. In this to-be situation, only export, re-export, import, and possibly bonded warehousing procedures need to be implemented with declarations, although they can also be implemented with an event mechanism. These procedures reflect the start, end and relevant intermediate events for an authority. It is expected that, although a lot of research needs to be done, customs IT systems will be greatly simplified and the administrative burden of traders will reduce drastically. If a particular customs authority also implements System Based Auditing with periodic reporting similar to what is already feasible in current customs legislation, the administrative burden would be minimized for traders. 7 The resource paradigm for data sharing amongst traders is explored in the EU FP7 icargo project Page 17

18 4 Action plan To realize the vision, architecture, and roadmap, an action plan is required, which rather complex whilst it involves a great many stakeholders. The action plan involves all relevant stakeholders from an IT perspective. These stakeholders are presented, potential strategies are formulated, and the lines of an action plan with proposed actions are presented. Realization of the IT vision requires close collaboration of policies of all stakeholders involved. Of course, it is up to each stakeholder to have its particular policy. However, in the case that any of the stakeholder (groups) decides on another policy with respect to IT, that will have impact on policies of the other stakeholders. 4.1 Stakeholders from an IT perspective The following figure presents an overview of stakeholder groups from an IT perspective. These stakeholder groups are specified as: Public Sector. It consists of national and international legislators specifying policies and authorities implementing these policies, e.g. national customs administrations like HRMC and DCA analyzing risks and granting permission for goods movements and authorities providing data of the physical infrastructure (port, road, inland waterways, etc.) and its status. Business Sector. These comprise all enterprises acting in various roles like buyer, seller, logistic service provider (e.g. forwarder), stevedores, warehouse operators, and carrier. There are many examples of these enterprises, e.g. Unilever, Proctor & Gamble, Kuhne & Nagel, DHL, Seacon, BAP, and OCE. IT Solution and Service Providers. These can be classified further, namely: o Port Community Systems providing interoperability services to all stakeholders operating and utilizing port facilities. Examples of these are Portbase, Portic, and DBH. o Commercial Service / Visibility Providers providing integration and visibility services globally to supply and logistic chain stakeholders. Examples are Descartes, GT Nexus, and LogIT. o COTS (Commercial Off The Shelf) Software Providers providing IT solutions supporting operational processes of enterprises in the business sector. Depending on the functionality, all types of COTS solutions can be distinguished, e.g. Enterprise Resource Planning (ERP) solutions provided by enterprises like Oracle, Microsoft, and SAP, Transport Management Systems (TMS) and Fleet Management solutions provided by Quantum, Kewill, Intellitrans, etc., and integration functionality provided by IBM, Oracle, Microsoft, Tibco, and others. o COTS Implementation Service Providers supporting an enterprise in the implementation of COTS solutions, e.g. Deloitte, CGI, and ATOS. In some occasions, Page 18