第1章ー1:IoT全体像をイメージする

IoTの活用を騒がれ初めてもう15年近くにもなります。
一方でIoT導入の敷居が高く、一部の大手企業のみが何とか使いこなしているというのが現状です。
私としましては、そんなに難しい事ではない筈なのに何故こんなに苦労しているのだろうか?という疑問がありました。
漸く最近になってその原因が分かってきました。
それは、ハードウェア・ファームウェア・ソフトウェア・クラウドといった各種技術が集約されないと出来ない技術なので、それを統合的に見れる人が少ない事が導入に難儀されている原因では無いかと思います。
つまり、余りにも広範囲な知識を求められますので、分からない部分は他社と協力して。。。という分業化の末にお互いが巧く噛み合っていないというのが原因かと思われます。

私はIoT惣明期から関わってきまして、もっとも詳しい中の一人と思います。
また、私は芸術系大学から独学で電子回路設計を習得したことから、人が理解し難い部分や、理解しておかなくて良い部分・しておかねば成らない部分が分かる方です。そういう立場から、分かり易く解説していけるかと思います。お付き合いください。

また、BravePIやBraveJIGを発表している弊社ですが、最後はBraveJIGの統合ページにマニュアルとして統合します。
そのページが完成するまでは、こちらで草稿という形で情報を発信していきたいと思います。

また、内容につきましては、技術者のみを対象とせず、誰でも解りやすい解説に努めます。
私は経験的に、教える立場としては、マニュアル教本を1ページからジックリ順番によんでも理解できないと思っていますので、ボンヤリと霧が貼った中でも構成が分かるイメージを重視して書いていきます。
IoTをヤレと言われた企画部の方でも、技術者と話ができるレベルまでを目標とします。
その中では《イメージを掴む》ことを先ずは主目的としますので、分かり易い為の《嘘》も織り交ぜていきます。これは理解し易くするための《嘘》だと思ってください。
そして、最後に(全体の理解を深めたタイミングで)は、その『嘘』を回収しますのでご心配無く。

誰でも解るように説明しますのでご期待下さい。
何度か見直しを繰り返しながら、より分かり易い解説に改定していきます。最後はBraveJIG専用ページを構築中ですので、そちらにマニュアルとしてマージして行く予定です。

IoTの全体像

先ずは、IoTの全体像を掴みます。
先ずは、このイメージを掴みます。大体分かられるとは思いますが、初めての方にも分かる様におさらいしましょう。

そもそも皆さんのイメージされているIoTですがInternet of Thingsの頭文字を取ったIoTという略語です。
これはよく知られてます。
かねてより言われていた文句は「あらゆるモノをインターネットに繋ぐ」という言葉は聞いたことがある方が多いと思います。
そして、「あらゆるモノ」とは「センサー」と言われてきました。
つまり合わせると「あらゆるセンサーをインターネットに繋ぐ」と言うことになります。

ところが、「ソレがどうした?」と思われる方も多数居られるでしょう。
メリットが明確に言われる事なく、漠然とそんな台詞を言う方が多く、「何の為に?」という理由と根拠が曖昧です。
会社の上層部から「IoTをやれ!」と言われた経験のある方も多いでしょうが、実の所はその上層部も「何の為に?」が分からないままに「とにかくやれ!」と言われているなんてケースも多々あるみたいです。

ではここでは明確にしましょう。
答えはDX化でも無いですwそれも一体なんだか分かりませんよね~w それでも「DX化だ!やれ!」なんて流行っているのはIoTの時と同じで、理由と根拠が曖昧な意味不明のスローガンなだけですw 

共通する答えとしては、
 ①人材不足解消
 ②リソースの合理化
 ③リソースの少人化(人の関わりが必要な作業の削減)
と言うことで良いかと思います。

実際の現場毎にこれ以上のメリットはありますが、それはその現場現場のアイディアを出し合ってのIoT活用事例の多様化になるかと思います。

その中で最も分かり易い、センサーの活用という視点で先ずはIoTの全体像を掴んでいきましょう。

 

