第1章をマスターしますと、ほぼIoTシステムの構成の『骨組み』部分は理解されてかと思います。
事実、この位の構成要素だけ理解しておけば、大雑把に理解できます。

この第2章ではどうしても理解しておくべき、技術面に踏み込んだ知識をマスターして頂きたいと思います。
出来るだけ、簡素にイメージを掴む程度の知識に絞って行きます。

IoTシステムに於いては、IoTセンサー機器の情報を一手に『ルーター』に集めて、『DBサーバー』に送り込むのも理解されている筈です。

そして、『DBサーバー』は①社内LANでも②クラウドでもどちらに置いても良いという点も理解されたかと思います。
①か②のどちらに置くかは、会社のルールや社内の事情で決めるしか無いという点も理解されたと思います。

また②クラウドに置くと、開発に最低でも3年は掛かり、外注費用もかなり掛かります。
他方、①社内LAN上に置けば、『IoT導入支援キット』を使えば、即座に完了するという点も理解されたかと思います。

大体の構成イメージは付いておられると思います。

ここで、『通信』という言葉が出てきました。これは『インターフェース』とも言います。

実は、IoTシステムは4つのインターフェースを組み合わせて、実現しているのです。

では『インターフェース』を考える際に必要な『知識』を少し掘り下げてみましょう。

いきなり、難しい言葉が出てきましたｗ

『トポロジ』です。※『トポロジー』と言う方も居ますが、ここでは『トポロジ』で統一します。

これは一体何なのか？を真面目に伝えようとしますと、非常に難解な言葉ですので、直感的に掴みましょう。
※その位の理解で全く問題ありませんｗ

「繋がり（通信）における、関係性」　：この様に理解しましょう。

もう少し、イメージを確実にする為に例を上げます。

コードレス電話（もう今は無くなってきてますので、若い方は逆に難しいかもｗ）を考えます。
家庭内用途の固定電話の無線コードレス電話機をイメージします。
リビングに『親機』が鎮座し、電話線に繋がっています。
各部屋には夫々『子機』があり、『親機』と無線で繋がっています。
『子機』で電話しようとすると、音声が無線で『親機』に繋がり、中継器となって、固定電話の先の相手と話せます。

これは、コードレス電話における『無線通信の関係性』ですよね。これが、『（コードレス電話機の）無線通信のトポロジ』です。
そして、この『親機』と『子機』というのが、このトポロジを説明する上で、『各役割』を示しています。

もう一つ例を上げます。
トランシーバーが分かる方は、それをイメージして下さい。これも若い人は難しいかもしれませんｗ

グループでトランシーバーを各自が持ちより、通話をします。
グループ内で喋りたい人が、ボタンスイッチを押したまま、押している間に喋ります。
すると、グループ内で、他の方は、聞く側となり、SPから声が聞こえます。
通信してますよね。
これも、トランシーバーのトポロジと言うことです。

そして、色んな『通信』に於いては、この『トポロジ（通信の関連性）』という考え方が重要に成ります。
この『トポロジ』を決めて、どの様な関連性で目的を成立させるのか？が重要になりますよね。それが『トポロジ』です。

大体イメージの一片は掴めましたか？

『トポロジ』とは難しい言葉ではありますが、単なる『通信の関連性を定義』した考え方ということです。

その位の理解でOKです。

だ～いたいイメージは分かりましたか？ざっと理解しておけば良いぐらいです。

そして、これは『通信の関連性』と言いましたよね。

と言うことは、インターネットも通信ですし、インターフェースです。ここにも『トポロジ』の概念は必要だという事です。
 

無線通信に於いては、
『親機』←→『子機』というトポロジの関係という『各役割』が有りました。

ネットワーク通信のトポロジでは、
『Server(サーバー）』←→『Client（クライアント）』というトポロジの関係を示す『各役割』があります。

よく、「サーバーが～！」とか普段から使ってますよね。
でもそれは、『サーバ（Server)』と『クライアント（Client)』との2つの役割を合わせて、『1対』の関係なんです。

サーバーというのは、トポロジという考えに基づいて、与えられた役割であり、必ずクライアントも合わせた考え方なのです。

そして、この『役割』は絶対！！なのです。

上図がインターネット・ネットワークのトポロジです。
これは、分かる方も居られるでしょう。

ここで質問です。
「誰が（どの役割が）最初のアクションを起こすでしょうか？」

