Embedded Systems Specialist Examination cheat sheet
Embedded Systems Specialist Examination · Keep the key ideas within reach.
組込みシステムの事業戦略・製品戦略の策定
ローンチ判断は「市場投入時期」「開発コスト」「品質リスク」の3軸で評価する。品質基準を満たさない段階での前倒し出荷は、リコール費用とブランド棄損を将来費用として計上して比較する。
製品ロードマップは顧客価値の変化点(規制改定、通信規格の世代交代、主要部品のEOL)を起点に区切る。部品EOL通知は通常6〜12か月前が多く、代替品の再設計期間を見込んで後継機の計画を前倒しする。
プラットフォーム戦略では、共通コア(RTOS、ドライバ、通信ミドルウェア)と差分(センサ、筐体、アプリ)を分離し、機種展開ごとの再開発コストを共通資産の償却で回収する。
差別化要因は「機能」だけでなく「検証済みの信頼性」「長期供給保証年数」「認証取得済み」で定義できる。産業用途では供給継続年数が受注条件になることが多い。
投資判断にはNPV(正味現在価値)と回収期間を用いる。組込み製品は量産立ち上げ費用と認証費用が初期に集中するため、キャッシュフロー計画を開発費・治具費・認証費に分けて評価する。
競合分析はBOMコストと開発工数の両面で行う。部品点数削減、SoC統合、既存プラットフォーム流用の3点が原価低減の主要レバーとなる。
規制・標準(無線認証、機能安全、医療規制、サイバーセキュリティ要件)への適合は事業リスク項目として戦略段階で洗い出す。適合コストと取得期間を見積もらずに仕様を確定しない。
製品ポートフォリオは「利益率」「成長性」「技術共通性」で分類し、共通プラットフォームに乗る機種を優先的に拡張する。
ハードウェアとソフトウェアの要求仕様の策定
要求は「機能要求」「非機能要求(性能、消費電力、信頼性、安全性、セキュリティ)」「制約条件(コスト、サイズ、納期、既存資産)」に分類して管理する。
性能要求は測定条件付きで書く。例:応答時間は「入力検出から出力更新まで、常温・最大負荷時に50ms以内」のように条件・指標・閾値を明記する。
リアルタイム要求は平均値ではなく最悪応答時間(WCET)と周期・ジッタで規定する。周期TのタスクでCPU使用率U=Σ(Ci/Ti)を計算し、設計余裕を定量的に示す。
消費電力要求は動作モード別に定義する(アクティブ、スリープ、ディープスリープ)。平均電流×時間で電池寿命を算出し、要求値と照合する。
トレーサビリティを確保する。要求ID→設計要素→テストケース→結果の対応表を作り、変更時に影響範囲を追跡できるようにする。
要求の検証可能性を確認する。「使いやすい」「高速に」など測定不能な表現は、測定方法と閾値に置き換える。
ハードとソフトの境界要求(インタフェース電圧、タイミング、割込み極性、初期化順序)は双方の仕様書に重複して記載し、食い違いを防ぐ。
安全要求は機能安全の安全度水準やサイバーセキュリティ要件を上位から導出し、診断機能・フェイルセーフ動作として具体化する。
システムアーキテクチャ設計と機能分担
機能分担の判断基準は「リアルタイム性」「更新頻度」「変更のしやすさ」「コスト」である。ハードで実現すると高速・低消費電力、ソフトで実現すると柔軟・変更容易になる。
HW/SW協調設計では、処理量・メモリ帯域・消費電力を指標に、CPU、DSP、FPGA、専用アクセラレータ、ASICへの割当てを比較評価する。
アーキテクチャパターンは階層化(HAL/ドライバ/ミドルウェア/アプリ)を基本とし、上位層が下位層の実装詳細に依存しないようにする。
リアルタイム設計では優先度ベースのスケジューリングを採用し、優先度逆転を防ぐために優先度継承や優先度上限プロトコルを適用する。
通信アーキテクチャはCAN、LIN、Ethernet、SPI、I2Cなどの帯域・遅延・ノイズ耐性・コストを比較して選定し、ゲートウェイでのプロトコル変換方針を定める。
安全設計ではフェイルセーフ(安全側に停止)とフェイルオペレーショナル(機能継続)を機能ごとに決め、ウォッチドッグやデュアルチャネル比較などの診断機構を配置する。
セキュリティは信頼境界を図示し、セキュアブート、暗号鍵の保管場所、デバッグポートの無効化をアーキテクチャ段階で決定する。
ソフトウェア再利用のため、ハード依存部を抽象化インタフェースの背後に隠蔽し、機種差分を設定データと差し替えドライバに限定する。
組込みシステムの設計・構築・製造・テスト
テスト階層は単体テスト→結合テスト→システムテスト→受入テストの順に積み上げ、各層で要求IDとの対応を確認する。
カバレッジ指標は命令カバレッジ、分岐カバレッジ、MC/DCを使い分ける。高い安全度水準が要求されるソフトウェアではMC/DCが求められることがある。
静的解析とコードレビューを継続的インテグレーションに組み込み、コンパイラ警告をエラー扱いにして回帰を防ぐ。
ハードウェアの検証は電源投入シーケンス、クロック、リセット、信号品質(アイダイアグラム、オシロスコープ波形)を段階的に確認する。
量産工程では治具検査(ICT)、機能試験(FCT)、書き込み・校正・キャリブレーションを工程に組み込み、検査データをシリアル番号で追跡する。
出荷試験の合否基準は統計的に設定する。測定値のばらつき(標準偏差)から工程能力指数Cpkを算出し、1.33以上を目安に工程を安定させる。
環境試験(温度、湿度、振動、EMC)は製品仕様と規格に基づき試験条件を決め、試験前後の機能確認を記録する。
不具合は再現手順、発生頻度、環境条件を記録して管理し、修正後は回帰テストを必ず実施する。
開発環境の整備・改善
バージョン管理はソース、ビルドスクリプト、設定ファイル、ツールチェーン定義を同一リポジトリで管理し、再現可能なビルドを実現する。
CIではクロスコンパイラのバージョンを固定し、ビルド、静的解析、単体テスト、バイナリサイズ検査を自動実行する。
実機テストは自動化が難しいため、HIL(Hardware-in-the-Loop)やエミュレータを併用し、夜間バッチで回帰テストを回す。
デバッグ環境はJTAG/SWDによるオンチップデバッグ、トレース機能、ログ出力(UART、SWO、リングバッファ)を組み合わせる。
コード品質指標として静的解析の指摘件数、循環的複雑度、重複率を継続的に計測し、閾値超過でマージを止める。
ツールチェーンの更新は検証済みバージョンを固定し、更新時は差分検証(生成コード、最適化、サイズ、タイミング)を実施する。
開発環境の標準化により、新規参入者の立ち上げ時間短縮と、属人的な手順の排除を狙う。手順書は自動化スクリプトで代替する。