応用情報技術者 2009年 秋期 午後 問07
ディジタルフォトフレームに関する次の記述を読んで、設問1~3に答えよ。
S社は、低価格のディジタルフォトフレームを開発することになった。このディジタルフォトフレームは、外部メディアに保存されている静止画像を表示するもので、マイコンを搭載しており、本体は画面、電源スイッチ、左キー、右キーなどで構成されている。
〔ディジタルフォトフレーム仕様〕
(1) 外部メディアから画像データを読み込み、デコードしてから表示データを画面に表示する。
(2) 画像の表示切替えにはタイマで起動する自動切替え及びキー操作による手動切替えの二つの方法を用いる。
・自動切替えでは、外部メディアのファイルパスの昇順で表示切替えを行う。表示データは5秒間画面に表示する。この間、次に表示する1画像分の画像データの読み込み及びデコード(以下、表示準備という)を行う。電源を入れると、自動切替えを開始する。
・手動切替えでは、左キー押下で現在表示中の画像の前の画像、右キー押下で次の画像に切替えを行う。画像を5秒間画面に表示して、キー入力がなければ、自動切替えを開始する。
(3) 次に表示すべき表示データを用意できない間は、砂時計画像が表示される。砂時計画像の表示データはあらかじめROMに格納してある。
〔ソフトウェア構成〕
ディジタルフォトフレームの割込みハンドラー一覧を表1、タスク一覧を表2に示す。タスクには優先度があり、値の小さい方の優先度が高い。


タスク間通信はイベントを使って行われる。各タスクにはイベントキューがあり、イベントの情報はいったんイベントキューに蓄積される。イベントキューには上限があり、上限を超えたイベントは破棄される。イベント一覧を表3に示す。

〔メインタスクの処理〕
メインタスクでは、次の処理を行う。
(1)表示データを所定の画面表示用メモリ領域に格納することで、画面に表示する。
メインタスクの処理時間は非常に短いので、メモリ領域に格納後、すぐに次の処理に移る。
(2)自動切替え及び手動切替えを制御する。自動切替え及び手動切替えの動作を表4に示す。

〔シーケンス〕
自動切り替えのシーケンスを図1に、手動切り替えのシーケンスを図2に示す。


