数日前、私は優れた記事「スマートシステム開発者宣言：15の原則」を読みました。

私は、下の層、つまり基本的に提案された原則に対応するアーキテクチャの基本原則についての考えを共有することにしました。

断食の性質上、マニフェストよりもさらに主観的です。

まず、スマートシステムの開発者とユーザーなど、いくつかの用語を扱いましょう。 これは誰で、どこで分離が行われますか？

2つの明らかな極端があります。購入したスマートスイッチのメーカーと、ライトをオンにする妻です。 しかし、私は私の息子を誰に連れて行くのですか？彼らは時折ESP32を手に入れてセンサー、ボタン、その他のLEDストリップをはんだ付けし、同じスイッチと相互作用しますか？

しかし、ベンダーに目を向けても、それは完全に明確ではありません。 説明します。 明らかな極端：同じメーカーのすべてのデバイス、ハブも彼であり、彼のスマートフォンのアプリケーションはスマートシステムの開発者です。 しかし、同じネットワーク上に複数のベンダーがある場合はどうでしょうか？ しかし、もし1つの中央ハブ、別のデバイス、そして私がやり取りするクラウド、たとえばSiriがAppleであるとしたらどうでしょうか。 マニフェストの対象となるのはどれですか、どちらが同じ開発者ですか？ 私はマニフェストのグローバルな抽象化のレベルをわずかに下回っていると思いますが、それはところで、私はほぼ完全に共有しますが、より深い機能的分離を導入する必要があります。そうしないと、ユーザーエクスペリエンスに対する集団的責任は、私たち全員が現在ある程度観察している集団的無責任のいずれかになります、または、ユーザーレベルで統合されたエコシステムの堅固な囲いの中にあります。スマートフォンでスマートホームを管理するためのアプリケーションを複数持っているのはどれですか。

オブジェクトの次の分離を提案します：エンドデバイス、ハブ、ゲートウェイ、データクラウド、統合サービス、ユーザーインターフェイス。

たとえば、ユーザー、カスタマイザー、開発者、メーカー、サプライヤーなどのサブジェクト（役割として）は、これらのオブジェクトのコンテキスト内に存在します。

一緒になって、データの交換を通じてその機能を提供するシステムを作成および構成します。

この投稿ではもう少し詳しく、オブジェクトのみに焦点を当てます。

エンドデバイス

はい、これはかなり面白い質問です。 エンドデバイス、つまりモノのインターネットのまさに「モノ」とは何ですか？

スマートな掃除機で、すべてがはっきりしています：彼らは箱から引き出され、そのベースをコンセントに差し込んで、彼は服を着て、運転し、あなたのペットの自由な創造性で白いカーペットを重ね合わせて充電しました。 しかし、すでに電球があれば、奇妙なことに、それはそれほど単純ではありません。

今、私はシャンデリアをいくつかのランプで見ており、3つの異なるスイッチで点灯します（別々に、核弾頭を起動するのとは異なります）。実際、パネルのDINレールの調光器は機能します。 ここで、「もの」は最終アクチュエータを意味するように見えますが、面白いのは、この調光器がマルチチャンネルであり、他のシャンデリアのどれを制御するかさえ覚えていないことです。したがって、ここではすべてではなく一部のみです。 しかし同時に、妻の「明かりをつける」というフレーズは直感的です。

私は読者に別のバンドルの「もの」を見つけることを勧めます：ルームコントローラー（サーモスタット）は、8チャンネルPWMの1チャンネルを介してラジエーターヘッド（加熱）を制御し、チャンネル0-10Vアクチュエーターのチャンネル4の1を冷却します。ダクト内の空気の流れ。

私はこの文脈で残酷な首相にぶつかり、「モノ」の正確な定義を導入するというアイデアを持っていましたが、その機能の意味でエンドデバイスについて話し、それらの数とそれらの相互作用は今のところ括弧から除外されます。

それから、直感的な「暖かくする」または「出かけるときにエコノミーモードをオンにする」ことは非常に明白です。

ハブ

