シリーズの関連記事を読む

• 未来の工場の実現を目指す【Part 1】エッジ向けのAIを活用したセンサーの設計

×

Figure 1

   

要約

産業用のシステムに更なるインテリジェンスを追加するにはどうすればよいのでしょうか。そのための方法はいくつかあります。典型的な例としては、エッジまたはクラウドで稼働するAIと、アナログ／デジタル・コンポーネントを備えるセンサー・システムを組み合わせる方法が考えられるでしょう。ただ、AIの具体的な活用方法は様々です。そのため、センサー・システムを設計する際には、アプリケーションに応じ、いくつかの競合する要件について考慮しなければなりません。例えば、意思決定にかかる時間、ネットワークの使用量、消費電力／バッテリの寿命、機器に適合するAIのモデルなどに関する要件が存在するはずです。本連載のPart 1では、振動の監視を実現するワイヤレス・プラットフォーム「Voyager 4（EV-CBMVOYAGER4-1Z）」を紹介しました。その中で特に注目したのは、このAIベースのプラットフォームを構成するハードウェアの設計についてです。今回（Part 2）は、エッジで使用するインテリジェントなセンサー・システム向けに構築されたソフトウェアのアーキテクチャとAIのアルゴリズムに焦点を絞ることにします。特に、Voyager 4で使用するAIのモデルを開発するために実際に採用したシステム・レベルのアプローチについて詳しく解説します。

状態監視用のセンサー向けのソフトウェア設計

Voyager 4は、アナログ・デバイセズが状態監視の用途に向けて開発したワイヤレス・プラットフォームです。これを利用すれば、開発者は現場の機械あるいは評価環境にワイヤレス・ソリューションを迅速に配備してテストを実行することができま未来の工場の実現を目指す【Part 2】エッジのセンサー・システムにAI用のソフトウェアを実装する方法著者：Tom Sharkey、システム・アプリケーション・エンジニアす。Voyager 4が対象とする典型的なアプリケーションはモータの状態監視です。この種のソリューションは、産業分野の現場で使用されるロボットやタービン／ファン／ポンプ／モータなどの回転機械を対象として広く活用されています。

但し、Voyager 4のようなワイヤレスのエッジ・デバイスで使用するソフトウェアを開発するのは必ずしも容易ではありません。実際、センサーの設計における初期の段階から、そのシステムのアーキテクチャに関する様々な事柄について熟慮する必要があります。例えば、システムの個々の部分がどのように動作するのか、様々なコンポーネントを連携させるためにはどのように統合を図ればよいのか、ニューラル・ネットワークなどの有用なアルゴリズムや分析ツールをどのように適用してエッジにインテリジェンスを追加すればよいのかといった検討を実施しなければなりません。最終的な目標は、エッジ・デバイス用のソフトウェアと接続先のホスト用のソフトウェアを開発することです。それらのソフトウェアは、理解するのが容易で、変更やアップグレードが可能なものでなければなりません。

Voyager 4は、2つのマイクロコントローラに加えて、センサー、パワー・マネージメント用のボード、フラッシュ・メモリ、通信用インターフェースなど数多くのペリフェラルを備えています。それらの構成要素を組み合わせた状態であらゆる制御を行うためのコードを開発するのは容易ではありません。

本稿では、Voyager 4を開発した際に適用した設計プロセスを紹介します。特に、実際に採用した手順を強調しつつ、いくつかの具体的な実装例を示すことにします。それを通じ、エッジで使用する独自のセンサー・システムを開発する方法についてより深く理解していただくことを目指します。

この連載では、3回にわたりVoyager 4について詳しく解説しています。本稿は、そのPart 2です。Part 1～Part 3では、それぞれ以下に示す事柄について説明します。

• Part 1：Voyager 4の全体像について解説しました。センサーのアーキテクチャを構成する要素、ハードウェアの設計、電力のプロファイリング、機械的な統合方法などについて詳しく説明しました。
• Part 2：ソフトウェア・アーキテクチャとAIのアルゴリズムに焦点を絞ります。Voyager 4 向けのAI モデルを開発／配備するために採用したシステム・レベルのアプローチについて詳しく解説します。
• Part 3：AIをベースとする実用的なアルゴリズムの実装について説明します。その上で、Voyager 4 によって検出が可能な様々な障害（不均衡、位置ずれ、ベアリングの欠陥など）について解説します。

Voyager 4の概要

