UN/CEFACT Smart Container Project

UN/CEFACT Smart Container Project

Next steps: From Data elements to APIs

Hanane BECHA, Project Leader

Michael Schroeder, Editor

Todd Frazier, Editor

02/04/2019

Outline

I. Standards, SOA Concepts and APIs

II. UN/CEFACT Approach

III. From Data Elements to APIs (Application Programming Interfaces)

Step 1. White Paper - completed

Step 2. BRS Development – in process

Step 3. Messaging Development – in process

Step 4. API Development – planned

IV. Summary

I. Standards, SOA Concepts and APIs

APIs for SOA

• Service Oriented Architecture (SOA) is an architectural methodology built upon the concept that capabilities should be implemented as services. The ‘Client’ can utilize any software component following the usage specification, irrespective of the technologies upon which the service was developed or upon which the 'calling client' was developed.

• Application Programming Interface (API) is a source code-based specification to be used as an interface by software components (services) to communicate with each other. Independent SOA services communicate using a common API.

• APIs can be created in any chosen syntax (Web Services) based on standardized syntax-neutral data exchange structures (Master data exchange structure)

• API is a layer for providing data access. API's should be architected with SOA support in mind (e.g., JSON, REST, SOAP).

Increasing interest in API Standardization

• ISCO. A new UN/CEFACT group developing API standards.

• Openshipping.org aims to define APIs. In particular, a specific API covering the Container Status Moves for shipping lines and BCO usage only

• Digital Container Shipping Association (DCSA): A new association to encourage collaboration on digitalisation, standardisation and interoperability in the container shipping industry.

• INTTRA, a US-based software firm spearheading a non-commercial initiative CONNECT to develop standards and data sharing protocols to help improve the free flow of information between carriers, ports, freight forwarders and BCOs.

Reduction on a single format reduces the amount of necessary mappers

Without a common format, each actor With a common format, the actor only needs to communicate using a format needs to maintain one commonwith each individual; i.e. many formats standard of communication.are necessary to communicate to all.

A

B

CD

E

A

B

CD

E Standard

Format

II. UN/CEFACT Approach

Global Trade – Semantic Anchors

A Global Standard must be based on a common repository of terms. The UN/CEFACT Core Component Library is this repository. (see examples below)

• Shipment (Trade Delivery)

• A shipment is an identifiable collection of one or more Trade Items (available to be) transported together from the Seller (Original Consignor/Shipper) to the Buyer (Final/Ultimate Consignee):

A Shipment can only be destined for one Buyer

A Shipment can be made up of some or all Trade Items from one or more Sales Orders

A Shipment can have only one Customs UCR

A shipment may form part or all of a Consignment or may be transported in different Consignments.

• Consignment

• A consignment is a separately identifiable collection of Consignment Items (available to be) transported from one Consignor to one Consignee via one or more modes of transport as specified in one single transport service contractual document:

A Consignment can only have one Transport Service Buyer

A Consignment can only have one Transport Service Provider

A Consignment can only have one Consignor

A Consignment can only have one Consignee

The Transport Service Buyer can be either the Consignor or the Consignee

A Consignment is made up of one or more Consignment Items

A Consignment can be made up of some or all Trade Items (aggregated into Consignment Items) from one or more Shipments

UN Layout Key Families

Building semantic models using a common library

Supply Chain(BUY PAY Context)

Reference Data Model

e.g. Invoice

e.g. Order

e.g. Quotation

BUY PAY Master (Master message structure)

BUY SHIP PAY Reference Data

Model

UN/CEFACT Core Component Library (CCL)

Based onBased onBased on

Based on

Multimodal Transport(SHIP Context)

Reference Data Model

e.g.Bill of Lading

e.g. Booking

e.g. BayPlan

SHIP Master

(Master message structure)

Based on

Based on

Based on Based on

Based on and subset of

BUY SHIP PAY MASTER(Master message structure)

Based on

