EUROPEAN COMMISSION. CASSANDRA Common assessment and analysis of risk in global supply chains

Transcription

1 EUROPEAN COMMISSION 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. D3.22 CASSANDRA Deliverable Title Interfaces v2: Dissemination level Written By Checked by PU Jose Gato Luis (ATOS) German Herrero (ATOS) 08/02/2013 Approved by Dr. Heather Griffioen-Young / TNO 09/ Issue date 11/03/2013

2 Executive summary Scope of this document This document describes the second version of the CASSANDRA interfaces design. This deliverable is expected as a prototype and it includes incremental work from the first version D321 (in the scope of T340 and T350). The design studies and prototypes the different possible options that should be considered to improve the visibility in a supply chain. Specifically the main pillars to build a data pipeline using common interfaces, previously defined in the CASSANDRA s architecture. Thus, the document covers the interfaces design from the next different perspectives: CASSANDRA backbone specifies the different interfaces of CASSANDRA from a business perspective using the data pipeline. These interfaces will be used as base for the different implementations of this WP and the configuration of the Living Labs. Data Capture Interface: specification and design of the Data Capture concepts that will be implemented in the living labs and the IT Environment Lab. This section should be considered as the main outcome and description of the progress during this period. Dashboards first version of the different dashboards to be released in this WP. These dashboards will be used in their related living labs. This sections provides an interfaces vision from an integration and implementation perspective. IT Environment Lab: different progress achieved in this environment, specially, a better data model (provided with a new version of the ontology) and authentication and authorization mechanisms. Main changes come from Objectives to achieve, the IT Environment Lab covers innovative solutions to implement and test the differnent interfaces to be provided, such as: data capture (DC), data sharing (DS), logistic services (LS) and configuration and maintenance (CM) interfaces Ontology design (Semantic Data Model): which includes a first design of the data model. Ontology design (Semantic Data Model) covers the interoperability needs using the different common interfaces. This first version focus in the objects: activities, actors and entities This document release (D322) of the interfaces prototypes makes a special focus on the Data Capture Interface and the Ontology design. The IT Environment Lab also provides an update with new developed functionality. The other sections remain without remarkable modification due the in incremental nature of this deliverable. This updated version includes: As summary, this deliverable goes in depth with the different interfaces that will provide the data pipeline from different perspectives: innovation, interoperability, integration and business. These prototypes will facilitate the correct living labs implementations. Page 2

3 Document History Deliverable Title: WP Deliverable number: Interfaces V2 WP3 T350 D3.22 Lead Benificiary Authors Jose Gato Luis Germán Herrero Henk Wiersema Laura Daniele Contributing Authors Alejandro Bosch Wout Hofman RuiVenancio Frank Koldijk Participants ATOS Org ATOS ATOS TNO TNO Org ATOS TNO GMV IBM Doc. History Version Comments Date Authorised by Classification V0.1 Release for discussion with 01/08/2012 Jose Gato WP300 partners V0.2 IT Environmentlab 15/09/2012 Jose Gato V0.3 Dashboard 27/09/2012 Rui Venancio V0.4 IT EnvironmentLab 01/10/2012 Jose Gato V0.5 CASSANDRABackbone 02/10/2012 Wout Hoffman V0.6 Customsdashboard 31/10/2012 Frank Koldijk V0.7 Overview/Conclusions 31/10/2012 Germán Herrero V0.71 DC interface specification 28/01/2013 Henk Wiersema V0.72 IT Environment Lab update 06/02/2013 Jose Gato V0.73 Last Progress and update 06/02/2013 Germán Herrero V0.74 Ontology description 08/02/2013 Laura Daniele V0.8 Updated executive summary and progresses under the IT Environment Lab PU 26/02/2013 Jose Gato Number of pages: 64 Number of annexes: 0 Page 3

4 Contents Executive summary... 2 Scope of this document... 2 Document History... 3 Index Introduction CASSANDRA backbone Summary: the CASSANDRA Backbone Configurations of the CASSANDRA Backbone Pipeline Configurations Evaluation of pipeline configurations CASSANDRA strategy The role of customs dashboards Data Capture Interface Views and Context Purpose Of the current description of DC interface Specifications CASSANDRA Message Specification CASSANDRA Message Header Specification CASSANDRA Message Payload Specification CASSANDRAAPI Description Use Case and Examples Summary Design decisions CASSANDRA Interface Future Design Issues Dashboards IBM dashboard for customs Introduction Customs Dashboard Use Cases Customs Dashboard System Context Customs Dashboard Interface towards the Pipeline GMV dashboard for business/customs Dashboard access Dashboard data elements Dashboards Presentation IT Environment Lab Profiles management Data storage infrastructure REST interface Web Application for profiles management Page 4

5 5.5 Operational Environment Specific Objectives to achieve for this release Web application Data persistence storage and REST interface Operational Environment Involved Technologies Global architecture with CASSANDRA s architecture interfaces User s guide: Login page List of companies Insert warehouse Search activities Add / edit company Add / edit profile View profile/ List of activities Add/edit activity Ontology design (Semantic Data Model) Introduction Core ontology Moveable Resources and Static Resources Conclusions References Page 5

6 Index of figures Figure 1: Interfaces of the target CASSANDRA integration architecture... 9 Figure 2: PCS Pipeline...11 Figure 3: GS1 Pipeline...12 Figure 4: BCS CASSANDRA Backbone...12 Figure 5: Hybrid CASSANDRA Backbone...13 Figure 6: Business Communication Level view...17 Figure 7: CASSANDRA Message Level view...18 Figure 8: CASSANDRA Message layout...19 Figure 9: Use Case diagram: Customs Dashboard Interaction...26 Figure 10: System Context diagram: Customs Dashboard Interaction...27 Figure 11: Service context - DS Query()...28 Figure 12: Service context Event Repository...29 Figure 13: Service context Get...29 Figure 14: Service context getpartydata...30 Figure 15: Service context - Query Callback...31 Figure 16 High Level architecture...32 Figure 17 Entities relationship, relating Users, Organizations and Roles...33 Figure 18: The Home Page...36 Figure 19: The Welcome Page...37 Figure 20: The Administration Page, as seen by the Site Manager...37 Figure 21: The Administration Page, as seen by an Organization Administrator...38 Figure 22: The Ships page, a standard page for regular Users...38 Figure 23: Adding an Organization...39 Figure 24: Adding information to Organizations...40 Figure 25: Creating a User...40 Figure 26: Adding information to Users...41 Figure 27: Administrating an Organization...42 Figure 28: Available Roles; can be assigned to Users or Organizations Figure 29:Provider profile instance...44 Figure 30:Compatibility between profiles of customers and providers...45 Figure 31: Business Process Example...47 Figure 32: Register Company...48 Figure 33: CASSANDRA architecture and interfaces...51 Figure 34: Login page...52 Figure 35: List of companies...52 Figure 36: Insert warehouse...52 Figure 37: Search activities...53 Figure 38: Add company...53 Figure 39: Edit company...53 Figure 40: View company / List of profiles...54 Figure 41: Add profile...54 Figure 42: Edit profile...54 Figure 43: View profile / List of activities...55 Figure 44: Add activity...55 Figure 45: Edit activity...55 Figure 46: Foundational concepts (upper ontology)...58 Figure 47: Activity...58 Figure 48: Event...59 Figure 49: Actor/Role...59 Figure 50: Entity...60 Page 6

7 Figure 51: Location...60 Figure 52: Activity...61 Figure 53:Moveable and static resources...61 Page 7

8 1 Introduction Given the prototype (incremental) nature of this deliverable, this document extendsthe outcomes from the previous version. The document summarizes the work accomplished int340 and T350 during their second period (M18-M21). This second version hasa special focus on the data capture and the ontology design, but also includes the previous results: Backbone configuration, specification with the different business interfaces. These interfaces are specially considered during the implementation of the different developments and the living labs. Customs and business dashboards, using the proposed interfaces (by the CASSANDRA s architecture) to acomplish the specific objetives indentified in the different WP3 activities: o Data consolidation and historical information o Piggy Backing mechanism o Data capture interfaces o GUI interface The IT environment lab to develop and test CASSANDRA s interfaces with semantic features for a better interoperability and supply chain visibility. This environment develops a set of tools to create the data pipeline, using the proposed CASSANDRA interfaces for integration and interoperability between supply chain stakeholders. Data Capture to acomplish this interface regarding the CASSANDRA architecture. This interface will facilitate the interoperability between actors participating in a supply chain and customs, using a common interface through the data pipe line. Ontology design for semantic data model and interoperability The document structure shows the developments realized as prototypes that will be improved during the final iteration of this task and the accompanying deliverable. Page 8

9 risk meta data supply chain data DC Interface supply chain data risk meta data DC Interface CASSANDRA D3.22 Interfaces v2 Public 2 CASSANDRA backbone The CASSANDRA project aims to improve visibility of logistic processes and combine available data for more efficient services and to decrease hardcopy document handling. In this way parties and authorities are able to reduce costs with improved data quality and completeness. To achieve this objective, CASSANDRA needs to develop IT solutions allowing authorized parties to piggy back on trader data. To fully retrieve all data, including upstream data and to allow piggy backing, traders have to be able to share data electronically. The latter is the long term solution, which will be demonstrated in the so-called IT Environment Lab. In the meantime, a solution which we will call the CASSANDRA Backbone Interface will be developed as a basis for the Living Labs. border customs authority authority customs authority CM Interface CM Interface DS Interface LS Interface trader Data Sharing transaction links data supply chain data DC Interface Data Capture CM Interface LEGENDA DS: Data Sharing Interface DC: Data Capturing Interface LS: Logistics Service Interface CM: Configuration Management Interface Cassandra Configuration & Maintenance ontology security. Figure 1: Interfaces of the target CASSANDRA integration architecture Thus, CASSANDRA IT Solutions distinguish: CASSANDRA Backbone Interface: demonstrate upstream data capture in a limited number of tradelanes including the Consignment Completion Point (CPP) data for container consolidation. Large Scale Implementation: methods, tools, and technology for large scale implementation of CASSANDRA. The CASSANDRA Integration Architecture (Deliverable 3.11) addresses these issues by increasing interoperability amongst traders (shippers, consignees, forwarders, carriers, etc.) and replacing declaration systems with real-time monitoring of goods flows (piggy backing). Upstream data is currently captured by use of visibility platforms offered to business and customs. These platforms are developed by project partners in WP3. Basically, these platforms support similar functionalities, each with its particular business case: Business platforms: filling the gap of lack of visibility due to lack of interoperability amongst traders, also by offering data capturing functionality for missing data. Solutions offered by Business Community Systems (BCSs) like East Port Page 9

10 Technology, Port Community Systems (PCSs) like Portbase and Portic, and visibility platforms like GS1-EPCIS based solutions, Descartes and others develop this functionality. Customs platforms: the mashup of data from various sources, including existing declaration systems required whilst declaration systems still exist. IBM is developing required functionality in cooperation with Dutch and UK customs. In the light of the expected project results, customs platforms can either retrieve data from sources under the regime of a customs authority, e.g. traders operating in the country governed by a customs authority, or from business dashboards in that country retrieving upstream data from other countries, e.g. Portbase or Destin8 retrieving data from East Port Technology. This restraint is given by the fact that cross border data sharing amongst customs authorities as specified in a globally connected customs of the World Customs Organization (WCO) is not yet feasible. When globally connected customs is feasible, customs will not depend on these business dashboards. This chapter first presents the proposed option for the backbone and identifies the work to be done. Secondly, the choice for this option is discussed by presenting different pipeline configurations. Thirdly, the details of the work to be done are specified. 2.1 Summary: the CASSANDRA Backbone The following figure shows the proposed CASSANDRA Backbone, which consists of basically two parts: (1) the business systems that share data, interconnected by the black lines, and (2) the customs dashboard that integrates with these business systems, connected to the business systems by the blue lines. Only two customs dashboards are shown; other countries also can have the same functionality. Of course, traders can also share data. The challenge of the CASSANDRA Backbone design is to have an open system for all parties without forcing the use systems of a specific solution provider. Taking this into account the CASSANDRA BACKBONE will be a network of different available logistic nodes semantically connected by unified interfaces. The CASSANDRA Backbone identifies three potential data suppliers for business systems: SR_1. Port Community Systems. SR_2. Business Community Systems, either owned by stakeholders (e.g. a BCS for a country like East Port Technology or TradeXchange) or a commercial service (e.g. Descartes). SR_3. An internationally operating trader like DHL or Kuehne&Nagel. In the backbone, a customs dashboard always connects to one or more CASSANDRA Backbone systems operating within its domain, e.g. a PCS and an internationally operating BCS or trader also operating in that domain. Customs thus has one or more links to business systems in the backbone. There are two solutions for data sharing in the backbone: SR_1. All data is pushed by an XML message from one system in the backbone to another, e.g. from a PCS to a customs dashboard or from a BCS to a PCS. SR_2. A system in the backbone generates an event for another system that is the basis for data retrieval by a web service.. Page 10

11 In the IT Living lab both solutions will be part of the research experiments in order to demonstrate the benefits of the most innovative and scientific technological objectives identified in the CASSANDRA architecture The CASSANDRA Backbone can be used in the Living Labs, e.g. the BAP tradelane will use East PortEast Port Technology and Descartes to share data and make it accessible to UK customs. From a security perspective, each system in the CASSANDRA backbone has its specific mechanisms in place, which might include single sign on (e.g. for Descartes interconnecting with Portbase). In the same way, a trader can submit its data in proprietary formats to a business system in the backbone. 2.2 Configurations of the CASSANDRA Backbone This section first outlines the different pipeline configurations, secondly positions customs in these configurations and thirdly evaluates the solutions. Finally, a strategy for CASSANDRA will be proposed Pipeline Configurations The following pipeline configurations are foreseen: 1. PCS pipeline (see next figure): globally interconnected PCSs exchange upstream data, including local terminal milestones indicating the actual departure or arrival of containers. The figure shows interconnected PCSs that capture trader data, e.g. forwarder, terminal, etc. (of course, all PCSs have traders linked to it). Basically, one country can have one or more PCSs. Figure 2: PCS Pipeline 2. GS1 pipeline (see next figure): globally interconnected GS1 solutions based on an extension of EPCIS for CASSANDRA (EPCIS + ), including terminal milestones indicating the actual departure and arrival of containers. The current implementation of the GS1 EPCIS stores events linked to the identification of objects. A GS1 EPCIS implementation does not store actual data of objects, but is able to store relations between objects. Events stored in different implementations Page 11

12 can be retrieved via a discovery service that registers these different implementations. Figure 3: GS1 Pipeline 3. BCS pipeline (see next figure): a global pipeline based on data shared amongst traders that are member of a BCS. Basically, a BCS is owned by (a number of) its members, e.g. East Port Technology (China) or Tradenet (Singapore) owned by customs, but also commercial operating BCSs like Descartes are considered in this context. These BCS solutions also include terminal milestones. Figure 4: BCS CASSANDRA Backbone Page 12

13 4. Trader pipeline: traders like globally operating forwarder (Kuehne&Nagel, DHL) are also able to capture all relevant supply chain data thus constituting a pipeline. 5. Hybrid solutions: a combination of the above mentioned solutions. An example is shown in the following figure with two PCSs, one BCS like East Port operating in China and a globally operating BCS like Descartes. Figure 5: Hybrid CASSANDRA Backbone The hybrid solution shows a backbone established by BCSs, PCSs, GS1-EPCIS + and trader systems. A trader is shown as a globally operating trader that is able to (but does not necessarily) interface with all other systems in the countries in which it operates. It is also possible that there will be more than one solution in a country, e.g. a country can have a PCS, a BCS like Descartes can offer services in that country, a global trader can offer a pipeline solution, and a GS1 EPCIS implementation can be offered to, for instance, retailers. By having them all interconnected, a trader will have visibility of its goods flow in its chain. The challenge of the hybrid solution is the integration of GS1 EPCIS for CASSANDRA, which basically will store events of objects, whereas other CASSANDRA Backbone systems also store all object data. Page 13

14 2.2.2 Evaluation of pipeline configurations Each of the proposed solutions has advantages, but does not completely cover all aspects of tradelanes. The following table lists the strong points of each individual solution: Solution Strong points Weak points PCS Member owned, terminal and customs milestones in a port. Local coverage, not compulsory for all traders (incomplete data set), not every country/port has a PCS BCS, member owned Customs milestones, etc. Not all relevant milestones, e.g. lack of terminal milestones, not every country has a BCS. BCS, commercial service Global coverage, large number of traders (e.g. Descartes has some traders connected) Not complete coverage of all tradelanes, competition. GS1-EPCIS( + ) Open standards, discovery services, shippers/consignees in for instance retail and health care, identifications. Not widely implemented by all GS1 countries, changes to standard yet to specified and accepted by GS1 Global Central server managed by GS1 with external information references (business security concern) Trader Closed system with its particular Risk Based Approach (RBA, see WP2). Only coverage for those tradelanes in which this trader acts at import and export side, not always full RBA implementations. Table 1: Pipeline configuration evaluation RBA is the main focus of WP2 and could deal with (1) traders handling exceptions in their processes and (2) conditions and rules for accepting goods/containers upstream in the tradelane (at the source, of a shipper or his (local) representative). 2.3 CASSANDRA strategy The CASSANDRA project can have different strategies for implementing pipelines, for instance (to be completed with potential other strategies): Select one particular pipeline configuration. One particular pipeline configuration is selected and all effort is put intorealizing that configuration in the project. An example is to select the PCS or GS1 pipeline configuration. This strategy will never cover all tradelanes since not all ports have a PCS or all countries have a GS1 EPCIS implementation. This solution consequently does not seem an ideal one too follow. Compose a hybrid solution for tradelanes. This is a practical approach in selecting particular partners to compose a pipeline for a tradelane, e.g. the combination of East Port Technology and Descartes to support the BAP China-UK tradelane. It may imply that interfaces between these solutions differ per tradelane and is therefore not proposed as a proper strategy. Page 14