ものが何であるかについてのこれまでの考えを考慮すると、ハブは本質的にさらに仮想的なものの工場です。 ラジエーターに温度センサーとヘッドが既にある場合に、サーモスタットを作成できるハブです。 彼は、「全世界」のデバイスを作成でき、それをオフにすることができます。 おもしろいですが、ハブは完全に仮想化できます。たとえば、EIBまたはKNXでは、基本概念はグループアドレスです。センサーはデータを送信し、アクチュエータは各機能の1つ以上のグループアドレスを受信します。 したがって、アパートの出口に何らかの1/1/1状態0に送信するスイッチがあり、光を担当する各アクチュエーターに存在する場合（たとえば、1/0 / 11、1 / 0/12など）追加の物理デバイスなしで「全世界の電源を切る」ようなデバイスがあります。

この例では、ハブはネットワーク自体です。他の場合、ハブは物理世界に別の物理デバイスとして存在することがよくありますが、「あまり物理的ではない」ハブの別の良い例を挙げることができます-これはNode-REDです。

既存のデバイスからのデータストリームがこのまさにハブにどのように流れ込み、そこからシステムの他の部分に流れるのかを意図的に述べていないことに特に注意してください。 他のシステムオブジェクト-ゲートウェイ-は、この機能を担当します。

ゲートウェイ

過去40〜50年にわたって、さまざまなトポロジと抽象化レベル（独自のプロトコル）を備えた多くのネットワークが作成され、何らかの形でモノのインターネットシステムの一部になりました。 2つのネットワークを接続するために、トラフィック交換ノードが作成されます。そのようなノードが1つのプロトコルのすべてのデータを別のプロトコルにパックする場合、トンネルと呼ぶのが一般的です。一方、交換が発生した場合、ストリーム全体をローカルであるかのように完全に動作させることができるためです抽象化、そのようなノードはゲートウェイと呼ばれます。

この記事では用語にかなり精通しているので、 ゲートウェイという用語を使用し、実際に存在するデバイスがどこからどこで実際にゲートウェイであるかを解析するのにもう少し時間を費やしましょう。 遅かれ早かれ、プロセス制御システムで働いていた全員が「セントラル」ネットワークを追加のネットワークで拡張しました。たとえば、多くのメーターがModbusのProfibusに接続されていました。

これは非常によくできたケースであり、あまり多くのことを止めることはできませんが、Xiaomi Mijia Multifunctional Gatewayはどこにロックされていますか？ ZigBeeからWi-Fiへと言いたいのですが、これは完全に真実ではありません。 はい、ゲートウェイの片側にZigBeeネットワークがありますが、サードパーティのデバイスを接続しても、このゲートウェイを介して到達することはできません。 ゲートウェイの反対側にWi-Fiがありますが、ゲートウェイはプロトコル（ハッカーによってmiIOプロトコルと呼ばれた）を介してローカルネットワーク上で通信を提供するだけでなく、ローカルネットワークを離れるときにMi Homeアプリケーションの動作を保証するXiaomiクラウドとも通信します。 もう1つの非常に興味深いゲートウェイは、Samsung SmartThingsですが、問題があります。

Groovyがその多様性をすべて備えている理由が以前に疑問であった場合、私は今、曇りに入札することの難しさを呼ぶでしょう。

私が間違っていることを願って、私の立場を説明します。 Samsung SmartThingsエコシステムと互換性のある新しいデバイスを作成する場合、2つのオプションを選択できます：ハブに接続するか、クラウドに直接接続します。自動化を作成する場合は、ハブによって生成されたデバイスの上に名前を付けたものをクラウドに移動します。 ポイント。 つまり、マニフェストの違反があります。 アプリケーションを介して（明らかにIoTとTizen IoTの記事の図に基づいてローカルに希望はもうありません）、またはデバイスを統合する必要があるため、別のネットワークのモーションセンサーからも、インターネットが機能しない場合はトイレのライトをオンにしませんネットワークではなく-それ以外の場合はクラウド経由。

Tizen IoTを使用して管理してくれた方、私を修正してください。

同様の状況がLogitech Harmonyであり、アップグレード後にローカルオートメーションが壊れました。