最初のアクションを起こすのは、『Client(クライアント）』です。
このアクションを『①Request（リクエスト）』と呼びます。

サーバーはその①Request（リクエスト）に対して、
②Response(応答：要求されたデータを返信）するのです。
これが『ネットワークトポロジ』の通信の順序です。とても重要。

そう言う『トポロジ』だという事です。

データを持っているところが『貯めている』のですから、『サーバー』ですよね。コレには異論は無いでしょう。

詳しい方はご存知ですが、インターネットなお仕事をしてない方は、知らなかったと思います。

この様に『サーバー』と『クライアント』は1対の関係なのです。
 

IoTシステム全体のネットワーク・トポロジを簡単に図式化しました。
ここには、

①『Webサーバー』と『スマホ・パソコン（Webブラウザ）』：間のインターフェース・トポロジ
②『DBサーバー』と『Webサーバー』：間のインターフェース・トポロジ
③『ルーター』と『DBサーバー』：間のインターフェース・トポロジ
④『IoTセンサー機器』と『ルーター』：間のインターフェース・トポロジ

IoTの実現には簡単に図式化しても、4つものインターフェースを全体としては繋いでいます。
　＝『Server(サーバー）』と『Client（クライアント）』の4つの関係を繋いでいると言うことです。

※②に関しては『DBサーバー』と『Webサーバー』とServe~Server間を繋いでいます。
これもこの関係性の中で、何方かが『Server』で何方かが『Client』として動作している筈です。
ここら辺は、私は詳しく無いのですがｗ　役割を決めて通信しているのは、間違いありません。
まぁ、ここは専門の開発者がやっているので、そういう風に取り決めてネットワーク通信をやってるんだろうな～位でOKです。

これが一般的な『IoTシステム全体のネットワーク』であり、細かく4つに分けると、『ネットワーク・トポロジ』を繋いでいると言うことです。
既存の、IoTシステムは、全てこの形に成っています。
恐らく、世界中全てのIoTシステムは、このトポロジで作られています。

ここで注目して欲しいのは、④のところです。
IoTセンサー機器は『Client（クライアント）』に成っていると言うことです。
　　　※実はこの事がとても重要で、問題なのです。

ココで1つ大事な事を言っておきます。
「ネットワークトポロジ上では、Clientが最初Request（リクエスト）のアクションを起こし、ServerがResponse（レスポンス）する」
と書きましたよね。

では、
「IoTセンサーは、何をRequestして、DBサーバーからは何をResponseするのでしょうか？
IoTセンサーこそが、データを持っている側ですよね？　センサー側はDBサーバーから何をResponseしてもらうのでしょうか？」

この疑問です。

ここからが本論です。

振り返ります。
『Server（サーバ）』とは『データを貯めている所』です。
もう少し深掘りすれば『データを持っている所』ですよね。

最初にデータが入ってくる所は、IoTセンサーですよね。

一般的なIoTシステムのトポロジは、間違っていませんか？

「ClientがRequestして、Serverが（貯めているデータ）をResponseする」のが正しいネットワークトポロジです。

「IoTセンサーが最初にデータを取得するところです。そここそがServerである筈では？
　絵のCloud上のサーバーみたいな所こそが、Clientでは？そこがIoTセンサーにRequestするのが正しいのでは？」

コレまでの、当たり前のIoTシステムは、全く逆に成ってませんか？？

そうなんです。ここまでの解説をしっかり読んできた方は分かると思います。

IoTシステムに於いて『トポロジ』の、そもそも論を無視したうえでシステム構築しているケースだらけなのです。

題目にも有るように、こんな『正しいIoTシステム』を実現するには、ハードウェア設計者しか作れません。
何と言っても、ハードウェアのプログラム（Firmware)で、独自に開発しないと作れないのです。

私がコレに気付いたのは、8年程前の事でした。

これには、既存の『DBサーバー』に当たる所を、Clientとして設計をゼロからやらなければならず、
色んな会社に相談しましたが、全て「そんなの無理！」とお断りされました。

そして、Braveridgeでは自社で独自にこのシステム構成を作り上げようと決めました。
それがLTEを使ったIoTシステムです。
苦節4年程ですか、BraveGATEというシステムをつくりあげました。
 

ちょっと難しいかもしれませんので、メリットを書きます。

①クラウド上にDBサーバーを構築しなくて良い→大幅な『時間』の短縮に成ります。
②ネットワーク構成が1系統と単純化します。
③クラウド上にDBサーバーが無いので、データストレージ機能が無い→保存機能はPCブラウザ側ですれば良い。
④IoT機器側へ必要な時に、必要なデータを取りに行ける。→超低消費電力
⑤IoT機器側へ、動作命令や設定のアクションコマンドが送信可能。→例：動作サイクルの設定や変更も可能。休止も可能

とIoTには最適だと思います。
実はもうかなりの実績があります。例えば、Braveridge『ため池管理システム』にも使っていますし、他社様も使われています。
ため池管理システムでは、
・晴れた時の撮影回数の制限。
・雨が予想される（アメダス連携等）と、撮影回数を増やす。
・本格的に雨が降り出した時に、管理者自身の意志に合わせて随時撮影可能。
・必要な時に、必要な動作をブラウザシステムから命令をすることが可能です。

ちょっと、ここは一気に説明しましたので、これからも改訂していき、更に分かり易い内容に変更して行きます。

 

BraveJIGにおいて、社内LAN構成（＝オンプレミス型IoT)でも、クラウド型構成（LTEを使ったシステム）でも、
全く同じ構成で作られてます。

つまり、社内LAN構成型であっても、IoTセンサー側は『Server(サーバー）』として動かしています。

BraveGATEを使った場合と同じ様な構成になっており、『IoT導入支援キット』もコレに対応しています。
『IoT導入支援キット』には『Webサーバー（YOKA Viewer)』がありますが、ここが、IoT端末『DBサーバー』にRequestを送っています。

ここら辺はもう少し、分かり易い様に改訂していきますので、お楽しみに。

BraveJIGにおいては、BraveGATEで培ったノウハウを組み込んでおり、開発の期間が圧倒的に短い事が大きなメリットになります。