IoT構成の全体像(センサーを活用する場合に絞ります)

BraveJIGの全体像を簡略化した以下の構成図を理解して行く事を目標に説明します。
この絵は、簡潔に纏めたよく出来たIoTの全体像ですので、これを使うことにします。

この構成図が分かれば、IoTの企画もやりやすくなりますし、技術部門とも話は通じます。頑張りましょう。

IoTセンサー

まずは上図を参照ください。
この部分がIoTのセンサーの部分になります。
四角い本体の先に青色部のホルダーに固定された黒くて小さなセンサーがケーブルで接続されています。
これはセンサー本体のみを小さな専用筐体に入れて、ケーブルで延長されています。

思い返してください。
IoT(Internet of Things)の基本は、このセンサーで取得したデータをインターネットに上げる=アップロードする事なんです。

ここを少し解説しますと、一般的にはこのセンサー部分は『四角い本体』の中に入っているのが一般的なIoTセンサー機器です。
BraveJIGでは、センサー部分を独立した小型の筐体に入れ、本体部とは別にしています。
本体部はセンサーからデータを読み出して、処理する機能を持っています。

IoT機器においては、このセンサー部は『四角い本体』の中に入って居るのが一般的だと書きました。
なぜBraveJIGはわざわざ別筐体として分けているのか?ということです。
これは長年の経験から、センサーを置きたい場所や箇所はピンポイントであることが多い為です。
それを四角い筐体に入れてしまっては、置きたいピンポイントの所に大きな四角い筐体が来ることになり邪魔ですよね。
また、「加速度センサーを使って、モーターの異常振動を検知する」等という難しいこともしている場合があるのですが、筐体が大きいとソレをモーターに固定することに成ります。『加速度センサー』のみならず、電池を含めた全体を振動を受けるモーターに固定するなんていうのは現実的では有りませんよね。
ましてや、本体ごとモーターに付けると言っても、どうやって固定するのでしょうか?無理ですよね。
だから、センサー部は本体とは別筐体にした方が、合理的だと思っていますので、別筐体とし最適なピンポイント固定が出来る様にしているのです。

少し踏み込んでみます。
この『四角い本体』には何が入って居るのかと言いますと、センサーから受け取ったデータをシステム全体が扱い安いデータの形に『処理』しています。
『処理』する機能はMCUMicro Controller Unit:通称マイコン)で受け持ちます。
データをそのまま生のデータのままに、システムに送り出すワケには行かず、必ずここで処理する必要があります。

この『処理』というのを、分かり易く例えれば、『山手線を走っている列車の座席(この場合は新幹線の座席をイメージして下さい)に、ちゃんとデータを並べる等の作業』などが、ここで言う『処理』と考えてください。これをファームウェアでプログラミングし処理します(マイコンに書くプログラムをファームウェアと言います)。
山手線を走る列車に、テキトウに生のデータをドンドン投げ込んでしまったら、取り出すのが大変になりますから、ちゃんとルールに従って座席に並べるという処理が必要になります。こういう処理をしています。しなくては成らないと言うことです。

修学旅行の引率でクラス毎にバスを分け、名前順に座席を決めてソコに座るルールに従えば、引率者にとっても楽ですよね。
そういうルールを作って管理すれば、サービスエリアで生徒を置き去りにしてしまっているのも直ぐに分かりますよね。

エンジニアの設計に於いても、このように管理しやすい形のルールを作ったり、座る順序のルールも作っておかないとダメなんです。
そして、ちゃんと管理するにはこんな処理をしないと行けませんし、ルールも決めなければ成りません。これもプログラムします。
一般社会と同じです。

そして、センサー周辺の透かしを観て想像して頂ければ分かると思いますが、色んなセンサーに対応し内蔵することが出来るようにしています。

色んなセンサーは色々と各ICメーカーから発売されておりIC化されています。その大きさは、大体4mm x 4mm以下のサイズで販売されています。
かなり小さいですよね。

弊社で使用しているセンサーはもう3mm x 3mm以下のモノが普通に成ってます。以下に写真を貼っておきます。
 

