応用情報技術者 2017年 春期 午後 問07
スマートウォッチに関する次の記述を読んで、設問1〜3に答えよ。
G社は、腕時計型のスマートウォッチ(以下、ウォッチという)を開発している。ウォッチは、スマートフォン(以下、フォンという)と連携して、電子メール(以下、メールという)の内容表示などを行う。ウォッチとフォンから成るシステムの構成を図1に示す。ウォッチは、フォンを経由してインターネットに接続できる。


〔ウォッチの構成〕
ウォッチは、MPU及び日付時刻用タイマを内蔵しており、マイク、通信部、画面表示部及び音声入力スイッチを備えている。画面表示部には、タッチパネルが付随している。
〔ウォッチの機能〕
ウォッチは、タッチパネルへのタッチとマイクへの音声入力によって、機能を切り替えることができる。ウォッチの機能を表1に示す。


〔ウォッチの動作仕様〕
ウォッチは、利用者の操作及びフォンからの通信によって、次のとおり動作する。
・電源が投入されると、時計機能を実行する。
・フォンから時刻表示指示、メール受信通知、電話着信通知又は天気予報表示指示を受信すると、対応する表1中の機能を実行する。
・タッチパネルへのタッチを認識すると、機能選択画面を表示する。機能選択画面では、“時計” 及び “天気予報” の二つのボタンが表示される。ボタンへのタッチを認識すると、対応する表1中の機能を実行する。
・機能選択画面では、ボタン以外の部分へのタッチは無効である。
・利用者が音声入力スイッチを押すと、フォンに対して音声受付開始通知を送信し、利用者が音声入力スイッチを押し続けている間は、音声受付状態となる。音声受付状態では、音声受付画面を表示し、マイクが感知した音声を、フォンに送信する。利用者が音声入力スイッチを離すと、音声受付状態は解除される。
・音声受付状態では、タッチパネルへのタッチは無効である。
・音声受付状態で、フォンから各種通知又は指示を受信した場合は、音声受付状態は解除され、受信した通知又は指示に対応する、表1中の機能を実行する。この連の処理の間、利用者が音声入力スイッチを離さずに押し続けていたとしても、音声受付状態は解除されたままである。再びウォッチを音声受付状態にするには、利用者は、一度、音声入力スイッチを離して、再度、押す必要がある。
〔フォンにおける音声処理〕
フォンは、ウォッチから音声受付開始通知を受信すると、音声処理アプリケーションを起動して、ウォッチからの音声情報の受信を待つ。
ウォッチから音声情報を受信すると、音声処理アプリケーションは、受信した音声情報を解析する。解析の結果、“時計” という音声を認識した場合には、ウォッチに時刻表示指示を送信する。“天気” という音声を認識した場合には、ウォッチに天気予報表示指示を送信する。いずれの音声も認識できなかった場合には何もしない。
〔ウォッチのソフトウェア構成〕
ウォッチは、イベントドリブンプリエンプション方式のリアルタイム OS を使用する。ウォッチのタスク構造を図2に、ウォッチのタスク一覧を表2に、ウォッチの割込みハンドラ一覧を表3に、それぞれ示す。



