www.youtube.com 本動画では、令和2年度（2020年10月）エンベデッドシステムスペシャリスト試験 午後Ⅰ 問2を取り上げ、所有者の後方を自動的に追尾するスーツケースという題材を通じて、追尾仕様の読解、リアルタイムOS上でのタスク設計、そして盗難防止機能の追加に伴う設計変更を、問題文・解答例・採点講評の意図に沿って整理します。午後Ⅰで求められるのは、知識の披露ではなく、与えられた仕様から「この装置はどの条件で何をするのか」「どの遅延やジッタが安全性に影響するのか」を因果で説明できる読解力です。本問は自走ロボット系の典型課題である追従制御と安全停止を扱い、タスク間のメッセージ設計やバッファ設計の妥当性が、そのまま得点差になります。 設問1は制御部の仕様理解が中心で、追尾モードから電源OFFへ移行する契機を、電源ボタンや電池切れ以外まで含めて漏れなく抽出できるかが問われます。ここで重要なのは、追尾機能が「便利な機能」である一方、衝突や盗難といった危険事象に対してはフェイルセーフが優先される、という設計思想を問題文から読み取ることです。異常な加速度の検出が契機になるのは、物体との衝突などのリスクを検知したら走行系を継続させないためであり、スマホからの指示が契機になるのは、サービス提供者側が利用者操作によって状態を確実に収束させるためです。単に「異常があったら止まる」と一般論で書くのではなく、問題文に明示された契機を字句として確定し、なぜそれがOFFへ直結するのかを説明できると、午後Ⅰの要求に合致します。 次に、測位情報の計測が失敗し続けた場合の動作は、採点上の分かれ目になりやすい読解問題です。直感的には「目標位置が分からないから停止する」と書きたくなりますが、本問の仕様はそう単純ではありません。測位ユニットは計測成功時にのみ目標位置を記憶し、失敗時は新しい目標位置に更新しないという前提があるため、失敗が継続した場合でも、最後に成功したときの目標位置という“確定している唯一の参照点”へ向けて移動し、その位置で停止する、という振る舞いになります。ここは、問題文が意図的に「失敗＝即停止」と誤読しやすい形で書かれており、仕様の記憶条件まで含めて追えるかが合否を分けます。午後Ⅰの読解ポイントとして、成功時のみ更新される状態量があるとき、失敗が続くとシステムは何を参照して動くのか、という観点を持って読むことが重要です。 設問2は制御部ソフトウェア、すなわちリアルタイムOSを前提にしたタスク設計が中心となります。測位情報の通知を受けたメインタスクの処理については、測位ユニットから受け取った測位情報をスマホへ送信するという、役割分担の基本を正確に書けるかが問われます。ここでのポイントは、測位ユニットが直接スマホへ送るのではなく、制御部の中心であるメインタスクが情報ハブとして振る舞う構造を読み取ることです。タスク設計の問題は、処理内容そのものよりも、どのタスクがどのI/Fを担うかというアーキテクチャの整合性が採点されます。 走行プランに必要なレコード数の最小値を求める設問は、本問の最大の難所の一つです。走行プランは0.25秒間隔で生成されるレコードをまとめたものですが、入力側である物体識別情報は1秒間隔で通知されるという仕様があり、さらに入力から走行プラン生成・通知までに最大0.6秒のジッタがあることを織り込む必要があります。多くの誤答は、0.25秒という生成周期だけでバッファを見積もり、入力の粗さやジッタを無視してしまうところから生まれます。実装現場でも同様に、センサ入力周期と制御出力周期の不一致、処理遅延のばらつきがあると、最小バッファを小さく見積もって欠落や取りこぼしが発生します。正答が8となるのは、1秒周期の入力を受けてから最大0.6秒遅れて制御系へ反映される場合でも、走行制御が必要とする0.25秒刻みのレコード列を途切れさせないために、最低限確保すべき時間窓が決まるからです。午後Ⅰでの学びは、数式処理というより、仕様に含まれる複数の時間条件を同じ時間軸上に並べて、最悪条件でバッファ要件を確定するという設計思考にあります。 段差による停止までの最大走行距離を求める計算問題も、条件の読み落としが失点に直結します。走行制御タスクが段差による停止を判断するまでに最大0.18秒かかり、その後モータユニットへ停止指示を出してから実際に停止するまでに最大15cm走行するという二段階遅延を足し合わせ、さらに指定の端数処理で整数化する必要があります。ここで重要なのは、停止距離が「判断遅れによる走行距離」と「指示後の惰性走行距離」の合算である点で、どちらか一方だけを計算すると過小評価になり、安全停止設計として成立しません。正答が57cmとなるのは、こうした最悪時系列を一つの停止シナリオとして結んだ結果であり、落ち着いて単位と端数処理を揃えることが午後Ⅰの計算問題対策になります。 初期設計における不具合を問う設問は、タスク配置の誤りが安全性へどう波及するかを説明できるかが核心です。段差あり・段差なしの通知を走行プランタスクが受け、走行プランタスクが停止を判断する設計では、物体識別情報を受け取ってから走行プランを生成・通知するまでの0.2～0.6秒という処理時間の間に、段差ありの情報を受け取っても即時に走行制御へ反映できません。その結果、古い走行プランに従って段差まで走行してしまい、段差に突っ込む可能性が生じます。ここは単なる「停止が遅れる」ではなく、どのタスクがボトルネックになり、どの遅延が“古い指令の継続”を生むのかを、問題文の時間条件を根拠に因果で書くことが求められます。午後Ⅰの読解ポイントとして、制御における安全判断は、生成系のタスクよりも、実行系のタスクに近い位置で即時に反映される設計が望ましい、という原則を、本問は具体的な数値で体感させています。 設問3は盗難対策としてのハンドキャリーモード追加で、機能追加時に「最低限どの構成要素へ給電し続ける必要があるか」「どの情報をタスク間でやり取りするか」「監視をいつ開始するか」という、要求を設計に落とし込む応用力が問われます。ハンドキャリーモードでは追尾走行そのものよりも、所有者からの距離計測、強い加速度の検出、施錠機能が本質です。したがって制御部と電源部を除けば、測位ユニット、加速度センサ、施錠・解錠ユニットが最低限必要な構成要素になります。ここでのポイントは、便利機能を残す発想ではなく、盗難抑止という目的に対して必要十分な機能へ絞り込むこと、すなわち省電力と目的達成を両立する設計判断にあります。 表4のタスク間メッセージを埋める設問では、2m以上離れたことを示すのは距離に関する測位情報であり、静止時より強い加速度を示すのは加速度異常である、というように、イベントの意味とメッセージ名が一致しているかが採点されます。ここで曖昧な表現をすると誤答になりやすく、午後Ⅰでは問題文の用語体系に合わせて、同じ語を同じ意味で使うことが重要です。 最後に、メインタスクが加速度検出タスクに計測開始を通知する条件は、過剰通知という運用上の問題を踏まえた設計改善を問うています。加速度異常が高頻度で通知されると、盗難検知の価値が下がるだけでなく、処理負荷や誤作動にもつながります。そのため監視期間を限定し、ブレスレットからの距離が2m未満から2m以上に変化した瞬間、すなわち所有者の手元を離れた可能性が高まったタイミングで計測を開始する設計になります。ここは「離れたら監視する」という一般論ではなく、距離の状態遷移をトリガにして監視を開始する、というイベント駆動設計の形で書けるかがポイントです。 本動画で得られる学びは、追尾ロボットという題材を借りて、仕様の“記憶条件”を含めた読解、複数周期とジッタを前提にしたバッファ設計、停止に関する最悪時系列の組み立て、そして安全判断をどのタスクに置くべきかというアーキテクチャ判断を、一つの過去問の中で体系的に整理できる点にあります。特に、測位失敗時の動作のように直感に反する仕様、走行プランのレコード数のように周期不一致と遅延の合成を要求する設問、初期設計の不具合のようにタスク配置と遅延が安全性へ直結する論点は、午後Ⅰで頻出の「与件から因果で答える」力を強く鍛えます。動画を見る意義としては、正解を知るだけではなく、なぜその振る舞いになるのか、なぜその数になるのか、なぜその設計だと危険なのかを、問題文中の条件だけで論理的に再構成できるようになることにあります。これができれば、同種の自走制御・安全停止・機能追加の問題に対しても、読み方と解き方を再現でき、合格点に直結する安定した得点源に変わります。
