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

解答の導き方

誤りやすいポイント

• 気圧の高さだけで活動状態を決めないようにします。気圧から分かるのは、首輪デバイスの高さです。
• 「横臥」と「起立」は、どちらも首が静止していることがあります。区別するには、気圧から首の高さも確認します。
• 加速度センサの波形では、値の基準位置だけでなく、振動の有無にも注目します。

FAQ

解答の導き方

• a（2本目から3本目の破線まで）
  この区間の気圧は低いままなので、首は高い位置にあります。そのうえで、加速度X・Y・Zのすべてに大きな振動が現れています。図3ではX、Y、Zがそれぞれ牛の前後、左右、上下方向なので、首が前後左右上下に大きく揺れていることになります。表2で首が高い位置にあり、「首が前後左右上下に大きく振動する」のは「歩行」です。
• b（4本目から5本目の破線まで）
  この区間では気圧が高くなっているので、首は低い位置にあります。首が低い活動状態は、表2では「横臥」「横臥反芻」「採食」の三つです。
  加速度センサは、静止していても重力加速度を計測します。首輪デバイスが傾くと、それまで上下方向のZ軸にかかっていた重力の一部が前後方向のX軸にもかかるようになり、各軸の値の基準が変わります。この区間では、加速度Xが負側に移ったままになり、加速度Zも一段ずれているので、首が前後方向に傾いた姿勢になっていると読み取れます。さらに、加速度Xと加速度Yに小さな振動が続いているので、首は前後左右に振動しています。
  首が静止している「横臥」や、左右にだけ振動する「横臥反芻」とは合いません。首が低い位置で前後方向に傾き、「首が前後左右に振動する」状態に当てはまるのは「採食」です。

誤りやすいポイント

• 気圧の高低を、首輪デバイスの高さと逆に解釈しないようにします。位置が低くなると気圧は高くなります。
• 気圧だけで活動状態を決めないようにします。首が低い状態は「横臥」「横臥反芻」「採食」のいずれでも起こるため、加速度の傾きと振動の方向も合わせて判断します。
• 振動が出ている軸を確認します。左右方向のYだけが小さく振動するのは反芻の特徴で、前後方向のXにも振動があれば採食と判断できます。
• 図3の軸には正負の向きが示されていないので、負側に移ったこと自体より、基準の値が変わった（傾いた）ことに注目します。

FAQ

解答の導き方

誤りやすいポイント

• GPSモジュールが首輪デバイスに搭載されていることだけから、どこでもGPS割込みを利用できると考えないようにします。
• GPS割込みは、GPS衛星から電波を受信したときに発生します。電波を受信できない環境では、割込みも発生しません。
• 設問では消費電力削減を除くよう指定されています。消費電力の大小ではなく、牛舎内でGPSの電波を受信できるかに着目します。

FAQ

解答の導き方

1. 牛舎サーバが確認したいのは、牛の活動状態そのものではなく、各首輪デバイスから送られる判定データが新しいものに更新されたかどうかです。
2. 表3の判定データには、「牛ID」と「時刻データ」が含まれています。牛IDによってどの牛のデータかを区別でき、時刻データによって、そのデータがいつのものかを確認できます。
3. 判定データの内容は、牛の状態が変わらなければ前回と同じになることがあります。そのため、活動状態などの値が変わったかどうかだけでは、データが更新されたかを正しく判断できません。一方、同じ牛IDについて、受信した時刻データが前回から変わっていれば、新しい時点の判定データが届いたと判断できます。

誤りやすいポイント

• 牛の活動状態が変化したかどうかで更新を判定しようとすることです。状態が同じでも、新たな計測結果が送られている場合があります。
• 全ての首輪デバイスのデータをまとめて時刻で比較することです。牛IDごとに前回の時刻データを管理する必要があります。
• 通信周期だけを根拠に更新済みと判断することです。周期が定められていても、各首輪デバイスからのデータが新しくなったかは、受信データの時刻で確認します。

FAQ

解答の導き方

1. 表3の「1送信分のデータ量」は、ヘッダから時刻データまでを合計します。
   $4+2+2+1+58+2+6=75$ バイト
2. 通信仕様には「実効伝送速度は、5,000ビット／秒」とあります。1バイトは8ビットなので、75バイトをビット数に直すと次のとおりです。
   $75\times 8=600$ ビット
3. 送信時間は、データ量を伝送速度で割って求めます。
   $600÷5,000=0.12$ 秒
   よって、小数第2位までで 0.12秒 です。

1. 表4から、計測判定モードは90ミリW、送受信モードは120ミリW、スリープモードは30ミリWです。問題文では、3分間隔で起床して計測判定モードを30秒間実行し、その後、送受信モードを1.5秒間実行するとあります。
2. 1周期の長さは3分、つまり180秒です。したがって、スリープモードの時間は次のように求められます。
   $180-30-1.5=148.5$ 秒