〔ファイルサイズの検討〕
画像を5秒間表示している間に表示準備を完了させることができるファイルサイズの上限について討した。
読み込むファイルサイズをA(Mバイト)とすると、読込み時間はe秒で、デコード時間はf秒である。したがって、eとfの合計が5秒以内となるファイルサイズはgMバイト以下となる。
設問1:
図1、図2中のa〜dに入れる適切な字句を解答群の中から選び、記号で答えよ。
解答群
ア:イベントキューに蓄積
イ:イベントを破棄
ウ:画像データの読込み
エ:画面表示用メモリ領域に格納
カ:手動切替え
オ:自動切替え
キ:砂時計画像を表示
ク:タイマ(5秒間)をセット
ケ:タイマのセットを解除
コ:次の画像の表示準備
サ:表示データへのデコード
模範解答
a:キ
b:エ
c:ク
d:ケ
解説
解答の論理構成
-
a の判定
- 仕様(3)には「“次に表示すべき表示データを用意できない間は、砂時計画像が表示される。”」とあります。
- 図1で a はタイマイベント直後、まだ読込み・デコードが終わる前に実行される処理なので、ここで表示できるのは砂時計のみです。
- よって a = 「キ:砂時計画像を表示」。
-
d の判定
- 手動切替えの動作①は表4に「“キーイベント受信後、タイマのセットを解除する。”」と明示されています。
- 図2で d はキーイベント直後に行う処理であり、この内容と一致します。
- よって d = 「ケ:タイマのセットを解除」。
-
b の判定
- 表4の自動切替え②に「“デコード後の表示データを画面表示用メモリ領域に格納後、タイマ(5秒間)をセットする。”」とあります。
- 図1・図2ともにデコード完了イベントの直後に b が置かれているため、ここは表示データを画面に送る処理です。
- よって b = 「エ:画面表示用メモリ領域に格納」。
-
c の判定
- 前述の表4自動切替え②後半に続く処理は「タイマ(5秒間)をセットする」です。
- 図1では b の直下、図2でも同じ位置に c があり、表示データを格納した直後に実行される処理であることが読み取れます。
- よって c = 「ク:タイマ(5秒間)をセット」。
以上より、解答は
a:キ、b:エ、c:ク、d:ケ になります。
a:キ、b:エ、c:ク、d:ケ になります。
誤りやすいポイント
- 砂時計と画像格納のタイミングを混同する
「表示データがなければ砂時計を表示」という一文を読み落とし、a を「ウ:画像データの読込み」と誤答するケースが多いです。 - タイマ関連の2つの操作を区別できない
「タイマのセットを解除」と「タイマ(5秒間)をセット」は正反対の動作です。手動切替え①と自動切替え②を対比しないと d・c を取り違えます。 - 表4を図と照合しない
表だけで判断すると b と c の順序を逆に解釈しやすいため、シーケンス図の矢印位置を必ず確認しましょう。
FAQ
Q: 砂時計表示はどのタスクが行いますか?
A: 「メインタスク」が画面表示用メモリ領域に砂時計の表示データを格納することで行います。割込みハンドラや他タスクではありません。
A: 「メインタスク」が画面表示用メモリ領域に砂時計の表示データを格納することで行います。割込みハンドラや他タスクではありません。
Q: 手動切替え後、自動切替えに戻る条件は?
A: 表4より「画像を5秒間画面に表示して、キー入力がなければ、自動切替えを開始する。」ため、タイマイベントが発生すると再び自動切替えフローへ遷移します。
A: 表4より「画像を5秒間画面に表示して、キー入力がなければ、自動切替えを開始する。」ため、タイマイベントが発生すると再び自動切替えフローへ遷移します。
Q: イベントキューが満杯になった場合の動作は?
A: 問題文には「上限を超えたイベントは破棄される。」と明記されており、古いイベントが保持されるわけではありません。
A: 問題文には「上限を超えたイベントは破棄される。」と明記されており、古いイベントが保持されるわけではありません。
関連キーワード: RTOS, タスク間通信、割込み処理、シーケンス図、タイマ制御
設問2:
右キーを連続押下したとき、押下回数の分の画像が表示されない現象が発生した。この原因を20字以内で述べよ。なお、動作中は外部メディアを抜き出せない。
模範解答
読込み要求イベントが破棄されたから
解説
解答の論理構成
-
連続して右キーを押すと、割込みハンドラからメインタスクへ【問題文】の「キーイベント」が次々に送られます。
引用:
・「左キー又は右キーを押下するごとに実行され、キーイベントを送信する。」
・「キー割込みハンドラからメインタスクに送信する。」 -
メインタスクは手動切替え動作に従い、キーイベントを受信するたびに「画像データの読込み及びデコードを行う」ため、ファイルタスクに「読込み要求」を発行します。
引用:
・表4 手動切替え「②画面に表示する画像データの読込み及びデコードを行う。」
・イベント一覧「メインタスクからファイルタスクに送信する。」(読込み要求) -
しかしファイルタスクは「読み込み速度は2Mバイト/秒である」と記載されており、実際のディスク I/O には時間がかかるため、メインタスクが発行する「読込み要求」の処理が追いつきません。
-
その結果、ファイルタスクのキューが満杯になります。イベントキューについて【問題文】は「イベントキューには上限があり、上限を超えたイベントは破棄される。」と明記しています。
-
キューが満杯の状態でさらに右キーを押すと、新たに発行された「読込み要求イベント」がキューへ入らず破棄されます。破棄された要求に対応する画像データは読み込まれず、結果として「押下回数の分の画像が表示されない」現象が起こります。
-
よって原因は「読込み要求イベントが破棄されたから」です。
誤りやすいポイント
- 「キーイベント」が破棄されていると誤解する
実際にあふれるのはメインタスク→ファイルタスクの「読込み要求」です。 - 外部メディア抜き取りによるエラーと勘違いする
問題文には「動作中は外部メディアを抜き出せない」と明記されており無関係です。 - 読込み速度やデコード速度ばかりに注目し、イベントキュー制限を見落とす
キューサイズが最終的なボトルネックになります。
FAQ
Q: 右キーをゆっくり押した場合は正常に切替わるのですか?
A: はい。ファイルタスクが読込みを終えるまでに次の「読込み要求」が届かないため、キューがあふれず破棄も起きません。
A: はい。ファイルタスクが読込みを終えるまでに次の「読込み要求」が届かないため、キューがあふれず破棄も起きません。
Q: キューサイズを大きくすれば問題は解消しますか?
A: ある程度は緩和できますが、極端に速い連打では再び上限に達します。根本的にはタスク間フロー制御や二重バッファなどの対策が必要です。
A: ある程度は緩和できますが、極端に速い連打では再び上限に達します。根本的にはタスク間フロー制御や二重バッファなどの対策が必要です。
Q: なぜ「デコード要求イベント」は破棄されにくいのですか?
A: 「デコード要求」はファイルタスクの処理完了後に1:1で発行されるため、ファイルタスクが詰まっている間は新しく発生しません。そのため主に「読込み要求」が集中します。
A: 「デコード要求」はファイルタスクの処理完了後に1:1で発行されるため、ファイルタスクが詰まっている間は新しく発生しません。そのため主に「読込み要求」が集中します。
関連キーワード: イベントキュー、割込みハンドラ、ノンブロッキングI/O, ボトルネック、バックプレッシャー
設問3:
本文中のe、fに入れる適切な数式、及びgに入れる適切な数値を答えよ。数値は小数第2位以下を切り捨てて小数第1位まで求めよ。
模範解答
e:A/2
f:20A/1000
g:9.6
解説
解答の論理構成
-
読込み時間を計算
- 表2で外部メディア読込みを担当するファイルタスクについて、問題文には
「・読み込み速度は2Mバイト/秒である。」
とあります。ファイルサイズを [Mバイト] とすると、読込み時間 は したがって e には「」。
- 表2で外部メディア読込みを担当するファイルタスクについて、問題文には
-
デコード時間を計算
- 同じく表2でデコードタスクの性能として
「・1Mバイト当たりのデコード時間は20ミリ秒である。」
と示されています。ファイルサイズを [Mバイト] とすると、デコード時間 は よって f には「」。
- 同じく表2でデコードタスクの性能として
-
5 秒以内に終わる条件を立式
- 仕様では「画像を5秒間表示している間に表示準備を完了させることができるファイルサイズの上限」とあります。
- 準備時間は
- これが 5 秒以内に収まる条件は
-
上限ファイルサイズ を求める
-
小数第2位以下を切り捨てて小数第1位まで求めるという指示より、A = 9.6 Mバイトしたがって g は「9.6」。
-
誤りやすいポイント
- 「20ミリ秒」を秒へ換算し忘れ、 秒としてしまう。
- 5 秒以内の条件を「<」だけで書き、等号を認めない形にして立式ミス。
- 切り捨て指示を見落として 9.7 Mバイトや 9.62 Mバイトなどと解答。
- 読込み速度「2Mバイト/秒」を逆数にせず としてしまう。
FAQ
Q: 2Mバイト/秒はビット換算が必要ですか?
A: 本問はバイト単位で統一されているため、ビット換算は不要です。速度をそのまま で扱います。
A: 本問はバイト単位で統一されているため、ビット換算は不要です。速度をそのまま で扱います。
Q: 20ミリ秒のままでも不等式を解けるのでは?
A: ミリ秒のままでも解けますが、読込み時間を秒で表したので単位を合わせるために秒換算が必要です。単位混在のままだと計算ミスの温床になります。
A: ミリ秒のままでも解けますが、読込み時間を秒で表したので単位を合わせるために秒換算が必要です。単位混在のままだと計算ミスの温床になります。
Q: 9.6Mバイトきっかりのファイルは確実に 5 秒で終わりますか?
A: 理論上は 5 秒ぴったりになる境界値です。実装上のオーバーヘッドを考慮すると余裕を持たせるのが実務的です。
A: 理論上は 5 秒ぴったりになる境界値です。実装上のオーバーヘッドを考慮すると余裕を持たせるのが実務的です。
関連キーワード: スループット、タイミング制約、不等式、ミリ秒換算


