OpenFogリファレンス・アーキテクチャを策定
OpenFogコンソーシアムでは、フォグコンピューティングを広く普及させるため、「OpenFogリファレンス・アーキテクチャ第1版」注3、注4を策定し、2017年2月に公開している。ここでは、多様なフォグノードのタイプやクラウドとの構成に関連する技術・仕様要件が定義されている。
フォグノードも、エッジ側に近いフォグノードの場合にはデータ収集やその高速処理あるいは一次処理が主になるが、クラウド側に近いフォグノードではコンピューティングや分析などが主になるため、異なった機能要件や実装をフォグノードに記述できるように、リファレンス・アーキテクチャが策定されている。
〔1〕フォグコンピューティングのフォグノード：レイヤ構成
図5は、フォグコンピューティングにおける、エッジ側とクラウド側のフォグノードについて違いを示している。
図5 モジュラ・アーキテクチャによりエッジ側とクラウド側で異なる要件に対応
コグニッションレイヤ（Cognition Layer）：収集したデータから情報や知見を得るなどのデータ処理を行うソフトウェア、アプリケーション、プロセスなど
出所 今井 俊宏、「フォグコンピューティング」、2017年12月19日
フォグコンピューティングでは、クラウドとデバイスの間に、何段か（例：3レイヤ構成）のフォグノードが置かれる。
- デバイス側に近いフォグノード（レイヤ1）には処理能力を高く（ストレージ能力は小さく）、
- 逆に、クラウド側に近いフォグノード（レイヤ3）には、ストレージ能力を高く（処理能力は小さく）
のように、要件に合わせて最適な機能構成とすることが可能である。
フォグノードをエッジ側に設置して、例えば交通量カメラの映像データの処理を高速に行う場合は、図5の下に示すように、アクセラレータには処理性能の高いハードウェア（前述したFPGAやGPGPUなど）を搭載しておく。しかし、エッジ側より上位にありクラウドに近いフォグノードにはそこまでの高速処理は求められず、むしろストレージ（メモリ）の容量やCPUパワーを多くしてフォグノードにもたせるようにする。このようにフォグノードは、モジュラ構造を採用することで、最適なフォグコンピューティングを構築する。
このように、フォグノードがどこに設置されるかによって、フォグノードのコンポーネントの構成が変わってくる。
〔2〕エッジコンピューティングのエッジノード
エッジコンピューティングの場合は、フォグコンピューティングとは異なり、レイヤ構造になっていない。
例えば、センサーデータの収集や、現場で使用されているさまざまなネットワークインタフェース（Bluetooth、Wi-Fi、ZigBeeなど）のプロトコル変換を行ったり、場合によってはタイムスタンプ（時刻表示）のないデータに、エッジでタイムスタンプを付与したりすることなども行っている。
IoTデバイスに近い「エッジ（ゲートウェイ）」は、処理能力よりもIoTデバイスからの情報収集やインタフェース（プロトコル変換）機能や、デバイスとの関係に重点が置かれている。
このように、エッジノードは一定の処理能力はもっているが、より高度な処理についてはクラウドで行うということになっている。
▼ 注3
リファレンス・アーキテクチャ：参照アーキテクチャ。システムを構築するうえで、仕様書やマニュアルだけでは不十分な場合があるため、開発するシステムの「ひな形」を作って、実際に各種のソフトウェアやハードウェアを組み込み（実装して）、商用システムを開発する人に提供される簡易的な実装モデルのことである。
フォグコンピューティングのアーキテクチャの全体イメージ
▼ 注4
「OpenFog Reference Architecture for Fog Computing」、February 2017
