アレクサンダー・グシャチナー、オレグ・ジカレフ

はじめに

出荷自動化フレームワーク（SAF）

Sea-Freight Automation Foundation（SAF）

バージョン0.2、2018年10月4日

トランスポートプロセスの情報サポートの現在のモデルは、次のように特徴付けることができます。

手動プロセス制御、手動タスク実行、データ再入力。

定期的に繰り返され、複雑な決定を必要としないものを含むほとんどのビジネスプロセスは、人によって完全に制御され実行されます。 さまざまな物流契約を履行する過程で、スタッフは定期的に電話をかけ、電子メールを使用し、さまざまなWebフォームにデータを再入力し、さまざまなオンラインプラットフォームで貨物を追跡し、契約の履行を文書化します。

大規模なモノリシックプラットフォーム。

使用されるほとんどの制御システムは、変更が困難な大型のモノリスであり、新しい技術やビジネスの変化を制限し、適応させることを困難にします。

そのようなシステムは次のとおりです。

情報プラットフォーム ：荷送人のプラットフォーム、税関シングルウィンドウプラットフォーム、コンテナラインプラットフォーム、鉄道プラットフォーム、海洋ターミナル管理システム（TOS）、トラック輸送プラットフォーム、港湾管理システムなど

管理システムとインターネット上で動作する個々のクライアント間の相互作用を提供する統合プラットフォーム ：商用クラウド統合プラットフォーム、ポートコミュニティシステム、電子決済システムなど

断片化されたプロセス。

ビジネスプロセスは、別個の無関係なフラグメントに分割されます。 たとえば、コンテナのエクスポートプロセスは次のフラグメントで実行されます。

*           . *          . *         .
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その結果、輸送プロセス全体を追跡することはできず、参加者はしばしばデータを再入力する必要があります。

多様なユーザーインターフェイス。

通常の営業日中、反復的な標準タスクを実行するユーザーは、このタスクがまったく異なる方法で実行されるオンラインプラットフォームを使用する必要があります。 たとえば、コンテナラインの場合、各ターミナル管理システムには、コンテナを船舶に予約するための独自のユーザーインターフェイスがあります。

ビジネスロール、契約、およびトランザクションの標準の欠如。

その結果、さまざまな参加者がさまざまな方法で互いに対話し、それぞれの役割が明確に定義されておらず、ビジネスオペレーション（トランザクション）がさまざまな方法で実行され、文書化されます。

標準APIの欠如。

1つの目的の情報統合プラットフォームと商用統合プラットフォームには、異なる統合機能があります。非標準APIをサポートし、EDI、XML、コンマ区切り値ファイル、Excelなどのさまざまなメッセージ形式を使用します。

さまざまなインターネットプロトコルを使用します。 \

FTP、電子メール、WEBサービスなど、インターネット上のデータを交換するためのさまざまなプロトコルを使用することにより、状況は複雑になります。 \

多くの参加者のインターネットサービスの不足。

ほとんどのコンテナラインと貨物運送業者は、さまざまな24時間年中無休のサービスを備えた独自のWebサイトを持っていますが、ほとんどの荷送人、道路運送業者、通関業者はインターネット上に常駐していません。 その結果、電話、インターネットメール、会議がコミュニケーションの主な手段となり、このコミュニケーションは参加者がアクセスできない場合にしばしば停止します。

上記の要因はすべて、次の結果につながります。

• ビジネスプロセスの低レベルの自動化。
• プラットフォームの実装とサポートの高コスト。
• さまざまな商用統合プラットフォームのサービスに対する輸送参加者の追加費用。
• 交通機関の参加者は、交通機関のさまざまな段階で情報にアクセスできない、不透明であり、困難に直面しています。

Maritime Automation Framework（SAF）は、標準的なビジネスロール、契約、トランザクション、およびAPIを導入することでプロセスの自動化を促進することを目的としたオープンソースイニシアチブです。

SAFの主要な定義と特性：