15 Define interfaces for constructing the hybrid solution. A common interface for all combinations is specified and implemented in the tradelanes. The common interface is proposed to various standardization bodies like GS1 () and EPCSA (European PCS Association). This strategy requires cooperation of all participants and needs management effort, but could result in a potential high adaption of the solution by trade. This document proposes following the third strategy. 2.4 The role of customs dashboards Customs requires upstream data captured by the implementation of the CASSANDRA Backbone in its country. While a hybrid solution is proposed as a strategy for the backbone and customs will still have declaration systems, customs has to integrate its dashboard to: All systems active in the country under the regime of customs that compose the backbone. At the most, these are one or more PCSs and BCSs,, and one or more traders. One or more declaration systems, specifically ICS for capturing data of incoming goods. These declaration systems do not capture data of the Consignment Completion Point. Declaration systems can be a trigger for customs to retrieve additional data from the CASSANDRA Backbone, but this data can also be retrieved directly from the backbone even before the data is captured in a declaration system. It is proposed that customs dashboards integrate with the CASSANDRA Backbone with the same interface used by the different systems of the backbone. In case the customs dashboard is filled with pipeline data, a push mechanism is applied. Page 15

16 3 Data Capture Interface The CASSANDRA project aims to address 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 business and government, and improve supply chain visibility, efficiency of trade compliance and effectiveness of border control and supervision by combining E-Freight and E-Customs (container security). At a high abstraction level, the data sharing concept of CASSANDRA is a communications network for the exchange of business information in (CASSANDRA) messages, and a means of communicating them between CASSANDRA (business) partners. These communications means consist of CASSANDRA interfaces (as described by this document) that can be considered the endpoints of the CASSANDRA network, and a backbone that implements the communications capabilities. CASSANDRA messages consist of a header and a payload. The header contains information needed by the backbone and interfaces to properly send, deliver and receive messages. The payload contains business information to be exchanged. For acceptance by CASSANDRA partners as well as for other (obvious) reasons, the specification of CASSANDRA messages, interfaces and backbone must be aligned with commonly used standards such as GS1 and UN/CEFACT. In order to profit from the CASSANDRA network, partners will need to implement the CASSANDRA interface and hook it up to both the backbone and their own business context. This must be done throughout the architectural stack, from the (physical) network level all the way up to the process and business levels. To facilitate this, given the large number of partners and their highly variable ways of working, we will start small and allow that the specifications of the interface mature over time. Thus, the first interfacing will be realized for a small number of trade lanes in the Living Labs, each of which has its own backbone. Later, this will be transformed into a situation where a single 1 backbone can be used by the different trade lanes. In order to keep the specification, design and development for the CASSANDRA backbone and interfaces manageable, it is imperative to distinguish between the various functional layers as used in the GS1 message architecture 2 and the CEFACT layered processing model (LPM) 3. We thus identify the following layers: 1) Business communication layer (BCL), containing the functionality for assembling semantically meaningful business content (such as documents, instructions etc.) into a valid CASSANDRA message payload conforming to the (business) ontology that is/needs to be developed. Also, it contains functionality for creating CASSANDRA message headers that handle business application level routing (again conforming to the business ontology). Thus, the CASSANDRA message header can be seen as a standardized (set of information on an) envelope and the payload as the envelope s contents. 1 this is from a functional point of view. The actual realization may be distributed/consist of multiple components. 2 GS1 XML Message Architecture Implementation Guide, Issue 1, July UN/CEFACT Standard Business Document Header Technical Specification Version 1.3, Page 16

17 2) CASSANDRA Messaging Layer (CML), containing all functionality for communicating (sending, routing and receiving) CASSANDRA messages.this layer contains the functionality for converting addresses between the BCL and the TRL (Transport and routing layer see below). Also, it may contain functionality for checking the integrity of the structure (syntax) of messages transmitted, routed, or received. Note that checks for correct semantics belong in the business layer, as the business defines the corresponding ontologies. 3) Transport and Routing Layer (TRL), containing all functionality for transporting messages between CASSANDRA stakeholder systems. This layer has no knowledge whatsoever about how CASSANDRA messages are structured. It may use any existing protocol that provides the required functionality, such as ebms, AS2, FTP, SOAP, etc. Within the context of a specific Living Lab, it must be decided which protocol(s) to use for this layer. This chapter specifies the CML Interface version 1 (CMLIv1), i.e. the functionality that CASSANDRA partners need to implement in order to communicate with CASSANDRA partners through CASSANDRA messages. Version 1 pertains to the implementation of interfaces as is used during the Living Lab operational phase in the CASSANDRA project. 3.1 Views and Context At the business communication level (BCL), the exchange of information between CASSANDRA partners can thus be seen as depicted in the below figure: Customs PCS PCS Customs T1 T2 T3 T4 Figure 6: Business Communication Level view All rounded rectangles represent the business process applications of CASSANDRA business partners, in various roles (T1 thru T4 are traders 4 ). The color of the rectangle designates a country that the partners are in. Traders exchange information regarding containers with one another, using Port Community Systems (PCS) for translating (or otherwise converting) their (business) documents as they are sent to other traders. Customs organizations can query what containers are being shipped into or out of the country. Business applications and processes can exchange business information, business documents, business requests and business responses using terminology (including identification of other parties) that remains within the business scope. Sending information e.g. to the Dutch Customs thus does not require knowledge of where they are to be reached this is sorted out by the CML. 4 We use trader as a generic term for parties such as producers, forwarders, carriers etc. Page 17

18 At the CASSANDRA Message Level (CML), the exchange of CASSANDRA Messages can be seen as depicted in the below figure: Customs PCS PCS Connection by means of CASSANDRA Backbone Interface Customs T1 T2 T3 T4 Figure 7: CASSANDRA Message Level view All sharp-edged rectangles represent CASSANDRA CML interfaces at the various CASSANDRA partners premises, hooked up to the CASSANDRA backbone. Note how this view differs from the view of the business level. At this level, it is all about the communication of (payloads within) CASSANDRA messages, irrespective of what the payload is. It is basically a question of routing messages that have standardized headers (envelopes). Routing is based on partner properties in the registry of the CML. CML offers these properties to the TRL to enable connection to the desired CASSANDRA Partner. 3.2 Purpose Of the current description of DC interface The purpose of this section is to define the functionality of the CML interfaces (version 1) and the requirements this sets to CASSANDRA messages and in particular: the headers, in such a way that CASSANDRA partners involved in the Living Labs can start to build such an interface and install it for use. Thereby the interface (version 1) should not block any feasible solution that shows up during the LL operational phase. In this phase the use of common known standards is preferred and the interface should offer a smart use of it within the CASSANDRA backbone. Page 18

19 3.3 Specifications This section describes the specifications for a CML interface version 1 (i.e.: for use in the Living Labs). This means that we try to keep things as simple and generic as we possibly can; any extensions to the CML will be postponed to subsequent versions. The properties of being generic and simple allow CASSANDRA partners that want to use the CML to focus on the business and processes (in the BCL) as they can be confident that business messages will be delivered. Also, it allows CASSANDRA partners that want to realize (create) CML interfaces for actual use to rest assured that their interfaces can actually be used, and will interoperate (at the CML level and below). However, CASSANDRA partners still need to agree upon the following topics: - At the BCL level, process flow between different partners, and contents of the CASSANDRA message payloads has to be agreed upon by the partners involved. Note that partners can use messages as defined by a wide variety of standards as payload the CML does not limit the contents of CASSANDRA message payloads. - For the TRL level, the various transportation protocols that will be used must be agreed upon, as well as the corresponding addresses that each CASSANDRA partner will use at the TRL for accessing the CML interface. - For the CML level, actual CMLv1 interfaces have to be built that can use the protocols and addresses as agreed upon for the TRL level. - CASSANDRA partners must agree to start using the CMLv1 interface as it becomes available - Where to collect requests for changes and new features (e.g. from new insights from LL or IT-LL) so that they can be evaluated for subsequent versions of the CML. The specifications in this document are limited to the messages used within CASSANDRA and the call for the Data Capture for Dashboard use CASSANDRA Message Specification A CASSANDRA Message maps straight onto what is called a StandardBusinessDocument in the UN/EDIFACT standard (see figure to the right). This setup of the CASSANDRA message allows for putting anything you like into the payload. Of course, it is convenient to use other standard payload syntax, such as the GS1 XML (UN/CEFACT) payload (see below) CASSANDRA Message Header Specification The CASSANDRA message header maps onto the StandardBusinessDocumentHeader (SBDH). More detailed information on the structure and use of the SBDH can be found in the SBDH v1.3 technical implementation guide and XML templates: Figure 8: CASSANDRA Message layout CASSANDRA Message Payload Specification As has been mentioned earlier, the payload can be pretty much anything, at least from the point of view of the CML. From a BCL point of view, however, the payloads must be agreed Page 19