3. 消費電力量は、各モードの電力にそのモードの時間を掛けて求めます。時間を秒で扱う場合は、3,600で割るとミリWhになります。
   • 計測判定モード：$90\times 30÷3,600=0.75$ ミリWh
   • 送受信モード：$120\times 1.5÷3,600=0.05$ ミリWh
   • スリープモード：$30\times 148.5÷3,600=1.2375$ ミリWh
   1周期当たりの合計は、$0.75+0.05+1.2375=2.0375$ ミリWhです。
4. 1日は24時間で、3分間隔の周期数は次のとおりです。
   $24\times 60÷3=480$ 周期
   よって、1日当たりの消費電力量は、$2.0375\times 480=978$ ミリWhです。

誤りやすいポイント

• 表3のデータ量をバイトのまま伝送速度で割らないようにします。伝送速度はビット／秒なので、バイト数を8倍してビット数に直します。
• 送信時間の計算では、表3の各項目を合計します。ヘッダも「1送信分のデータ量」に含まれています。
• 1周期の時間から計測判定モードと送受信モードの時間を引いて、スリープ時間を求めます。スリープ時間を180秒としてしまうと、各モードの時間を重複して計算することになります。
• 電力の値を足すだけでは消費電力量になりません。各モードの電力に、そのモードの継続時間を掛けてから合計します。

FAQ

解答の導き方

• 牛ID1は、ビーコン2のRSSIが最も大きいため、区画2です。
• 牛ID2は、ビーコン1のRSSIが最も大きいため、区画1です。
• 牛ID3は、ビーコン2のRSSIが最も大きいため、区画2です。

誤りやすいポイント

• dBmのRSSIは負の値になることが多く、値がより負に大きいほど信号が強い、と誤解しやすいです。例えば−53.4は−76.2より数値が大きく、信号も強い値です。
• (a)では、ビーコン1のRSSIだけを比べます。ほかのビーコンのRSSIを使って牛IDを選ばないようにします。
• (b)では、境界線上にいるときの等距離関係と、ビーコン1との距離関係を分けて考えます。
• (c)では、各行について最も大きいRSSIを選びます。RSSIの大小を区画番号の大小と取り違えないようにします。

FAQ

解答の導き方

1. 問われているのは、牛が牧草を再生中のエリアに入ったとき、牛舎サーバ側から再生を指示しても、すぐに音声が再生されないことがある理由です。サーバから首輪デバイスへの指示が、いつでも届くわけではない点に注目します。
2. 本文では、牛舎サーバと首輪デバイスの通信に「ポーリング方式」を用い、「通信周期は、3分」とあります。さらに、牛舎サーバは首輪デバイスに送信要求を送り、首輪デバイスは送信要求を受信したときに判定データを送信します。つまり、サーバと首輪デバイスは常時通信しているのではなく、決められた周期で通信します。
3. そのため、牛がエリアに入った直後にサーバが再生を指示しようとしても、次の通信機会まで指示を送れないことがあります。この通信の待ち時間が生じる理由を、15字以内で答えます。

誤りやすいポイント

• 牛がエリアに入ったことをサーバが検知できれば、すぐに首輪デバイスへ指示できると考えてしまうことがあります。検知後に指示を届ける通信のタイミングも考える必要があります。
• 首輪デバイスの計測判定モードの処理時間や、送受信モードの処理時間を理由として答えるのは適切ではありません。問われている遅れの原因は、サーバと首輪デバイスの通信周期です。
• 「通信に時間がかかるから」とだけ答えると、周期による待ち時間が伝わりません。通信周期が3分であることを示します。

FAQ

解答の導き方

1. GPSを使っていたとき、首輪デバイスのMCUはGPSモジュールから「現在時刻を読み取る」とされています。また、判定データには「時刻データ」が含まれます。つまり、首輪デバイスで記録するデータには、時刻を正しく付ける必要があります。
2. GPSの代わりに時計モジュールを追加すれば、首輪デバイス自身で時刻を得られます。しかし、時計モジュールの時刻が牛舎サーバの時刻と一致するとは限りません。時刻がずれていると、首輪デバイスの記録時刻と牛舎サーバ側で扱う時刻を正しく対応付けられなくなります。
3. 通信仕様では、牛舎サーバからの送信要求に「現在時刻」が含まれます。この時刻を基準に首輪デバイス側の時計を調整すれば、両者の時刻をそろえられます。

誤りやすいポイント

• 時計モジュールを追加すれば十分だと考えることです。時計モジュールは時刻を得る手段ですが、牛舎サーバとの時刻の一致までは保証しません。
• RSSIから時刻も得られると考えることです。RSSIは測位に使う受信信号強度であり、時刻を取得する機能ではありません。
• GPSが担っていた機能のうち、位置情報だけに注目することです。GPSモジュールは現在時刻も提供していたため、置き換え後も時刻を正しく扱う方法が必要です。

FAQ