ここでは、Voyager 4の全体像について簡単におさらいしておきます。状態監視用のセンサーに関する詳細や、Voyager 4を構成するハードウェア、パワー・マネージメント、セキュリティなどについては、本連載のPart 1をご覧ください。

Voyager 4の主要な構成要素を図1に示しました。まず、振動のデータの収集には、MEMS（Micro Electro Mechanical System）加速度センサー「ADXL382」を使用します。ADXL382は3軸に対応するデジタル出力の製品であり、帯域幅は8kHzです。収集されたデータは、動作モードに応じて複数の異なるパスでやり取りされます。

未処理の振動データは、パス[a]を介してBluetooth® Low Energy（BLE）に対応するマイクロコントローラ（以下、BLEコントローラ）「MAX32666」に直接送信されます。同コントローラを使用すれば、BLE（無線）またはUSBを介して未処理のデータをユーザに送信することができます。それらのデータは、エッジのAIのアルゴリズムのトレーニングに使用されます。そのトレーニングには、AIに対応するマイクロコントローラ（以下、AIコントローラ）「MAX78000」の外部ツールを使用できます。パス[b]は、Voyager 4を使用して収集した未処理のデータをAI対応のMAX78000に引き渡すために使われます。このパスを使用するのはMAX78000の外部ツールによってモデルをトレーニングした後です。このパスが使用されるモードにおいて、未処理のデータはユーザに送信されるのではなく、エッジに実装されたAIのアルゴリズムに引き渡されます。それらのデータを基にして、監視の対象となっている機器の故障が予測されます。パス[C]とパス[D]は、それぞれモータの障害が検出された場合と検出されなかった場合に使用されます。障害が検出された場合、BLEコントローラを経由してホストにフラグまたはユーザ向けのアラートが送信されます。一方、障害が検出されなかった場合、センサーは次のイベントを検出するまでスリープ・モードの状態で保持されます。

Voyager 4のソフトウェアとAIのアルゴリズムを開発する際には、このアーキテクチャについてシステム・レベルで完全に理解することが重要です。そのために、本稿では以下に挙げる事柄について詳しく解説します。

• BLEに関する用語
• BLEのペリフェラルの実装
• BLEのセントラルの実装
• AIのアルゴリズムのトレーニングと配備

BLEの特徴

産業分野でエッジに配備されるセンサーを設計する場合、ネットワークへの接続性（コネクティビティ）が重要な要素になります。接続性は、使用可能な電力／必要な電力をベースとしつつ、通信範囲、デバイスの寿命全体にわたる信頼性、サイズなどあらゆる事柄に影響を及ぼします。表1は、各種のワイヤレス接続技術を比較したものです。ご覧のとおり、BLEには他のワイヤレス接続技術にはない固有の長所があります。BLEの通信距離、消費電力、信頼性は、産業分野の状態監視の用途において特に有用です。BLEに対応するエッジ・デバイスを設計／開発するためには、まずBLEのプロジェクトで使用される基本的な用語について理解する必要があります。

表1. ワイヤレス接続技術の比較

	通信距離	消費電力	信頼性	堅牢性	総所有コスト	メッシュ構成の可否	セキュリティへの対応
Wi-Fi	100 m	多い	低い（単一のRFチャンネル）	低い	高い	可	あり（WPA）
BLE	20m～100m	少ない／中程度	中程度／高い	低い	中程度	可	あり（AES）
ZigBee、Thread	20m～200m	少ない／中程度	低い	低い	中程度	可	あり（AES）
Smart-MESH	20m～200m	少ない	高い	高い	低い	可	あり（AES）
LoRa-WAN	500m～3000m	中程度	低い	低い	高い	不可（スター・トポロジ）	あり（AES）

BLEが提供するすべての機能について詳しく説明しようとすると、1冊の本になってしまいます。そこで、本稿ではBLEデバイス（BLEに準拠するデバイス）を実装する際に考慮しなければならない重要な概念に注目することにします。具体的には、以下の事柄を取り上げます。

• ソフトウェア・スタック
• ペリフェラルとセントラルのモデル
• プロトコルとプロファイル

BLEのソフトウェア・スタック

BLEのソフトウェア・スタックは、BLEに準拠するデバイスが実装しなければならない標準プロトコルの集合です。図2を見ると、スタック内の様々なプロトコルがどのような名前でどのように階層化されているのかがわかります。ユーザによる通信やデバイスの接続といった高レベルの機能は、データのカプセル化／パースといった基本的なタスクを担当する低レベルのプロトコルによってサポートされています。