20 upon by CASSANDRA partners in order for their mutual processes to interoperate. This requires not only agreement on the syntax and structures to be used, but also on the ontology (the meaning, semantics). However important this may be, it is outside the scope of this document. We suggest that communication between LL-partners at the business (payload) level be done with standard messages within the UN/CEFACT or GS1 message sets 5. For examples, see the use-case below. Another remark we would like to make regards identifiers, e.g. for container numbers (the LLinterface implementation uses the ISO 6346 standard for this). Identifiers are commonly used as a key; for example, container numbers are used to get information about identified containers from the Data Capture call to Partners. Identifiers (numbers, names) however are NOT a key by themselves. You need to know that such numbers or names have been registered as a key (or identifier) with a party that we call an Identifier Authority. For example, companies usually are registered in some company register e.g. at the nation s Chamber of Commerce. When using a number to identify a company, it is thus relevant to also identify the Chamber of Commerce where the company is registered with that number. In general, every identifier (key) thus consists of a name or number and an Identifier Authority. Thus, URIs containing an Identifier (and IdentifierType) should therefore also contain the IdentifierAuthority CASSANDRAAPI Description For this version, it is the task of the BCL to create a complete CASSANDRA message, that is to say: including the SBDH (and of course, the payload). The entire message is then passed to the CML which then sends it to the destination as specified in the SBDH. The translation of the SBDH contents into addresses, URI s, numbers etc. that are needed by the TRL is entirely up to the CML. In the operational phase of the LL the specifications of the network connection to other partners is kept within a registry in the CML. For example, the table that converts data that identifies a business endpoint (for receiving or transmitting messages) into an IP-address and/or URI for the protocols that can be used between the source and destination endpoints, is part of the CML. Such tables will be maintained manually (for the moment, anyway). It would be nice if a working implementation of a CML (or of modules that implement the CML for a specific transport protocol) would be shared amongst the CASSANDRA partners in the various Living Labs. 3.4 Use Case and Examples In order to show how this setup works, we describe a small use case. In this use-case, consider a container C that ships from Singapore to Rotterdam. Then, the trader in Singapore sends a message to the Singapore PCS stating that it has put Container C on Ship S. The Singapore PCS sends this message to the Rotterdam PCS, converting it as required. The Rotterdam PCS sends the message on to the receiving trader in Rotterdam, converting the message as required. Outside CASSANDRA, the trader in Singapore sends a message to Dutch Customs for customs clearance. Then, if the customs officer so decides, (s)he sends a request to the Rotterdam PCS to get data for the desired logistic object (Container C). Rotterdam PCS answers using the standard UN/CEFACT messages - IFTMIN 6 (describing the container) and 5 See Page 20

21 - DESADV 7 (description of stuffed goods, especially focused on consigner and consignee of the goods and the goods description). A description of these massages can be found in the UN/CEFACT community. For the Data Capture demands, the interface should have a pull mechanism to supply logistic data to dashboard- and monitoring systems. The connection to the CML is a generic call in which identifiers of different identifier authorities can be used, as described above. Get Logistic Data can thus be summarized as follows: URL Method GET Identifier- Type The name of the Identifier as type for the key Querystring Identifier- The name of the Identifier Authority Authority Identifier The key of the desired logistic object Logistic- Object The name of the logistic object the identifier relates to Returns 200 OK & XML (logistic/data) 401 Unauthorized 404 Not Found Table 2: GetLogisticData method For parties that agree to supply data in advance, the CASSANDRA Interface has a push mechanism. This mechanism equals the pull mechanism so parties can use messages in the pull and push mechanisms in the same way. The connection to the CML is a generic call in which identifiers of different identifier authorities can be used, as described above. Post Logistic Data can thus be summarized as follows: URL Method POST Query- Identifier- The name of the Identifier as type for the key 6 Specified at m 7 Specified at tm Page 21

22 string Type Identifier- Authority The name of the Identifier Authority Identifier The key of the desired logistic object Logistic- Object XML The name of the logistic object the identifier relates to Logistic data Returns 200 OK 401 Unauthorized 404 Not Found Table 3: PostLogisticData method 3.5 Summary Design decisions CASSANDRA Interface As a summary, the following points describes the first decisions about the implementation of the Data Capture interface that should be followed to implement this interface by the different IT components involved in the backbones of the Living labs: 1. The interface supports pull and push mechanism 2. Communication is secured by Two-way SSL authentication 3. Syntactic and semantic CASSANDRA interface services are compatible 4. StandardBusinessDocumentHeader (SBDH) is used as message standard 5. Message payload is supplied in known UN/CEFACT messages 6. Customs collects data from hubs within native customs domain 7. Data is supplied to Customs in IFTMIN and DESADV messages Page 22

23 3.6 Future Design Issues The purpose of this document is to describe the CASSANDRA Interface Solution for the Living Lab operational phase. Besides this technical implementation for the short term, there are some issues partners should agree upon taking into account Business demands and data availability. 1. Connecting Customs to Global BCS s Global BCS s are potential data suppliers. Connecting them to the CASSANDRA Backbone does not affect the interface description. After the research period of CASSANDRA LL s there should be an advice on how to connect potential data suppliers to the CASSANDRA Backbone. 2. Access to Message Logging to enable historic analysis In order to provide dashboards with historic information Partners should archive messages the actual data is based on. Dashboard systems are able to query for changes and specific messages 3. Security The acceptance of the CASSANDRA Backbone depends largely on the offered security level of the provided solution. Business parties have two main concerns: a. Is the data supplied to the trusted Business Partner b. Does the supplied data contain the allowed data for the role of the Business Partner Depending on the results provided by the IT Living Lab there should be an advice how to set up the security issues in the CASSANDRA Backbone. 4. Self Service The interface should have an opportunity to execute self service activities such as a. Provide new or changed portal addresses b. Testing messages for development issues Page 23

24 4 Dashboards 4.1 IBM dashboard for customs This section focuses on the interfaces between the Customs Dashboard and the CASSANDRA pipeline from which the data, rendered on the dashboard, is obtained Introduction In the field of Information Technology, an interface is a concept that refers to a point of interaction between IT systems or components. In the context of the CASSANDRA dashboard the interfaces determine the way the Dashboard communicates with the outside world. In defining the interfaces, the following comes into play: The type of interaction with the outside world is driven by the use cases that a system is expected to support. The CASSANDRA Customs dashboard Uses Cases, as discussed in requirement gathering sessions with NL and UK Customs, are described in the next Section What exactly is outside and what remains internal to the Dashboard is reflected in a system context diagram. That diagram is depicted and explained in Section The exact nature and contents of the interfaces with the outside world, essentially those that allow the Dashboard to find relevant supply chain data and to retrieve it from the CASSANDRA Pipeline, vitally depend on the decision with respect to the CASSANDRA Integration Architecture and the associated Interoperability standards. In the above Section Error! Reference source not found. it was proposed to adopt a Hybrid Solution. The common interface that is proposed, however, has not yet been fully fleshed out. Section will include a proposal, providing the necessary details that allow unlocking the supply pipeline data Customs Dashboard Use Cases In requirements gathering sessions with the Customs Container Targeting Teams in the UK and the Netherlands it was concluded that the major benefit of a Customs Dashboard would be in providing additional data (primarily about the real consignor, the real consignee and the actual goods description ) relating to a declaration submitted by a third party (a logistics agent). That additional data should be shown in a comprehensive view, preferably allowing for the possibility to dig deeper and access further information about the involved parties. Two potential use cases were discussed: The primary Use Case assumes that Customs want to obtain additional supply chain information about a targeted (so called amber ) declaration that has been submitted to Customs in the usual way (i.e.: the current modus operandi around declaring Import remains unchanged). 1. A Customs official will enter the ID of a container or consignment mentioned in an amber declaration; 2. The dashboard will call a discovery service, passing on the ID of the object about which additional pipeline information is desired; 3. The discovery service will return references to the (locations of the) repositories where information about the object is stored; 4. The dashboard subsequently calls all the repositories to retrieve all available (event) data about the involved object; Page 24