Based on

Based onBased on

UN/CEFACT BUY-SHIP-PAY reference data models• Cover the data requirements of the international supply chain (BUY-SHIP-PAY)

process model

• Share a common library (subset of the UN/CEFACT Core Component Library –CCL)

• Include “Master” exchange syntax neutral message structures for developing process aligned subset structures

• Subset message structures can be realized into any required exchange syntax (e.g. JASON, any XML or EDIFACT etc.)

• Support collaborative information sharing

- such as enabled by data exchange pipelines

UN/CEFACT – International Code Lists

13

Rec 16

UN/LOCODE

Rec 5 (ICC)

INCOTERMS

Rec 9 (ISO)Currency Codes

Rec 20 Units of

Measurement

Rec 28Transport Means

Type Codes

Commodity

Codes (WCO HS)Rec 21

Package Type Codes

Multiple

UN/EDIFACT Code Lists (UNCL)

Rec 7

Date Formats

Rec 8

UNIC

Rec 24 Logistics Status

Codes

Rec 19Transport Mode

Codes

Rec 3 (ISO)Country Codes

III. Step by Step: From Data Elements to APIs

Share a common understanding of the Smart Container Business use cases & stakeholders: SCOPE

Smart Container White Paper1

Define structured data elements generated by smart container

and their qualifiers TERMINOLOGY /SEMANTIC

Business Requirements Specifications (BRS) & Entities Relationship

Diagrams

2

Select the data elements for a given use case

Generic message structure (Technology

Neutral!)3

APIsChoose the SYNTAX (language) to

be used to communicate4

Steps Deliverables Resources

Project Working Group from different backgrounds

UN/CEFACT CODES Lists & Multi Modal Transport

Reference Model (MMT)

Contextualized Notification Messages Structures

Multi Syntax World

UN CEFACT T&L Domain Smart Container ProjectStep by Step: from Data Elements to APIs Current efforts 2

Project Time Line 10/17 1/18 4/18 6/18 10/18 1/19 2/19 4/19 6/19 10/19 4/20

PAST

• UN/CEFACT Forum – 10/17, Rome, IT - Project proposal and head of delegations approval

• Interim – T & L Domain, – 1/18, Start of the Smart Container Project

• UN/CEFACT Forum – 4/18, Geneva, CH

• Interim – 6/18, Work Session, hosted by CIF/David Roff, Liverpool, UK

• UN/CEFACT Forum – 10/18, Hangzhou, CN

• Interim – 1/19 Semantics and Message Structures, Smart container data model review , Paris, FR

• White Paper published, UNECE – 1/19

• Interim – 2/19, Smart Container data model and BRS document, Marseilles, FR

• UN/CEFACT Forum – 4/19, Geneva, CH

PLANNED:

• Interim – 6/19, Messaging and API Work Session, TBD

• UN/CEFACT Forum – 10/19, TBD

• API Development – date TBD

• BRS document, publication target – 4/20

• UN/CEFACT Forum – 10/19, TBD

NOTE: Between face-to-face meetings we have been conducting weekly conference calls to continue progress

Step 1: White Paper on real time Smart Container data for supply chain excellence

White Paper Excerpt

Contributors - Smart Container White Paper1. Hanane BECHA, Smart Container Project Leader (TRAXENS, Marseille)

2. Michael Schroeder, Smart Container Project Editor (Hapag-Lloyd AG - Project Manager / IT Consulting, Hamburg)

3. Todd Frazier, Smart Container Project Editor (FedEx/IATA, USA)

4. Stellios Stratidakis, Marine Traffic, Athens

5. Jaco Voorspuij, GS1

6. Laurent Gonzalez, GS1 France

7. Bertrand Geoffray, BIC , France

8. Jorn Heerulff, BIC,

9. David Roff, CIF, UK

10. Christophe THUILLIER (Port of le Havre.. Unfortunately, he is deceased a day or two before Christmas!)