データベース・サーバー(Data Base Server)

次に知っておかねば成らないものが、データベースサーバーです。DBとも言われますが、DataBase Serverの略語です。
IoTと言えば必ずコレが必要です。サーバーの一種です。会社内の『サーバー』と言ってるのはある種『データベースサーバー』でもあります。
例えば、ペーパーレス化で、ペーパーをスキャンしてPDF書類にして、保存しているのも『(PDF書類の)データベースサーバー』です。
Wordやエクセルの書類も保存されているのは『(Wordやエクセルの)データベースサーバー』に保存されています。
また、会社の購買部門が価格情報や品番を統合して参照するサーバーも又『(購買品番毎の)データベースサーバー』です。
一般的に『データベース』と言っているものは大抵は、目的に応じて最適化された『データベースサーバー』のことです。
※この図中でマスクしてますが、YOKA SERVERと書いている部分は、私が名前を付けているだけで、単なる代名詞だと思ってください。
 今の所は、特に意味は無いです。

ここで大事なことは、『サーバー』とは『貯めている所』と翻訳して大体正解です。
つまり、『データベースサーバー』を言語化したら『データを貯めている所』と思えば大体当たっています。

この次の項目で説明しますが、『Webサーバー』というのを聞いたことがあるかと思います。
こちらも『サーバー』ですが、役割が違います。これは次の項目で説明します。

IoTの活用にも勿論、『データベースサーバー』が必要です。センサーから取り出したデータを貯めておく必要があるためです。

『データベースサーバー』の中身は決まったフォーマット(プログラマが理解できる・想定している形)になっておかねば成りません。
つまり、最初からそのフォーマットを定義しておかないとダメなんです。イメージで言いますとエクセル表のフォーマットみたいなもの。

色んなデータ管理を1つのフォーマットで管理するのが最も効率的です。
色んなデータに対応するフォーマットにすると、エクセル表の『列』が右に右に長いエクセル表になると思えば良いです。
エクセル表で右側を拡張しすぎると分かり難いですが、プログラマにとっては面倒と言うことはありません。
始めにキチンと決めてさえいればOKなのです。だってプログラムが参照するのは《行x列》を指定して読み出すだけなので簡単です。

実際のデーターベースのプログラミングでも、そのフォーマットをエクセル表と同じ様に定義します。
この時には、充分にどんなデータベース・フォーマットにするのかを熟慮しておかねば成りません。

各種様々なセンサー全てに対応するフォーマットにしておくには、多くの列数と定義付け(項目付け)をしないとダメです。
加速度センサーのデータ列は『列M』で、温湿度センサーのデータは『列N』で、測距センサーのデータはずっと右側の『列X』で。。。
と使う予定のセンサーの項目が増えれば増える程『列』は増えます。

では《行》の方の項目は何になるでしょうか?
これは《時間》である事が多いです。
※行と列を入れ替えても良いですが、ここでは縦軸《行》を時間としておきましょう。どちらでもかまいません。フォーマット次第です。

ある1個のセンサーデータをエクセル表の対象項目である何列目の、時間《縦行》に格納すれば、他の列項目の所には《ゼロ》を示さないといけません。
そのセンサーのデータは無いからです。となるとある時間のセンサーデータとは、指定の時間の指定の列項目にデータが入って居て、他は《ゼロ》と言う事です。
これは、プログラム設計上の管理を簡潔にバグが発生しないようにするためですのでご理解くださいw
事実その様にします。

実は、エンジニアリングの設計においても、人間様の分かり易い統合管理手法の仕組みそのままなんです。
ここら辺が弱いと、ソフト設計もちゃんとしていません。人間様が頭で分かり易い様にしますが、プログラムもソレに則っていると言うことです。

これをもっと砕けた表現でいうと、修学旅行の引率の先生は、クラスごとにバスを分け、どの席に誰が座っているのかを示す『表』を持っています。
これに乗っ取り管理すれば、高速道路のサービスエリアから出発する際に誰も置いてきぼりにしない様にその様にしてますよね。
あれと全く同じ様な『管理のしやすさ』は、エンジニアリングでも同様に利用していると思っておいて間違いないって事です。

