応用情報技術者 2019年 秋期 午後 問07

解答の論理構成

1. 制御パターン全体に使える時間は【問題文】の「制御パターンは最大60ミリ秒で完了する。」という記述から $60\text{ ms}$ です。
2. 各状態（ON／OFF）が取り得る最短時間は同じく【問題文】の「ON状態及びOFF状態の最短時間はそれぞれ350マイクロ秒である。」から $350\text{ μs}$ です。
3. したがって、1つの状態が占める最短時間 $350\text{ μs}$ をできるだけ詰め込めば状態数を最大化できます。 $$\frac{60000\text{ μs}}{350\text{ μs}}=171.428\dots$$ 整数で数えられる状態数の上限は小数点以下を切り捨てた $171$ です。
4. よって、「ON状態の数」と「OFF状態の数」の合計の最大値は 171 となります。

誤りやすいポイント

• 60 ms を 60,000 μs に換算し忘れる。単位換算ミスは典型的失点要因です。
• 38～40 kHz という搬送波周波数から1周期（約25 μs）を使って計算してしまう。最短時間は「350マイクロ秒」であって搬送波周期ではありません。
• ON と OFF を“ペア”と決めつけて 2 で割ると 171÷2 のように誤算する。問われているのは合計個数です。

FAQ

解答の論理構成

• 問題文では、赤外線リモコンが使う光について「赤外線リモコンは、38～40kHzで点滅を繰り返す赤外光を使用する」と明記されています。
• 一方、赤外線センサには蛍光灯や太陽光などの外部光も入ります。この外部光は幅広い周波数成分を含むため、目的の 38～40kHz 成分だけを取り出す必要があります。
• 周波数が “ある狭い範囲” の信号成分を通過させ、それ以外を減衰させる回路は「バンドパスフィルタ」です。
• したがって、赤外線センサ後段で 38～40kHz 成分を抽出するフィルタは「バンドパスフィルタ」となり、解答群の「ウ」を選択します。

誤りやすいポイント

• 低周波成分を除去するだけと誤解して「イ：ハイパスフィルタ」を選んでしまう。ハイパスでは高周波側に上限がなく、目的帯域より高いノイズも通してしまいます。
• 「赤外線＝光だから周波数は高い」と連想し「エ：ローパスフィルタ」を排除できず迷うケース。光の“点滅周波数”としては音声帯域に近いためローパスでは信号が削ぎ落ちます。
• 光学系のイメージで「ア：UVフィルタ」を選ぶミス。ここで扱うのは電気的信号周波数であり、紫外線遮断フィルタとは目的が異なります。

FAQ

解答の論理構成

1. 初期化直後にセットされるタイマ
   図3 の処理 2 行目は【問題文】引用
   「setTimer(5000)」
   すなわちプログラム開始時に “5,000 ms” のタイマイベントが予約されます。
2. 他のイベントは発生しない前提
   設問条件は【問題文】引用
   「学習対象リモコンで何も操作が行われないとき」
   よって “ONイベント” “OFFイベント” は一切キューへ入りません。
3. イベント待ちの動き
   ① 5 行目で waitEvent() へ遷移
   ② 38～40 kHz の赤外光が来ないので待機を継続
   ③ 5,000 ms 経過時にタイマイベントが発生し、これが最初に取得するイベントになります。
4. タイマイベントを受けた後の分岐
   6 行目の判定は
   「イベント ＝ c ？」
   初回イベントがタイマイベントなので “No” に進み、処理 12 に到達します。
5. プログラム終了までの時間
   イベント待ち以外の時間は無視できるとの前提（【問題文】「イベント待ち以外の処理時間は無視できるものとし」）より、 開始からタイマイベント受信までの “5,000 ms” が実質的な動作時間です。
6. 単位換算
   $5,000\text{ms}=5\text{s}$

誤りやすいポイント

• 5000 ms と 60 ms のタイマを混同する
  5,000 ms のタイマは“最初”に一度だけ設定され、60 ms タイマは ONイベント発生後にしか設定されません。
• 「startSensor()」に要する時間を考慮してしまう
  処理時間は無視できると明示されているので計算に入れません。
• キューが空でも waitEvent() が即時復帰すると誤解
  実装仕様はブロッキング待ち。イベントが来るまで戻りません。

FAQ

解答の論理構成

1. 【問題文】には「最初に通知されたイベントが OFF イベントのときは、変数 rst に False を設定する。」とあり、OFF から始まる入力は失敗扱いです。逆に言えば、正常な制御パターンは ON から始まると読み取れます。
2. 同じく【問題文】で「制御パターンの抽出が成功し…T[2×k]には、a状態の長さが、T[2×k+1] には、b状態の長さが格納される。」と指定されています。
3. 手順 6 の判定（図3）で待っている最初のイベントは後続の処理で ON／OFF のペアを取り込む流れになっています。したがって偶数添字（2×k）が“最初の ON から次の遷移まで”の時間、奇数添字（2×k+1）が“OFF から次の遷移まで”の時間になります。
4. 以上より、aには「ON」、bには「OFF」を入れるのが整合します。

誤りやすいポイント

