Definition and context of development and usage

e-Freight Framework

e-Freight

Origin

The e-Freight Framework as used in this project is also known as the Common Framework. Its development started in the FREIGHTWISE project as a response to the EU Commissions request for a framework for information exchange in transport and logistics. At the time of FREIGHTWISE, a number of EU projects aimed to develop THE standard framework for information exchange in logistics and make it an international standard. The people involved in these projects understood that collaboration was better than competition, and that led to the joint effort of creating “One Common Framework for Information and Communication Systems in Transport and Logistics”.
The projects involved were: FREIGHTWISE, e-Freight, INTEGRITY, Smart‐CM, SMARTFREIGHT, EURIDICE, RISING, DiSCwise, iCargo, COMCIS, eMAR and others.
This joint initiative also led to the ambition of making the Common Framework an international standard, ultimately approved by ISO.
The standardisation process started in 2008 through cooperation with the technical committee in OASIS that was developing version 2.1 of UBL. Much work was involved in adapting the ideas of the Common Framework to the principles of UBL and to provide the required backwards compatibility. Eventually key elements of the Common Framework became part of the official version of UBL 2.1.
After making UBL 2.1 complete and official, OASIS started a process of having this standard accepted by ISO. This process was completed late 2015, and elements of the Common (e-Freight) Framework are now part of ISO/IEC 19845.

e-Freight

Common Framework

The development of the Framework started by defining the roles that were involved in transport and logistics:
Logistics Services Client (LSC) – associated with the Logistics Demand domain, where demand for logistics services originates and where such services are being purchased.
Logistics Services Provider (LSP) – associated with the Logistics Supply domain, which responds to the demands from LSCs.
Transport Network Manager (TNM) – associated with the Transport Network Management domain and responsible for providing information about availability and status for the transport and logistics infrastructure.
Transport regulator (TR) – associated with the Regulation Enforcement domain and responsible for ensuring that transport and logistics operations are being conducted according to rules and regulations.

The scope for the Framework was all transport modes and combination of modes into multimodal services. It was also realised that the role that has been called Freight Services Integrator (FSI) is not a separate role in relation to the ones described above. The FSI characterises an organisation or person that combines the roles of LSC and LSP in order to conduct business. From an information exchange point of view, the FSI does not have any special requirements.
By carefully analysing the information required by these roles to do a proper job, the reference model described in Figure 1 illustrates the domains and a minimum set of electronic documents that are required for operators in the different domains to do their jobs properly.

These electronic documents are:
Transport Service Description – TSD,
Transport Execution Plan – TEP,
Goods Item Itinerary – GII,
Transportation Status – TS,
Multimodal eWaybill – MWB,
Transport Progress Status – TPS, and
Common Reporting Schema – CRS
The TSD, TEP, GII, TS, and TPS are part of the ISO/IEC 19845 standard.