経験のある方も居られる筈ですが、閃いて設計終盤にフォーマットに追加したい《項目》を追加しようとすると、エンジニアが烈火の如く怒りますねw 
始めに決めた統合管理フォーマットを変更しろという事を技術者の要望しているわけです。
これは、そこまで設計とデバッグを繰り返してきたのは、始めに決めたフォーマットに準じてテストし設計しているものを変更要望ですw
簡単な《追加》が簡単ではない、設計と検証の全ての見直しになるから烈火の如く怒るワケですw
だから、御法度なんです。

あくまでも例ですが、『データの日付』を『西暦』で管理すると決めていたが、『和暦』も追加して欲しいと言うような単純な要望は安易そうですw
エクセルをイメージして下さい。
『列項目』が増えるワケです。しかも、分かり易く西暦の右側に『和暦の列』が増やします。
すると、その右側のセルは全て『列項目』が1つずつズレて変わってしまいますよね。
元々、『列D』だった列が、和暦の追加で『列E』になるのです。そして元々『列D』だったデータが全て『列E』になり、
ソレよりも右側の列は全てズレてしまいますよねw 単純に『和暦も追加お願い~!』って軽そうな話が、大ごとになるわけです。

そうなると、最初から最終のフォーマットを定義しておかねば成らないんです。

Webサーバー(Web Server)

ここが以外と重要な所になります。

『Webサーバー』という言葉はよく耳にすると思います。「ありゃ~何だ?」と思っている方も多いと思います。
実の所、私も2年前位までは「Webサーバーって一体何さ??」という状態だったのは本当ですw

Web関係の仕事をしてある方には当たり前なんでしょうが、私の様なエンジニアでもこんな感じだったので、一般の方はもっと分からないと思います。

これを私なりに、直感的に分かりやすいイメージで把握できるよう解説します。
細かい所をいうと「違う!」って言葉も予想されますが、サッパリ分からない方に向けて先ずはイメージを掴む説明に徹します。

上図を見て下さい。
右上に『Webサーバー』というのが、上述した『DB(データベース)サーバー』の右側に描いてます。
そして、『Webサーバー』の右下に矢印が描かれて、スマホとパソコンを配置してますよね。
そして、『DB(データベース)サーバー』には矢印は繋がっていません。

IoTにおいて、『センサーから取得したデータを、DBサーバーに貯める』という所までは説明しました。
しかし、『DBサーバー』に貯めるのがIoTの目的ではありませんよね。そのままでは、「はぁッ?で!だからどうした??」の状態ですw
人間様がそのデータを観ることが出来ないと、何の役にも立たないわけです。つまり、『可視化』する必要があります。
ではどうやって『可視化』するのか?って事です。

(A)1つ目の方法は、パソコンで『可視化』すべく、『アプリケーションソフトを開発する』です。

昔はそんな感じでしたよね。そういう『(アプリケーション)ソフト』がCD/DVDに入っていて、それをインストールする。

しかし、この方法は、異なるOSに合わせて複数開発する必要があります。
Windows/iMac/Linux/... そう言えばスマホで観るのが多いからiOS Appも開発せねば。。。
そういえば今では、Androidスマホも対応せねば。。。となるとソレだけ開発すれば『可視化』が出来ます。
この方法は、開発費用も時間も大変な事に成りますよね。
しかも毎年OSの大幅アップデートが有りますから、毎年毎年OSのアップデートに合わせて、アプリを更新せねば成らなく成りますよね。

これはもう大変です。
私が使って居る電子回路設計ソフトであるCADもWindows版しか有りません。Mac版は無いです。

今では、この『可視化手法』は、悪手です。

(B)もう一つの方法があります。『Webブラウザで観る』方法です。

Webブラウザで閲覧ならば、Webページの閲覧時に使っている機種やOSやスマホやタブレットに応じて異なる事は有りませんよね。
どれも共通で同じ様に閲覧可です。

