IIoTの分類法

キングスは上質なガラスのスツールでチェスをします。誰もがこれを覚えていますか？

ほとんどの場合、それはおそらくぎこちないです。私のためではない。このニーモニックは、私が人生の分類法を思い出すのに役立ちます：王国、門、綱、目、家族、属、種。

地球上の生命の広さと深さ、そして多様性は圧倒的です。分類法は、システムのタイプをその特性によって論理的に分割します。生物学の科学は、優れた分類法がなければ不可能です。これにより、科学者は植物や動物を論理的なタイプに分類し、共通点を特定し、生物システムのクラス全体を理解するためのルールを構築することができます。

産業用モノのインターネット（IIoT）の幅と深さ、多様性も圧倒的です。 Science of IIoT Systemsには、同様に編成されたアプリケーションタイプの分類法が必要です。そうして初めて、システムを実装するための適切なアーキテクチャとテクノロジーについて話し合うことができます。

最初の問題は、トップレベルの部門を選択することです。動物界では、ほとんどの動物に「陸、海、空」の動物のラベルを付けることができます。ただし、これらの環境の説明は、動物を理解するのにあまり役立ちません。クジラの「建築」はタコのようなものではありませんが、クマのようなものです。理解するには、動物はその特徴と構造によって分けられなければなりません。

また、アプリケーションを「医療、運輸、電力」などの業界で分割することも役に立ちません。これらの環境は重要ですが、適用可能なアーキテクチャとテクノロジーは、業界の境界線に沿って分割されていません。ここでも、主要な課題を定義する特性をより深く理解する必要があり、それらの課題がアーキテクチャを決定します。

これは強力で衝撃的な主張でさえあることを私は理解しています。これは、たとえば、各業界の特注の標準、プロトコル、およびアーキテクチャは、IIoTシステムの将来のアーキテクチャを設計するための有用な方法ではないことを意味します 。それにもかかわらず、それは現場のシステムの明らかな事実です。エンタープライズインターネットになった変革のように、汎用テクノロジーが特殊目的のアプローチに取って代わります。理解を深め、IIoTの可能性を実現するには、業界固有の古い考え方を放棄する必要があります。

では、分割には何を使用できますか？ IIoTの昆虫から爬虫類から哺乳類を分離するために使用できる明確な特性は何ですか？

機能的および非機能的の両方で、使用できる要件は何千もあります。動物の場合と同様に、スペースを有用な主要なカテゴリに分割するいくつかの要件を見つける必要があります。

目標はスペースを分割してシステムアーキテクチャを決定できるようにすることであるという認識によって、タスクが簡素化されます。 。したがって、適切な分割基準は、a）明確であり、b）アーキテクチャに影響を与えます。それは簡単に聞こえるかもしれませんが、実際には非常に重要です。それを行う唯一の方法は、経験を通してです。私たちは探求の初期段階にあります。ただし、大きな進歩は私たちの集合的な把握の範囲内です。

1000近くの実際のIIoTアプリケーションに関するRTIの豊富な経験から、以下のいくつかの初期の部門を提案します。できるだけ鮮明にするために、各部門の「メトリクス」も選択しました。もちろん、線はそれほどはっきりしていません。しかし、数字は明確さを強制し、それは重要です。数字のヤードスティック（メータースティック？）がないと、意味が失われることがよくあります。

IIoTタクソノミーの提案

信頼性[指標：継続的な可用性は「99.999％」よりも優れている必要があります]

「信頼性の高い」という感謝の気持ちには満足できません。ほとんどすべてがそれを「必要」としています。意味のあるものにするためには、その信頼性を実現するためのアーキテクチャ上の要求についてより具体的にする必要があります。それには、障害がどれほど早く問題を引き起こし、それらの問題がどれほどひどいのかを理解する必要があります。

信頼性を分類するための最も簡単で最も有用な方法は、「年間5分間の予期しない障害の結果は何ですか？」と尋ねることです。 （ここでは、エンタープライズクラスのサーバーの「5-9s」ゴールデン仕様であるという理由だけで5分/年を選択します。多くの産業用システムは、数ミリ秒の予期しないダウンタイムにも耐えられません。）

これは、システムアーキテクチャに大きな影響を与えるため、重要な特性です。短時間でも障害が発生しないシステムは、冗長コンピューティング、センサー、ネットワークなどをサポートする必要があります。信頼性が本当に重要な場合、それはすぐに-またはおそらく-主要なアーキテクチャの推進力になります。

リアルタイム[メトリック：応答<100ms]

「リアルタイム」を特徴づける方法は何千もあります。すべてのシステムは「高速」である必要があります。ただし、有用であるためには、どの速度要件がアーキテクチャを駆動するかを具体的に理解する必要があります。

Webサイトを8秒以上待つことを望まない人間のユーザーを満足させることができるアーキテクチャは、2ミリ秒で応答しなければならない産業用制御を決して満足させません。応答速度が数十ミリ秒（ms）またはマイクロ秒（µs）で測定されると、設計に大きな影響を与える「カーブの膝」が発生することがわかります。 100msを選択します。これは、データパス内のサーバーまたはブローカーによって課せられる潜在的なジッター（最大遅延）に関するものだからです。通常、これよりもはるかに高速に応答するシステムは、ピアツーピアである必要があり、それはアーキテクチャに大きな影響を与えます。

