MCUファームウェア外注：受け入れ要件に何を書くか

外注したMCUファームウェアの受け入れ条件は、別の技術者がビルド、書き込み、合意したインターフェースの確認を行い、故障時の動作を説明できることです。デモの成功だけでは、センサー切断、設定保存中の電源断、長時間のネットワーク停止後に何が起きるかは定まりません。

本稿は、ベアメタルとRTOSを含む資源の限られたMCU製品向けの受け入れ構成案です。技術チェックリストであり、特定基板の試験合格を示すものではありません。安全に関わる製品には、別途危険分析、開発プロセス、適用規制の確認が必要です。

1. 価格を確定する前に範囲を確定する

MCUの型番とリビジョン、基板版、クロック、外部メモリー、周辺モジュール、ツールチェーン、SDK、RTOSの版を構成表にします。実際の接続機器とプロトコル文書も列挙します。「RS485対応」は電気インターフェースを示すだけで、通信速度、送受信切替時間、レジスター、再試行、アプリケーション互換性までは定義しません。

必須機能、明示的な対象外、他の関係者が満たす前提を分けます。顧客提供のブートローダーがあれば、イメージ形式、予約メモリー、更新の取り決めを確認します。ハードウェアが変更中なら、受け入れ対象の基板版と、後の端子・部品変更を評価する方法を決めます。

各要件に固定IDと観測可能な結果を付けます。「確実に収集する」では不十分です。入力フレーム、期待する復号値、許容報告遅延、チェックサム異常時の処理、証拠の採取方法まで記載します。

2. 端子からアプリケーションまでのデータ経路を定義する

各インターフェースの物理設定、フレーム形式、タイムアウト、資源の所有者、エラー処理を記録します。計測製品では、同一サンプルについて計器表示、受信バイト、工学値、送信ペイロードを比較できるようにします。単位、倍率、符号、無効値、時刻の取得元も必要です。

生成側が消費側を上回った場合の方針も決めます。キューは新規データを拒否する、最古データを捨てる、タスクを停止させる、故障を通知するなどの動作が可能です。万能な選択肢はありません。方針とカウンターを定め、無通知の欠落と入力がない状態を区別します。

伝送上の到達と実行完了も分けます。応答が「解析済み」「受理済み」「実行済み」のどれかを明確にします。再試行でリレーが二重動作し得るなら、冪等性またはシーケンス番号の規則を合意し、重複コマンドを意図的に試験します。

3. 時間とメモリーの限界を測定可能にする

慣れたtick周期を流用せず、製品要件から時間制限を決めます。入力エッジ、測定点、負荷条件、判定統計を指定します。例えば通信負荷を並行動作させ、ロジックアナライザーで入出力応答を測ります。観測最大値と解析上の上限は区別します。有限回の試験は全実行順序の証明にはなりません。

RTOSでは、所定負荷中のタスク別スタック余裕、割り当て失敗、キュー最大使用量、実行時間を採取します。FreeRTOSにはスタック使用量やオーバーフロー確認機能がありますが、設定と移植実装に依存します。高水位値は実行済み経路の証拠であり、将来の全呼び出し経路の安全性は保証しません。FreeRTOSのスタック確認文書を参照してください。

すべての指標に単位を記載します。APIやプラットフォームにより、スタック深度は要素数またはバイト数です。診断と更新の余裕を確保し、合意したRAM・Flash予算をリリース報告に示します。

4. 正常系だけでなく故障時動作を受け入れる

• 不正入力：途中で切れたフレーム、過大フレーム、チェックサム異常を送信し、処理時間の上限、エラー計数、次の正常フレームでの復帰を確認します。
• 機器不在：安全な治具でセンサーを外すかバスを使用不能にし、タイムアウトと無関係な機能の応答を確認します。
• ネットワーク断：許可された試験ネットワークを止め、再試行間隔、キュー上限、復旧後の破棄・再送方針を確認します。
• 設定更新中断：復旧可能なベンチ機で、許可された設定更新中に電源を切ります。次回は完全な設定または定義済み既定値を選び、部分データを使わないことを確認します。
• 実行停止：試験用ビルドで必須タスクの進行を止め、ウォッチドッグ、リセット原因、安全な出力状態を確認します。
• 不正更新：製品の復旧設計に従い、不正イメージ情報の拒否や更新中断を試験します。破壊的試験の前に検証済み復旧手段を確保します。

台数、反復回数、環境、合否条件は事前合意します。これらはプロジェクト固有の判断であり、普遍的な業界閾値ではありません。故障注入時に管理できない産業負荷を接続しないでください。

5. 引き渡し後にも使える診断機能を求める

故障記録には、症状とビルド識別子、リセット原因、稼働時間、必要最小限の状態を関連付けます。保存期間、取り出し方法、満杯時の動作を定義します。便利だからという理由でパスワード、秘密鍵、顧客ペイロード全体を記録しないでください。

対応プラットフォームではコアダンプが事後解析に役立ちます。ESP-IDFはFlash・UART出力と対応ビルドを使う解析手順を提供しますが、これはESP-IDF固有で、全MCU共通ではありません。Espressifのコアダンプガイドを参照し、受け入れ前に制御された故障で抽出手順を実証します。

6. リリース一式も試験対象にする

ソースと依存関係の版、ビルド手順、設定、リンカースクリプト、パーティション配置、書き込み方法、バイナリー、ハッシュ、デバッグシンボルを要求します。ライセンスと再配布義務も含めます。開発用認証情報と製造設定手順は分離し、秘密を引き渡しアーカイブに埋め込みません。

受領側の技術者が、元開発者のPCに頼らず、記載されたクリーン環境でビルドし、指定機へ書き込めることを確認します。バイト単位の再現性が必要なら、時刻、生成ファイル、ツール入力の制御を定義します。そうでなければ機能再現性を定め、ハッシュが異なり得る理由を記録します。

試験手順、生データ、要件ID別結果、未解決差異を一緒に納品します。既知問題には条件、影響、回避策、担当、処置を記載します。必須動作の未実装を備考に隠す「条件付き合格」では意味がありません。

7. 受け入れ不具合を層別に調べる

生データが正しく復号値が違うなら、ネットワークの前にフレーミング、バイト順、換算を調べます。ログ時だけ遅れるなら、ブロックとバッファー動作を比較します。ウォームリセットだけで戻るなら、周辺状態保持、リセット順序、設定妥当性を調べます。一度に一要因だけ変え、失敗版を残して同じ試験で改善を示します。

実際の範囲にチェックリストを適用する

ObeitaのSTM32データ収集・MQTT統合プロジェクト構成は、計器デコードとEthernet・携帯回線接続を扱います。生フレームと公開値を結ぶ範囲例であり、上記試験完了の証拠ではありません。引き渡しレビューにはファームウェア・BSP診断を参照してください。

基板版、プロトコル例、現行ソース・ビルド一式、許容できない故障結果の短い一覧を準備すると、「完成」を確認可能な受け入れ計画にできます。