今ではこの手法が一般的です。勿論、アップデートは必要でしょうが、初めのアプリケーションソフトよりかは楽です。

これが今の主流です。
それを実現するために、必要なのが『Webサーバー』というわけです。

その『Webサーバー』は、
「スマホやPCの(Webブラウザ:IEやChromeやSafari等)で同様の表示を実現するための、
 共通のルールに則った形(データベース・フォーマット)の形で情報を貯めているサーバーということ」って事で、これがWebサーバーです。


iPhoneで観たとき、Androidで観たとき、WindowsのEdgeで観たとき、Mac OSのSafariで観たときetcがバラバラな見え方に成りません。
どのWebブラウザで観ても大体は同じ様に観えますよね。
これは、共通のWebブラウザ表示で、フォーマットを共通化されたルールに基づいているので、こういう事が可能なワケです。

そして、IoTに於いても『Webサーバ』を、これに従えば、どんなWebブラウザであっても、表示は同じになります。
図中のスマホやパソコンでは、
Webブラウザで『Webサーバー』を読みに行けば、使っているWebブラウザに関わらず、同じ様な表示が可能なワケです。

凄く便利ですよね。
こう言う仕組みに成っています。

因みに、普通一般のWebブラウザによるネットサーフィンですが、『サービス提供者』が膨大なWebサーバーを作っています。
頭が下がります。
それを、スマホやパソコンで指定のアドレスの目的のWebサーバーからダウンロードして、私達はブラウザ上で観ているダケって事です。
『IPアドレス』って聞いた事あると思いますが、それは目的のWebサーバーのアドレス(≒住所)って事に成るわけです。

※実際には、『IPアドレス』は直接叩いてませんよね。例えば、Amazonですと、https://amazon.co.jpとか、英文に成ってますよね。
 『192.168.13.231』とかの『IPアドレス』は入れませんよね。こりゃ~分かり難いですw私でも無理。
 これはたまに聞くと思いますが『DNSサーバー』なる翻訳機能サーバーが、人間にわかりやすい様に通訳していると思っておいてください。 
 他にも機能を持っているみたいですが、我々普通の人間様はその位の理解で問題無いですw
 

+ルーター(Router)

ここまで、概略や全体構造のイメージが分かったかと思います。

整理しますと、
『センサー』→『DB(データベース)サーバー』→『Webサーバー』→『Webブラウザ』

で、IoTの目的である、センサーデータを人間様が『可視化』できる所まではご理解頂けたかと思います。
これ以降の積極的活用方法については、こう言ったIoTの仕組みを知った後に皆さんがアイディアを出し合って考える部分です。

ココでちょっと話しておいたほうがよい事を書いておきます。
よく14年ほど前頃にはIoTをご紹介すると「IoTで一体何ができるんだ!?」と上から口調でよく聞かれましたw
私は「そりゃ~貴方が自分の会社の課題点を把握して、こういう改善をしたいんだがIoTでどうやったら改善できるのか?」って、
質問・相談してくれるのが正解です!何が出来るんかって?知らんがな!って思ってましたw 言っては居ませんがw そう思っていましたw

勿論、分からないから聞いてあるんでしょうが、分かれば活用範囲はもの凄く広いと言うことです。
ここはそのための場ですので、広く理解し易い様に心掛けます。

そして、最初に説明したIoT化の代表的な目的である①②③をしっかりと見据えておれば、改善すべき点が観えてきます。
ここは逸らさないようにして下さい。

それでは元に戻ります。
流れは大体把握出来たかと思いますが、問題は『センサー』の部分です。

どこが問題かというと、センサーが《1個》ですねw この為だけにIoTシステムを作ったのでは元が取れません。
複数のセンサーを多数活用して幅広く利用するのが正しいです。

では複数のセンサーのデータを集めるにはどうしたら良いでしょうか?

これはこう言うイメージが正しいです。
会社の各自パソコン夫々が夫々《光インターネット回線》を引いたら大変ですよね。

