1. 継続的なエラー検出と修正

製品の開発段階では入念な計画セッションが行われるものの、稼働中に予期しないエラーが発生することがある。その深刻度にかかわらず、こうしたエラーを発見し修正することは健全なプロセスである。これには、以下に示すいくつかの手順が含まれる。

• 開発・動作中に発生しうるエラーの記録を残しておくこと。
• 実際の設計上の考慮事項から逸脱した、プロセス中のあらゆる変更点を把握しておくこと（部品の変更、アルゴリズムの変更など）。
• 想定されるすべての条件がそろった実際の稼働環境でテスト稼働を行うこと。実行時にエラーを検出できる、（できればリアルタイムの）クロスチェック機構を構築すること。私自身は、エラーを発見するためにMQTTダッシュボード上のリアルタイム読み取り値を監視していた。

最後の手順は、その製品自身の環境における操作性を確保するためのものである。では、上記のいずれかの措置でエラーが発見された場合はどうすればよいだろうか。

• エラー分析ドキュメントの作成を始める。上記で述べたように、開発中に記録したすべての項目をそこにコピーする。
• 仮説をグループ分けしながら絞り込んでいく（ファームウェア関連のエラー、ハードウェア関連のエラー、ソフトウェア関連のエラーなど）。
• 仮説を一つずつ検証し、エラーが解消されるまで結果をドキュメントに追記していく。
• テストの際は、適切なテストベンチを用意し、実際の結果を比較に用いること。

2. 製品のリモート設定

当社の製品の大半は、MQTT／HTTPを介してデータを配信または取得している。センサーや製品から配信されるデータは、関連するソフトウェアがそれを解釈し、ユーザーフレンドリーな形でユーザーに表示できるように構成されている。

では、この挙動を変更する必要が生じた場合はどうすればよいだろうか。開発者やユーザーが、目的により適した形でデバイスを別の方法で設定したいと考えた場合はどうすればよいだろうか。

従来の方法でデバイスを再プログラムすることは、デバイスによってはアクセスが困難な場所（例えば土中や、機械の重要部分など）に設置されている場合があるため、煩雑になりかねない。私たちは、この問題に対処できる実現可能な手法を考案する必要があった。

すでにデータの送受信にGSMベースのモジュールを使用していたため、同じハードウェアを活用できる方法を採用することにした。望ましい方法を実現するため、以下の手順を検討した。

• 開発時に、すべてのデバイスでMQTTのサブスクライブ処理を有効化する。
• 設定を変更する必要のある以下のパラメータを含む文字列を、「Configuration」トピックに配信する。
  – デバイスID ― デバイスの識別に使用する。
  – 配信メッセージの順序。
  – 配信先のトピック。
  – 配信間隔。
  
• ボタンの短押しによる割り込みをトリガーとして、デバイスを設定モードに切り替える。
• デバイスはサブスクライブ処理を開始し、上記のメッセージを受信する。
• 設定は2つの段階で行われる。
  – デバイスIDを照合し、自身のIDと一致する場合にのみ変更を行う。
  – 元のファームウェア内の上記パラメータを変更し、設定モードを終了して通常動作に戻る。
  

上記の方法により、手動操作を必要とせずに、製品の継続的な適応が可能となる。

3. 製品のキャリブレーション（校正）

製品の設置時には、出力や一部のセンサー読み取り値を、その製品が置かれる環境に合わせて微調整する必要がある場合がある。このプロセスは「キャリブレーション（校正）」と呼ばれる。こうした読み取り値のすべてが配信データの中に表示されるとは限らないため、キャリブレーション時にはそれらを取得するための方法が必要となる。このプロセスは、前述のものと非常によく似ている。実現手順は以下の通りである。

• 開発時に、すべてのデバイスでMQTTのサブスクライブ処理を有効化する。
• 以下のパラメータを含む文字列を、「Calibration」トピックに配信する。
  – デバイスID。
  – リッスンするポート。
  – キャリブレーション中の配信間隔。
  
• ボタンの長押しによる割り込みをトリガーとして、デバイスを設定モードに切り替える。
• デバイスはサブスクライブ処理を開始し、上記のメッセージを受信する。
• キャリブレーションについても、前述の手順と同様に行われる。

4. 自動テスト

限られた期間の中でプロジェクトのかなりの部分を開発し終えた後、製造されたPCB（プリント基板）の一部の周辺機器が誤動作するという経験をしたことはないだろうか。これは組込みシステム開発においてよくある問題である。この問題を完全に回避することはほぼ不可能であるが、私たちは、予算に高額な追加費用をかけることなく早期発見を可能にするアイデアをブレインストーミングした。以下のシンプルな手順でこれを実現しようとしている。

• プロジェクトで使用される一般的な周辺機器や技術を特定する（例：Bluetooth／BLE、GSM、3G、LoRa、USBなど）。
• PCBを初めて使用する際に、上記の周辺機器の機能をテストするための一連のテストベンチを構築する。
• 受け取ったバッチの各PCBに対し、上記の中から必要な項目を選んで適用する。
• 不具合があれば、それを検出・記録する。

定期的な電源テストや基本機能テストと組み合わせることで、この方法は通常運用において無駄になっていた多くの時間と労力を節約することができる。

5. エラーロギング

上記のエラー検出手法は開発中には非常に効果的であるが、設置後に発生しうるエラーを特定するには、より高度な技術が必要となる。この種のエラーは、通信上の問題、環境の変化、経年による物理的損傷など、さまざまな原因によって発生しうる。例えば、接続が損なわれている場合、リモートプラットフォームを使ってどのようにエラーを見つければよいのだろうか。

このような場合、製品が稼働中にリセットされたとしても、開発者がエラーにアクセスできるような形で記録しておく必要がある。フラッシュメモリは、この問題に取り組むうえで優れたリソースである。このシナリオでフラッシュメモリが使用されるのは、以下の特性を備えているためである。

• フラッシュメモリはリセット時に消去されない。
• メモリはセクタに分割されているため、メモリ全体を消去することなくセクタ単位で消去でき、継続的な使用が可能である。
• フラッシュメモリは製品にあらかじめ搭載されているため、外部ハードウェアを追加する必要がない。
• フラッシュメモリの読み書き速度は比較的低いものの、このシナリオにおいては十分な性能である。

この問題に対処するため、以下の手順が取られている。

• 製品が稼働中に直面しうる問題を定義し、辞書（インデックス表）としてラベル付けする。
• 稼働中にエラーが発生するたびに、そのエラーに割り当てられたインデックスをフラッシュメモリに書き込むよう、ファームウェアに指示する。
• このような場合、ユーザーや開発者は、USBポートをシステムに接続してフラッシュメモリを読み取ることで、デバイスが誤動作を起こした正確な原因を特定できる。

6. 結論

計画・開発段階で主要機能のみにこだわることは、製品のライフタイムを通じた運用にとって不利益となりかねない。エラードキュメンテーション、リモート設定、キャリブレーション、自動テスト、そしてエラーロギングを取り入れることで、製品の性能を大幅に向上させることができる。上記のすべての手法は、運用時のコストと時間の消費という観点において、非常に効果的である。