データセットのスケール[指標：データセットのサイズ> 10,000アイテム]

繰り返しになりますが、「ノード」の数、アプリケーションの数、データアイテムの数など、スケーリングするディメンションは数千あります。スペースをこれらすべてのパラメーターで分割することはできません。実際には、それらは関連しています。たとえば、多くのデータ項目があるシステムには、おそらく多くのノードがあります。

広いスペースにもかかわらず、2つの簡単な質問がアーキテクチャの要件と相関していることがわかりました。 1つ目は「データセットサイズ」で、曲線のひざは約1万アイテムです。システムがこれほど大きくなると、すべてのデータ更新をすべての可能な受信者に送信することはもはや実用的ではありません。したがって、データ自体の管理は、アーキテクチャ上の重要なニーズになります。これらのシステムには、データを明示的にモデル化して選択的なフィルタリングと配信を可能にする「データ中心の」設計が必要です。

チームまたはアプリケーションの規模[指標：チームまたは相互作用するアプリケーションの数> 10]

選択する2番目の尺度パラメーターは、「プロジェクト」上のチームまたは独自に開発されたアプリケーションの数であり、ブレークポイントは約10です。開発者の多くの独立したグループが相互作用する必要のあるアプリケーションを構築する場合、データインターフェイス制御が相互運用性の課題を支配します。繰り返しになりますが、これは多くの場合、これらのインターフェイスを明示的にモデル化および管理するデータ中心の設計の必要性を示しています。

デバイスデータ検出の課題[指標：>多変数データセットを備えた20種類のデバイス]

一部のIIoTシステムは、実行前に構成および理解することができます（または必要です）。これは、すべてのデータソースとシンクが既知であることを意味するのではなく、この構成が比較的静的であることだけを意味します。

ただし、IIoTシステムがラックとマシンまたはデバイスのラックを統合する場合、多くの場合、運用中に構成して理解する必要があります。たとえば、プラントコントローラHMIは、ユーザーが監視するデータを選択できるように、インストールされているデバイスまたはラックのデバイス特性を検出する必要がある場合があります。 「20」の異なるデバイスの選択は任意です。ポイント：ラック内のデバイスにさまざまな構成がある場合、この「内省」は、手動の体操を避けるための重要なアーキテクチャ上の必要性になります。この特性を備えたほとんどのシステムには、20を超えるデバイスタイプがあります。

配信の焦点[指標：ファンアウト> 10]

「ファンアウト」とは、単一のデータ項目の変更時に通知する必要のあるデータ受信者の数として定義されています。多くのプロトコルは単一の1：1接続を介して機能するため、これはアーキテクチャに影響を与えます。エンタープライズの世界のほとんどはこのように機能し、多くの場合、1：1セッションプロトコルであるTCPを使用します。たとえば、ブラウザをWebサーバーに接続したり、電話アプリをバックエンドに接続したり、銀行をクレジットカード会社に接続したりします。

ただし、IIoTシステムでは、多くの場合、より多くの宛先に情報を配信する必要があります。単一のデータ項目を多くの宛先に送信する必要がある場合、アーキテクチャは効率的な複数の更新をサポートする必要があります。ファンアウトが10程度を超えると、1：1接続のセットを管理してこの分岐を行うことは実用的ではなくなります。

コレクションの焦点[指標：ファンが100を超える一方向のデータフロー]

本質的に収集の問題に制限されているシステムは、デバイス間で重要なデータを共有しません。代わりに、大量の情報を送信して、上位レベルのサーバーまたはクラウドに保存または分析します。

これは、アーキテクチャに大きな影響を与えます。収集システムでは、多くの場合、ハブアンドスポークの「コンセントレーター」またはクラウドベースのサーバー設計を使用できます。

分類法の利点

IIoT分類の定義は簡単ではありません。このブログは表面をかじっただけです。ただし、そのメリットは計り知れません。これらのニーズを解決することは、システムアーキテクトがプロトコル、ネットワークトポロジ、およびコンピューティング機能を選択するのに役立ちます。今日、適切な設計でサーバーが必要ない場合でも、設計者はサーバーの場所や構成などの問題に苦労しています。 「リアルタイム」や「モノ」などの過負荷の用語は、実際のユースケースが重複することなく、テクノロジー間で大きな混乱を引き起こします。

インダストリアルインターネットコンソーシアムがこの重要な課題に取り組む時が来ました。その最新のワーキンググループは、これらの最も基本的なビジネスおよび技術的義務を明確にすることを目的として、この問題に対処します。バルセロナで開催される次回のIICメンバー会議で、このグループのキックオフを支援できることをうれしく思います。興味のある方は、私（[email protected]）、Dirk Slama（[email protected]）、またはJacques Durand（[email protected]）までご連絡ください。まず、IIoT全体で広範な共同体験を共有することから始めます。