幸いなことに、開発者としてはスタックのコンポーネントに関する基本的な知識があれば十分なケースが多いはずです。なぜなら、独自のバージョンを実装した様々なハードウェア・デバイスの中から必要なものを選択すればよいからです。そのようにすれば、あらかじめ構築されたBLEのスタックを利用しつつ、デバイス自体を制御するためのアプリケーションの一部を開発するだけで済みます。

図2に示したとおり、BLEのスタックは、一般的にはアプリケーション、ホスト、コントローラの3つに分類されます。これらのうち、アプリケーションは、ユーザ向けのインターフェースと、ユーザが実装する特定のアプリケーション用（振動の監視用）のコードを定義します。一方、ホストはBLEのソフトウェア・スタックの上位層に相当し、プロファイルやプロトコルといった高レベルの機能を制御します。コントローラはBLEのスタックの下位層に当たり、リンク層と2.4GHzの無線に対応可能な物理層が含まれています。先ほど触れたように、Voyager 4では、BLEコントローラとしてMAX32666を選択しました。同ICは、長距離（4×）の通信と高いデータ・スループット（2Mbps）に対応します。Arm® Cortex®-M4をベースとする低消費電力の製品であり、Bluetooth 5 Low Energyに対応する無線機能を備えています。

ペリフェラルとセントラルのモデル

BLEに対応するデバイスは、その役割に応じてペリフェラルまたはセントラルと呼ばれます。データは双方向にやり取りされるので、両者には共通する部分もたくさんあります。ただ、両者には接続方法の面で大きな違いがあります。ペリフェラルに相当するデバイスは、実際に接続を行う前に、自身は接続が可能な状態であることを通知します。一方、セントラルに相当するデバイスは、接続が可能なペリフェラルをスキャンした上で接続を開始します。データはペリフェラルとセントラルの間で双方向に送信される可能性があるわけですが、セントラルがホストであると見なされます。以前はペリフェラル、セントラルをそれぞれサーバ、クライアントと呼んでいました。

Voyager 4は、データを収集してセントラルに送信するペリフェラルとして定義されています。Voyager 4の開発プロジェクトでは、設計／開発を簡素化して理解しやすいものにすることを1つの目標としていました。以下では、図3に示すように、1つのセントラル・デバイスが1つのペリフェラル・デバイスと通信を実施する最も単純なケースに注目することにします。

プロトコルとプロファイル

Bluetoothに関する用語の中でも、プロトコルとプロファイルは混同されやすいものだと言えます。プロトコルとは、データのカプセル化、フォーマッティング、ルーティングなど、デバイスの動作を担う基本的な機能を実現するビルディング・ブロックのことです。一方のプロファイルは機能のバンドルに相当します。つまり、バンドルとしていくつかの機能を組み合わせることにより、基本的な動作モードが実現されます。基本的には、特定の機能を実現するためにプロトコルを組み合わせたものがプロファイルだと言えます。例えば、デバイスのバッテリの残量を調べるためにはバッテリ・サービスのプロファイルが使用されます。すべてのBLEデバイスには、他のBLEデバイスと接続できるようにするために、GAP（Generic Access Profile）とGATT（Generic Attribute Profile）という非常に重要なプロファイルを実装しなければなりません。GAPは、アドバタイズ、デバイスの検出、接続の管理といった低レベルの機能に対応します。一方のGATTは、高レベルのデータの整理やデバイス間のデータ転送の管理に使用されます。それだけでなく、確立された接続を介してデバイスがデータの読み出しと書き込みを行えるようにします。

プロキシミティ（近接）プロファイルをはじめとするその他のプロファイルは、デバイスに追加の機能を提供するためのアドオン（オプション）として扱われます。例えば、Bluetooth SIG（Special Interest Group）によって定義されたプロファイルもこれに相当します。定義済みのプロファイルのセットは、スマート・ウォッチやスマート・メータといった一般的なデバイスを開発する場合には非常に便利です。それに対し、多くのカスタム機能を実装するデバイスの開発で利用しようとすると、何らかの制約が生じることがあります。

Bluetooth SIGによって定義されたものではないカスタムのプロファイルも使用できます。その場合、移植性が犠牲になりますが、設計の柔軟性が向上します。各プロファイルのデータはサービスとして整理されます。サービスは、いくつかのキャラクタリスティックで構成されます（図4）。

