エンベデッドシステムスペシャリスト 2020年 午後1 問02

解答の導き方

誤りやすいポイント

• 異常な加速度を検出した後に行う施錠やメッセージ送信だけを挙げて、電源OFFモードへの移行を見落とさないようにします。
• スマホとの連携機能には施錠・解錠などもありますが、この設問で問われているのは電源OFFモードへの移行につながる操作です。
• 測位に失敗したこと自体は、本文に電源OFFモードへ移行する契機として示されていません。

FAQ

解答の導き方

誤りやすいポイント

• 測位に失敗したら直ちに走行停止すると考えることです。測位失敗は、新しい目標位置が得られないことを意味しますが、それだけで走行停止するとは書かれていません。
• 測位に失敗すると、記憶済みの目標位置も消えると考えることです。目標位置は計測成功時に記憶され、失敗時に消去する処理は示されていません。
• 物体識別情報が新しい目標位置を与えると考えることです。物体識別情報は、走行プランを生成する際に使われる情報であり、目標位置は測位情報に基づきます。

FAQ

解答の導き方

1. 表3の下線①では、走行プランタスクが入力した測位情報をメインタスクに通知します。設問は、この通知を受けたメインタスクが何をするかを尋ねています。
2. 表3には、メインタスクが「スマホとの連携機能を実行する」とあります。また、図3ではメインタスクとBluetoothタスクが双方向に通信しています。したがって、メインタスクは受け取った情報をスマホへ送る役割を担います。
3. 表2では、スマホが「スーツケースから送られた測位情報から、スーツケースまでの距離を表示する」とされています。距離表示に必要なのは測位情報そのものなので、メインタスクは測位情報をスマホに送信します。

誤りやすいポイント

• 測位情報を受け取った後、目標位置として記憶するのは走行プランタスクです。設問で問われているのは、その情報を受け取ったメインタスクの処理です。
• スマホが距離を表示するからといって、メインタスクが距離を計算して送るとは限りません。表2にあるのは、測位情報を基に距離を表示する機能です。
• タスク間の通知と、スマホへの送信は別の段階です。走行プランタスクから通知を受けたメインタスクが、スマホとの連携機能を通じて送信します。

FAQ

解答の導き方

1. 走行プランは、0.25秒間の方向・速度を1レコードとして並べたものです。したがって、必要な時間分のレコード数を求めるには、まず走行プランで確保すべき時間を考えます。
2. 物体識別情報は1秒ごとに出力されます。一方、走行プランタスクがその情報を入力してから新しい走行プランを通知するまでには、0.2～0.6秒掛かります。連続する二つの走行プランの通知間隔が最大になるのは、先のプランの生成が0.2秒で終わり、次のプランの生成に0.6秒掛かる場合です。したがって、通知間隔の最大値は、$1+0.6-0.2=1.4$秒です。
3. 走行制御タスクは、段差ありの通知を受けると、走行プラン上で「0.5秒以内にその段差に至るか」を判断します。次の走行プランが通知されるまでの間に段差ありの通知を受けても、この判断ができるようにするには、プランが通知されてから次のプランが通知されるまでの時間に加え、判断に使う0.5秒分の先の走行も走行プランに含める必要があります。必要な時間は、$1.4+0.5=1.9$秒です。
4. 1レコードが0.25秒間なので、必要なレコード数は、$1.9÷0.25=7.6$を切り上げた数です。よって、走行プランに必要なレコード数の最小値は8です。

誤りやすいポイント

• 生成に掛かる最大の0.6秒だけを使い、連続するプランの通知間隔を求めてしまうことがあります。先のプランの生成時間が最短の0.2秒だった場合も考慮する必要があります。
• 段差ありの通知を受けた後に判断する0.5秒分を、走行プランの時間に含め忘れないようにします。
• 必要な時間をレコード数に換算するとき、7.6を切り捨てず、0.25秒単位を満たすように切り上げます。

FAQ

解答の導き方

誤りやすいポイント

• 段差が検出可能な範囲に入ってから、センサが次に確認するまでの最大0.1秒を加え忘れないようにします。
• 停止判断までの時間だけでなく、停止指示後に走行する最大15センチメートルも加算します。
• 段差センサの検出距離1.5メートルは、段差を検出できる範囲を表します。この設問で求める「範囲に現れてから停止するまでの走行距離」に、そのまま加えるものではありません。
• 速度の単位をそろえてから計算します。5.4キロメートル／時をセンチメートル／秒に直すと150センチメートル／秒です。

