Activity leader: Puertos del Estado

The aim of this Activity is the development of a Master Plan setting out the organisational, functional requirement and technical specifications required to enable the federative network of platforms concept.

The development of the Master Plan will be based on a combination of the elements developed in the Core Operating framework and the four design principles as developed in the DTLF combined by a validation thereof through the execution of Pilots and Living Labs in Activity 3. In this process the relevance of the CEF building blocks will be screened and addressed.  March 2020 an Interim Masterplan all be published, The Interim Master Plan will be the basis for constant interaction with the various pilots and living labs. The test results will ensure the revision and validation of this Interim Master Plan leading towards the final Master Plan, to be published November 2023.

This overall scope will include recommendations for national and international, public and private platforms. The essential requirement for the platforms is the need to ensure interoperability with and for service providers on a national as well as cross border basis. Specific requirements related to the various beneficiaries will be identified and tested in Activity 3.

The Activity comprises the following sub-activities:

•​Sub-activity 2.1: Design Principles

The Master Plan will further detail the four design principles of the federative network of platforms as recommended by the DTLF, namely:

• Plug and play – each user should be able to register and connect to a platform of choice and select the services it needs.

Processes and data structures will be specified to support the registration of a user and the ‘connection’ of its organisation's IT back office systems to integrate one or more selected Technology Independent Services. A public administration will indicate its data requirements for B2A data sharing with business. The ‘connection’ of IT back office systems can be done by creating a user’s organisation specific ontology. This will be based on or should be compatible with the ontology of the Technology Independent Services. This organisation’s ontology would then be mapped to the IT back office semantics, potentially by applying machine learning.

• Technology independent infrastructure services – the services of the platform should be designed technology independent, thus enabling different providers to offer a solution that best fits their end-users and to support different technologies for realising the services.
  
  The various Technology Independent Services will be specified on the basis of the DTFL's recommendations and more particularly:
  • Semantic model – an ontology supporting various standards of choice, modelling data to be shared between any two stakeholders in logistics, covering both B2B and B2A.
  • Process – the sequenced interactions between any two stakeholders.
  • Data – the minimal data set for each of the interactions identified in the processes. There may be variants to these data sets like mode specificity, commodity type specificity (e.g. reefer cargo, dangerous cargo), etc

Technical representation of the interactions. An example of this is Application Programming Interfaces supported with software code operating on a blockchain backbone.

• Federation – the commodity will establish harmonized connectivity and interoperability of different solutions (platforms). It will consist of platforms of different service providers, whereas these platforms can also operate in an enterprise domain, thus creating so-called peer-to-peer solutions.
  Various platforms and stakeholders’ solutions will be integrated via common data sharing protocols based on API (application programming interface) and semantic data standards. An example of this could be a Blockchain backbone whereby each participant could implement a BigChain DB note and become part of a cluster, or implement its own cluster, interconnect with other clusters by an InterLedger Protocol. To set up such an infrastructure the requirements of the various stakeholders of a Living lab should be assembled.
• Trusted, safe and secure – the commodity and its (integration with) end-users should be trusted, data sharing should be safe, secure and based on minimal central governance. Rules of engagement and behavioural rules will be developed; requirements in terms of Identity and Authentication on an international scale will be collected; registration and access rights; data governance and monitoring; data quality -provenance, and – integrity; roaming aspects related to a designated point of entry; governance and certification of the technical infrastructure (Plug and play; Technology Independent Services; federation); etc. Relations with (open) standards will be identified and potential for development of open standards.

•​Sub-activity 2.2: Technical Architecture
This sub-activity will elaborate requirements on a set of components such as a registry (database used to store configuration information about the installed software) and APIs mapped on the four design principles. It is essential that a federated network of platforms is technology neutral due to, amongst others, the dependency of the data integration of existing IT systems in the various EU Member states, i.e. relating Port Community Systems, Traffic and Corridor Management Systems, Single Window Applications, UCC (Union Custom Code) implementation schemes, and others. To this end the overall architecture plan will take into account the possible technology solution(s), including the CEF building blocks, and will not be restrictive or prescriptive.

•​Sub-activity 2.3: Validation of the Master Plan
Based on the experiences of the Pilots and Living Labs (to be implemented in Activity 3) this sub-activity will evaluate the performance and applicability of the FEDeRATED Interim Master Plan against lessons learned from each Pilot / Living Lab carried out in Activity 3 and provide the best practices and lessons learnt for final implementation to allow seamless data sharing for B2A, A2B, A2A and B2B. The FEDeRATED Validated Master Plan will incorporate and outline the set of agreements between the partners on the functional, technical and organisational requirements to be implemented with respect to the federated network of platforms.

The aim of this sub-activity is to revise the Interim Master Plan by providing recommendations for further implementation of the federative network of platforms concept in the various EU Member States and in relation to third countries.