フィールド展開されたデバイスでのソフトウェアトレース

ソフトウェアトレースは、特に高度な視覚化と組み合わせると、すべての組み込み開発者のツールボックスで重要なツールになります。ほとんどの組み込みシステムには、同じシーケンスが何度も繰り返される周期的なパターンがたくさんあります。デバッグするときは、異常、つまり、通常とは異なることが起こった通常の周期的な動作からの逸脱を見つけたいことがよくあります。

ただし、ソフトウェアトレース自体は、データ収集の一形態にすぎません。テキストまたは数値のログデータの山で問題を探すことは、干し草の山で針を探すことに似ていますが、適切な視覚化により、検索は視覚的なパターン認識の問題に変換されます。これは、人間の脳が特に十分に備えていることです。 。実行時間、応答時間、タスクの切り替え、タスク間のメッセージパッシングを示すインタラクティブなグラフ–これらすべてにより、開発者はファームウェアの実行における異常をすばやく見つけて、どこを深く掘り下げることができます。

視覚的なトレース診断用のツールは少なくとも10年前から存在しており、ラボでの開発とデバッグに役立つことが証明されています。安全な「モノのインターネット」クラウド接続を追加する組み込みソフトウェア開発者が増えるにつれ、テスト中に見逃されていた現実の問題をキャプチャするために、フィールドに展開されたデバイスでのトレースの使用を検討するのは非常に自然です。結局のところ、ソフトウェアベースのトレースには追加のハードウェアは必要なく、接続されたIoTデバイスは、通常のアプリケーションデータと同じように、診断トレースデータをアップロードできることは明らかです。このようにして、開発者は、実際の運用中に問題を引き起こす残りのソフトウェアの問題にすばやく気づき、原因を理解するための詳細な診断を取得することができます。

このシナリオでは、ソフトウェアトレースは、事故の場合に旅客機で使用されるような仮想の「フライトレコーダー」に匹敵します。これは、常に記録している製品の統合された部分であり、問​​題が発生した場合に重要な情報を提供します。ただし、実際のフライトレコーダーボックスとは異なり、これはソフトウェアソリューションであり、ソフトウェアの問題を対象としています。

この種のIoTデバイス監視のソリューションの1つは、PercepioのDevAlert（図1）です。これは3つの部分で構成されています。ファームウェアモニター、アラートのトレースとアップロードを可能にするためにファームウェアに追加する小さなライブラリ。視覚的なトレース診断のためのTracealyzerツール。アラートの分類と保存、開発者への通知、重複するアラートの除外などを担当するクラウドサービス。

図1。 Percepio DevAlertは、IoT開発者に、クラウドに接続されたデバイスのエラーに関するフィードバックを即座に提供し、デバイスソフトウェアの迅速な継続的改善を可能にします。
（画像をクリックすると拡大します）

初期バージョンはAWSで実行され、AWS IoTコアを使用するRTOSアプリケーションを対象としていますが、ソリューションは他のクラウドプラットフォームに適合させることができます。

ソフトウェアトレースとクラウド接続
開発ラボでのトレースとデプロイされたデバイスのトレースは、2つの異なるものです。今日ラボでビジュアルトレース診断を使用していて、それをフィールドに拡張しようとしている場合は、検討する必要のあることがいくつかあります。

USBやイーサネットなどの直接的な物理接続と比較して、クラウド接続は限られた帯域幅とはるかに長い応答時間の両方を提供します。たとえば、5 KBのデータをアップロードするには、ワイヤレスインターフェイスを介して数十ミリ秒または数百ミリ秒かかる場合があります。ただし、このアプローチでは、トレースは継続的に送信されませんが、アラートが生成された場合にのみ、最新のイベントのごく一部のトレースのみが送信されます。アラートは、正常性チェックの失敗、ハードフォールト、ウォッチドッグリセットなど、アプリケーションコードでエラーが検出された場合など、異常ではあるが重要なことのみを対象としています。

インターネットに接続されたデバイスはすべて安全である必要があります。したがって、新しい攻撃ベクトルを導入しないことが重要です。 DevAlertでは、新しい接続を導入するのではなく、既存のクラウド接続に依存することでこれを解決します。これは、AWSおよびその他の主要なIoT /クラウドプロバイダーのセキュリティを活用し、X.509証明書を使用したデバイス認証やTLSを使用した暗号化通信などのベストプラクティスに従って保護されたクラウド接続用の検証済みSDKを提供します。これにより、DevAlertのアップロードは通常のIoTアプリケーションデータと同じくらい安全になり、セキュリティを強化するために、一方向の通信のみが必要になります。着信メッセージをリッスンすることはありません。

このアプローチでは、アラートは、デバイスで通常使用されるのと同じクラウドアカウントに、同じレベルのセキュリティでアップロードされます。クラウドに入ると、データのごく一部がクラウドサービスに提供されます。これには実際のトレースデータは含まれていません。これは機密情報と見なされる可能性があるため、デバイスのクラウドアカウントに残ります。図2aと2bは、データフローとセキュリティバリアをより詳細に示しています。

図2a。 データフローはデバイスソフトウェアで始まり、開発者はソースコードにアラートを追加します。デバイスクラウドアカウントにアップロードされるすべてのアラートには、アラートに先行する最新のイベントを含む短いトレースが含まれます。最後に、メタデータ署名がDevAlertクラウドサービスに転送されます。 （画像をクリックすると拡大します）