• OFF イベントを先頭に読み取ってしまい、配列の偶数・奇数を逆に覚えるミス。
• “赤外線センサは ON→OFF, OFF→ON の遷移だけ通知する”という仕様を見落とし、同一状態が続くケースを想定してしまう。
• タイマ 60ms の終了条件に気を取られ、配列格納順が問われていることを見落とす。

FAQ

解答の論理構成

1. イベント分岐 c の考察
   • プログラム冒頭で startSensor() を呼び、続いて waitEvent() で最初のイベントを待ちます。
   • 本文に「“最初に通知されたイベントが OFF イベントのときは、変数 rst に False を設定する。”」とあります。つまり最初に欲しいのは ON 側のイベントです。
   • さらに赤外線センサの仕様として「“赤外線センサは、ON状態からOFF状態、又はOFF状態からON状態に遷移したことを制御部に通知する。”」と明記されています。
   • 以上より、フロー図 6 番目の判定では“ONイベント”を Yes 側に取ることで、OFF が最初に来た場合を自然にエラー扱い（No 側）にできます。
     ➜ c ＝ 「ONイベント」
2. 変数更新 d の考察
   • フロー 11-2 で TN ← 今回値 − 前回値 と長さを計算し終わった後、次ループでも差分計算を行うためには「今回値」を次回の“前回値”として保存しておく必要があります。
   • したがって 11-4 の代入は 前回値 ← 今回値 が妥当です。
     ➜ d ＝ 「今回値」
3. 整合性チェック
   • 最初に ON が来た場合だけ ON/OFF のペアが偶数個並び、ループ終了後の「N は奇数？」が True となり「rst ← True」。
   • 最初に OFF が来る、途中で信号が切れる、タイムアウトする場合はいずれも N が偶数となり rst ← False。
   • よって解答は論理的に矛盾しません。

誤りやすいポイント

• 「最初に ON が来る」と「最初が OFF なら失敗」の規則を見落として、c を“OFFイベント”と誤記するケース。
• 前回値 ← 今回値 の更新を忘れ、常に最初のカウンタとの差を取り続けてしまう実装ミス。
• 16 ビットカウンタが 65,535 でロールオーバーすることを踏まえ、11-3 の負値補正ロジックを軽視する失点。
• タイマ setTimer(60) が「60 ミリ秒」と読めず、“60 秒”と早合点してフロー全体を誤解するケース。

FAQ

解答の論理構成

1. プログラムは 前回値 ← getCount() と 今回値 ← getCount() の差を TN に代入しています。
   ⇒ 【問題文】「getCount() … カウンタのカウント値を32ビットの符号付き整数型の戻り値として返す。」
2. カウント値は上位16ビットが常に０の16ビットカウンタで、65,535 まで進むと次に 0 に戻ります。
   ⇒ 【問題文】「カウンタは16ビットで1マイクロ秒ごとにカウント値が1加算され、カウント値が65,535に達すると、次のカウントで0に戻る。」
3. したがって
   ・前回値＝65,535 近辺
   ・今回値＝0 近辺
   となると 今回値－前回値 は負の値になります。
4. フロー中の下線① TN < 0 判定は、まさにこの負値を検出するための処理です。
5. 以上より「カウント値が0に戻ったとき」という事象が解答となります。

誤りやすいポイント

• 差分計算をミリ秒単位と誤解し、赤外光が途切れた時間と混同する。
• getCount() が32ビットと記載されているため「32ビットならオーバーフローしない」と思い込む。実際には上位16ビットが常に 0。
• 「OFF→ON 切替え時のみ wrap-around が起きる」と誤認し、タイマイベントとの組合せを考慮し忘れる。

FAQ

解答の論理構成

1. カウンタの仕様把握
   • 【問題文】には「カウンタは16ビットで1マイクロ秒ごとにカウント値が1加算され、カウント値が65,535に達すると、次のカウントで0に戻る。」とある。
   • 16ビットなので 0〜65,535 の範囲で周回し、1周の幅は 65,535−0＋1＝65,536 である。
2. 差分計算と負値発生の理由
   • フロー 11-2 で「TN ← 今回値 − 前回値」を計算する。
   • ラップアラウンドが起きずに 今回値 > 前回値 なら正値になるが、ラップ後は 今回値 < 前回値 となり TN が負になる。
   • そこでフロー 11-3 で「TN < 0？」を判定し、負の場合に補正処理②へ遷移する。
3. 補正量の決定
   • 周期幅（1周分）は前述のとおり 65,536。
   • ラップ時の実際の経過時間は
     今回値 + (65,536 − 前回値)
     であり、計算式 今回値 − 前回値 に 65,536 を加えるとちょうどこの値になる。
   • よって TN へ加算すべき定数は 65,536。
4. 結論
   • ②の補正内容は「TN に 65,536 を加算する」である。
   • これにより TN は常に正の経過時間を保持し、後続処理が安定して動作する。

誤りやすいポイント

• 65,535 と 65,536 を取り違える
• unsigned と誤解し負値が出ないと思い込む
• ミリ秒とマイクロ秒を混同し補正値を 60 などにしてしまう
• ラップが複数回起きると誤解して 2×65,536 などを加算する

FAQ