「自動化ネットワーク-自動化ネットワーク」タイプのゲートウェイを破棄する場合、ゲートウェイの動作で最も重要なことは、コアネットワークからのデバイスのプレゼンテーションを変換するターゲット抽象化であり、これは既にデータクラウドによって決定されています。

データクラウド

これは、同時に最も明白で最も非自明なシステムオブジェクトです。 その機能とその必要性は明らかですが、このコンポーネントがどのように正確に実装されているかは最も明らかではなく、エンドユーザーの欲求に依存しません。

したがって、私はむしろ個人的なウィッシュリストと思考のこの部分に注ぎます。

わかりやすいAPIがあり、シンプルな場合に便利です。このAPIが開いていて、簡単に接続できるとさらに便利です。

ここでは、シンプルさについて予約します。 単純さは、数学の話ではないにしても、原則として主観的なものです。 私の個人的な意見は、私の経験と欲望に基づいています。 もちろん、数十万の量で特定の製品をリリースしようとしている会社にとって、単純さは完全に異なります。

趣味の結果を自分の周りの世界に織り込みたい。 これには何が必要ですか？

主な制限リソースは時間、2番目は知識、3番目はお金です。 1日で何らかの形でクラウドを介して機能するデバイスを作成できない場合、「Mayy Chumorrow」および「Magnya」と同義である限り、「後で」行われます。 さて、それが何らかの形で機能するのであれば、数日休んだ後、おそらく正常に機能するでしょう。 IoTは本質的に学際的なものであり、ここではOAuth2サーバーを上げ、証明書を追加し、APIを実装する必要があります。これらはすべて、音声アシスタントを備えた小さな自家製のマイクロコントローラーを作成するために行われます。

以前の考えは「どのように？」に関するものでしたが、「何？」にはそれほど重要な問題はありません（これは課題ではありません。つまり問題です）。

IoTに使用できるすべての主要なデータクラウドを、データポイントと機能の2つのクラスに分割します。

データポイントのクラウド 。 これは、SCADAの世界と並行した進化、または直接の子孫です。

ここに温度センサーの測定値があります-さて、それをクラウドのどこかに書いてみましょう。 温度センサーはバッテリー上にあるため、充電レベルを維持する必要があります。重要ではありません。上記を参照してください。 これを可能にするクラウドのクラスはすべてあります。 メインプロトコルがMQTTの場合は簡単に認識できます（ただし、CoAPとSTOMPの両方が可能です）。 すばらしいこと-私自身はIoTだけでなく、それを「常識に対する自由の勝利」と呼んでいます。 プロトコルが非常に柔軟であるため、誰もが同じ問題を独自の方法で解決できます。

機会という形のデータのクラウド 。 約8〜9年前、ホームプラットフォームの次のバージョンを書いていたときに、システム内のオブジェクトを取得して分類したかったと認めています。 システムがこれが電球であり、これがスイッチであり、これがバルブであることを理解するように。 明らかな最初の反復：型のリスト（ただし、OOPは同じであるため、実際にはクラスです）。 その後、スイッチが表示されますが、バッテリーではOOPの電源が動作しています-継承して新しいものを取得しました。 そして、それはバッテリーが何である可能性があることが判明しました。 次に、デバイスクラスのツリーに切り込むのではなく、デバイスの「機能」に分割し、それらを組み合わせてスイッチを取得する必要がありました。

Apple HomeKit、Alexa、Google、その他のスマートホームのクラウドエコシステムの仕組みです。 それは幸せのようです。

しかし、上で言ったように、私はこのアプローチを8〜9年前に使用しました。 そして、私はこれらの機能を自分で決めました。IPカメラまたはアスタリスクPBXを追加したいのですか？ 素晴らしい。 終わって仕事をしています。

しかし、不幸なことに、上記のスマートホームのクラウドエコシステムは、実際にはIoTのエコシステムではなく、音声アシスタントのエコシステムであり、その機能は全世界とすべてのデバイスに共通するはずです。 プロセスに新しい機能を追加することは、私の「追加と作業」とは大きく異なります。 私たちは皆、これらの生態系のd明期に「ゲートをオンにする」必要があったことを覚えています。 状況はSmartThingsでも同様です。

