応用情報技術者 2022年 春期 午後 問07

解答の論理構成

1. 自動撮影の基本動作
   • 問題文には「撮影を開始してから Ta秒間撮影する。ここで、Taはパラメタである。」とあります。
   • したがって動体を1回だけ検知した場合、撮影時間は開始時刻＋Ta秒で終了します。
2. 途中で新たに動体を検知した場合
   • さらに「撮影中に新たに動体を検知すると…更にTa秒間撮影を行う。」と明記されています。
   • 検知のたびに残り時間がリセットされるイメージではなく、「検知した時点」から改めてTa秒追加される仕組みです。
3. 設問の条件整理
   • 動体を最初に検知したのが時刻 $t_1$。
   • $t_1$ 以降、途切れずに撮影を継続しつつ、最後の検知が時刻 $t_2$ に発生。
   • 「途切れることなく」とあるため、$t_1$ と $t_2$ の間に複数回検知があったとしても撮影はずっと続いています。
4. 撮影終了時刻の決定
   • $t_2$ で最後に検知した瞬間、そこから Ta秒 が新たに加算されます。
   • 従って、撮影終了時刻は
     $t_{\text{end}}=t_2+Ta$
5. 撮影継続時間の算出
   • 開始は $t_1$、終了は $t_2+Ta$。
   • よって撮影時間 $T$ は
     $T=(t_2+Ta)-t_1=(t_2-t_1)+Ta$

誤りやすいポイント

• Taを「毎回上書きで残り時間をTaに戻す」と誤解し、$(t_2-t_1)$ を答えてしまう。
• 最後の検知があった瞬間を含めてTa秒撮ることを忘れ「$(t_2-t_1)-Ta$」など減算してしまう。
• 動体が検知されなかった区間があると仮定し、撮影が一旦止まるケースと混同する。設問は「途切れることなく」と強調しています。

FAQ

解答の論理構成

1. 初期条件の整理
   スマホは「視聴を開始」した時点で遠隔撮影が始まっています。このときワイヤレスカメラは遠隔撮影状態に遷移し、
   「・スマホから遠隔撮影終了が要求される、又は撮影を開始してから60秒経過すると撮影を終了する。」
   により $60\text{秒}$ のタイマがセットされます。
2. 通信障害の影響
   問題文には、
   「・ワイヤレスカメラとスマホが通信するときに通信障害が発生すると、データの再送は行わず、障害発生中の送受信データは消滅するが、撮影は続ける。」
   とあります。よって、$10\text{秒}$ から $30\text{秒}$ までの $20\text{秒}$ は映像が届かないだけで、カメラ側では遠隔撮影を継続しています。タイマも停止・延長されません。
3. 「再度の開始要求」が届かない理由
   通信障害が始まって $5\text{秒}$ 後（＝時刻 $15\text{秒}$）にスマホが送った遠隔撮影開始要求は、障害中のためカメラに届きません。従って、
   「・撮影中に再度、遠隔撮影開始が要求されると、その時点から60秒間…」
   の条件は発動せず、タイマはリセットされません。
4. 視聴終了時刻の決定
   以上より、最初にセットされた $60\text{秒}$ タイマがそのまま有効です。
   したがって視聴終了は視聴開始からちょうど $60\text{秒}$ 後、答えは
   $\boxed{60}$

誤りやすいポイント

• 「再度の開始要求」があったから $60\text{秒}$ 延長されると勘違いする
  → 要求がカメラに届いて初めてタイマがリセットされます。通信障害中に送った要求は消滅します。
• 通信障害の時間を加算してしまう
  → 撮影は継続し、タイマも進み続けます。映像が届く・届かないはタイマに無関係です。
• 「視聴が中断したから終了も遅れる」と考える
  → 終了条件はカメラ側のタイマまたは終了要求だけで決まります。スマホ側の視聴可否は無関係です。

FAQ

解答の論理構成

1. 図2で 待機状態 → S1 の遷移条件が「遠隔撮影開始イベント（8）」と示されています。遠隔撮影が開始されると直ちに 表3の「⑧　遠隔撮影タイマ設定」が実行されていることから、S1は“遠隔撮影のみ”を行うモードであると判断できます。
   表1に該当する状態名は「遠隔撮影状態（遠隔撮影だけを行っている状態）」です。
