Embedded Systems Specialist Examination study guide
Embedded Systems Specialist Examination · Work through your exam, one topic at a time.
エンベデッドシステムスペシャリスト試験（略号ES、英語名称Embedded Systems Specialist Examination）は、IPAが実施する情報処理技術者試験の高度試験の一つです。スマート家電や自動運転など、あらゆるモノがつながるIoTが進展する中で、ハードウェアとソフトウェアを適切に組み合わせたシステムの企画・開発を推進し、必要な機能・性能・品質・セキュリティなどを確保する組込み・IoT系のフルスタックエンジニアを目指す方に最適とされています。対象者像は、高度IT人材として確立した専門分野をもち、IoTを含む組込みシステムの開発に関係する広い知識や技能を活用して、市場動向・関連業界の動向を踏まえた事業戦略や製品戦略の策定、ハードウェアとソフトウェアの要求仕様の策定、要求仕様に基づいた設計・構築・製造を主導的に行う者です。業務面では、ライフサイクルの統括、機能要件・技術的要件・環境条件・品質要件の調査分析と機能仕様の決定、機能分担の検討とシステムアーキテクチャ設計、汎用モジュールやプラットフォーム利用・資産再利用の方針策定、リアルタイム性を考慮したハードウェアとソフトウェアのトレードオフに基づく設計書・仕様書の作成、ソフトウェア開発モデルの選択と各工程の主導、技術動向の分析と外部専門家の知識の活用、開発環境の整備・改善が求められます。期待する技術水準には、リアルタイムOSに関する深い知識と汎用的なモジュールに対する知識、品質要件の吟味、プラットフォーム利用や既存製品の再利用可能性を踏まえた設計、開発環境の構築と改善が挙げられています。2026年度はCBT方式により後期に実施されます。現行試験制度は2026年度の試験実施をもって終了し、2027年度から新試験制度に移行する予定です。準備では、試験要綱・シラバスと過去問題を参照し、組込みシステム特有のリアルタイム性、ハードウェアとソフトウェアの機能分担、品質・セキュリティ要件を軸に、事業戦略から開発環境整備までの各段階を一貫して説明できる力を養うことが有効です。. Topics on this exam: 組込みシステムの事業戦略・製品戦略の策定, ハードウェアとソフトウェアの要求仕様の策定, システムアーキテクチャ設計と機能分担, 組込みシステムの設計・構築・製造・テスト, and 開発環境の整備・改善. The Embedded Systems Specialist Examination study guide has 5 sections and about 147 words.
01組込みシステムの事業戦略・製品戦略の策定
このドメインは「作れるか」ではなく「事業として成立するか」を問う。市場と顧客要求から製品コンセプトを定義し、製品ラインとプラットフォームへの投資判断、原価・価格・数量の整合、長期供給や規制対応までを筋道立てて説明できるかが試される。 評価対象はライフサイクル全体のコスト：開発費、BOM、製造・検査、保守、部品の長期調達、廃止対応。 年間便益＝出荷台数×1台あたりの改善額。回収期間＝投資額÷年間便益。回収期間が製品ライフを超える投資は、戦略上の理由がなければ成立しない。 差別化に効く機能と、あって当然の機能を分ける。後者に過剰投資すると原価だけが上がる。 規制・認証（機能安全、無線、EMC）は発売時期とコストの制約条件として計画に織り込む。 共通コア＋派生機種の構成は、BOM低減・開発工数削減・品質の均一化をもたらす。一方で全機種が共通コアの性能に縛られ、上位機種で過剰スペックや差別化不足を招く。共通化の範囲は「どの機能を共通化し、どこを可変にするか」を機能単位で決め、可変部のインターフェースを先に固定する。 Worked example ：年間1万台の産業用コントローラで、基板を共通化すれば1台あたりBOMが500円下がるが、共通化に3,000万円かかる。年間便益は10,000台×500円＝500万円、回収期間は3,000万円÷500万円＝6年。製品ライフが5年なら、この1機種だけでは回収できない。共通化の対象を2機種に広げて合計2万5千台にする（回収1.2年）か、削減額を800円に引き上げる（回収3.75年）か。数字で示せなければ投資は承認されない、という判断の型を覚える。 技術的な新規性だけで計画を立て、市場規模・販売価格・競合を確認しない。 10年供給を約束する製品で、部品のEOL（生産終了）と代替品評価を計画に入れていない。 PoCの成功を量産成立と同一視する。歩留まり、認証取得、製造設備、検査時間は別の課題。 上位機種まで同じスペックで設計し、原価と消費電力を無駄に上げる。.
30 words, under 1 min02ハードウェアとソフトウェアの要求仕様の策定
要求仕様は後工程のすべての判断基準になる。このドメインでは、機能要求と非機能要求を漏れなく、検証可能な形で書き切れるか、ハードとソフトのどちらで実現するかの判断材料を揃えられるかが問われる。 「すぐに反応する」「十分な精度」は要求ではない。「押下から100ms以内にLEDが点灯する（99.9%の確率で）」のように、測定条件・値・許容差まで書く。 非機能要求を必ず項目として立てる：応答時間とジッタ、スループット、消費電力、動作温度範囲、EMC、振動・衝撃、MTBF、起動時間、ファーム更新時間。 各要求に識別子を振り、設計・テストケースとのトレーサビリティを確保する。根拠（誰がなぜ求めたか）も残す。 要求と設計を分けて書く。「RTOSを使う」は要求ではなく解決手段であり、設計側の記述である。 処理量、リアルタイム制約、コスト、消費電力、柔軟性、将来の変更頻度を並べて比較する。ソフトは変更に強く、専用回路やFPGAは性能と電力効率に強い。迷ったら「最悪条件での処理時間」と「変更可能性」で決める。 Worked example ：「モータ電流を監視し、過電流なら5ms以内にPWMを遮断する」という要求を考える。ソフトで実現するなら、ADC割り込みから遮断までの最悪応答時間を、割り込み禁止区間、RTOSのディスパッチ、より高優先タスクの実行時間を含めて積み上げる。見積りが5msに迫る、または超えるなら、コンパレータ＋ハード遮断回路へ移す。要求が「機能」ではなく「最悪応答時間」で書かれているから、この判断がそのまま根拠になる。 非機能要求を落とし、設計段階で性能不足が発覚する。 「最大」「標準」「通常」を定義せずに使い、テストで解釈が割れる。 顧客の暗黙の前提（既存機との互換、設置環境、電源品質）を確認しない。 要求の根拠を残さず、変更時に影響範囲が追えなくなる。. 非機能要求（時間、電力、温度、EMC、信頼性）を必ず項目化する. 要求IDによるトレーサビリティと根拠の記録.
30 words, under 1 min03システムアーキテクチャ設計と機能分担
アーキテクチャ設計は、要求を満たす構造を決め、機能をハード・ソフト・OS・通信のどこに配分するかの判断である。このドメインでは、性能・リアルタイム性・コスト・変更耐性のトレードオフを、根拠のある数字で説明できるかが問われる。 時間制約の厳しい処理、繰り返しの多い処理は、専用ハード（FPGA、DSP、アクセラレータ）やペリフェラルへ寄せる。 変更が多い処理、UI、通信プロトコルの上位層はソフトへ。 共有資源（バス、メモリ、DMA）の競合を設計時に洗い出す。平均性能ではなく最悪値を積み上げる。 インターフェース（信号線、プロトコル、タイミング、エラー時の振る舞い）を先に固定する。曖昧なままだと結合テストで作り直しになる。 電源投入・リセット・異常系の状態遷移をアーキテクチャとして定義する。 Worked example ：1280×720の画像に3×3の畳み込み（9回の積和）を30fpsでかけたい。1フレーム約92万画素×9＝約830万MAC、毎秒30フレームで約2.5億MAC/秒。1GHzのCPUで1サイクル1MACでも、実効効率20%なら5億MAC/秒が上限で、他の処理を考えれば余裕はない。そこで畳み込みをFPGAにオフロードし、CPUはフレーム転送と結果判定だけを担う。判断の根拠は「必要演算量」と「実効性能」の比較であり、実機ベンチマークを待たず見積りで先に決めている点が要点。 平均処理時間で設計し、最悪実行時間（WCET）を確認しない。 割り込み優先度と共有データの排他を決めず、間欠的な不具合の温床を作る。 機能配分だけ決めて、異常時の縮退動作やフェイルセーフを定義しない。 冗長化を後付けし、コストと基板面積が破綻する。. 性能は平均値ではなく最悪値（WCET）で積み上げる.
30 words, under 1 min04組込みシステムの設計・構築・製造・テスト
このドメインは、設計から量産出荷までの工程をつなぎ、品質を作り込めるかを問う。詳細設計、コーディング規約、テスト設計、量産検査、トレーサビリティが個別の作業ではなく一連の流れとして説明できる必要がある。 コーディング規約（MISRA Cなど）と静的解析を設計段階で回す。言語仕様の未定義動作は、実機で再現しない不具合の代表例。 テストは単体→結合→システム→受入の順に、要求IDと対応づけて設計する。分岐網羅（C1）だけでなく、安全領域ではMC/DCが求められることがある。 タイミング依存の不具合は実機でしか出ないことが多い。HILで故障注入や境界条件を作り込む。 量産では「設計したものが正しく作られているか」を短時間で確認する。書き込み、キャリブレーション、ファンクショナルテスト、出荷検査の順に工程を組み、テスト時間がタクトと設備台数を決める。製造番号とファーム版の紐付けは、市場不具合の追跡に必須である。 Worked example ：月産2万台、1台あたりの出荷テストが120秒、設備1台、稼働率80%とする。稼働時間を20日×8時間＝160時間＝576,000秒、×0.8＝460,800秒、÷120秒≒3,840台。2万台には全く足りない。テストを60秒に半減しても7,680台。設備を3台に増やすか、テスト項目を機能保証に必要な最小限に絞り、設計段階でテスト容易性（テスト用ファーム、自己診断）を組み込む必要がある。工程能力は設計の結果である、という視点が問われる。 テストを設計の後始末と捉え、テスト容易性を設計に組み込まない。 版管理が不完全で、書き込んだファームと検査仕様が一致しない。 カバレッジ数値だけを追い、未達理由を分析しない。 量産での初期不良や経時変化（温度、はんだ、部品ばらつき）を検証計画に入れない。. テストは要求IDと対応づけ、段階ごとに設計する. タイミング依存不具合はHILの故障注入で摘出する.
29 words, under 1 min05開発環境の整備・改善
このドメインは、チームが同じ品質で素早く作れる状態をどう作るかを問う。クロス開発ツール、デバッグ環境、CI、版管理、自動テストを組み合わせ、手戻りと待ち時間を減らす施策を、効果の数字とともに説明できるかが焦点となる。 ツールチェーン：クロスコンパイラ、リンカ、デバッガ（JTAG/ICE）、トレーサ。バージョンを固定し、誰がビルドしても同じバイナリになる再現性を確保する。 版管理とビルド：ソース、設定、ツール設定、テストスクリプトを同一リポジトリで管理。コミットごとに自動ビルドと静的解析を回す。 実機依存のテストはHILラックとシミュレータを併用し、実機待ちの渋滞をなくす。 ライセンス管理と教育。ツールは人数分のライセンスと習熟がなければ定着しない。 Worked example ：手元ビルドが30分、1日3回で1人あたり1.5時間。10人なら1日15時間がビルド待ちに消える。ビルドサーバ＋キャッシュ＋並列化で5分に短縮すると待ちは1日2.5時間、削減は12.5時間/日。さらに静的解析をコミット時に自動化すれば、レビューで見つかっていた不具合が実装直後に検出され、修正コストが下がる。改善は「待ち時間」と「不具合の検出段階」の2つの指標で測る。 ツールのバージョン固定をせず、環境差による「自分の環境では動く」を生む。 自動テストが不安定（フレーキー）で、赤信号が無視されるようになる。 効果を測らずにツールを導入し、定着しない。 署名鍵、外部ライブラリ、OSSライセンスの管理を環境設計に含めない。. ソース・設定・テストを同一リポジトリで管理しCIを回す. 実機待ちはHILとシミュレータの併用で解消する.
28 words, under 1 minMore study resources for Embedded Systems Specialist Examination
- Exam-day guideBring the exact ID type and name spelling used on your registration.