セントラルとペリフェラルの間で接続が確立されると、セントラルはそのペリフェラルに関連づけられたプロファイルとサービスを要求することができます。図5は、セントラルから要求があったときのVoyager 4のGAP、GATT、カスタム・プロファイル（およびそのサービス）の構造を表しています。

Voyager 4を開発した際には、基本的なGAP/GATTのプロファイルに加えて、1つのカスタム・プロファイルを定義しました。そのカスタム・プロファイルはコマンド・サーバとして使用します。コマンド・サーバはセントラルからのコマンドを処理し、何らかのデータを返すか、ペリフェラルそのものの構成を更新します。

ファームウェアの実装

BLEコントローラは、システムの中核を成すものです。このコントローラは、接続されたBLEのセントラルによって、すべてのペリフェラル・センサーとペリフェラル・デバイスからのデータを取得または変更できることを保証します。

デバイスの構成

BLEに対応するMAX32666には、BLEスタックがあらかじめ実装されています。そのため、必要な構成関数に必要な値を入力として引き渡すことにより、ペリフェラルの概要を定義できます。ここで図6をご覧ください。この例では、Voyager 4に電源が投入されるたびに呼び出されるペリフェラル・セットアップ関数に対し、データ長、アドバタイズの種類、スキャン時のデータ検出に用いる配列に格納される文字のリストを設定しています。

このようなBLEデバイスには、無線の送信電力、戻り値のデータ型など、設定しなければならない数多くの項目が存在します。恐らく、使用するハードウェアには構築済みのサンプルが付属しているでしょう。それらのうち1つを出発点として変更を加えていくことをお勧めします。MAX32666の場合、「BLE DATS」というサンプル・コードが付属しています。これは、BLEに対応するデータ・サーバ（ペリフェラル）を実現します。Voyager 4の開発プロジェクトでは、そのコードを起点として使用しました。図6のように設定を行うと、セントラルが接続可能なデバイスをスキャンする際、このペリフェラルが「Voyager」という名前で認識されます。これを使えば検索結果の絞り込みを行うことができます。例えば、検索の対象とする名前のデバイスのみがセントラルによって表示されるようにするといった具合です。図7に示すように、デバイスの名前と共に、デバイスのMAC（Media Access Control）アドレスとRSSI（Received Signal Strength Indicator）の値を表示することも可能です。

スタックの他の構成用の設定を使用すれば、デバイスの他のモードに対応する名前や動作を制御することができます。例えば、製造元のIDや、読み出し／書き込みコマンドに対する応答などが制御の対象になります。

コマンド・サーバ

Voyager 4では、セントラル側とペリフェラル側の設計を並行して実施しました。そのため、BLEの単一のサービスを備えるカスタム・プロファイルを使用することにより、ペリフェラルのインターフェースを簡素化することができました。このプロファイルは、セントラル・デバイスからコマンドを受け取り、加速度センサーで取得したデータ、温度のデータ、デバイスに関するその他の情報を応答として返します。

この単一のカスタム・サービスは、Voyager 4のような複雑なデバイスでBLEによる通信を行うためのものとしては一般的ではありません。ただ、このサービスはいくつかのメリットを提供します。例えば、Voyager 4のペリフェラルへのコマンド入力として文字列を使うとします。その場合、データのパース方法に応じて様々な種類のコマンドと値を使用できます。その結果、コマンドに関する柔軟性が高まり、Voyagerのバージョン間で後方互換性を実現することが可能になります。

ペリフェラルとセントラルの間で接続が確立されたとします。その場合、セントラルは双方向の通信を実現するために、カスタムのキャラクタリスティックに対して通知コマンドを発行します（図11）。それにより、ペリフェラル側に通知システムが確立され、それに対応するセントラル側のコールバック関数が割り当てられます。その結果、このカスタムのキャラクタリスティックのデータが更新される度にセントラル・デバイスに通知が届き、新しいデータが転送され、セントラル・デバイスのコールバック関数が呼び出されるようになります。

ファームウェアのアーキテクチャ

図8に、Voyager 4のハードウェア構成を示しました。この図を見れば、様々な構成要素と、データ・パス、電源について把握できます。ソフトウェア開発の大半は、BLEコントローラを対象として実施しました。BLEコントローラは、コマンド・センターとして動作します。つまり、BLEに対応するデバイス向けのインターフェースと、センサーやマイクロコントローラが内蔵するデータ用パイプラインを調整する機能を提供します。システム内の様々なセンサーやマイクロコントローラと相互に作用するために、BLEコントローラとAIコントローラを対象とするデバイス・ドライバも開発しなければなりません。実際、エッジのセンサー向けに必要なコードの開発作業の大部分は、それらのドライバを開発／統合するために行われました。