実際はソコにはルーターが存在してます。
細かい話をしますと、スイッチングハブと呼ばれる機器を社内LANに接続して大量のパソコンが繋がる様に中継しています。
スイッチングハブとは中継器でもありますし、拡張の中継器でルータの機能を拡張するのを補助するものです。
その大元には、『(Ethernetを使った)ルーター』に繋がっています。

ご自宅の《光インターネット》をイメージして下さい。そこには《ルーター》or《WiFiルーター》ってのがありますよね。

アレは、大元の光回線インターネットに繋ぐ《ゲートウェイ》後の、《家内ルーター》です。
あの機能は、会社でも自宅でも同じですが、色んな複数の機器を繋ぐ中継器という存在です。
※《ゲートウェイ》ってのは、光回線接続へバイパスする機能だと思っておけば良いです。実はこれもNTT光回線網の1つのルータなんですがね。

IoTシステムのセンサーも同じで、色んな複数のセンサー機器を複数繋ぐ中継器が必要なんです。
これが、《IoT(用途の)ルーター》です。
これの存在により、光インターネット回線から、分岐して夫々の複数の機器を1本の経路にまとめてくれるものです。
これにより、複数台のセンサーで取得したデータをルーターで一本化しているワケです。

だから『+ルーター』を付加する事によって、IoTセンサーを複数台接続して、色んなセンサーのデータを集めることが出来る訳です。
BraveJIGに置いては、専用のルーターを設計して販売します。

ここで謎・疑問があると思います。
各社で『IoTゲートウェイ』やら『IoTルーター』というのが販売されていますよね。
「どうして、Braveridgeはその汎用的な『IoTルーター』を使わないのか??使え無いのか?」いう疑問です。

もう既に、複数のIoTルーターを持っているので、なぜBraveJIGでは又ルーターを買わねばならないのか?
その汎用ルーターに繋げれば良いではないか?
と言う疑問です。

この点について説明します。
幾つか複数の理由があって汎用ルーターを使っていません。使える様にはしていません。

①汎用ルーターの消費電力が大きすぎて、電池駆動が出来ない。

 →恐らく、汎用IoTルーターの消費電力は2.5whを超えています。
  WiFiやLTEの機能を持つ様な、汎用ルータも売られていますが、それでは消費電力は5.0whを越えていると思います。
  [wh(ワット時)] って単位をいきなり使ってますが、パソコンのUSBポートから取り出して良い電力は[最大2.5wh]のみ です。
  1時間あたりの消費電力という単位が[wh(ワット時)]です。[h]は1時間あたりという意味の単位です。
  USBポートはUSBスピーカー等も繋げますのでまぁまぁの電力を使っても平気に思えますが、そんな電力でも全く足りない程の
  消費電力なのが汎用IoTルーターの消費電力の現実と言う事です。

      昔はラズパイもUSBポートで動いてましたが、WiFi付きとなり、もうUSBポートでは動かせません。ACアダプタが必要です。
  ましてやLTE通信機能まで付いている様な『汎用IoTルーター』ともなると、5.0wh何かでは全然足りません。
  10[wh]以上の能力のACアダプタ電源を準備しないとダメなんです。
  
  ACアダプタを繋げば良いじゃないか?とお思いでしょうが、その通りですw
  しかし、Braveridgeでは電池駆動できる程の低消費電力ルーターの設計を得意としています。
  そういう『IoTルーター』ならば、電池で駆動できる・USBで駆動できる・ACアダプタでも使える『IoTルーター』になります。

