Embedded Systems Specialist Examination case studies
Embedded Systems Specialist Examination · Put your knowledge to work in context.
エンベデッドシステムスペシャリスト試験（略号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 case studies are 5 cases and about 443 words.
1機種横断プラットフォーム化の投資判断と適用範囲の決め方
産業用ポンプ向けインバータ制御基盤を手がける中堅メーカー（開発者15名、年商80億円）では、12機種の制御ソフトを機種ごとに個別開発してきた。年間出荷は合計8万台、1機種あたりの平均製品寿命は5年である。次期ファミリでは、RTOSと共通ミドルウェアによるプラットフォーム化案（NRE 1億2,000万円、開発工数30%削減見込み）が提案されている。一方、最上位2機種は表示器とネットワーク監視のためLinux SoCが必要で、下位10機種はCortex-M7クラスで足りる。上位2機種は台数では全体の15%だが、売上では40%を占める。現行では市場不具合の横展開に平均3か月を要し、同一原因の不具合が別機種で年2〜3件再発している。顧客の1社は年1回の機能追加要求を出しており、その都度10機種分の回帰テストを手作業で実施している（1機種あたり2人週）。経営層は「工数削減効果だけでは投資判断できない」と難色を示し、さらに遠隔ファームウェア更新（セキュアブート必須）と機能安全規格への準拠が求められている。競合A社は共通プラットフォームを3年前に導入し、機種展開を年2機種から年5機種に増やした実績がある。開発部長は、プラットフォームの適用範囲と、共通化で失う機種別最適化の評価方法で悩んでいる。. プラットフォーム化のGo/No-Goを判断するために、どの定量指標を揃えるべきか。工数削減率以外の指標を3つ以上挙げ、算出方法と判断の目安を示せ。. 上位2機種（Linux SoC）と下位10機種（MCU）を単一アーキテクチャに統一する案と、2階層に分けて共通ミドルウェアで束ねる案を比較し、適用範囲の決め方を論じよ。. 揃えるべき指標 指標 算出方法 判断の目安 --- --- --- 5年TCO (機種別の開発・保守工数 + 不具合横展開工数 + 回帰テスト工数) × 単価 と、(NRE + 共通部分の保守工数) の比較 投資回収3年以内 不具合横展開コスト 1件あたり工数（調査＋修正＋全機種回帰）× 年間再発件数（現状2〜3件） 共通化で横展開が1回で済む前提の効果を金額化 回帰テスト工数 現行1機種2人週×10機種/年 = 20人週 → 自動化前提で何割減るか CI投資とセットで評価する 機能追加リードタイム 受注からリリースまでの日数、機会損失額への換算 競合A社の機種展開ペースに対する劣位の解消 セキュリティ対応工数 脆弱性1件あたりの全機種対応工数が、共通化で1回になる効果 遠隔更新・セキュアブート要件では必須 削減率だけでは足りない理由 : 分母が新規開発に偏り、横展開・回帰・セキュリティ・部品共通化による調達スケールメリットが含まれない。さらに、機種別最適化を失うことによる下位機種のメモリ増・部品コスト増が分子に出てこない。したがって「工数削減率」ではなく「5年間のキャッシュフロー差」に換算して判断する。削減率30%という数字は、母数の取り方で同じ提案が黒字にも赤字にもなるため、意思決定の土台にならない。. 比較 単一アーキテクチャ（全機種Linux SoC）: 共通化率は最大になるが、下位10機種でBOM増（SoC、DDR、PMIC、基板層数）、起動時間、リアルタイム応答、消費電力が悪化する。台数の大半が下位機種であるため、損失は台数倍で効く。 2階層（上位2機種=Linux SoC、下位10機種=MCU）: OS層は共有できないが、その上のアプリ層・通信・診断・ロギング・セキュリティを共通化できる。共通化の便益は「共有できるコード量×その部分の不具合密度」に比例するので、まずどの層を共有するかを決めるのが先。 決め方 1. 共有境界を「HAL/OS抽象化APIより上」と定義し、上位・下位の双方が同じAPIで実装できるかを2機種のプロトタイプで確認する。 2.
110 words, under 1 min2曖昧な顧客要求を検証可能な要求仕様に落とす
在宅医療向け携帯型輸液ポンプの新製品開発。顧客（医療機器メーカー）から提示された要求文は「流量精度は臨床的に問題ないこと」「バッテリは1日以上もつこと」「誤操作を防止すること」の3行のみである。目標仕様として、流量範囲1〜500 mL/h（常用10〜50 mL/h）、流量精度はIEC 60601-2-24準拠（定常±5%以内）、連続動作8時間以上、重量400 g以下、単3電池4本または専用Liイオン電池、と社内で決まっている。ハード担当は「モータとポンプ機構の選定を先に決めたい」、ソフト担当は「流量補正はソフトで行う前提でよいか」と主張し、要求レビューは未実施のまま設計が進みかけている。誤操作防止についてはUIの話として片づけられそうになっている。看護師へのヒアリングでは「チューブ交換後の再開時に流量が一時的に低下する」「電池残量表示が急に0になる」という声が上がっている。規制対応としてISO 14971のリスク管理と、IEC 62304のソフトウェア安全クラスB（想定）が適用される。開発はあと10か月で設計凍結、量産はその6か月後である。. 流量精度をハード（ポンプ機構・モータ）で担保するか、ソフト補正で担保するか。配分の判断基準と、その決定がIEC 62304の安全クラスに与える影響を論じよ。. 「流量精度は臨床的に問題ないこと」 → 「流量設定1〜500 mL/hの全範囲で、定常状態の流量誤差は設定値の±5%以内（IEC 60601-2-24の試験方法に準拠、背圧0/13.3/26.6 kPa、各30分）。起動後60秒以内およびチューブ交換後の再開時は、60秒間の積算流量が設定値の±10%以内に収束すること」。曖昧語を規格の試験条件に置き換え、過渡状態を別要求として切り出す。ヒアリングで出た「再開時に流量が低下する」は、まさにこの過渡要求の欠落が原因である。 2. 「バッテリは1日以上もつこと」 → 「常用流量50 mL/h、25℃、新品電池で連続8時間以上。残量警告は残り30分時点で発報し、警告後の流量精度は±10%以内。残量表示の誤差は実残量の±10%以内」。何をもって1日とするかの根拠（在宅での使用実態、交換頻度）を顧客と合意する。ここが未合意のまま設計すると、後工程で仕様変更になる。 3. 「誤操作を防止すること」 → これはUI要求ではなくリスクコントロールである。ISO 14971で危険状態（過量注入、流量停止の見逃し、誤設定）を特定し、リスクコントロール手段として「設定値の上限クランプ」「変更時の二段確認」「閉塞検知とアラーム」を要求化し、それぞれに検証試験を定義する。 進め方 : 要求ID・根拠（顧客/規格/リスク）・受入試験・トレーサビリティ先を必須項目にした要求仕様書テンプレートを先に作り、「臨床的に」「十分な」「適切に」を禁止語リストでレビュー時に検出する。. 考え方 : 流量精度は「機構の送液むら」「モータ回転の制御分解能」「チューブ特性のばらつき」「背圧・温度変動」の合成で決まる。±5%をいきなりどちらかに割り当てるのではなく、誤差要因に分解して配分する（誤差配分）。例えば機構の脈動に±3%、モータ制御に±1%、センサ・補正残差に±1%と割り当て、二乗和または最悪値加算で±5%に収まることを確認する。 判断基準 ソフト補正で吸収できるのは再現性のある誤差（回転数と流量の非線形性、電圧・温度ドリフト）に限る。ランダムな脈動やチューブのロットばらつきはソフトでは消せない。したがって「再現性のない誤差はハードで小さくする」。 ソフト補正はコストが安いが、補正テーブルの校正工程と経時変化の保証が必要になる。製造工程に校正を追加できるか（タクト・設備投資）が現実的な制約になる。 電池電圧低下でモータ特性が変わるため、電圧補償はソフト側が妥当。 IEC 62304への影響 : ソフトが流量の安全上限を超える誤差を検出して停止するなら、その機能はクラスBの要求（アーキテクチャ設計、単体テスト、トレーサビリティ）を満たす必要がある。ソフトを「補正のみ」に限定し、過量注入の防御をハード（流量リミッタ）に置けばソフト要求は軽くなるが、コストと重量が増える。 → 「防御はハード、精度向上はソフト」に分けるのが妥当。その前提でクラスBの要求範囲を設計初期に確定させ、ソフト担当の主張（補正はソフト前提）を無条件に受け入れない。.
47 words, under 1 min3ライン検査カメラにおけるハードウェア／ソフトウェア機能分担
基板外観検査用ラインスキャンカメラの開発。センサは4096画素×16ライン、ラインレート60 kHz、16 bit/画素で、生データ量は約7.9 GB/s（4096×16×2 byte×60,000 line/s）。カメラ筐体はIP65、ファンレス、消費電力15 W以下、BOMは現行比+15%以内が条件。処理は(1)固定パターン補正・シェーディング、(2)2値化と欠陥候補のラベリング、(3)形状特徴によるクラス分類の3段構成。撮像から判定出力までのレイテンシは20 ms以内。現行案はCortex-A55 4コア+NEONのみで、試作では(1)だけで1ライン処理時間の80%を消費し、60 kHzに届かず45 kHzで頭打ちになっている。代替案として、FPGAを追加する案（+8,000円/台、NRE 3,000万円、消費+3 W）と、SoCをCortex-A76クラスに変更する案（+5,000円/台、消費+5 W、ファンレス限界に近い）が比較されている。年間出荷5,000台、製品寿命4年。ソフト担当は「まずNEONの最適化をもう一段やるべき」と主張している。. 3つの処理のうち、どれをFPGAへオフロードし、どれをCPUに残すか。定量根拠を示して配分を決めよ。. レイテンシ20 msという要件を、パイプライン遅延とスループットに分解して検証する方法を述べよ。. FPGAを追加することで生じる新しい失敗モードと、検証・製造でそれをどう管理するかを述べよ。. まずボトルネックの定量化 : 60 kHzは1ライン16.7 µs。45 kHzで頭打ちということは1ライン約22.2 µsかかっており、(1)がその80%＝約17.8 µsを消費している計算になる。ここを削らない限り、他を最適化しても60 kHzには届かない。 割り当て案 (1)固定パターン補正・シェーディング → FPGA。画素ごとの定数演算で、入力順にストリーム処理でき、CPUを介さずDDR帯域も削減できる。7.9 GB/sをCPUで受けてから処理する構成は、帯域としても現実的でない。 (2)2値化とラベリング → 2値化はFPGA寄り。ラベリングは連結成分管理のためFPGAの内部メモリとロジックを消費する。1ラインあたりの欠陥候補が数個程度なら、2値化のみFPGA、ラベリングはCPUでも間に合う可能性がある。実測で決める。 (3)クラス分類 → CPU（NEON）。品種ごとにパラメータが変わり変更頻度が高い。FPGAに置くとロジック再コンパイルが必要になり、品種切替のリードタイムが悪化する。 コスト比較 : FPGA案は+8,000円×5,000台×4年＝1.6億円。SoC変更案は+5,000円だが消費+5 Wでファンレス15 Wの枠を超えるリスクがあり、熱設計のやり直しコストが読めない。加えてA76クラスでも(1)のストリーム処理が線形に速くなる保証はない。 → (1)のFPGA化を先行させ、試作の実測で(2)の割り当てを決める。NEON最適化は(3)に対しては有効だが、(1)の17.8 µsを桁で減らすことは難しい。. レイテンシ20 msは「1ラインの処理時間」ではなく「撮像から判定出力までのパイプライン遅延」である。ここを混同すると、スループットは満たすが遅延で不合格になる。 分解 : 遅延 = センサ露光・読み出し遅延 + バッファリング遅延（Nライン分）+ 処理遅延 + 出力・通信遅延。例えばFPGAで16ライン分のバッファを持つと、60 kHzでは16/60,000 = 0.27 ms。バッファ段数を増やすほどスループットは安定するが遅延は増える。判定をフレーム単位でまとめる設計にすると、フレーム周期分の遅延が丸ごと乗るため、ライン単位で判定を出す構成にする。 検証方法 先頭にマーカ画素を持つ擬似欠陥パターンを撮像し、入力エッジから出力エッジまでをオシロスコープまたはタイムスタンプで測る。 最悪条件で測る。すなわち欠陥が画面末尾にある場合、CPU負荷が最大の場合、FPGAバッファが満杯の場合。平均値ではなく最大値を合格判定に使う。 メモリ帯域は、FPGA→DDR→CPUの経路に同時に7.9 GB/sを流したときに競合が起きないかを帯域モニタで確認する。平均帯域が足りていても、バーストで詰まれば遅延スパイクになる。 落とし穴 : 試作の45 kHz評価はスループットの評価であり、レイテンシは別途測っていない可能性が高い。FPGA化の効果を判断する前に、現行構成での遅延の内訳を実測しておくべきである。.
99 words, under 1 min4低温で発生する起動失敗の切り分けと量産試験の設計
産業用コントローラ（Cortex-M4、外部NORフラッシュ、降圧DCDC）の量産移行から3か月、月産2万台。市場クレームとして「電源投入時に、まれに起動しない（電源再投入で復旧）」が0.3%の割合で発生している。社内の再現試験では室温で0.02%、-10℃環境では2%に上昇する。起動シーケンスは、リセット解除→ブートローダがフラッシュから設定を読む→DCDC出力電圧をソフトで段階的に上げる→アプリ起動、という順序で、電圧立上げの待ち時間はシーケンサで25 ms刻みに設定されている。フラッシュの読み出しマージンはデータシート上-40〜85℃で保証されている。製造工程のFCTは室温で起動確認を1回行うのみ。トレーサビリティは基板ロット単位で確保しているが、フラッシュのウェハロットまでは追えていない。基板ロット別の再現率はまだ集計できていない。ハード担当は「フラッシュは保証内なのでソフトのタイミング問題」、ソフト担当は「電源立上げが遅いだけ」と主張して平行線である。顧客からは4週間以内に是正方針の提示を求められている。. FCTに追加すべき試験と、その妥当性をどう評価するか。検出率・タクト・コストの観点で論じよ。. 事実の整理 室温0.02%、-10℃で2% → 温度依存がある。温度依存は、部品特性のばらつき、タイミングマージン、電圧立上げ時定数のいずれかを示唆する。 再投入で復旧する → 恒久的破壊ではなく、起動シーケンスの途中で状態が確定してしまう事象。 起動列にソフト制御のDCDC立上げが入っている → ソフトの待ち時間とハードの立上げ時間の競合が最有力。 3軸の実験計画 1. 設計軸: シーケンサの待ち時間（25 ms刻み）を意図的にずらし、フラッシュ読み出し開始時点の電源電圧が規定以上かを測る。フラッシュの読み出し可能最低電圧と、読み出し開始信号をオシロで同時観測し、マージンをmVとmsで定量化する。 2. 部品軸: フラッシュとDCDCのロットを変えて再現率を比較する。ウェハロットが未追跡のため、まず保管サンプルからロットを特定し、複数ロットで-10℃×1000回投入を実施する。 3. 製造軸: DCDCのフィードバック抵抗、フラッシュのデカップリングの実装状態をX線・断面で確認する。基板ロット別の再現率を集計する。 事前に決める判定基準 : 電源電圧マージンがほぼ0 mVなら設計起因。ロット間で再現率が10倍以上違えば部品起因。基板ロットで偏れば製造起因。これを先に文書化しておかないと、結果が出た後に解釈で争い、4週間が空費される。.
83 words, under 1 min5リードタイム20%短縮に向けた開発環境への投資配分
組込みソフト開発部門40名（5グループ）を抱える事業部。製品は3つのツールチェーン（A社MCU純正、GCC系、旧社内ツール）でビルドされ、CIはJenkins 1台で運用している。フルビルドは45分、単体テスト込みで70分。開発者は夜間にビルドを仕込み、朝に結果を見る運用で、ローカルでは通るがCIで落ちることも多く、CIの信頼性は低いと見られている。静的解析は3年前に導入したが警告が約10,000件あり、「新規警告ゼロ」も守られていない。実機HILは3台を共有し、予約はホワイトボード管理。自動テストは全体の20%程度。リリース判定は手作業のチェックリストで、過去1年に2回、テスト未実施の機能が市場に出た（重大度はいずれも中）。ツールチェーンのライセンスはフローティング5席を40名で共有し、ビルド時に取得待ちが発生する。各グループは独自スクリプトを育てており、同じ製品でもグループによってビルド手順が異なる。経営層の指示は「開発リードタイムを20%短縮せよ」の一言で、予算は年間2,000万円である。. HILの不足をどう解消するか。SIL・仮想化との使い分けと投資判断の順序を示せ。. まず計測 （2週間、コストほぼゼロ）: リードタイムを価値流れで分解する。典型的な待ちは「ビルド待ち」「HIL予約待ち」「CI失敗の原因調査」「リリース判定待ち」である。現状データ（ビルド45分・テスト70分、HIL予約待ちが何日か、CI失敗率、手戻り工数）を集めてから投資先を決める。感覚でCI高速化から始めると、ボトルネックがテスト待ちだった場合に効果が出ない。 投資配分の例 施策 概算 期待効果 --- --- --- CI高速化（キャッシュ、増分ビルド、分散） 300〜500万 フルビルド45分→15分。夜間バッチからPRごと実行へ HIL増設（3台→6台）＋予約自動化 600〜800万 予約待ちの解消、夜間自動実行 SIL環境とテスト自動化基盤 400万 自動化率20%→60%、回帰の再現性 静的解析のベースライン化とゲート運用 100万 新規警告ゼロの維持 ツールチェーン統合（3→2）とライセンス増 200万 取得待ちの解消、手順の統一 順序 : 計測 → 静的解析運用（安く効く）→ ツールチェーン統合とライセンス → CI高速化 → HIL/自動化。アムダールの法則で、各改善が全体時間にどれだけ寄与するかを試算してから着手する。 判断の軸 : 40名の待ち時間は工数換算で経営層に説明できる。ビルド待ちが1日1回30分×40名なら月約87人時であり、CI投資の回収根拠になる。. ベースラインの固定 : 現行コードの警告10,000件を既知としてベースラインに記録し、PRでは「新規警告ゼロ」だけを判定する。これで初めてゲートが機能する。 2. トリアージ : 「バグ直結（未初期化、NULL参照、配列外参照、リソースリーク）」「マルチタスク競合（共有変数の保護漏れ）」「スタイル・可読性」に分類する。組込みでは競合と未初期化を最優先。MISRA準拠は製品の安全要求に照らして適用範囲を決め、全ルール一律適用はしない。 3. ゲート化 : CIで新規警告が出たらマージ不可。既存警告は「触ったファイルだけ返済する（ボーイスカウトルール）」とし、新規開発コードは最初から警告ゼロで入れる。 4.
104 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.