移植可能なコードの開発

Voyager 4用のファームウェアの開発に当たっては、コードを複数の抽象層に分割しました。それにより、1つの特定のマイクロコントローラに固有な細部を、アプリケーションとドライバのコードから切り離しました。これはよく知られている問題への対処法です。一般的には、アプリケーション層に加えて3つの異なる層にコードが分割されます。3つの層とは、ハードウェア抽象化層（HAL：Hardware Abstraction Layer）、ボード・サポート・パッケージ層（BSP：Board Support Package）、ドライバ層です。このアーキテクチャを図9に示します。

HALは、プログラムが個々のデバイスの細部について把握していなくても、様々なハードウェアと相互に作用できるようにするための統一された手段を提供します。一方のBSPは、ハードウェアに依存するソフトウェアを定義します。そしてドライバ層は、レジスタのマッピングなど、個々のデバイスのより細かい部分を定義します。例えば、Voyager 4は2つのマイクロコントローラを備えています。1つは、BLEによる接続を実現するためのMAX32666（BLEコントローラ）です。もう1つは、畳み込みニューラル・ネットワーク（CNN：Convolutional Neural Network）に対応するアクセラレータを内蔵したMAX78000（AIコントローラ）です。図10に示すように、Voyager 4のHALは、両マイクロコントローラによって使用される最も基本的な通信コマンドであるSPI（Serial Peripheral Interface）とI²Cについて定義しています。例えば、あらゆるデバイスのドライバから発行されたSPIの呼び出しは、まずHALのSPI関数によって処理されます。この関数では、BSPがそのマイクロコントローラに対応する適切なSPIコマンドを使用するための具体的な情報をルックアップします。

HALは、システム内のどのボードにとっても同一のものとして維持されます。一方のBSPは、マイクロコントローラごとに更新されます。BSPは、システムの汎用ビルディング・ブロックも定義します。それにより、アプリケーションの呼び出しが、実際に使用される具体的なデバイスから切り離されます。図10において、BSP内のMain_Adxlブロックは、実際に使用される下層の加速度センサー用の抽象層です。初期化（Initialize）や読み出し（Read）など、どの加速度センサーにも共通するコマンドはBSP層で定義されます。それに対し、get_raw_xyz_dataといった低レベルの関数は、ドライバ層のADXL382のブロックで定義されます。ドライバのコードをMAX32666からMAX78000に移植する場合、加速度センサー用のコードは、その加速度センサーそのものにしか関連しないので、変更の必要はありません。新たなマイクロコントローラと通信できるようにするために更新されるファイルは、BSP層に含まれるものだけです。

この構造は、システムの一部を置換／アップグレードする場合にも明らかなメリットをもたらします。例えば、Voyager 4の開発を進めている最中に、メインで使用する加速度センサーのアップグレードを決断したことがありました。そのときに更新が必要だったコードは、ドライバ層に含まれるものだけでした。そのため、メンテナンス、変更、テストを簡単に実施できました。

データ用のパイプラインとBLEのセントラル

温度やバッテリの情報は、要求されればBLEのセントラルのアプリケーションに提供されます。ただ、Voyager 4の主な役割は状態の監視と振動の検出です。データ・スループットとデータの送信頻度に関する要件は、この振動センサーと一般的な状態監視の設定（1日に1回だけ短時間で測定を行うなど）に関するものになります。ただ、BLEは高いデータ・スループットには対応できません。一方、ADXL382は広帯域幅の3軸加速度センサーであり、高性能のモードでは1軸当たり毎秒1万6000個のサンプル・データを収集します。システムに含まれているコンポーネントを使用すれば、取得したサンプル・データをいくつかの方法によって送信できます。

ライブ・データの送信

Voyager 4では、セントラルから要求されている間は、バッファリングを一切行うことなく利用可能になり次第直ちにデータを送信することができます。この機能はデモ用のモードとして便利なものであり、高性能の加速度センサーで取得したデータをリアルタイムで示すことができます。但し、このモードで動作させるとバッテリの消耗が早くなります。また、送信可能な速度を上回るペースで大量のデータが生成されると、データ・パケットの喪失や破損が発生します。

メモリからのデータの送信