②WiーFiを使った『IoTセンサー』を良く拝見することが多いですが、それも電池駆動が出来ません。

 →Wi-Fiを使ったIoTセンサーに比べると、Bluetooth®(Low Energy)であればCR2032ボタン電池でも1年動作が出来ます。
  Wi-Fiを使ってはとてもボタン電池では動かせません。
  良く、中国のESP社製の格安WiーFiモジュールを使ったIoTセンサー機器を観るのですが、Bluetooth®何十倍もの消費電力です。

  無線接続のIoTシステムを構築しようとすると、電池駆動が必須となります。
  その場合にはBluetooth®(LowEnergy)しか、電池駆動のIoTセンサーを実現出来ません。

  また良く、「Bluetooth®は飛ばない! 5mとか10mとしか飛ばない規格。 まぁ近接無線通信なのでこんなもの!」
  「Wi-Fiは良く飛ぶんだが、Bluetooth®は飛ばない」というのが一般的では無いでしょうか?したり顔で当たり前の様に言う人も居ます。

  これまで、「Bluetooth®は良く飛ぶ!」なんて事を言ってる人には一人も出会った事が有りません。

  しかし、これ『大嘘』ですw

  Bluetoothの通信距離の真実は、

   ーBT4.2の旧規格でも、見通しで150~200m飛びます。
   ーBT5.xの新規格のLongRange仕様を使えば、見通しで1.1km飛びます。海辺や空中に飛ばせば3.5km位飛びます。

  当たり前ですが、電波法もちゃんと守って、ボタン電池で動かしてコレですw

  これが、当たり前の真実なんです。
  Bluetoothで見通し通信距離で5~15mしか飛ばないというのは、アンテナの最適化をしていない設計者の設計と言うことです。
  →つまりは、設計不具合品ですw ちゃんと治させて良い事案です。治せないとは思いますがw

  私は何年もこの真実を訴えているのですが、なかなか一般的にならないのが不思議です。

  どうです?Wi-Fiにする意味があります?無いです! LongRangeで設計すれば見通し1.1kmも通信可能です。
  しかも、センサーデータって凄く小さいデータなので、わざわざWi-Fi機能を使うまでも無いんです。
  
  1つの基準を言っておきますと、動画の無線伝送はBluetooth®では無理です。
  それ以下の無線データ転送はBluetooth®で充分です。
  弊社では『ため池管理システム』を販売していますが、静止画カメラ~ルーター間の静止画の無線伝送はBluetooth®で1.1km飛んでいます。

③Bluetooth®(LowEnergy)の規格は、IoTに最適化された無線規格。

 →Bluetooth®LowEnergyは、Bluetooth®を使っているエンジニアも殆ど理解していない仕様で作られています。
  98%以上の方が勘違いしている所があります。この点についても良く、講演では喋るのですが。。。理解は広がっていません。
  
  この点についても、第2章か第3章で書こうと思っていますので、乞うご期待です。文系な方々でも分かるように説明出来ます。

如何でしょうか?代表的な『汎用IoTルーターを使わない(採用しない)理由の3つ』を上げました。

IoTを成功させるには、Bluetooth®LowEnergyの活用と専用のルーターを作らないと、実用性の無いIoTになってしまうので、
専用のルーターを作っていると言うことです。

弊社では、LTEーM(携帯無線の規格)を使っても、電池駆動できる程に低消費電力設計にしています。


さて、この『+(専用)ルーター』を追加することで、複数のセンサーが繋がりました。

上図で観ますと、長方形のオレンジのレバーが付いたものが『+(専用)ルーター』になります。

これを、文章にしてみますと、

『N個のセンサー』→『+ルーター』→『DB(データベース)サーバー』→『Webサーバー』→『Webブラウザ』

が出来上がりました。
これで、イメージに近い、複数のIoTセンサーを繋いだ、IoTシステムになってきたと思いませんか。

だいぶんIoTらしく成ってきました。まだもう少しあります。

折角なので、IoTセンサーを繋ぐ所の絵についても、解説しておきましょう。下図に続きます。

折角、Bluetooth®についても記述しましたので、Bluetooth®LowEnergy規格にも対応した図として纏めてみました。

また、複数の各種センサーもハイライトしてみました。
沢山のセンサーが繋がるイメージは出来ましたでしょうか?

多分大丈夫とは思いますが、これを観ている方々の中で少し「?」と思われる点を予想してみます。

なんだか、Bluetooth®の無線接続が出来るのに、『有線接続?』という記述があるぞ?と言う所が気になった方も居られると思います。
ここについて少し深掘りしてみます。

実は、BraveJIGのシステムでは『無線接続』と『有線接続』を共有できる設計にしました。