設問1:
利用者が、ウォッチに対して“天気”と発声したのに、天気予報機能が実行されなかった。実行されなかった原因として当てはまらないものを、解答群の中から選び、記号で答えよ。
解答群
ア:ウォッチが、音声を正しく取得できなかった。
イ:ウォッチとフォンとの間の通信に失敗した。
ウ:音声入力スイッチが押されていなかった。
エ:音声入力の途中で、利用者がウォッチのタッチパネルにタッチした。
模範解答
エ
解説
解答の論理構成
-
音声による天気予報起動の一連の流れ
・ウォッチ側で音声を取得し、フォンへ送信する――【問題文】「利用者が音声入力スイッチを押すと、フォンに対して音声受付開始通知を送信し、…マイクが感知した音声を、フォンに送信する。」
・フォン側が音声を解析し、“天気”を認識すると命令を返送する――【問題文】「解析の結果、“天気” という音声を認識した場合には、ウォッチに天気予報表示指示を送信する。」
・ウォッチがその指示を受け取り、天気予報機能を実行する――【問題文】「フォンから…天気予報表示指示を受信すると、対応する表1中の機能を実行する。」 -
各選択肢の成立可否
ア:ウォッチが音声を取得できなければ、上記①の最初で止まり機能は動かない。成立。
イ:ウォッチ―フォン間通信が失敗すれば、音声も指示も届かず機能は動かない。成立。
ウ:音声入力スイッチが押されていなければ、そもそも音声受付状態にならず機能は動かない。成立。
エ:音声受付状態中のタッチは無視される――【問題文】「音声受付状態では、タッチパネルへのタッチは無効である。」
よってタッチ操作が原因で天気予報機能が阻害されることはない。成立しない。 -
よって、実行されなかった原因として当てはまらないものは「エ」と判断できる。
誤りやすいポイント
- 「タッチが無効=何も起こらない」ことを「処理が中断される」と誤解しがち。
- タスク図や割込みの“マスク”という語に惑わされ、タッチ操作が音声処理を強制終了すると勘違いするケース。
- 音声処理は“フォン側”で認識される点を見落とし、ウォッチ内だけで完結すると想定してしまうミス。
FAQ
Q: タッチ操作割込みがマスクされるのに、なぜタッチが原因にならないのですか?
A: マスクはタッチ割込みを“発生させない”だけで、既に音声受付状態に入っている処理を中断するものではありません。タッチイベント自体が無効化されて終わりです。
A: マスクはタッチ割込みを“発生させない”だけで、既に音声受付状態に入っている処理を中断するものではありません。タッチイベント自体が無効化されて終わりです。
Q: 音声入力スイッチを離さずにタッチした場合でもタッチは無視されますか?
A: はい。【問題文】「音声受付状態では、タッチパネルへのタッチは無効である。」と明記されています。
A: はい。【問題文】「音声受付状態では、タッチパネルへのタッチは無効である。」と明記されています。
Q: “音声を正しく取得できなかった”とは具体的にどの場面を指しますか?
A: マイク故障、環境ノイズ、サンプリング処理失敗などでウォッチ自身が音声データを生成できなかった場面です。
A: マイク故障、環境ノイズ、サンプリング処理失敗などでウォッチ自身が音声データを生成できなかった場面です。
関連キーワード: 音声認識, 近距離無線通信, リアルタイムOS, 割込みマスク
設問2:
音声入力タスクが音声情報に書き込むデータの、1秒間のデータサイズは何kバイトになるか。答えは小数第1位を切り上げて、整数で答えよ。ここで、1kバイト=1,000バイトとする。
模範解答
16
解説
解答の論理構成
-
音声ストリーム 1 サンプル当たりのデータ量
表2の音声入力タスクの説明に「量子化ビット数16ビット」とあります。
16 ビット = 2 バイトです。 -
1 秒間に取得するサンプル数
同じく表2に「サンプリング周波数8kHz」とあるので、
8 kHz = 8,000 サンプル/秒となります。 -
1 秒間の総バイト数
8,000 サンプル × 2 バイト = 16,000 バイト/秒 -
k バイト換算と端数処理
問題文に「1kバイト=1,000バイト」と明示されています。
16,000 バイト ÷ 1,000 = 16.0 kバイト
切り上げ指定ですが既に整数なので 16 kバイト。 -
よって解答は
16
誤りやすいポイント
- 「16ビット」を 16 バイトと勘違いして 8 倍の誤差を出す。
- 1 kB を 1,024 バイトで計算してしまい 15.6→16 との違いに戸惑う。
- 8 kHz を 8,192(=8×1,024)と読み替えるなど、k の扱いを誤る。
- 切り上げを意識せず 15 や 15.6 と回答して減点される。
FAQ
Q: 「8kHz」は 8,000 か 8,192 か、どちらで計算すべきですか?
A: 問題文では 1k バイト=1,000 バイトと定めており、k を 1,000 と扱う文脈です。したがって 8kHz も 8,000 サンプルとして扱います。
A: 問題文では 1k バイト=1,000 バイトと定めており、k を 1,000 と扱う文脈です。したがって 8kHz も 8,000 サンプルとして扱います。
Q: 量子化ビット数 16 ビットをそのまま 16 として計算してはいけませんか?
A: 1 バイト=8 ビットなので、16 ビット=2 バイトへ換算する必要があります。そのまま 16 を掛けると 8 倍の誤差が生じます。
A: 1 バイト=8 ビットなので、16 ビット=2 バイトへ換算する必要があります。そのまま 16 を掛けると 8 倍の誤差が生じます。
Q: 既に 16.0 kB ですが「小数第1位を切り上げ」は無視してよいですか?
A: 切り上げ指示は必ず確認します。今回は 16.0 kB で端数がないため、切り上げても 16 kB となります。
A: 切り上げ指示は必ず確認します。今回は 16.0 kB で端数がないため、切り上げても 16 kB となります。
関連キーワード: サンプリング周波数, 量子化ビット数, PCM音声, データ量計算, バイト換算
設問3:ウォッチのソフトウェアについて、(1)〜(3)に答えよ。
(1)図2中の a 〜 d に入れる適切なタスク名を答えよ。
模範解答
a:画面入力
b:画面表示
c:音声入力
d:画面作成
解説
解答の論理構成
- 【問題文】では、ウォッチのタスク構造を示す図2と、対応するタスクの機能を列挙した【表2 ウォッチのタスク一覧】が与えられています。
- 【表2】に記載されたタスク名と処理概要を抜粋します。
- “画面入力”:タッチを認識した箇所の座標情報を、メインタスクに通知する。
- “画面表示”:画面情報の内容を基に、画面の更新を行う。
- “音声入力”:割込みハンドラから起床されると、音声入力開始通知をメインタスクに通知し、音声情報書込処理を開始する。
- “画面作成”:メインタスクから受けた情報を基に、表示画面を作成し、画面情報に書き込む。
- 図2では、a 〜 d の各タスクと “メイン” が実線矢印(メッセージ通信)や破線矢印(共有メモリ)で結ばれています。
- a から “メイン” への実線矢印は「座標情報」を送る流れであるため、座標を通知する “画面入力” が該当します。
- “メイン” から右上の b へ実線矢印、さらに d から b へ破線矢印〈画面情報〉があることから、画面情報を受け取って実際に表示を行う “画面表示” が b となります。
- 左下の c から “メイン” へ実線矢印、さらに c から “通信” へ破線矢印〈音声情報〉が示され、これは音声情報をメモリに書き込む “音声入力” の動作と一致するため、c が “音声入力” です。
- 右下の d は、d から “メイン” へ実線矢印で画面作成完了を知らせ、同時に〈画面情報〉を書き込むタスクなので “画面作成” が入ります。
- 以上より解答は
a:画面入力
b:画面表示
c:音声入力
d:画面作成
誤りやすいポイント
- “画面表示” と “画面作成” を逆にしてしまう
“画面作成” はメモリに〈画面情報〉を書き込むタスクであり、実際の描画命令を出すのは “画面表示” である点を混同しやすいです。 - a を “タッチ操作” 割込みハンドラと誤解する
図2に示されているのはタスク間通信の構造であり、割込みハンドラそのものではありません。タッチ割込み後に起床される “画面入力” が正解です。 - “音声入力” と “通信” を取り違える
音声情報をメモリに書き込む役割は “音声入力” であり、外部送信をまとめて管理するのは “通信” です。図中に破線〈音声情報〉があることで区別できます。
FAQ
Q: “画面作成” と “画面表示” の役割分担はなぜ必要ですか?
A: “画面作成” はバックグラウンドで画面バッファを生成し、ユーザへの表示タイミングを “画面表示” に一任することで、描画中断やちらつきを防ぐダブルバッファリング的な分担を実現しています。
A: “画面作成” はバックグラウンドで画面バッファを生成し、ユーザへの表示タイミングを “画面表示” に一任することで、描画中断やちらつきを防ぐダブルバッファリング的な分担を実現しています。
Q: 音声入力中にタッチ操作は無効とありますが、タッチ割込み自体は発生しますか?
A: 【問題文】に “音声受付状態では、タッチパネルへのタッチは無効である。” とある通り、割込みレベルで “タッチ操作割込みをマスク” しているため、タッチ割込みハンドラは起動しません。
A: 【問題文】に “音声受付状態では、タッチパネルへのタッチは無効である。” とある通り、割込みレベルで “タッチ操作割込みをマスク” しているため、タッチ割込みハンドラは起動しません。
Q: “通信” タスクは図2でどことメッセージ通信しますか?
A: 実線矢印で “メイン” と双方向通信します。メインからは音声情報送信開始/終了指示などを受け取り、逆に受信データをメインへ通知します。
A: 実線矢印で “メイン” と双方向通信します。メインからは音声情報送信開始/終了指示などを受け取り、逆に受信データをメインへ通知します。
関連キーワード: タスク間通信, 割込みマスク, イベントドリブンOS, 音声サンプリング, ダブルバッファリング
設問3:ウォッチのソフトウェアについて、(1)〜(3)に答えよ。
(2)割込みマスクに関する次の記述中の e、f に入れる適切な字句を答えよ。
割込みハンドラとメインタスクは、どちらもタッチ操作割込みのマスクを操作している。これは、例えば、ウォッチがフォンからメール受信通知を受信した直後に、利用者がウォッチのタッチパネルにタッチした場合の不都合を避けるためである。その不都合とは、e を表示した後、利用者が表示された e を確認する前に、画面が f に切り替わってしまうことである。
模範解答
e:メールの内容
f:機能選択画面
解説
解答の論理構成
-
メール受信直後のウォッチの動作を確認
- 【問題文】に「フォンから時刻表示指示、メール受信通知、電話着信通知又は天気予報表示指示を受信すると、対応する表1中の機能を実行する。」とあります。
- 表1の「メール表示」には「フォンが受信したメールの内容を表示する。」と明記されています。
よって、メール受信通知を受けた直後にウォッチが表示するのは “メールの内容” です。
-
タッチ操作時の画面遷移を確認
- 【問題文】に「タッチパネルへのタッチを認識すると、機能選択画面を表示する。」とあります。
したがって、利用者がタッチすると表示は “機能選択画面” に切り替わります。
- 【問題文】に「タッチパネルへのタッチを認識すると、機能選択画面を表示する。」とあります。
-
不都合が起こる場面を整理
- 割込みハンドラとメインタスクがタッチ操作割込みをマスクしていなければ、
①メール受信通知 → “メールの内容” 表示
②表示直後にタッチ割込み → “機能選択画面” 表示
という順になり、利用者がメールを読む前に画面が切り替わってしまいます。 - 記述の空欄 [ e ] と [ f ] にはそれぞれこの ① と ② に該当する表示名を入れるのが自然です。
- 割込みハンドラとメインタスクがタッチ操作割込みをマスクしていなければ、
-
よって
- [ e ] には「メールの内容」
- [ f ] には「機能選択画面」
が入ると論理が一貫します。
誤りやすいポイント
- 「メール表示画面」などと書きたくなりますが、表1の文言「メールの内容」をそのまま引用する必要があります。
- [ f ] に「時計」や「天気予報」と誤って入れる例が多いですが、タッチ後に必ず出るのは「機能選択画面」です。
- 割込みマスク=タスクの排他制御とだけ考え、画面遷移の目的を見落とすと設定ミスになります。
FAQ
Q: 「メールの件名」「メール表示画面」ではダメですか?
A: 表1にある正式な機能説明が「メールの内容」であり、問題文はその表現を求めています。
A: 表1にある正式な機能説明が「メールの内容」であり、問題文はその表現を求めています。
Q: タッチ割込みをマスクするのは誰がいつ解除しますか?
A: メインタスクが「適切なタイミングで、タッチ操作割込のマスクを解外する」と明示されています。
A: メインタスクが「適切なタイミングで、タッチ操作割込のマスクを解外する」と明示されています。
Q: 音声受付状態中のタッチはどう扱われますか?
A: 【問題文】に「音声受付状態では、タッチパネルへのタッチは無効である。」とあり、割込み自体が無効化されます。
A: 【問題文】に「音声受付状態では、タッチパネルへのタッチは無効である。」とあり、割込み自体が無効化されます。
関連キーワード: 割込みマスク, イベントドリブン, リアルタイムOS, 画面遷移, タッチパネル
設問3:ウォッチのソフトウェアについて、(1)〜(3)に答えよ。
(3)タスクの動作に関する次の記述中の g に入れる適切な字句を答えよ。また、次の記述中の、“意図しない現象”とはどのような現象か、15字以内で述べよ。
画面表示タスクが画面の更新を行っているときに、画面作成タスクが動作を開始すると、意図しない現象が発生した。この問題を解決するために、画面表示タスクが画面の更新を行っているときに、画面作成タスクが動作を開始しないように、それぞれのタスクの g を、適切に設定した。
模範解答
g:優先度
現象:複数画面が混在表示される。
解説
解答の論理構成
- 【問題文】には、画面表示タスクについて
“画面情報の内容を基に、画面の更新を行う。”
とあり、画面作成タスクについて
“表示画面を作成し、画面情報に書き込む。”
と記載されています。両タスクは同じ“画面情報”に対して書込み/読出しを行うため、同時実行すると競合が発生します。 - さらに、ウォッチは“イベントドリブンプリエンプション方式のリアルタイム OS”を採用しており、タスクは優先度順にプリエンプト(割込み実行)されます。
- したがって、画面表示タスクが実行中に画面作成タスクが起床されると、OSがプリエンプトを許可すれば両タスクが交互に実行される可能性があります。このとき“画面情報”の内容が途中で書き換わり、結果として
“複数画面が混在表示される。”
という意図しない現象が生じます。 - 解決策として、同 OS のスケジューリング要素である“優先度”を調整し、画面表示タスク実行中はそれより低い優先度の画面作成タスクがスケジューリング対象にならないようにします。
- よって g に入る語は“優先度”となり、意図しない現象は“複数画面が混在表示される。”が適切です。
誤りやすいポイント
- イベントドリブン=排他制御不要と誤解し、優先度以外の同期手段(セマフォなど)を回答してしまう。
- “複数画面が混在表示される。”を「画面が更新されない」「画面がフリーズする」などと抽象化し過ぎてしまう。
- 画面作成タスクに高い優先度を設定すると誤って記述し、かえって競合を助長する回答を選択してしまう。
FAQ
Q: 優先度の調整以外に対策はありますか?
A: 排他制御用のミューテックスやセマフォで“画面情報”への同時アクセスを防ぐ方法もあります。ただし本問題はリアルタイム OS のプリエンプション特性と優先度設定に着目させる内容です。
A: 排他制御用のミューテックスやセマフォで“画面情報”への同時アクセスを防ぐ方法もあります。ただし本問題はリアルタイム OS のプリエンプション特性と優先度設定に着目させる内容です。
Q: なぜ画面表示タスクの方を高い優先度にすべきなのですか?
A: 画面表示処理は利用者へのレスポンスに直結するため即時性が要求されます。表示が終わってから次の画面を作成しても体感遅延が小さいため、高優先度を与えるのが合理的です。
A: 画面表示処理は利用者へのレスポンスに直結するため即時性が要求されます。表示が終わってから次の画面を作成しても体感遅延が小さいため、高優先度を与えるのが合理的です。
Q: “混在表示”はどのように確認できますか?
A: 画面の一部が旧画面、別の部分が新画面の内容を示すようなチラつきや欠けとして現れます。利用者から見ると一瞬“二重描画”のように見えるケースが典型です。
A: 画面の一部が旧画面、別の部分が新画面の内容を示すようなチラつきや欠けとして現れます。利用者から見ると一瞬“二重描画”のように見えるケースが典型です。
関連キーワード: リアルタイムOS, プリエンプション, タスク優先度, 競合状態, 画面描画