Voyager 4では、もう1つのオプションとしてフラッシュ・メモリにデータを保存できるようになっています。この方法であれば、前の値を上書きすることなく、加速度センサーで取得したデータを安全に記録することができます。保存されたデータはセントラルに対して直接送信されるか、セントラルからのコマンドを受け取った時点で送信されます。この方法はリアルタイム対応ではなく、データは数分前のもの、数日前のものであるかもしれません。パケットに対するBLEのアクノレッジメント・システムを利用すれば、データが一切変更されることなくセントラルに引き渡されることを保証できます。あるいは、失われたデータがあれば再送するという仕組みを設けることも可能です。

上記の方法は、産業分野の一般的な状態監視の環境に対しては非常に実用的なものです。しかし、日々ほとんど変化のない振動のデータを送信することにより、バッテリの寿命の大半が浪費されることになります。

エッジにおける分析の実行

バッテリの消費量を節約するには、エッジで分析を行い、無線リンクを介して必要なデータだけを送信するべきでしょう。当然のことながら、バッテリを節約できるのは、エッジで有意義な知見を生成するために必要な電力が、BLEによってデータを送信するために必要な電力よりもはるかに少ない場合だけです（詳しくはPart 1を参照してください）。

図8を見ると、加速度センサーから2つのマイクロコントローラに直接データを受け渡すパスが存在することがわかります。エッジで分析を行う場合には、AIコントローラによって加速度センサーで取得した振動のデータを直接読み出し、オンボードのAIモデルを使用して分析を実施します。

セントラルのユーザ・インターフェースの設計

BLEのペリフェラルの設計は、Voyager 4のペリフェラルの設計と並行して実施しました。そのため、両者の間のやり取りについては高い柔軟性が得られました。一般に、セントラル・デバイスは、Voyager 4のペリフェラルをスキャンして接続を行い、文字列のコマンドを送信してその戻り値を処理しなければなりません。最初に接続した後、すべてのBLEのコマンドはペリフェラルのカスタム・サービスに直接送信されてパースされます。この例におけるセントラルは、Pythonで記述され、WindowsベースのPC上で稼働するGUI（Graphical User Interface）です。このGUIは、BLEのペリフェラルのライブラリ（BLEak）を使用して、標準的なBLEのコマンドを発行します。BLEakは、Pythonの標準ライブラリであるasyncio上に構築されており、BLEのコマンドを非同期で実行することを可能にします。そして、ユーザ・インターフェースを操作可能な状態に保ち、フリーズすることがないよう維持します。

GUIがペリフェラルに正しく接続されると、Voyager 4が備える単一のカスタム・キャラクタリスティックに対して通知のコマンドが自動的に発行されます（図11）。それにより、このキャラクタリスティックが更新されたら、そのことがセントラルに必ず報告されるようになります。この処理は重要なものです。それにより、その後のコマンドが正常に実行されたかどうかを表すアクノレッジメントまたは応答をVoyager 4から受け取ることになるからです。

データの要求方法

データの要求には、必ず簡単な文字列のコマンドが使用されます。例えば、セントラルはsetphy 2コマンドを発行することにより、2Mの無線機能を使用することをVoyager 4に指示します。BLEの2Mというのは、距離と信頼性をいくらか犠牲にしつつ、より高速なデータ通信を可能にするモードのことです。ペリフェラル・デバイスは、まずそのコマンドをパースし、それが有効であることを確認します。その上で、入力値を2にしてペリフェラル内部のsetphy関数を呼び出します。その結果、使用する無線機能が切り替えられます。この関数がVoyager 4によって正常に実行されると、Return: OKコマンドがセントラル・デバイスに対して発行され、ユーザに対する表示が行われます。

加速度センサーで取得したデータの解釈

GUIのユーザは、データを受信する前にsetadxlcfgコマンドを使用することで、接続されているVoyager 4の加速度センサーを構成することができます。ペリフェラルが開始コマンドを発行すると、ペリフェラルからセントラルに対して加速度センサーで取得したデータの送信が始まります。デフォルトでは、セントラル・デバイスとペリフェラル・デバイスはライブ・データのモードで動作します。このモードはデモを実施する際に便利だからです。

ペリフェラル側では、ユーザが指定したサンプリング・レートで内部のFIFO（First In, First Out）バッファに最新のデータが保存されていきます。FIFOバッファが一杯になると、Voyager 4のカスタムのサービスにフラグが立ち、新しいデータを利用可能であることがペリフェラルに通知されます。その後、データはペリフェラルに送信されてパースされ、3軸（X、Y、Z）の加速度データの配列の形式に整えられます。データは必ずプロットされますが、それらを後で分析するためにcsvファイルとして保存することも可能です（ファイルの種類は、データの保存に関するオプションで選択します）。