11. Victor Dolcemascolo, French Gouverment

12. Joelle Friedmann, Geneva

13. Cleiton Alves dos Santos Joao Simoes, Brazilian Customs

14. Rudy Hemeleers, E-CMR Project Editor, DTLF rep. and an Independent consultant Luxembourg

15. Lance Thompson, Secretary, UN/CEFACT - UNECE Geneva

16. Ian Watt, UN/CEFACT Vice Chair: International Supply Chain, Australia

17. Sue Probert, UN CEFACT Chair and an Independent consultant

Step 2: Semantic

This is an example of an existing data model of the UN/CEFACT Core Component Library

UN/CEFACT Smart Container Modeling

SEMANTIC MODEL MultiModal Transport (MMT)

(subset of BSP)

MultiModal (MMT) Master message structure

Smart Container message model

APISmart Container Data schema

Buy/Ship/Pay (BSP)Semantic modelSubset of CCL

BUY SHIP PAYMaster message structure

MMT subsetExchange Syntax-neutral data exchange structure

Part of

Part of

Sensor

Sensor ID

Sensor Owner ID (optional)

Sensor Manufacturer ID (optional)

Sensor Position (optional)

Sensor type Enum

Sensor Unit Enum

Characteristics Range of Values [X, Y] (optional) ??

Expected Values Setting Configuration range [A, B] (optional)

TimeStamp

Universal UTC

Date

Hour

Minutes

Seconds

ZOI (Zone Of Interest are the places in “the itinerary/trip plan” for geofencing/facility) ??

Place Type Enum {Depot pick-up, Master Contract Consignor Place Of Acceptance, POL,

POT, POD, FDD, Depot return} (optional)

Indicator Public information OR Private information (optional)

Place Code (optional)

Place Name (optional)

Booking Reference??

Booking Reference ID (optional, example empty container)

Transport Equipment Operator (optional)

Transport Equipment ID

Trip plan {ordered set of legs (start ZOI + end ZOI) + mode of transport + Party+

ETD/ETA}??

House Transport Contract Reference(s)

Indicator Smart Booking

Requested/Expected measurements for the different sensors (e.g., humidity,

temperature settings)

Responsible Container Party

Responsible Container Party ID

Contact

Email (optional)

Phone number (optional)

Indicator ZOI or Leg

Linked to the leg/ZOI of trip plan

Semantic: Smart ContainerThis was a start on defining the semantic, currently in progress, for the Smart Container Project. This is based on the Multi-Modal Transport Data Model.

BRS Excerpts

Component Library Approach: Reduction of complexity through reusable document building blocks

23

Article IDDescriptionPriceColorWeight

Article

Article IDDescriptionPriceColorWeight

Catalog_Article

Article IDDescriptionPriceColorWeight

Order_Article

Article IDDescriptionPriceColorWeight

Invoice_Article

Contextualization by omitting non-used elements

Contextualized messages structures

24

Bill of Lading/IFTMCS

Container BayPlan/BAPLIE

Pipeline Data Exchange Structure (CORE/SELIS)

C

Operational Manifest/IFCSUM

1:1

1:1

1:1

1:1

1:1

1:*

1:1

1:1

1:1

1:1

1:1

1:1

1:1

1:* 1:*

1:1

Step 3: Example Smart Container Message layout (work in progress)

Step 4: API based on Generic Master Message structure to serve the whole ecosystem

Smart ContainerData

Elements/message

Multimodal TransportReference

Data Model

UN/CoreComponent

Library

New data

Elementshighly cross-compatible Smart Container API

APIs: JSON, REST, SOAP, etc.Multi Syntax world

IV. Summary

Summary

• CCL as semantic building blocks for the definition of business data for processes - Context free – reuse in multiple business sectors

• Customization of generic core components to specific business sectors and application domains

• Specific APIs (code-based specifications) to be used as interfaces by different services (software components) to communicate with each other and build a composite service.