2. 図2で 待機状態 → S2 の遷移条件が「動体検知通知イベント（5、7）」です。表3で「⑤ サーバに動画データ送信」「⑦ 自動撮影タイマ設定」は自動撮影時に用意された処理であり、動体検知を契機に自動撮影が始まることを示します。
   表1に該当する状態名は「自動撮影状態（自動撮影だけを行っている状態）」です。
3. 以上より、
   • S1＝「遠隔撮影状態」
   • S2＝「自動撮影状態」
   が妥当となります。

誤りやすいポイント

• 「動画データ通知イベント」を見て撮影中であることだけに注目し、S1とS2の区別をタイマ処理でなく“データ送信先”で判断しようとして混乱するケース。
• S2からS3の遷移に「遠隔撮影開始イベント（8）」が含まれているため、S2を“待ち受け”と誤認してしまうケース。
• 表3の処理番号を見落とし、「⑧ はS1にもS3にも付いている＝どちらも遠隔撮影状態」と考えてしまうミス。

FAQ

解答の導き方

1. 状態名（S1, S2, S3）の対応を確認する
   • 図2に「待機状態 → S1イベント：遠隔撮影開始イベント（8）」とあり、待機からS1へ入るのは「遠隔撮影開始イベント」であることが明示されています。表2の「遠隔撮影開始イベント」は「スマホから遠隔撮影開始が要求されたときに通知されるイベント」ですから、S1は遠隔撮影のみを行う「遠隔撮影状態」に対応します。
   • 同様に図2の「待機状態 → S2イベント：動体検知通知イベント（5、7）」や「S2 → S3イベント：遠隔撮影開始イベント（8）」から、S2が自動撮影のみの「自動撮影状態」、S3が自動撮影と遠隔撮影の併行である「マルチ撮影状態」であると読み取れます。
   • 以上より、図中の遷移と表2／表3の対応を使って各遷移がどのイベントで起きるか判断します。
2. [a] が「遠隔撮影開始イベント」である根拠（段階的説明）
   • 図2に「待機状態 → S1イベント：遠隔撮影開始イベント（8）」とあり、この遷移のイベント名が明示されています。表2で「遠隔撮影開始イベント」は「スマホから遠隔撮影開始が要求されたときに通知されるイベント」ですから、図のその位置に入るべきイベントは「遠隔撮影開始イベント」です。
   • 処理番号（8）は表3の「遠隔撮影タイマ設定」であり、遠隔撮影開始時に遠隔撮影用の60秒タイマを設定する動作と整合するため、この遷移が遠隔撮影の開始を表していることが確かめられます。
3. [b] が「自動撮影タイマ通知イベント」である根拠（必ず示すべき対応関係を明示）
   • 図2の注記に「（処理）内の数字は、表3の項番の処理を行うことを示す」とあります。表3の⑤は「サーバに動画データ送信」であり、⑤ が付く遷移はサーバへ動画データを送る動作を表します。
   • 本文の自動撮影の説明に「撮影を開始してからTa秒間撮影する。… Ta秒間の撮影が終わるとバッファの動画データはサーバに送信される。」とあるため、Taの満了（＝自動撮影タイマの通知）が発生したときにサーバ送信（表3の⑤）が起きることが明らかです。表2の「自動撮影タイマ通知イベント」は「自動撮影で使用するタイマでTa秒後に通知されるイベント」ですから、Ta満了を表すイベントは「自動撮影タイマ通知イベント」です。
   • 図2の別の遷移に「待機状態 → [c] イベント：自動撮影タイマ通知イベント（2、5）」と記されていることも、Ta通知が②（撮影終了）や⑤（サーバ送信）を引き起こすことを示しています。
   • また、図2にある「S2 → S3イベント：動画データ通知イベント（4）」のように「動画データ通知イベント」は表3の④「バッファに書込み」と対応しているため、もし [b] が「動画データ通知イベント」なら遷移に付く処理番号は④であるはずです。ところが該当遷移は⑤（サーバ送信）を伴っているため、該当イベントは「動画データ通知イベント」ではなく「自動撮影タイマ通知イベント」であると結論できます。
   • 以上より、図中で⑤が付された遷移（該当する [b]→S3の遷移）は「自動撮影タイマ通知イベント」に対応します。

誤りやすいポイント