25 5. The repositories return the data about the suply chain object events, possibly including hyperlinked references to relevent supply chain documents which the dashboard will display in its who, when, what and where sections; 6. The user will click a hyperlink of a referenced document; 7. The dashboard will request the referenced document by following the hyperlink; 8. The supply chain partner s (extranet) system will return the referenced document; 9. the user enters the ID or the name/address of a party that he wants to obtain further information about from a Party Information Service Provider such as Dunn & Bradstreet or DG/TAXUD (NOTE: the implementation of this step is still to be decided upon); 10. The dashboard calls the service from the selected Party Information Service Provider (see above NOTE); 11. The Party Information Service Provider will return the data about the requested party (see above NOTE). Steps 8 or step 11 may end this use case. In practice, however, the user may decide to request additional information about the events by repeating steps 6 and 9. Asecond potential Use Case assumes Customs to be subscribed to certain supply chain events, i.e.: supply chain exceptions such as container integrity violations, route deviations or excess dwell times. NOTE: the implementation of this use case is still to be decided upon. 1. The Dashboard will receive a supply chain (exception) event, of a type to which Customs is subscribed, after it has occurred and the event repository that has captured the event has published the alert by calling a Customs Secure Trade Lane (STL) Monitoring component; 2. The STL Monitoring component will forward the alert to the Customs dashboard; 3. The dashboard will alert the user that a supply chain exception event was received. The two use cases are visualized in below diagram: Page 25

26 Figure 9: Use Case diagram: Customs Dashboard Interaction Customs Dashboard System Context For its implementation, the Customs Dashboard will include a UI component, called the Risk Assessment Support Portal. The STL Monitoring component discussed above, will also be considered an internal part of the system to be implemented (provided that it is decided that the raising of supply chain exception events will be included in the Living Lab). Outside of the system are the user, the CASSANDRA pipeline, including the discovery service and the event repositories of the supply chain parties. The (extranet) systems of the supply chain parties in which the referenced documents reside will also be external to the Dashboard, as well as the systems of the Party Information Service Providers. Internally, the Customs Dashboard, hereafter referred to as the system, will comprise several functional components which, together, will implement the functionality specified in the Use Case(s) described above. The system, with its internal components, the outside world and the interfaces between the system and the outside world, is depicted in the below system context diagram. Page 26

27 Figure 10: System Context diagram: Customs Dashboard Interaction The CASSANDRA Customs Dashboard comprises twomain components: Risk Assessment Support Portal, including the following sub components: o Supply Chain Data Request Handler: to support UC-1 (entering targeted object) o Data Collector: to query for event repositories, to retrieve supply chain event data to obtain possible master data, to fetch referenced documents to request party data o Secure Trade Lane Alert Handler: to flag received alerts o Data Renderer: to display: requests trade lane data (where, when, what, who) referenced documents party data alerts Secure Trade Lane Monitoring, including the following sub components: o STL Exception Alert Subscription Manager; to subscribe to STL alerts (NOTE: subscriptions will not be needed in the initial version, even if it is decided to support alerts in the Living Lab) o STL Event Handler: to listen for exception alerts, evaluate alerts forward alerts to the Risk Assessment Support portal (NOTE: to be decided) Customs Dashboard Interface towards the Pipeline The interaction between the Dashboard and the CASSANDRA pipeline and the other systems in the outside world is implemented through web services. The web service interfaces are described next: Page 27

28 Calling the Discovery Service: Query() The Discovery Service (DS) is called to obtain information about the event repositories that contain data about a particular supply chain object. How the DS itself acquires the information (by being informed when an event repository captures an object for the first time) is beyond the scope of the Dashboard. The Discovery Service interface is currently in the process of being defined as part of the GS1 Global Visibility Framework EPCIS standard specification. Although it is expected that the Discovery Service definitions, described below, will become part of the formal standard, strictly speaking they are still in a provisional state. Service context Figure 11: Service context - DS Query() Service operations The DS will expose a two-way (request-response) operation called Query with the argument query-epc-ds which takes an XML message called QueryRequest, including the ID of the involved supply chain object, as an input message. In return the service will pass an XML document called QueryResponse containing the addresses of the event repositories that contain events pertaining to the supply chain object. For the technical details about the Query interface, the contents of the XML request and response messages and the service security arrangements, we refer to the documentation about the DS in the presentation eztrack DS integation. Calling anevent Repository service: Poll() The Event Repositories of the CASSANDRA supply chain participants are assumed to expose the EPCIS Query Control Services interface, as defined in the EPCIS standard specification as part of the GS1 Global Visibility Framework. The event repositories are called to obtain information about the events pertaining to a particular supply chain object. In addition, the repositories can be queried for master data, such as the meaning of certain codes or identifiers (e.g.: for goods, locations, business steps, event types) that are needed to interpret the event data and render it to a human user in a comprehensive fashion. Service context Page 28

29 Figure 12: Service context Event Repository Service operations Any EPCIS compliant event repository will expose a two-way (request-response) operation called Poll. This operation can be called with two distinct query name arguments: o MatchAnyEPC which takes an XML message called simpleeventquery, including the ID of the involved supply chain object, as an input message. In return the service will pass an XML document containing the events pertaining to the supply chain object. o SimpleMasterDataQueryincluding parameters specifying the master data (vocabulary) object(s) about which further information is requested. For technical details about the Poll operation of the EPCIS Query Control Interface, refer to the EPC Information Services (EPCIS) Version Specification, published as the formal GS1 Global Visibility Framework standard. Calling a Supply Chain Partner s Extranet: GET The Supply Chain partners are assumed to make the documents available, whose references they have included in the events that they stored in their Event Repositories. The reference should be hyperlinked, that is: it must the Universal Resource Locator (URL) identifier, pointing to a website that supports the HTTP GET method which will return the referenced document at the request of an authorized business partner. Service context Figure 13: Service context Get Service operations By calling the HTTP GET method on the obtained URI, the supply chain partner s extranet implements a simple REST based web service. For authentication purposes, the service may also be exposed over the secure HTTPS protocol. In response to the request, the caller gets the relevant document in return. The document may be in two formats, either as a: o PDF document, or an Page 29

30 o XML document whose format must comply with the format that CASSANDRA has defined for documents of the relevant type Since, to date, there is no CASSANDRA standard for supply chain documents defined yet, the Customs Dashboard assumes the document to be in PDF format. Calling a Party Information Service Provider: getpartydata() Within the CASSANDRA project, contacts are currently being established with potential Party Information Service Providers, such as Dunn & Bradstreet or TAXUD (EORI database). These service providers expose services that will allow clients, such as Customs, to obtain additional data about a party who is mentioned in the context of a supply chain transaction (e.g: in an event or in a referenced document) and who was previously unknown to Customs or about whom Customs want to acquire additional information. Note that a decision about implementing this service depends on the conditions under which the Party Information Service Providers are prepared to participate in the CASSANDRA Living Lab. Service context Figure 14: Service context getpartydata Service operations The service that the Party Data Service Providers shall expose will need to support an operation which (the real name being yet unknown) we will call getpartydata. That operation may support several parameters by which the call can be attuned to the nature of the party ID that is available to Customs. The ID may be of a known type (D&B, GLN, EORI) or may be unknown, in which case a string, denoting the name and/or address of the sought party can be passed as a parameter. The service operation is two-way (request-response) and is assumed to return an XML file whose name, structure and semantics may differ per Party Data Service Provider and is still to be defined. Receiving a Supply Chain Exception Alert: QueryCallBack() A Supply Chain party may subscribe to (receiving) supply chain events of a particular type, pertaining to particular supply chain objects, that are generated by his business partners. In the context of the CASSANDRA Living Lab, such events will likely be supply chain exceptions, such as container route deviations, goods sold at the high seas or excess dwell times about which Customs want to be informed. Page 30

31 The GS1 Visibility Framework supports a subscription mechanism by which events (rather than being pulled by a caller) are actively pushed to the client. Whether or not this mechanism will be supported by participants in the Living Lab, is still to be decided. Service context Figure 15: Service context - Query Callback Service operations If it is decided that alerts will be supported, then in order for the Dashboard to receive the supply chain alerts, it will need to implement the EPCIS QueryCallBack service, This service is being called by the Event Repository of the party that has issued the subscription and captured the event. That service shall support a callbackresultsoperation which takes a QueryResultsmessage, including the exception event data, as its input. For technical details about the callbackresultsoperation of the EPCIS QueryCallBack Interface, refer to the EPC Information Services (EPCIS) Version Specification, published as the formal GS1 Global Visibility Framework standard 4.2 GMV dashboard for business/customs This high level architecture describes what is being developed by GMV for the trade lane Portugal (Setúbal) Morocco (Casablanca). However, and since the reality in Morocco is not yet known, some changes to this approach can occur. Page 31

