FreightShare Lab (FSL) platform will include three basic types of third party system integration:

  1. Big Co or Aggregator of freight – this interface ensures that a system which connects to a FSL platform and already contains an algorithm to identify which routes and assets have freight sharing potential, searches the FSL database of uploaded schedules and identifies the match (this can be done by the FSL or the Integrating 3rd party, depending on the design decisions).
  2. ERP system or TMS system of a Big Co – this interface serves as an automated feeder of selected information to the FS platform. ERP data will be updated periodically, will be event based (integrating party will have settings available on the frequency and type of update) and will include mainly the following information:

    • Asset information
    • Schedules
    • Business rules
    • Pairing rules and constraints
  3. Third party optimisation engine – third parties will be able to connect their optimisation engines as server applications that can be accessed by users via a web service (or another means). These applications will have access to the schedules and asset information uploaded by fleets. They may require their own additional information and may connect or provide a separate user interface, where the fleets that select their services can choose their preferences and how their load should to be optimized. These applications will be connected to the service layer of the FSL platform and all executed transactions will be subject to monitoring and reporting on the platform level.

The FSL platform will have the following internal interfaces:

  • Web portal – web server hosting the FSL portal will integrate with the FSL platform, this will be the primary user interface of the platform.
  • Mobile application – mobile application will be connected to the web server, so that all rules and processes, including the connection to the database and the algorithm are implemented only on the web server and the app makes use of the information.
  • Algorithm – algorithm will be hosted on a separate environment and integrated with the FSL platform. The optimisation inputs will be sent to the algorithm in form of files. The rules and periodicity of the interactions between the algorithm and FSL platform, as well as the event management (triggers of the algorithm), will be adjustable through the web portal.
  • User database – for security reasons, the user information database will be hosted separately and accessed by the web portal and matched with other events and real-time information.
  • Message queue – all information and message flows among system components will be realised through a message queue, to ensure traceability and accountability of all transactions.
  • All internal interfaces to these components.