• 参加者 （会社または個人）は一意の識別子を持ち、SAFで定義された1つ以上の役割を果たします ：輸出者、荷主、税関、海上ターミナル、港、海線など。
• 契約（エンゲージメント）は、 参加者が特定のビジネス目標を達成するために対話するための正式または非公式の契約です。たとえば、
• 荷積み港から荷揚げ港への海上でのコンテナの輸送および荷受人への輸送;
• 港への船舶の呼び出し;
• 輸出税関申告の登録;
• 荷送人から海上ターミナルへのコンテナの輸送;
• 海上ターミナルから荷受人への貨物配送。
• など
• E-Processは、 契約を実施するためのビジネスプロセスです。 各Eプロセスには独自のコードがあります。 原則として、そのようなプロセスの最後に、実行されたサービスに対して支払いが行われます。
• R-Appは、特定の役割を自動化するように設計されたアプリケーションです。 各R-Appは1つのメンバーに属し、一意の識別子を持っています。 SAFネットワーク全体は、このようなアプリケーションで構成されています。
• E-Chainは、特定のプロセス（ E-Process ）に参加しているR-Appアプリケーションで構成される一時的なチェーンです。
• R-Appアプリケーションは、クラウドサービス、デスクトップアプリケーション、スマートフォン用モバイルアプリケーション、分散ブロックチェーンアプリケーション（Dapp）などとして実装できます。
• R-Appは 、リモートメソッド呼び出しを介して相互にメッセージを交換します。クライアントR-AppはサーバーR-Appでメソッドを呼び出し、メッセージを送信し、応答として別のメッセージを受信します。
• SAFトランザクションは、送信されたメッセージ、応答で受信されたメッセージ（複数可）、メソッド名、および参加者識別子で構成されるデータオブジェクトです。
• トランザクション実行プロセス（ SAF-Transaction）は、メッセージの転送とR-App参加者の内部状態の変更で構成されます。
• クライアントとサーバーのR-Appは、実行するトランザクション（ SAF-Transaction ）を独自のデータベースに書き込みます。
• SAFは、各アプリケーション（ R-App ）の標準APIについて説明しています 。 APIは、リモート呼び出しのメソッドと、送信されたメッセージおよび応答で受信されたメッセージの形式を宣言します。
• R-Appは常時、24時間年中無休でインターネット上に提示され、オンラインレジストラ（ Online Registry ）に登録されています。
• R-Appアプリケーションは、異なるタイプのプロセス（ E-Process）に同時に参加し、あるプロセスから別のプロセスにデータを転送できます。
• R-Appは自動監視とプロセス制御（ E-Process ）に従事しており、遅延が発生した場合、アプリケーションは自動的にSMSまたは電子メールを介して参加者に直接連絡できます。
• SAF-Modelは、Proto 3データ記述言語で作成されたロール、規則、トランザクション、およびAPIの記述です。

SAFの使用は、以下の積極的な発展につながる可能性があります。

今日のステータス	SAF
輸送プロセスの手動制御および手動データ入力。	輸送のすべての参加者に適用される輸送プロセスのコンピューター制御。 プロセス参加者の可用性と有効性にあまり依存しません。 データの再入力の不足。
大規模なモノリシックプラットフォーム。	機能が明確に定義された小さなサービス（アプリケーション）。 必要に応じて、これらのサービスは既存のプラットフォームと統合されます。
断片化された無関係なプロセス。	すべてのプロセスの完全な統合。
さまざまなオンラインサービスのさまざまなユーザーインターフェイス。	統一されたユーザーインターフェイス。
ビジネスロール、契約、およびトランザクションの標準の欠如。	Proto 3データ記述言語で記述された標準のビジネスロール、契約、およびトランザクションの定義。
APIの標準の欠如。	Proto 3で記述されたメソッドとメッセージ形式の説明を含む標準API 。
多くのインターネットプロトコルの使用。	gRPCは、リモートプロシージャコール用のGoogleの最先端のマルチプラットフォームフレームワークです。
多くの参加者のインターネットサービスの不足。	輸送プロセスのすべての参加者のオンラインでの存在。