どのメーカーも、リリースしてIoTエコシステムの一部になることができるデバイスの機能の明確で包括的なリストを提供することはできません。 それが、内臓脂肪、血糖、またはアセトンの割合のようなシステムが何を知る能力を持っていないのですか？ すべてがうまくいったとき、または何かがうまくいかなかったときにあなたの注意を引くために、なぜ家は楽しい幻想であなたをサポートできないのですか？

一方、デバイスが何ができるかを理解せずにユーザーインターフェイスを作成する方法は？ SCADAのデータポイントアプローチは、トポロジおよびプロトコル機能を隠すのに便利でした。 信頼性（途中で切断があったかどうか）やアクセスレベルなど、いくつかの追加プロパティを使用してデータ（水平リスト）を取得しますが、それらのメインプレゼンテーションはニーモニックダイアグラムの形式でした。

しかし、IoTユーザーはポストPC時代に住んでおり、ニーモニックスキームは電話の画面上では不便であり、セットアップは許されないほど長くなります。

ある種の交配があるはずだと思います。 まず、システムはデバイスが何であるかを知っている必要があり、データポイントが必要です。 ただし、重要なことは、お気に入りの音声アシスタントなど、特殊なクラウドに配信する必要がある追加のメタ情報も必要であることです。 このような情報には、特に、外部クラウドの理解におけるデバイスのプロファイル（機能のセット）とその識別子の両方が含まれます。

デバイスメーカーの機能は、とりわけ、ビジュアルインターフェースと他のタイプ（音声インタラクション、AR / VRなど）の両方について、この製品の望ましいパフォーマンスを記述することです。 しかし、製造業者がこれを行わなかったとしても、しぶしぶと怠に圧倒された場合でも、ユーザーは今後このGoogleデバイスが「スマートホームケトル」として知っているものを選択でき、温度制御、オンオフ、モード、トグル はい、コンパクトにするためにaction.devices.traitsを削除しました。

これは、すでにサービスを統合する必要がある相互運用性を確保するためです。

統合サービス

これは同じゲートウェイですが、すでにクラウド間です。 一部の抽象化は他のものに置き換える必要があります。

相互作用の基本はイベントです。 クエリモデルとパブリケーションの両方があります。 このトピックは非常に広大なので、説明するときにボリウッドのwoodに陥ることがあります。 そこでは、ご存じのように、物理的に人が見ることができるよりも多くの映画が年間制作されています。

したがって、記事の終わりまでに、説明が始まる時点よりも現実からさらに遠くなります。

すでに多くの家庭用システムについて言及しましたが、LoRaWAN（およびTheThingsNetwork）、IFTTT、OpenStreetMap、AWS IoT、Azure IoT、気象サービスを思い出すことができます。はい、実際、ほとんどすべてのインターネットまたはイントラネットサービス（他の用語はありますか？）企業システムに入る必要があります。

ユーザーインターフェース

この部分については詳しく説明しませんが、家庭用IoTシステムであるデスクトップによってバイパスされることについて、私の意見では不当に嘆きます。 Mojave HomeKitでようやく出てきました-私にとってこれは戸惑います。 なぜ会社のキャッシュフローを計算できるスプレッドシートよりもやかんが複雑なのですか？ 結局のところ、Numbersを使用すればブラウザーで作業できますが、Appleの理解では、忘れられていたアイロンをオフにする必要はありません。 要するに、PWAを与える！

ユーザーインターフェイスは、主に便利な物理スイッチですが、許されないほど少数です。

AR、VR、Mixed Reality、音声アシスタント、スマートテレビ、スマートフォンやタブレット用のアプリケーション、EEGニューラルインターフェイスはケーキのチェリーです。

あとがき

Dockerとマイクロサービスはそれと何の関係があるのでしょうか？ 読者にとって興味深いものである場合は、このオブジェクトの分類に基づいたIoTシステムのアーキテクチャの実装における私の考えと開発を喜んで共有します。

自分で使います。