FAQ

解答の導き方

誤りやすいポイント

• 段差ありを検出した時点で、スーツケースが直ちに停止すると考えないようにします。検出後、停止を判断するタスクを経て走行制御タスクに指示が届く必要があります。
• 段差検出タスクが段差を検出することと、走行制御タスクが停止することは別の処理です。初期設計では、その間の通知と判断を走行プランタスクが担うため、処理中の遅れが問題になります。
• 問題となるのは、段差検出の性能ではなく、段差ありの通知を受けてから停止指示が出るまでの遅れです。

FAQ

解答の導き方

1. まず、盗難注意メッセージを送る条件を確認します。スーツケースがブレスレットから「2メートル以上離れたら」通知するため、スーツケースから見たブレスレットまでの距離を測る必要があります。表1では、ブレスレットの方向と距離を計測する構成要素として測位ユニットが示されています。したがって、距離を判断するために測位ユニットが必要です。
2. 次に、盗難警告メッセージを送る条件を確認します。ブレスレットから離れている状態で、スーツケースに「静止しているときの加速度よりも強い加速度」が生じたことを検出します。表1でスーツケースの加速度を計測する構成要素は加速度センサなので、これが必要です。
3. 盗難警告の条件を満たしたときは、スーツケースを施錠します。表1で施錠・解錠を行う構成要素は施錠・解錠ユニットなので、これも必要です。
4. スマホへのメッセージ送信には通信が必要ですが、表1ではスマホとの通信は制御部の機能として説明されています。設問では制御部を除くため、これを別の構成要素として加える必要はありません。また、ハンドキャリーモードでは追尾走行を行わないため、モータユニットや物体識別ユニット、段差センサも最低限の構成要素には含まれません。

誤りやすいポイント

• スマホにメッセージを送るため、Bluetoothモジュールを解答に含めたくなりますが、これは制御部に搭載されており、設問で除外されています。
• 追尾モードで使う構成要素まで含めないようにします。ハンドキャリーモードで必要なのは、距離の確認、加速度の検出、施錠です。
• 施錠する機能には施錠・解錠ユニットが必要です。異常を検出するセンサだけでは施錠できません。

FAQ

解答の導き方

誤りやすいポイント

• 盗難注意メッセージの条件はブレスレットまでの距離なので、物体識別情報と取り違えないようにします。物体識別情報は、進行方向にある物体やその動きに関する情報です。
• 加速度異常の通知だけで盗難警告を送信するのではありません。問題文では、ブレスレットから2メートル以上離れていることも条件になっています。
• 設問が尋ねているのは、センサ名や通知元タスク名ではなく、メインタスクに渡されるタスク間メッセージです。

FAQ

解答の導き方

1. ハンドキャリーモードでは、ブレスレットから「2メートル以上離れた状態」で、スーツケースが静止しているときより強い加速度を検出すると、盗難警告につながります。したがって、加速度の監視は、ブレスレットから離れた状態になったときに開始する必要があります。
2. 一方、所有者がスーツケースを持ち運んでいる間は、持ち上げたり歩いたりすることで加速度が変化します。距離に関係なく加速度センサを監視すると、盗難ではない通常の持ち運びでも加速度異常が高頻度で通知される可能性があります。
3. そこで、距離が2メートル以上かどうかだけでなく、距離がどの状態からどの状態に変わったかを条件にします。2メートル未満から2メートル以上になった時点で、盗難の可能性を検知するための加速度監視を開始します。つまり、開始条件は「ブレスレットからの距離が、2メートル未満から2メートル以上に変化した。」です。

誤りやすいポイント

• ハンドキャリーモードに入った時点で加速度監視を開始すると、所有者が持ち運んでいる間の加速度変化も検出してしまいます。
• 「2メートル以上であること」だけを答え、2メートル未満から2メートル以上への変化という開始のタイミングを示さないと、設問が求める条件として不十分です。
• 加速度が強くなったことは、加速度監視を開始する条件ではありません。監視を開始した後に、盗難警告の判断材料として使います。

FAQ