図2b。 クラウドサービスは、着信アラートを顧客のデバイスフリート全体からの以前のアラートと比較し、新しい問題について開発者に通知します。重複するアラートはカウントおよび保存されますが、通知は送信されません。このように、同じアラートが複数のデバイスでトリガーされた場合でも、開発者の受信トレイがフラッディングすることはありません。 （画像をクリックすると拡大します）

当然のことながらボリュームにもよりますが、クラウドアカウントへのアラートを受信するための運用コストは通常​​は低くなります。まず、問題が検出されない限り、アラートは送信されません。一般に、クラウドプロバイダーは、不定期のアラートメッセージの送信と保存に対してもほとんど課金しません。ほとんどのIoTアプリケーションは、より多くのデータを生成します。これは、IoT /クラウドサービスの価格設定に反映されます。たとえば、100万のMQTTメッセージをAWSIoTコアに送信するには1米ドルかかります。

アラート処理のほとんどは、Percepioによってホストされるフルマネージドサービスであるクラウドサービスで実行されます。初期処理のみがデバイス開発者のクラウドアカウントで実行されるため、クラウドコストが低く抑えられ、統合が簡素化されます。

報告されたエラーを修正するために無線アップデートを送信すると、より多くのデータをすべてのデバイスに転送する必要があるため、コストが少し高くなる可能性があります。 AWSは、600,000台のデバイスのフリートを更新するコストが1,275米ドルである価格設定の例を提供しています。ただし、これは、バグを修正しないままにするコストに比べればそれほど高くありません。顧客エクスペリエンスの低下、製品レビューの評価の低下、売上の低下、さらには事故や法的措置です。

組み込み開発のためのDevOps
ソフトウェアの問題が発生した場合にIoTデバイスを「電話をかける」ことができるようにすることには大きなメリットがあります。エラーの直接認識と詳細な診断により、開発者とデプロイされたコードの間にフィードバックループが作成され、開発者はバグをより迅速に修正し、更新されたファームウェアをより迅速にプッシュできます。図3を参照してください。このいわゆるDevOps哲学は、モバイル開発の標準であり続けています。とクラウドアプリケーション、そして安全なクラウドベースのIoTプラットフォームの導入により、組み込み開発もこのように機能することが可能になりました。

図3。 TracealyzerのDevAlertダッシュボードには、最近報告されたアラートとトレースが一覧表示されます。
（画像をクリックすると拡大します）

ビジネスの観点からは、このDevOpsスタイルの監視は、本番コードのバグの影響を受けるエンドユーザーが少なくなるため、不満を持つ顧客が少なくなります。ほとんどの組み込みソフトウェアには、すべての検証作業にもかかわらず、リリース時に見逃されたバグがいくつか含まれていますが、通常、すべての人に直接表示されるわけではありません。早い段階で問題を知っていれば、多くの顧客が影響を受ける前に問題を修正する時間がしばしばあります。理想的には、開発者は最初のアラートから数秒以内に通知を受ける必要があり、提供されるトレース診断により、迅速な分析と修正が可能になります。その後、開発者は問題を修正するために自動無線更新を送信できます。即時認識とトレース診断により、修理にかかる時間が大幅に短縮され、影響を受ける顧客の数が最小限に抑えられる可能性があります。

デバイスの信頼性が向上すると、責任のリスクが軽減され、カスタマーサポート、返品、デバッグのコストも削減されます。提供される診断により、開発者はデバイスから直接情報を取得し、状況を説明するためにユーザーに依存する必要がないため、顧客の問題を再現するのがはるかに簡単になります。自動フィードバックがない場合は、エンドユーザーが問題を報告し、十分に詳細な情報を提供することに依存します。 「システムが応答を停止する」などの漠然としたエラーレポートはあまり役に立ちません。考えられる原因を見つけるのに数週間かかる場合があります。それでも、それはあなたの最善の推測です。正しい問題を解決したかどうかは本当にわかりません。

バグだけではありません
注意すべき点の1つは、アラートは、見逃されたバグとその結果生じるエラーに関するものである必要はないということです。開発者はアラートを生成する場所と理由を自由に決定できるため、アプリケーションの主要なパフォーマンスメトリックを監視し、パフォーマンスの問題が発生する理由を確認するためにも使用できます。

ユーザーインターフェイスを監視することで、興味深い情報を明らかにすることもできます。ユーザーがタッチスクリーンでメニューを開く状況があるとします。例：車のインフォテインメントシステムで、次にどこに進むかを躊躇します。このような問題をキャッチするために、アプリケーション開発者は、各入力イベントの後にタイマーを開始し、たとえば5秒以内に入力が受信されない場合にアラートを生成できます。その後、ユーザーインターフェースの同じ部分について多くのアラートが受信された場合、これは組織がより良い製品を構築するのに役立つ重要なフィードバックになる可能性があります。

全体として、デプロイされたデバイスでソフトウェアトレースとクラウドベースのアラートを活用することには大きなメリットがあり、複雑ではありません。ただし、DevOpsスタイルのワークフローを完全に採用するには、無線アップデートの機能と、ソフトウェアテストの制限と、リリース後も継続的な改善の重要性を理解している応答性の高い開発組織が必要です。