• 図中の処理番号（（4）や（5）など）と表3の対応を確認せずに、イベント名だけの印象で判断してしまう。必ず「（処理）内の数字は、表3の項番の処理を行うことを示す」を参照すること。
• 「動画データ通知イベント」と「自動撮影タイマ通知イベント」を混同すること。前者はカメラがエンコードデータを生成したときの通知であり、表3では④（バッファに書込み）と対応している点に注意する。
• 「撮影中に動体を検知したとき」と「Taが満了したとき」はいずれもサーバ送信につながる場合がある（本文に明記）が、図のどの遷移がどのイベントに対応しているかは処理番号で確かめる必要がある。
• タイマ設定の扱い（「それぞれのタイマは新たに設定されると、直前のタイマ要求は取り消される」）を見落とすと、遷移後のタイマ動作を誤解する。

FAQ

解答の論理構成

1. 初期状態である「待機状態」は、【問題文】の表1で「カメラ部には電力が供給されておらず、撮影していない状態」と定義されています。
2. 動体を検知したときは自動撮影を開始しなければなりません。自動撮影開始時の動作は【問題文】の自動撮影仕様で
   　　‐「動体を検知すると撮影を開始する。」
   　　‐「撮影を開始したとき、スマホに撮影を開始したことを通知する。」
   　　‐「撮影を開始してからTa秒間撮影する。」
   　と明示されています。
3. この一連の処理に対応する項番は表3より
   　　①「カメラ初期化」
   　　③「撮影開始」
   　　⑦「自動撮影タイマ設定」
   　の3つです。
4. したがって、図2で「待機状態」から自動撮影を始める遷移に付与すべき処理、すなわちcに入る処理は「①、③、⑦」となります。

誤りやすいポイント

• 動体検知時にすぐバッファ送信（⑤）を入れてしまう
  待機中はまだ動画が存在しないため送信処理⑤は不要です。
• タイマ設定を忘れる
  Ta秒後の自動停止が必要なので⑦「自動撮影タイマ設定」を必ず入れる必要があります。
• カメラ初期化①の抜け漏れ
  待機状態では電力が遮断されています。撮影開始前に①が不可欠です。

FAQ

解答の論理構成

1. 自動撮影の通常手順
   引用: 「撮影した動画データは、一時的に制御部のバッファに書き込まれる。」
   引用: 「Ta秒間の撮影が終わるとバッファの動画データはサーバに送信される。」
   ── 本来は“書き込み→完了後に読み出し”という順序です。
2. 動体を再検知した場合の特別手順
   引用: 「撮影中に新たに動体を検知すると、バッファにあるその時点までの動画データをサーバに送信し始めると同時に、更にTa秒間撮影を行う。」
   ── “送信（読込み）”と“追加撮影（書込み）”が同時並行で発生します。
3. 書き込み位置の仕様
   引用: 「このとき、動画データはバッファの先頭から書き込まれる。」
   ── 送信がまだ終わっていない先頭領域へ、追加撮影データを書き始めることを意味します。
4. 不具合報告の状況
   引用: 「自動撮影中に動体を検知したときに発生しており、バッファの使い方に問題があることが判明した。」
   ── 上記の同時アクセスが原因で、未送信データが上書きされ“異常な動画データ”となったと推定できます。
5. したがって解答
   「書込みと読込みが同時に行われ、バッファの先頭のデータが上書きされた。」

誤りやすいポイント

• 「バッファの先頭から書き込まれる」を“空き領域のみ利用”と誤読しやすい。実際は先頭強制リセットなので転送中データと衝突する。
• “遠隔撮影”と“自動撮影”の挙動を混同し、遠隔撮影では問題が起きない理由（読込み先がスマホで同時書込みがない）を見落とす。
• 不具合を通信障害と結び付ける誤解。引用: 「通信及びハードウェアには問題がなかった。」と明示されている。

FAQ

解答の論理構成

1. 問題文には、従来方式でバッファの「先頭から書き込む」仕様が示されています。
   引用：
   「撮影した動画データは、一時的に制御部のバッファに書き込まれる。このとき、動画データはバッファの先頭から書き込まれる。」
2. 不具合の原因として「撮影中に新たに動体を検知」するとバッファ運用が乱れると記述されています。
   引用：
   「この不具合は、自動撮影中に動体を検知したときに発生しており、バッファの使い方に問題があることが判明した。」