AIのアルゴリズムの設計

Voyager 4の開発プロジェクトでは、モータの劣化が始まったことを検出できるようにすることを目標としていました。AIを利用したエッジでの分析では、音、温度、振動といった1つ以上の入力に基づいて、モータの状態のメトリクス／特性評価表を作成します。それによって、人手によるデータの分析を置換または補完することが目標になります。今日の状態監視アプリケーションで群を抜いて多く利用されているのは振動のデータです。

入力

一般に、エッジで稼働するAI対応のプロセッサは、かなりの量の電力を消費する傾向があります。このことは、すべてのワイヤレス状態監視ソリューションに共通するバッテリ寿命の延伸という目標に反します。それに対し、MAX78000であれば消費電力を抑えつつ、AIベースの推論を高速に実行することができます。実際、その全体的な消費電力は、BLEによるデータ送信で消費される電力と比べて少なく抑えられます。但し、エッジで稼働するAI対応のプロセッサを使用する場合には、低消費電力であることだけでなく、ニューラル・ネットワークのサイズがボードの仕様を超えないようにしなければなりません。この点には注意が必要です。そのボードには、512kBのデータ用メモリを備えるCNN用のアクセラレータが実装されます。そして、主に物体の検出、オーディオ処理、時系列のデータ処理といった用途に用いられます。

Voyager 4で使用するのは、加速度を表す時系列のデータです。アルゴリズムのトレーニングを行い、その性能を最大限に高めるために、いくつかの前処理を試行して最も高い精度が得られるものを選択しました。これについては、Part 3で詳しく解説します。

トレーニング

ニューラル・ネットワークのトレーニングを実施してMAX78000に配備するためのプロセスについては、GitHubの「Analog Devices AI」で詳しく説明しています。AIモデルは、最初はPyTorch®やTensorFlow®のような従来型のツールセットを使用し、ホストとなるPC上で作成します。そのモデルのトレーニングに必要なデータは、ターゲットとなるデバイスで保存してPCに転送しなければなりません。入力の一部分は、トレーニング・セットとしてモデルのトレーニングに使用されます。また、入力の他の一部分は検証用のセットとして使用されます。この検証用のセットは、トレーニング中に損失関数（ネットワークの性能の測定基準）がどのように変化するのかを観測するために使われます。

使用するモデルの種類により、必要なデータの種類と量は異なる可能性があります。特定のモータの障害を検出する（特性を評価する）ことを目的とする場合、モデルのトレーニングには、障害がない健全な状態の振動のデータに加えて、様々な障害が生じている場合の振動の概要を表すラベル付きのデータが必要になります。

Voyager 4の開発プロジェクトでは、まずオートエンコーダ・タイプのニューラル・ネットワークを使用しました。オートエンコーダでは、データにラベルが付いていなくてもデータの分類方法を学習することができます。このタイプのモデルは複雑な障害の分類には適していません。ただ、健全な状態のモータのデータなど、顧客が既に保有しているデータだけを使用して短時間でトレーニングを実施できます。

トレーニングに使用するデータの理想的な量は、条件に応じて異なります。ここで言う理想的な量とは、健全な状態にあるモータのデータの一般的な傾向を学習するために必要十分で、オーバーフィッティングが生じない量のことです。Voyager 4に付属するデフォルトのサンプルは、加速度センサーで取得した健全な状態のデータ（わずか30秒間に相当）を使ってトレーニングしたものです。ただ、検証を目的とし、障害（不均衡）が生じている場合の同量のデータも保存してあります。どちらのデータ・セットも、PythonベースのGUIを使用してトレーニングに用いるPCに直接保存しました。

モデルのトレーニングに使用する前に、入力されたデータに対しては前処理が施されます。続いて、トレーニング用のスクリプトを使用することで、複数回にわたり連続的にトレーニングが実行されます。その結果、最も高い性能が得られるモデルが選択されます。テストを実施するためには、障害が生じている状態のある程度の量の入力データも必要になります。健全な状態のデータでモデルのトレーニングを実施した後、障害が生じた状態のサンプル・データでテストを実施しなければ信頼に足る結果は得られません。

アルゴリズムの配備方法

