運用対応アプリケーションの開発に関する推奨事項

重要

これは Azure Sphere (レガシ) のドキュメントです。 Azure Sphere (レガシ) は 2027 年 9 月 27 日に 再提供されておりユーザーは現時点で Azure Sphere (統合) に移行する必要があります。 TOC の上にある Version セレクターを使用して、Azure Sphere (統合) のドキュメントを表示します。

Azure Sphere デバイス用のアプリケーションを開発する際に、アプリケーションが運用環境に対応していることを確認することを検討する必要があります。 このトピックには、アプリケーションがパイロットデプロイまたは運用デプロイの準備ができているかどうかを確認するためのベスト プラクティスのチェックリストが含まれています。 これらの項目が完了したことを確認すると、運用環境で発生する問題の数を減らし、発生した問題を簡単に診断できます。

Azure Sphere アプリケーションを開発するときは、 High-Level (HL)、 Real-Time (RT) コア、またはその両方のハイブリッドで実行するかどうかを決定します。 高度なアプリケーションは Azure Sphere OS 上でコンテナー化されて実行され、リアルタイム対応アプリケーション (RTApps) はベア メタルまたはリアルタイム コア上のリアルタイム オペレーティング システム (RTOS) で実行されます。

ここで示す推奨事項は、運用環境に対応したアプリケーションで品質と生産性を向上させることを目的としています。 次のチェックリストでは、両方のアプリケーションの種類に関する設計提案の簡潔な一覧と、各ポイントについて詳しく説明するトピックへのリンクを含む、推奨されるコーディングの基礎とソリューション設計に関する考慮事項を示します。 これらの提案は、現場分析、コード レビュー、実際のソリューションやデバイス設計での運用環境にデプロイされたアプリケーションの操作のサポートなど、お客様とのパートナーシップから派生しています。

コーディングの基礎

• 一般的な問題

  • 運用環境に対応したアプリケーションでベータ ツールセットが使用されないようにします。
  • API セットを対象とする場合は、最新の CMake ツールと Azure Sphere ツールを使用します。
  • 完全なコードの最適化とサイズを確保するには、アプリケーションを運用環境にデプロイする前に、リリース モードで最終的なイメージ パッケージをコンパイルすることを検討してください。 リリース パッケージをデプロイする前に、必ずリリース パッケージをビルドしてテストしてください。
  • 完全なビルドを実行するときに警告ゼロ ポリシーを使用して、コンパイラの警告が意図的に対処されるようにします。
  • 一貫性のある CI/CD パイプラインを設定し、適切な分岐戦略を使用します。

• メモリ関連の問題

  • 可能であれば、ハード コーディングではなく、すべての一般的な固定文字列を global const char* として定義して、データ ポインターとして使用できるようにします。
  • グローバル データ構造が比較的小さい場合は、動的に割り当てられたメモリにポインターを使用するのではなく、配列メンバーに固定長を指定することを検討してください。
  • 可能な限り動的なメモリ割り当てを避けてください。
  • メモリ バッファーへのポインターを返す関数の場合は、参照されるバッファー ポインターとその関連するサイズを呼び出し元に返す関数への変換を検討してください。

• 動的コンテナーとバッファー

  • リストやベクターなどのコンテナーに対して増分割り当てアプローチを使用することを検討してください。

高レベルのコア アプリケーション設計の提案

• 一般的な基礎

  • 終了時またはエラー時にすべてのハンドラーを適切に初期化して破棄します。
  • 常に終了コードを使用します。
  • アプリケーションが回復不能な状態にあり、再起動が必要であることを検出した場合は、デッドロック状態を危険にさらすのではなく、常に "クリーン" なアプリケーション出口として処理されるようにします。
  • エラー処理とログ記録を実装します。 詳細については、「 エラーの処理とログ記録」を参照してください。
  • システム タイマーをウォッチドッグとして使用して、アプリケーションが回復不能な状態かストールしているか (デッドロック、メモリ不足、接続が実装されたロジックを回復していないなど) かどうかを検出し、適切な回復に影響を与えます。 詳細については、「 システム タイマーをウォッチドッグとして使用するを参照してください。

• コンカレンシーの処理

  • 可能な限り EventLoop を使用してください。
  • 同時実行タスクの効率を探します。
  • スレッドとスコープを特定のタスクのみに使用するタイミングを評価します。 スレッドを使用するタイミングの詳細については、「 同時実行制御」を参照してください。

• 接続の監視

  • インターネット接続の状態を定期的にチェックする堅牢なステート マシンに基づいて、適切な接続正常性チェック タスクを実装します。
  • 電源管理が必要なソリューションの場合は、データ送信後に Azure Sphere チップの電源を切り、合計アップタイムを追跡し、シャットダウン タイマーを設定します。
  • cURL は最近、コールバックの動作を更新し、最適な実践を行いました。 Azure Sphere では、古いバージョンの cURL 動作が引き続き期待どおりに動作するように努力してきましたが、再帰コールバックを使用すると予期しないクラッシュ、接続の停止、潜在的なセキュリティ脆弱性が発生する可能性があるため、curl_multiを使用する場合は、セキュリティと信頼性に関する最新のガイダンスに従うことをお勧めします。 TimerCallback が 0 ミリ秒のタイムアウトで起動した場合は、再帰コールバックを回避するために 1 ミリ秒のタイムアウトとして扱います。 また、curl_multi_add_handleの呼び出しの後に少なくとも 1 回は明示的にcurl_multi_socket_actionを呼び出してください。

• メモリの管理と使用状況

  • Azure Sphere OS API を使用してアプリケーション のメモリ使用量を追跡し、アプリケーションが予期しないメモリ使用量に適切に対応するようにします。

リアルタイムのコア アプリケーション設計の提案

• MT3620 ウォッチドッグ タイマーを有効にしてデッドロックを検出し、適切な復旧ロジックを実装します。
• ハイブリッド HL コア アプリケーションと RT コア アプリケーションのコア間通信を実装します。

ソリューション設計に関する考慮事項

• 接続の要件とトラブルシューティング

  • すべてのネットワーク前提条件が満たされていることを確認します。 詳細については、「 接続要件とトラブルシューティングを参照してください。
  • OSNetworkRequirementCheck-HLAppとOSNetworkRequirementChecker-PCを使用して、接続の問題のトラブルシューティングを行います。

推奨コンテンツ

IoT ソリューションを運用環境に移行する際に考慮すべきその他の項目については、「 IoT ソリューションをテストから運用環境に移動する」を参照してください。