32 Figure 16 High Level architecture The solution will have a web interface (dashboards) accessible through a web browser. A Web Service will be available to communicate with existing PCS s and other external systems, following a SOA architecture approach. The directory service is not yet contemplated in this diagram. For the development of the dashboards we are using the most recent trends for web development. The dashboards are being developed using MVC patterns (Model-View- Controller) and open web standards. For the MVC patterns we can describe the different layers as follows: Model: The Model holds the data of the application and contains the business rules for manipulating that data. View: The View is the presentation layer of the application that contains all the logic for displaying the data to the user. Controller: The Controller acts as a traffic broker. It passes data back and forth to and from the Model and View layers. The controller has the responsibility to determine which action the user wants to execute and direct processing to the proper function to satisfy the user request. Generally, the Model and View communicate directly with the Controller, except for the View, which can use objects from the Model for specific display purposes Dashboard access The access to the dashboard is made through a creation of a user profile. The user profile is a representation of a person s identity and is used to store a collection of data associated with a specific user that can access the system. To restrict the access to the system, GMV has implemented three entities to control the access to the system as described infigure 17. Page 32

33 Figure 17 Entities relationship, relating Users, Organizations and Roles User The User is an individual and represents a member of staff for a particular organization that can access the system. Users don t have assigned permissions directly, but assume a role (or roles) and belong to a specific Organization. Roles The Role controls the permissions to perform certain actions and controls which data can be viewed or accessed. The Roles are a grouping of users that share a particular function in the system. By default the following roles are configured in the system: Carriers, Customs, Forwarders, Consignor, Consignee, Port Authority, Police, Terminal Operator and Administrator (that will be managed by GMV). The roles can be changed by the Administrator and they are not limited to the ones specified. Organizations The Organizations are a collection of users belonging to its staff. Each Organization has one role within, the Organization Administrator, whichhas the permission to add more users in the system acting on behalf of their organization. This procedure will decrease the effort of the administrator on the task of new user creation/approval of registrations. All the users created inside the organization inherit the access rules for the role associated to that specific organization Dashboard data elements The baseline of the information to be displayed in the dashboards is described in the delivery D1.2, section 3.3: Data viewed from government perspective. In order to restrict visualization access to each of the data elements to authorized roles, we have created a matrix where we expect to identify who can see what. The availability of this information will allow a better organization of the dashboards for each of the stakeholders. (The development of this table is under development) Cate gory Data Elements Roles Carri ers Cust oms Forwar ders Consi gnor Consi gnee Port Auth ority Poli ce Term inal Oper Page 33

34 3. Cargo and Consignments 2. Cargo carrying units (transport equipment, container, pallet, ) 1. Organizations & People CASSANDRA D3.22 Interfaces v2 Public Carrier Consignee Consignor Declaration Date Preference data Licensing data Notify party Person lodging summary declaration Declarant/Representative/P rincipal/importer of record/applicant ID number Signature / authentication Container Nr (equipment identification number) Conveyance reference number Gross Mass (kg) Inland mode of transport (origin) Identity and nationality of active means of transport at departure (e.g. vessel identifier) Identity and nationality of active means of transport on border crossing (e.g. vessel identifier) Identity and nationality of active means of transport at arrival (e.g. vessel identifier) Mode of transport at the border Inland mode of transport (destination) Transport document number Calculation of taxes Consignment weight (Net mass) Country of Origin Commodity Code (HS Code) Goods Description Number of items Goods Item number Item value (price) Invoice currency Total amount invoiced Exchange rate Nature of transaction Delivery terms ator Page 34