3. 対策として、バッファの残り領域を使い切ったら先頭に戻る“循環”方式へ変更すると明言されています。
   引用：
   「撮影中に新たに動体を検知した時点で、書き込まれているバッファの続きから動画データを書き込み、バッファの d まで書き込んだ場合は、バッファの e に戻る方式」
4. 循環的に最後まで書き込む位置はバッファの「終端」、戻る位置は「始端」と表現するのが自然です。これにより先頭／末尾間でポインタを折り返すリングバッファが実現できます。
5. 以上より、
   d＝「終端」、e＝「始端」と決定できます。

誤りやすいポイント

• 先頭・末尾という語をそのまま当てはめたくなるが、問題文は“戻る”対象を「バッファの e に戻る」としているため、循環開始点を示す一般語「始端」を用いる方が適切です。
• 「終端」を「最後」や「末端」と誤記すると配点対象外になる可能性があります。設問は字句を問うため語形の統一が重要です。
• 不具合の原因を通信障害と結び付けてしまうミス。問題文は「通信及びハードウェアには問題がなかった。」と明示し、論点をバッファ管理に限定しています。

FAQ

解答の導き方

1. 問題の目的を確認する
   設問は本文中の f に入るバッファの名称を問うものです。本文の変更前後の記述を比べることで、どのような動作をするバッファかを特定します。
2. 不具合の原因となっていた元の動作を確認する（根拠となる本文の抜粋を文中に組み込む）
   本文には「撮影した動画データは、一時的に制御部のバッファに書き込まれる。このとき、動画データはバッファの先頭から書き込まれる。」とあり、さらに「撮影中に新たに動体を検知すると、バッファにあるその時点までの動画データをサーバに送信し始めると同時に、更にTa秒間撮影を行う。このとき、動画データはバッファの先頭から書き込まれる。」とあります。
   この記述から、動体検知が重なったときに毎回「バッファの先頭から書き始める」動作があるため、既にサーバへ送信中のデータ領域を上書きしてしまい、サーバ側に異常な（壊れた）動画データが届く可能性があることが読み取れます。これが不具合の発生原因です。
3. 変更後の動作記述を解析する（重要箇所を引用して解釈）
   問題文の変更後は「書き込まれているバッファの続きから動画データを書き込み、バッファの d まで書き込んだ場合は、バッファの e に戻る方式」と説明されています。ここを分解すると次の点が分かります。

• 「書き込まれているバッファの続きから書き込み」：書き込み位置を保持してそこから追記する（書き込みポインタが進む）ことを意味する。
• 「d まで書き込んだ場合は、e に戻る」：バッファの末端に達したら先頭に戻って書き込みを続ける、すなわち書き込みが末端で折り返す（wrap-around）ことを意味する。

1. 上の動作説明と一般的なバッファ構造を照合する
   上記の「追記して、末端で先頭に戻る」振る舞いは、代表的なバッファ構造であるリングバッファ（別名：循環バッファ、circular buffer）の定義と一致します。リングバッファは書き込みポインタと読み出しポインタ（ヘッド／テール）を持ち、ポインタがバッファ末端に到達したら先頭に戻ることで連続的にデータを扱います。
2. 結論
   よって、本文の記述に合致する名称は リングバッファ です。

誤りやすいポイント

• 「リングバッファ＝絶対に上書きしない」と誤解する点
  リングバッファは末端到達で先頭に戻る構造を指しますが、読み出し（送信）が遅れている場合に書き込みが読み出し位置に追いつくと上書きが発生します。上書きの有無・扱いは実装方針（上書き許可、書き込み待ち、古いデータ破棄など）によって異なるため、問題文にある「戻る方式」からは単に構造がリングであることしか判断できません。
• 「先頭から書き始める／続きから書き始める」の表現を取り違える点
  元の不具合の記述での「先頭から書き込まれる」は、再検知のたびに書き込み位置をリセットしていることを示し、これが原因である点を押さえないと誤答につながります。
• 別のバッファ名（例えば二重バッファ、FIFOキュー、スタック）を答えてしまう点
  末端到達で先頭に戻る「wrap-around」動作が明示されているため、リングバッファ以外の用語は適合しません。

FAQ