モデルのトレーニングを終えたら、アナログ・デバイセズのオンライン・ツールセットを使用して、モデルの量子化と合成を実行します。量子化では、丸め処理や切り捨て処理によって、生成されたモデルの重みを調整します。そのようにして、よりサイズの小さいビンの集合を生成します。それにより、モデルのデータを格納するために必要なメモリの容量を削減できます。このような手法は、ニューラル・ネットワークをより小さなエッジ・デバイスに配備する場合に標準的に利用されています。一方、合成では、量子化されたモデルをマイクロコントローラが解釈できるC言語ベースのファイルに変換する処理が行われます。

上記のようなプロセスを経た結果、計3つのファイルが生成されます。それらのファイルはマイクロコントローラ用のアクティブ・プロジェクトにコピーします。すると、次に行われるファームウェアのアップデートに伴ってそれらがロードされます。3つのファイルのうち2つ（cnn.hとcnn.c）には、CNNの構成に向けてレジスタにデータを書き込むためのコードや、ロードするモデルに対応する便利な関数が含まれています。3つ目のファイル（weights.h）には、トレーニング（と量子化）済みのモデルの重みが含まれています。

続いて、デバッグ用のポートを介した有線のアップデートまたはOTA（Over the Air）のアップデートにより、新しいファームウェアをロードします。それによりモデルが配備されます。その結果、BLEコントローラはオンデマンドでAIによる推論を行うために、モデルに対してクエリを送れるようになります。

配備後の使用方法

新しいファームウェアが配備されたら、AIコントローラは有限状態マシンとして動作します。SPIを介してBLEコントローラからのコマンドを受け取り、それに対する応答を返します（図15）。

AIコントローラは、推論が要求されたらウェイクアップします。そして、加速度センサーからのデータを要求します。その後、AIコントローラは、時系列のデータを対象としてトレーニングで使用したのと同じ前処理を実行します。この点が重要です。最後に、この前処理の出力が、配備済みのニューラル・ネットワークに供給されます。それにより、ニューラル・ネットワークは分類の結果を報告できるようになります。

AIコントローラはバッテリを節約するために、ウェイクアップした際、自動的に推論を実行するように設計されています。そのため、BLEコントローラは分析が必要なときだけ、AIコントローラを起動すればよいということになります。

一般的な設定では、BLEコントローラは消費電力の少ないスリープ・モードから毎日短時間だけウェイクアップします。そして、加速度センサーから取得したデータに対するAIベースの推論を要求します。ユーザが設定した基準をデータが満たす場合、BLEコントローラはスリープ・モードに戻ります。例えば、「99%の確からしさで健全な状態を表しているという判定結果をモデルが出力している」といった基準を設定することになります。一方、データに異常があると推定される場合や、健全な状態にあると確信を持って判定できない場合には、BLEコントローラは近くのBLEのホストに接続し、それらのデータを共有することができます。以上のように、エッジで分析を実施すれば、健全な状態のデータをホスト・システムに送信する必要がなくなります。結果として、バッテリの寿命を延ばすことが可能になります。

まとめ

Voyager 4は、振動の監視を目的としたワイヤレス・システムです。その特徴は、状態監視ツールとしてのインテリジェンスを備えている点にあります。また、バッテリの寿命を延ばすためにエッジでAIによる分析を行えることも非常に重要な特徴です。状態監視向けの効果的なセンサー・システムを設計するには、いくつもの事柄について検討しなければなりません。本稿では、Voyager 4のハードウェアのシグナル・チェーン、BLEのペリフェラルとしてのVoyager 4の概要、システムの様々な要素を統合するために使用したファームウェアについて詳しく説明しました。また、Voyager 4におけるAIの活用方法についても解説を加えました。更に、エッジ向けのAIモデルの開発と配備について実際の開発プロジェクトで得た知見も示しました。

次回（Part 3）は、モータのいくつかの一般的な障害の分類方法や、Voyager 4に対するAIのアルゴリズムの具体的な実装方法について更に詳しく解説します。

＊英語版技術記事はこちらよりご覧いただけます。

著者について

Tom Sharkey

Tom Sharkeyは、アナログ・デバイセズのシステム・アプリケーション・エンジニアです。産業用エッジ／モーション／ロボティクス部門に所属。状態監視用のセンサー、ファームウェア／ソフトウェア、モータ制御に関する経験を有しています。2020年にリムリック大学で電子工学とコンピュータ工学の学士号を取得しました。