35 6. Supply chain configuration 5. Containe r/cargo Integrity 4. Movement and milestones (Tracking, tracing CASSANDRA D3.22 Interfaces v2 Public Location of goods Identification of warehouse (export/import) Number of packages (cartons, packages) Other specific circumstance indicator Shipping Marks Transport charges method of payment code Type of packages UN Dangerous Goods Code Unique consignment reference number (CRN) Valuation method and statistical value Declaration procedure Declaration type identifier Quota (box 39) Deferred payment Container integrity* Container security device (CSD) number (if applicable) Seal number Country of export (origin) Country of destination Country(ies) of transit (routing) code Customs office of exit Customs office of entry Date and Time first place of arrival First place of arrival code Place of loading code [sea carriage] Place of unloading code [sea carriage] Table 4: Permission Matrix Dashboards Presentation As stated previously in this document, all the screenshots displayed in this document are part of the initial prototype. Some changes can occur during the evolution of the project. Page 35

36 Home page The Home page features a minimalistic view of a sign-in form, requesting and Password for authentication. There is no registration option for new Users; this will be managed by special CASSANDRA members with higher priviledges that will assume the Role of creating new users. The administrator will create Users that will assume the Administration of their Organization, and this User will then assume the task of creating further users to their own Organizations. Figure 18: The Home Page Welcome Page The Welcome page features a global, shared view across all CASSANDRA users. Features of generic interest, such as a Calendar or an Announcements board, are displayed for everyone right after login for immediate attention. Visibility of contents can be stipulated depending of the Role or Organization that the logged User belongs to.figure 19 shows an example of content that can be included in this page. Page 36

37 Figure 19: The Welcome Page Individual extra pages are shown depending of the Role of the logged in User. For instance, the Administrators can access the Administration page. Regular Users see generic site related information, like a Ships data page, for instance. Administration Page The Administration page is only visible to the Administrator. These encompass also each Organization Administrator, and it differentiates only in content visibility. For instance, the Administrator can see all existing Organizations (Figure 20) while the Organization Administrator can see only the Organizations it belongs to, as shown in Figure 21.The Actions menu allows for editing and removal of the affecting information. Figure 20: The Administration Page, as seen by the Site Manager Page 37

38 Figure 21: The Administration Page, as seen by an Organization Administrator Ships Page Users who belong to the website but do not assume Administration roles basic Users see standard generic pages, like a Ships page, with retrievable information. These pages contain the nuclear information that interests the users of the CASSANDRA platform in their normal activities. Figure 22depicts random information of what could be seen when querying information for a particular ship. Figure 22: The Ships page, a standard page for regular Users The availability and visibility of this information can be molded to be filtered by the role of the logged in User. As an example, a User that assumes a Customs role can have extra content Page 38

39 that is of its interest, but it will not be available to a User with the Police role. Reversely, the same goes for information that can be of interest for the latter but not for the former Managing the CASSANDRA website Creating Organizations Organizations are the higher lever aggreators of Users. An Organization s creation is a Role assigned to the Administrator, who increasingly adds them as they join the CASSANDRA platform. Figure 23: Adding an Organization Specific Roles can be assigned to Organizations, grouping them in sets with particular permissions or purposes, which can then be inherited by its Users. For instance, several Carriers Organizations can be grouped under a single Carrier Role, which allows transversal permissions across all of them and into its Users. Updating Organizations Further information can be provided to an Organization, if intended, to add increasing details that can be useful for others. Page 39

40 Figure 24: Adding information to Organizations Example information that can be of interest is shown in Figure 24, such as Addresses and Phone Numbers. Creating Users Users are the individual participants of the CASSANDRA website. Users can be created by the Administrator and by the Organization Administrator. Minimal information is necessary to create a User. Figure 25: Creating a User Page 40

41 Updating Users Much like the Organizations, Users can be updated with increasing optional information, as seen in Figure 26. Figure 26: Adding information to Users Different groups of information can be included, completely optionally. For example, there is an option to include Addresses or Phone Numbers. Page 41

42 Users and Organizations Inside an Organization, the Organization Administrator has the option to Add new Users, as well as seeing current existing Users and executing maintenance operations over its information. Roles Figure 27: Administrating an Organization Roles are sets of permissions or visibility filters that can be applied to Users and Organizations, and more than one can be assigned to the Organizations or Users. These roles are pre-defined by the CASSANDRA Administrator and are immutable. Figure 28: Available Roles; can be assigned to Users or Organizations. Page 42

43 5 IT Environment Lab The IT Environment Lab will be the Environment for testing innovative solutions to achieve an ideal world. This world uses a common ontology to model the entire logistic processes and interfaces. In this world, the interoperability is the key factor: logistic processes, definitions, services and interfaces are commonly shared. The design and objectives of the IT Environment Lab will be achieved in parallel with the objectives of the Backbone and the Dashboards. This will facilitate the adaptation and usability of this environment development into the current/real world of CASSANDRA: Dashboards could make use of the advantages of the developed technology to provide a better data integration for risk analysis. For example, the IT Environment Lab will define data capture interfaces (and services) to expose information through the data pipeline for piggy backing process (interaction with the Dashboards). The Backbone could be configured thanks to the use of common interfaces and profiles. Living labs could be used as scenarios for testing IT Environment Lab technology. Profiles could be created by stakeholders to expose their services. Thus, interoperability tests could be done in a real Environment. The IT Environment Lab objectives will be based on the CASSANDRA architecture: concepts, interfaces and objectives (described in the deliverable D331 Integration Architecture(1)). Actually, the designed interfaces and the information exposed by them will create the data pipeline vision. The main development points of the IT Environment Lab are described in the following chapters. 5.1 Profiles management The IT Environment Lab mainstay refers to a supply chain Environment composed of profiles. These profiles describe a common understanding of logistic business, fostering interoperability and facilitating services integration by stakeholders. But, what is a profile? A profile is an actor description using a common (reference) model. This description includes business operations in terms of offers (what an actor knows how to do: provider) and goals (what an actor needs to do: customer). Thanks to the use of a common model, this description is understandable, shareable and used by everybody participating in this Environment. In CASSANDRA, the common model would be an ontology based on the WCO 8 data model v3 (or similar standards). These standards are in charge of modelling entities: actors, roles, activities, operations, etc. 8 WCO: Page 43

44 Figure 29:Provider profile instance With an ideal Environment composed of profiles (customers and providers) a new world of interoperability and supply chain visibility features is opened. Also, new business possibilities will be possible, based on the composition of supply chain actors. This logistic world facilitates the interoperability.not only for the current stakeholders and customs, but also, for new actors willing tojoin to a supply chain. Again, the key is the interoperability. The IT Environment Lab follows the CASSANDRA(1)architecture guidelines. So, profiles will define communication interfaces according to Data Capture (DC), Data Sharing(DS) and Logistic Sharing (LS). But also, these interfaces will be compatible with the CASSANDRA backbone point of view: Business System to Business System, Traders to Business Systems and Customs to Business Systems. Using these architecture premises the IT Environment Lab developments would be integrated into the Living Lab. 5.2 Data storage infrastructure The data storage manages profiles and ontology models with their semantic functionalities. This storage solution will be implemented as a framework that could be used to create different applications with functionalities such as: Users Management Profiles Management Semantic Searches and Matching Common Data Model (ontology) Management Common tools and functionalities Using this framework, different profiles management solutions could be implemented. In fact, the framework will be able to connect to different storage systems implementations. From a functional point of view, a knowledge repository is a semantic repository, where resources are stored semantically following an ontology 9 model. Inferences, queries, searches are also features of this data storage infrastructure. For example: inferences could find compatibility in destinations between France and Paris. Summarizing, the data storage framework exposes functionalities (above) for profiles management and it also connects (below) to a knowledge repository. In the case of the IT Environment Lab the functionalities will be exposed trough a REST interface. 5.3 REST interface 9 Ontology: Page 44

45 The REST 10 interface will make use of the data persistence storage, exposing the functionalities as web services. Thus, the IT Environment Lab will implement the SOA 11 proposed CASSANDRA architecture and their interfaces (DS, DC, LS). REST is a good solution to implement SOA architectures. Specially, in scenarios with a strongresources focus as opposed to(classical) services executions The design of this REST interface will facilitate the use of the more complex semantic issues and the data storage infrastructure. Thus, different applications could be implemented without needing to have a strong knowledge and expertise in semantics, delegating this responsibility to the data storage framework. 5.4 Web Application for profiles management A web application will be used as a user s interface to manage the different profiles of a stakeholder using the IT Environment Lab technologies. Following, a list of functionalities provided by the application: Register company Create/Show Customer/Provider Profiles Logistic Operations Company s business activities Modelled by the common data model Configure profiles: Common data model: Transport Activity Profile Instance: Transport of boxes from Madrid to Paris The different configuration options we will be exposed regarding the ontology possibilities and logical requirements. By the other side, configurations options such as prices will be considered as part of the internal business logic. It should not be exposed as a configuration option. Show your profiles Visualize/Edit your configured profiles Search for logistic operations (activities): WebTool to search for logistic operations. Compatibility between profiles of customers and providers Figure 30:Compatibility between profiles of customers and providers 10 REST: 11 SOA: Page 45

46 The profiles matching will allow finding compatible profiles from a semantic point of view. For example: Goal: To send bananas from Madrid to Paris Offer: To send goods across Europe (This kind of search (profiles matching) opens a new world of possibilities; actors can expose their services easily in a common understandable way. It also brings the possibility of multiple supply chain configurations and to react dynamically to reconfigure the supply chain in real time) 5.5 Operational Environment The operational Environment exposes the real services that have been described with profiles. These services include common interfaces to facilitate the processes execution. These common interfaces (modelled with the ontology) have to be engaged with the real IT systems of the company. In the scope of the operational Environment different alternatives will be studied to facilitate these engagements: ontology matching with data bases, SAWSDL 12, data transformation with XSD. 5.6 Specific Objectives to achieve for this release The main objective of this section is to expose a quick and clear idea of the main software components news in each release. This should facilitate the correct understanding of the different progresses in each deliverable, due the IT Environment Lab is been improved continuously during the T340 and T350 timeline Currently situation: we are releasing the second version of the deliverable D322 explained under the section February All the generic objectives, of the different software components, are explained in the following sub-sections (web applications, data storage...). Date: February 2013 As an update for the D3.22 the IT Environment Lab implements a new authentication and authorization mechanisms based on roles. An overview over this new feature: The system will allow companies to be registered through a web form. The system will store semantically this information creating a new resource of companytype. Automatically the system will also create a new user that will act as an administrator onbehalf of the recently created company. This user is also stored as a new semantic resource. This user will be able to login into the system to create profiles and activities or new (regular) users. They could also login into the system to create profiles and activities. With this new scenario, the system provides a first approach for data management with authentication and authorization. The different resources created will possess an owner that 12 Page 46

47 would allow creating different privacy policies. Also, users and resources belong to a first level entity, which is a company. The next update in D3.23 of the document will make an special emphasis on: User s guide, re-adapted to the last version of the ontology, making use of the new concepts and specifications. Specially, from the point of view of how to configure a business service. New funcionalities regarding authorization and privileges Improved services configurations adding into profiles information about: o Execution process: url, port, protocol, messages, implementation details o Business process: semantic patterns and processes related to the configured activity. This funcionality will require a new semantic tool to describe processes with a BPM editor. Figure 31: Business Process Example Date: October 2012 This chapter describes the specific developments of IT Environment Lab technologies for the first deliverable of T350 (D321), expected for October The first developments will be oriented to a first proof of concept to begin demonstrating the explained concepts and goals Web application Functionalities supported by the first version: Basic users management Basic companies management Create company description Basic profiles management Logistic operations matching: a customer profile could search for compatible provider profiles. Specific Improved functionalities in the D322 (Date February 2013): Page 47

48 Mainly improved user management and company registration. Previously, you could create company resources in the system. Now, you will register companies (that implies a resource creation together with an administrator user). This difference provides a hierarchy regarding the resources created: the top level of the hierarchy contains companies which possess different users (regular and administrators). After that, the different profiles and activities belong to users who act onbehalf of their companies. Figure 32: Register Company After a company registration, the system creates, automatically, an administrator user. The application also allows administrator users to create new regular ones after login. The user s authentication is implemented thanks to the use of Spring Security framework allowing a great variety of authentication and authorization possibilities: DDBB models, OpenID, Facebook Connect, etc Data persistence storage and REST interface Data storage (with their knowledge repository) will be exposed through a REST interface to offer functionalities, such as web services. The REST interface will expose services for: Users management o Web application login o Create/Delete users Company resources management o Create/Delete/Update/Show companies Profiles management o Create/Delete/Update/Show profiles (LS) Profiles matching for better interoperability o Search of compatible profiles Ontology Support to be used by the web application Page 48

49 o o o Get classes of type Activity Get classes of type Role Get classes of type Actor Example of a REST s interface specification: Create Basic Company This interface registers a resource of type Company with basic information (update in the version released with the D322 February 2013) url: method: PUT POST The profile's data is uploaded with a JSON with the next template: JSON to upload entity Company { } "entities": [ { "@class": "Company", "type": "Company", "name": "company_name", "description": "company_description", // Optional "login": "company_login", // Optional "password": "company_password", // Optional " ": "company_ ", // Optional ] } "addresses": [ ] "company_address", "company_address" // 0..N Optional The execution result is returned using the next template: JSON returned data { } "meta": { "code": code_id, "description": "description" } The finished execution of this process will create automatically a new user with the login/password information received in the request. This user will have an administrator role Operational Environment Page 49

50 For the first demonstration, an execution of a logistic service will be available. This service will log the process s steps, storing data that could be accessiblethrough a Dashboard (DC),PiggyBacking. The servicewill be executed (DS) between a customer and a provider following an instruction-planning-report pattern. As a proof of concept, the operational Environment will expose a simple service to be executed. Some functionality that will be probed: The service is part of the actor s profile. The different steps of the process execution (instruction, planning, and report) will be stored in the data persistence storage system. Accessible through the Data capture/sharing interface This information could be monitored through the Data Capture interface, PiggyBacking. The data to be monitored will be specified thanks to the pieces of data for security defined in the CASSANDRA project. This first service involves only a customer and a provider. Next versions will include more complex situations with interactions between several actors (Orchestration and Choreography) Therefore, the operational Environment will expose the Data Capture and Data Sharing interfaces Involved Technologies Different IT solutions have been studied to achieve these first objectives. Technological options have been selected, but the entire Environment will be designed with technological independence in mind. For example: GWT for the web application could be replaced with a native Android application using the REST interface. Following a list of selected technologies: Web application o GWT to develop the application. Java for development, but generating HTML, JavaScript and CSS. Great adaptability features REST interface o Jersey Framework (Java) Knowledge repository o Jena Framework (Java) 5.7 Global architecture with CASSANDRA s architecture interfaces This picture shows a global overview of the architecture defining the layer where the CASSANDRA s interfaces are implemented: Page 50

51 Interfaces: * CM: Configuration Manager * LS: Logistic Sharing Web Application REST Services CM LS Data Storage Data Model Data Storage Ont. Model Ont. Model Profiles Profiles Figure 33: CASSANDRA architecture and interfaces 5.8 User s guide: This user s guide shows the functionality for the first prototype. This prototype web application has been developed using the explained semantic framework to manage profiles. Using this framework as a base, the web application will be extended with new functionalities regarding the extracted requirements for the next development phases. Currently, the web application supports the basic functionalities specified for the first prototype in the previous chapters Login page The Login page is the first page of CASSANDRA, where a user could make a registration or login process(to enter inside a CASSANDRA community). After login, the application goes to the listing of companies. Page 51

52 5.8.2 List of companies Figure 34: Login page This page shows a list of companies participating in the community. Currently, it shows all companies, but in the future will consider permissions functionalities. From this page the user can view the details and profiles of a company, add a new company or edit an existing one. It also providesextra features to add warehousesand to makesearches of activities Insert warehouse Figure 35: List of companies From this page the user can addnew warehouses of type Place of Acceptance or Place of Delivery. This locations are used later to configure activities (services). Figure 36: Insert warehouse Page 52

53 5.8.4 Search activities This page allows making semantic searches between all the activities provided by the companies inside the community. It allows users to apply filters for more precision, those filters are: Services (type of the activity), and locations Acceptance from and Delivery to. Actually, this page supports the matching between offers and goals thanks to the use a common semantic model and the developed semantic framework for profiles Add / edit company Figure 37: Search activities From this form the user can add / edit the details of a company. The only required field is Name. Figure 38: Add company Figure 39: Edit company View company / List of profiles This page shows a list of profiles that belongs to a specific company. From this page the user can view the details of a profile and their relatedactivities. Possible actions: add a new profile or edit an existing one. Page 53

54 5.8.6 Add / edit profile Figure 40: View company / List of profiles Once you have a company registered, you can establish different profiles for the company according to his logistic business. Using the next form the user can add/edit the details of a specificprofile. The required fieldsare: Name, Actor and Role. The name of the company is not editable because the profile belongs to this company. Each profile is configured with a type of Actor and Role (Consumer or Provider) selected from two combo boxes, whose content is provided from the ontology. Loading/Updating the ontology in the server will expose new information for profiles creation. Figure 41: Add profile Figure 42: Edit profile Page 54

55 5.8.7 View profile/ List of activities This page shows a list of activities that belongs to aprofile. From this page the user can view/edit the details of an activity andcreate a new one. Figure 43: View profile / List of activities Add/edit activity From this form the user can add / edit the details of a specific activity (service). The required fields are Name, Acceptance from, Delivery to and Type. Each activity is configured with places of Acceptance from and Delivery to (which have been previously created in the page Add warehouse and stored in the semantic repository). The activity is also configured with a type of activity (provided by the ontology). Currently the only service that could be configured will be the Transport s Activity. Figure 44: Add activity Figure 45: Edit activity Page 55

56 This form could be extended with more configuration options regarding the ontology model, for example, with options about dates or modes of transport. This application is just a prototype constructed over the developed framework to manage profiles; it will facilitate this kind of extensions and new functionalities. Page 56

57 6 Ontology design (Semantic Data Model) 6.1 Introduction The logistics domain is a complex domain that involves a large number of actors (e.g., authorities and organizations), resources used and exchanged between these actors (e.g., containers and transport means), relations that properly link actors to their corresponding resources, and constraints that restrict the usage of the available resources under certain conditions. Often, these actors use different terminologies/standards to represent/exchange their information and adopt different technological solutions to implement their IT systems. At the same time, these actors need to interoperate with each other in order to fully exploit the possibilities offered by today s global market. Therefore, there is a need to foster communication, understanding and exchange of resources and information among logistics actors that use different terminologies/standards and heterogeneous IT systems. In other words, there is a need for semantic interoperability. Ontologies have been acknowledged as a powerful means that can be used to achieve semantic interoperability [1,2,3]. Towards the semantic interoperability goal, we propose an ontology for logistics that is beneficial for the following two main purposes: 1. Improve communication and re-use of knowledge, by providing a shared understanding that reduces ambiguities and misunderstanding in the terminology adopted by different actors in the logistics domain; 2. Facilitate the integration of existing systems, by providing a reference model that allows translation and matching, possibly automatically, among multiple heterogeneous systems that have been developed based on different semantic representations. We acknowledge that a single common ontology to improve communication and facilitate system integration for all possible applications in logistics is not feasible, since this ontology would become too complex and difficult to maintain. Therefore, we propose the development of a network of ontologies that is based on a core ontology, which explicitly specifies the main concepts adopted in the logistics domain. This core ontology can be further extended by creating new ontologies for the specific purpose of individual applications. 6.2 Core ontology The development of a core ontology (i.e. the identification of the main concepts) in logistics is not a trivial task. Nevertheless, virtually all practitioners in the logistics domain informally say that logistics is all about transporting something from a place of origin to a destination in a certain time and under certain conditions, so the key words transport, something, place of origin, destination, time and conditions are already hints to what type of concepts can be included in such a core ontology, regardless of its specific application in logistics. In general, we can consider logistics as the set of activities and events that take place among several actors in order to deliver certain products at the right time, right place and under the right conditions, by using suitable resources. Therefore, we propose a core ontology for logistics that is built on top of foundational concepts shown in Figure 46. Page 57

58 Figure 46: Foundational concepts (upper ontology) An Activity denotes some action and is relevant for the purpose of logistics, such as, for example, the activities of transport, storage, transhipment, loading and unloading. Some activities are atomic and can be used to compose more complex activities. For example, we can define a complex activity called full transport, which is composed by the following three atomic activities: (1) the loading of transport means with certain items in a location of origin, (2) the actual transport of these items, and (3) the unloading of the items at a destination location. Figure 47: Activity An Event represents an occurrence of interest for the execution of a certain activity. In contrast to an activity, which denotes an action that is continuous in time, an event denotes an occurrence at a specific moment in time. For example, the departure of a transport from a location of origin and its arrival to the destination can be regarded, respectively, as starting and ending events for the transport activity. Page 58

59 Figure 48: Event An Actor represents organizations, authorities or individuals that offer or require activities and operate on resources related to these activities. An actor can play a Role, for example consumer or provider. Providers publish their offers according to a service description, which specifies the type of activities, resources and conditions that the actor can satisfy. Provider offers are matched with specific consumer requests. The same actor can play the role of consumer or provider in different moments in time and depending on the activities. Figure 49: Actor/Role An Entity represents something that is used or exchanged during an activity. We distinguish between an Entity in a Spatial Entity, which represents tangible objects, such as equipment or a person, and an Intangible Entity, which represents intangible objects, such as a modality, a characteristics or a dimension. We also define a TemporalEntity, which represents the start time, end time or time interval associated to activities and events. In this regard, since time is a basic (foundational) concept relevant for logistics, but common to other domains, we re-use the time ontology proposed by W3C ( instead of specifying our time ontology from scratch. Page 59

60 Figure 50: Entity A Location represents the geographical area or geographical point used to define the place of origin and destination for entities and activities. Location can have different levels of granularity. Location can be coarse-grained for scheduling, since in long term planning it is sufficient to specify approximately the place of origin and destination, such as, for example, the Netherlands or the port of Rotterdam. However, location needs to be fine-grained for delivery, since one has to specify the precise address to which a certain item must be delivered. Figure 51: Location Figure 52 shows the mutual relationships between the foundational concepts described above (Activity, Event, Actor, Role, Entity, Location). Page 60

61 Figure 52: Activity 6.3 Moveable Resources and Static Resources This section focuses on the objects that are particularly relevant for logistics operations. We have classified these objects in Moveable Resources, which are characterized by the capability of moving on their own or being contained in another entity for the purpose of movement, and Static Resources, which are used to host and/or handle moveable resources. Figure 53: Moveable and static resources Page 61