『無線接続』では、必ず『電池』が必要となります。そしてその寿命も気にしなくてはいけません。
超低消費電力設計とは言え、電池のエネルギーは有限で寿命があります。

『有線接続』であれば、『+ルーター』に繋がる電源(USBかACアダプタ)により、電源が供給される仕組みです。
これなら、電池寿命の心配は有りません。

※先程言いました、USBで電源を取る場合は『有線接続』される総使用電力が2.5wを越えては成りませんが。
 そこは個別マニュアルで解説する予定です。

この2つの無線・有線接続を共存できるように工夫しています。

一般的なBluetooth®LowEnergyの規格では8台まで同時接続できます。
NordicSemiconductor社のICを使えば16台まで接続可能です。
BraveJIGではNordicSemiconductor社のnRF52840を使用していますので、16台は理論上は繋がります。
と言うことは、16台以上繋ぎたい場合は残りは有線接続となることに成ります。理論的にはw

所が、BraveJIGでは100台まではBluetooth®接続が可能です。

こんな無線接続仕様であれば、使う側は便利な筈です。
この実現の為に、弊社はIoTの特徴を熟知しているので、そう言う無線プロトコルにしています。
何も、Bluetooth®Low Energyの規格を変えて使っているのではなく、それを巧みにつかった独自のプロトコルにしています。

オマケに、一度『BraveJIGルーターと、BraveJIG(センサー)モジュールの親子関係のペアリングをしてしまえば、有線・無線どちらでも
繋がる様に工夫していますので、電池を繋げば自動で無線接続、外して有線接続すれば自動で有線接続します。
実際は、有線無線混載で『1ールーターあたり100台の有線無線混載接続』を実現しています。

※ホントはもっと多くのセンサーを無線接続できるのですがw色々と事情も有りましてw 100台に制限していると言うことです。
 100台以上接続するユースケースでは、もう1台の『+ルーター』を追加して頂ければ、合計で200台拡張出来ます。

如何でしたでしょうか?

取り敢えず、ここまでの説明で、

IoT全体像の骨格にあたる部分は説明できたかと思います。

勿論、これで終わりでは有りませんが、骨格部分の背骨ぐらいは説明出来たかと思います。
未だこの位の知識ではIoTの全体像をイメージするのは難しいかもしれませんが、非常に重要な『基礎部分』は説明出来たかと思います。

今回が『第1章の1』です。
続けて『第1章の2』で、もう少し掘り下げていきます。
次に掘り下げていく部分は
『+ルーター』→『DB(データベース)サーバー』の繋がりの部分について解説します。


「ここら辺が分かり難い!」というのがあれば、弊社info@braveridge.comにメールして下さい。分かり易く成るまで改訂を繰り返しますので。

オマケ→Bluetooth®LowEnergyについて

文中では、Bluetooth®LowEneryと何度も記載しています。

この15年間で、日本では(海外でも)、 

Bluetooth®LowEnergy=『BLE』

と表現するのが一般的です。
しかし、BTsigに於いては、これを『禁止』していますw ホントに禁止しています。

HPでBLEという表現を使っていると、すぐさま警告が来ますのでご注意ください。

またww 
Bluetooth®LowEnergyというのも無くなりましたw

コレからは、全てがBluetooth®1本です。

Bluetooth®LowEnergyとは今後書けなくなりますw


実はこれも15年近くの歴史がありまして、元々は
 ①Bluetooth®Smart
 ②Bluetooth®Smart Ready
 ③Bluetooth®Classic

と3つにカテゴライズされていました。

今ではBluetooth®に一本化されています。
これは③のBluetooth®Classicが廃止されていまして、全てはこれからBluetooth®LowEnergyのみです。
今、新に③Bluetooth®Classicモジュールを使った新規申請は禁止されていますので、全てはBluetooth®LowEnergyのみになります。

なので、Bluetooth®のみの表記で統一されています。全てはLowEnergyしか存在しません。

と言うことで、第1章ー2以降はBluetooth®LowEnergyという表現は、全てBluetooth®に統一します。

 

SNS SHARE