Alexander Gusyatiner, Oleg Zhikharev

INTRODUCTION

Marine Automation Framework (SAF)

Sea-Freight Automation Foundation (SAF)

Version 0.2, October 04, 2018

The current model of information support of transport processes can be characterized as follows:

Manual control of processes, manual execution of tasks and re-entry of data.

Most business processes, including those processes that are repeated regularly and do not require making complex decisions, are fully controlled and executed by people. During the execution of various logistics contracts, staff routinely make phone calls, use e-mail, re-enter data into various web forms, track shipments in various online platforms, document the implementation of contracts, and so on.

Large Monolithic Platforms.

Most of the management systems used are large, difficult to change monoliths, which limit and make it difficult to adapt to new technologies and business changes.

These systems include:

Information Platforms : shippers' platforms, customs platforms (Customs Single Window), container line platforms, railway platforms, sea terminal management systems (TOS), road carriers platforms, port management systems, etc.

Integration Platforms providing interaction between management systems and individual clients operating on the Internet: Commercial cloud integration platforms, Port Community Systems, Electronic Payment Systems, etc.

Fragmented Processes.

Business processes are divided into separate, unrelated, fragments. For example, the container export process occurs in the following fragments:

*           . *          . *         . 

As a result, it is not possible to trace the entire transport process and participants are often required to re-enter data.

Different user interfaces.

During a normal work day, a user who performs a repetitive standard task has to use online platforms, where this task is performed in completely different ways. For example, for container lines, each Terminal Management System has its own user interface for booking containers on a ship.

No standard for business roles, agreements and transactions.

As a result, different participants interact in different ways with each other, their roles are not clearly defined, business transactions (transactions) are performed and documented in different ways.

No Standard API.

Information and commercial integration platforms of the same purpose have different integration capabilities: they support non-standard APIs and use different message formats, such as: EDI, XML, comma-separated values ​​files, Excel, etc.

Using various Internet protocols. \
The situation is complicated by the use of various protocols for data exchange on the Internet: FTP, Email, WEB Services, etc. \

Lack of Internet services for a number of participants.

Most of the container lines and freight forwarders have their own websites with various 24/7 services, but most of the shippers, road carriers, customs brokers do not have a permanent presence on the Internet. As a result, telephone calls, Internet mail and meetings are the main ways to communicate and this communication often stops when participants are unavailable.

All of the above factors lead to the following consequences:

• Low level of business process automation.
• The high cost of implementation and support of platforms.
• Additional costs of participants in transportation for services of various commercial integration platforms.
• Freight participants are faced with the inaccessibility, opacity and difficulty of obtaining information at various stages of transportation.

The Sea Freight Automation Framework (SAF) is an open-source initiative that aims to increase the automation of processes by introducing a standard of business roles, agreements, transactions and APIs.

Basic definitions and characteristics of SAF:

• The participant (company or person) has a unique identifier and plays one or several roles defined in SAF : exporter, shipper, customs, sea terminal, port, sea line, etc.
• An agreement (Engagement) is a formal or informal agreement between the parties on interaction to achieve a specific business goal, for example:
• Container transportation by sea from the port of loading to the port of discharge and transferring it to the consignee;
• Ship call at the port;
• Registration of the export customs declaration;
• Transportation of the container from the shipper to the sea terminal;
• Delivery of cargo to the consignee from the sea terminal;
• etc.
• E-Process is a business process for the implementation of the Agreement . Each E-Process has its own unique code. As a rule, at the end of such a process payments are made for the services provided.
• R-App is an application designed to automate a specific role. Each R-App belongs to one participant and has a unique identifier. The entire SAF network consists of many such applications.
• E-Chain is a temporary chain consisting of R-App applications that participate in a specific process ( E-Process ) .
• The R-App application can be implemented as a cloud service, desktop application, mobile application for a smartphone, a decentralized blockchain application (Dapp), etc.
• The R-App exchange messages with each other via a remote method call: the client R-App calls the method in the server R-App , sends it a message and receives another message in response.
• SAF-Transaction is a data object consisting of a message sent, a message (or messages) received in response, method names, and participant identifiers.
• The transaction execution process ( SAF-Transaction) consists of forwarding messages and changing the internal state of the R-App participants.
• The client and server R-App record the transactions ( SAF-Transaction ) they perform in their own databases.
• SAF describes the standard API for each application ( R-App ). The API declares methods for remote calling, as well as formats of messages sent and messages received in response.
• The R-App is constantly, 24/7, represented on the Internet and is registered with online registrars ( Online Registry ).
• R-App applications can simultaneously participate in different types of processes ( E-Process) and transfer data from one process to another.
• R-App are engaged in automatic monitoring and process control ( E-Process ) In case of delays, applications can automatically contact participants via SMS or e-mail.
• SAF-Model is a description of Roles, Agreements, Transactions, and APIs performed in Proto 3 data description language.

The use of SAF can lead to the following positive changes: