応用情報技術者 2014年 秋期 午後 問07
DVDレコーダ、ブルーレイディスクレコーダ用のリモートコントロールボックスの設計に関する次の記述を読んで、設問1~3に答えよ。
U社は、タブレット、スマートフォン、PCなど(以下、端末という)から、家庭内の無線LAN(以下、無線LANという)を介してDVDレコーダ、ブルーレイディスクレコーダ(以下、これらを総称してレコーダという)を制御できるリモートコントロールボックス(以下、ボックスという)を設計した。
〔システムの構成〕
端末からボックスを介して、レコーダの番組録画予約と、録画された番組(以下、録画番組という)の視聴を行うことができる。端末とボックスはアクセスポイントを経由して無線LANで接続し、ボックスとレコーダは専用のケーブルで接続する。システムの構成を図1に示す。

〔レコーダの機能〕
レコーダは、ボックスからのコマンドで番組録画予約を行い、録画番組を視聴の際には、録画番組の映像と音声のデータ(以下、録画データという)をボックスに送る。
〔端末及びボックスの機能〕
端末には、専用のアプリケーションシステム(以下、アプリという)をインストールしてある。このアプリはボックスと通信を行い、ボックスを介して、レコーダの番組録画予約と、録画番組の視聴を行うことができる。ただし、レコーダが出力する録画データは端末に保存できないようにしている。また、ボックスのタスクの制約から、同時に視聴できる端末は1台だけである。
録画データは、ボックスで端末用のデータに変換されて端末に送られる。また、端末とボックス間の通信は全て暗号化されている。
ボックスは無線LAN 用にデータを送るために十分に大きな無線LAN 用のバッファを備えており、バッファに格納したデータを自動的に無線LAN に送る。
〔ボックスで使用するOS〕
ボックスは、独自のリアルタイム OS を使用する。この OS では、タスクは、実行状態、実行待ち状態、待ち状態のいずれかとなる。タスクにはあらかじめ、高、中、低の 3 種類の優先度が付与され、変更されることはない。
・実行状態のタスクがあるとき、より優先度が高いタスクの実行要求があると、実行状態のタスクは実行待ち状態になり、優先度が高いタスクは実行状態になる。
・タスク間の通信にはメッセージキュー(以下、キューという)及びリングバッファを使用する。
〔ボックスのタスク構成〕
ボックスで使用するタスクの構成を、表1に示す。

〔タスク間通信〕
タスク間の通信では、コマンドなどの短いデータはキューを使用し、サイズの大きい録画データはリングバッファを使用する。レコーダ制御タスクとエンコーダタスクの間にリングバッファA(以下、バッファAという)を、エンコーダタスクと無線LAN制御タスクの間にリングバッファB(以下、バッファBという)をそれぞれ割り当てる。
リングバッファは、書込みインデックスの値W、読出しインデックスの値R、及びデータを格納するバッファから成る。
リングバッファでは、データを書き込むと書き込んだデータ長が書込みインデックスに加算され、データを読み出すと読み出したデータ長が読出しインデックスに加算される。リングバッファではデータを全て読み出したとき、書込みインデックスの値Wと読出しインデックスの値Rの関係はdとなる。
〔視聴時のタスクの動き〕
録画番組を視聴するとき、ボックスはレコーダを制御して録画データを連続して受け取る。
端末から録画番組が指定されると、ボックスはレコーダにコマンドを送り、視聴を開始する。視聴を開始すると、各タスクが表2の処理を繰り返す。
1フレーム分の録画データが30ミリ秒周期でレコーダから送られ、ボックスで端末用のデータにブロック化され、ブロック単位で端末に送られる。

〔インターネット経由の予約機能の追加〕
インターネットを経由して番組録画予約を行う機能の追加を行うことになった。
端末が番組録画予約データを電子メール(以下、メールという)でボックス宛てに送ると、ホックスがメールを受信し、番組録画予約データを取り出して番組録画予約を行い、予約完了、予約エラーなどの処理結果をメールで端末に返信することにした。予約機能追加時のシステムの構成を図2に示す。

端末のアプリには、番組録画予約データを暗号化してメールで送信する機能と、ボックスで処理された結果をメールで受信する機能を追加した。
ボックスには、5分間隔でメールの有無をチェックする機能をeタスクに追加した。さらに、fタスクに、受信したメールから番組録画予約デー夕を取り出して番組予約タスクに通知する機能及び処理結果のメールを生成して送信する機能を追加した。
設問1:〔端末及びボックスの機能〕について
(1)同時に視聴できる端末を1台に制限したのはどのような理由によるものか。制約となるタスク名を含め、30字以内で述べよ。
模範解答
複数台では、エンコーダタスクの処理が間に合わないから
解説
解答の論理構成
-
端末数の制限に関する前提
【問題文】に「ボックスのタスクの制約から、同時に視聴できる端末は1台だけである。」とあります。
どのタスクがボトルネックになるかを確認します。 -
各タスクの処理時間
・レコーダ制御タスク……1フレーム当たり「4ミリ秒」
・エンコーダタスク……1フレーム当たり「6ミリ秒」、さらに「4フレームごとに、さらに…44ミリ秒」が追加
・無線LAN制御タスク……1フレーム当たり「1ミリ秒」
映像は「30ミリ秒周期」で到着するので、平均処理負荷を算出します。 -
エンコーダタスクの平均処理時間
4フレームをまとめて考えると
6 ms × 4 + 44 ms = 68 ms
1フレーム当たり 68 ms ÷ 4 = 17 ms
したがって 1ストリームあたり 17 ms<30 ms で余裕があります。 -
複数ストリーム時の影響
2台同時視聴なら 17 ms × 2 = 34 ms/フレームとなり、到着周期「30ミリ秒」を超過します。
到着より処理が遅れると、【問題文】注1) にある「録画データが消失してしまわないように…直ちに処理する」条件を満たせず、データ上書きが発生します。 -
制限理由の特定
超過を招くのはエンコード+暗号化+ブロック化を行う「エンコーダタスク」であり、他タスクは 30 ms 内に収まります。よって回答は
「複数台では、エンコーダタスクの処理が間に合わないから」 となります。
誤りやすいポイント
- 無線LAN制御タスクの「1ミリ秒」に着目し、通信がボトルネックと思い込む。実際は処理時間が短く問題になりません。
- レコーダ制御タスクの「4ミリ秒」だけを見て余裕が大きいと判断し、エンコーダタスクの追加「44ミリ秒」を見落とす。
- 「優先度」を理由に挙げてしまう。優先度は処理順序であり、根本的な時間超過の解決にはなりません。
FAQ
Q: 1台制限を解除する方法はありますか?
A: エンコーダタスクの処理性能を 2 倍以上に高めるか、2 系統のエンコーダタスクを並列実行できるように OS とハードウェアを改良すれば理論上可能です。
A: エンコーダタスクの処理性能を 2 倍以上に高めるか、2 系統のエンコーダタスクを並列実行できるように OS とハードウェアを改良すれば理論上可能です。
Q: 無線LAN の帯域は十分なのでしょうか?
A: 各フレームの転送に要する無線LAN制御タスクの時間は「1ミリ秒」と短く、バッファリングもあるため帯域ではなくエンコーダが律速要因です。
A: 各フレームの転送に要する無線LAN制御タスクの時間は「1ミリ秒」と短く、バッファリングもあるため帯域ではなくエンコーダが律速要因です。
Q: タスク優先度を高くすれば複数端末で視聴できますか?
A: 優先度を上げても処理自体の所要時間は変わらないため、30 ms 周期内に 2 ストリームを完了することはできません。
A: 優先度を上げても処理自体の所要時間は変わらないため、30 ms 周期内に 2 ストリームを完了することはできません。
関連キーワード: リングバッファ、タスクスケジューリング、リアルタイムOS, エンコード処理、帯域制御
設問1:〔端末及びボックスの機能〕について
(2)端末で録画データを保存しないこととしたのは、どのような権利の侵害を回避するためか答えよ。
模範解答
著作権
解説
解答の論理構成
- 【問題文】では「レコーダが出力する録画データは端末に保存できないようにしている。」と明記されています。
- 録画データを端末に保存すると、ユーザは番組を無制限に複製・配布できる可能性が生じます。これは放送事業者や制作会社が保有する映像・音声コンテンツの「複製権」を侵害する行為につながります。
- したがって、保存機能を排除することで「著作物を権利者の許諾なく複製・頒布してはならない」という法的要請を満たし、【模範解答】が示す「著作権」の侵害回避が目的になります。
誤りやすいポイント
- 肖像権やプライバシー権と混同する。録画番組の主たる保護対象は「著作物」であり、放送出演者個人の肖像権ではありません。
- 公衆送信権と複製権の区別に迷う。今回問題となるのは端末への保存=複製行為であり、公衆送信権(ストリーミング配信等)とは別です。
- 「私的複製なら合法」と早合点する。著作権法の私的複製規定は暗号化コンテンツや利用規約による制限、DRM によって適用が制限される場合があり、商用サービスでは安全側に倒して保存不可としている点を見落としやすいです。
FAQ
Q: ストリーミング視聴なら著作権問題は起きないのですか?
A: データが端末に一時蓄積されても、ストリーム終了と同時に自動消去されれば「一時的蓄積」に該当し複製権侵害にならないと解釈されます。
A: データが端末に一時蓄積されても、ストリーム終了と同時に自動消去されれば「一時的蓄積」に該当し複製権侵害にならないと解釈されます。
Q: 無線 LAN 区間が暗号化されているのも著作権保護のためですか?
A: 主目的は盗聴・改ざん防止ですが、結果として録画データの不正コピー防止にも寄与します。ただし保存禁止の決定打は端末側での記憶領域への書込みを禁止した設計です。
A: 主目的は盗聴・改ざん防止ですが、結果として録画データの不正コピー防止にも寄与します。ただし保存禁止の決定打は端末側での記憶領域への書込みを禁止した設計です。
Q: もし端末に録画データを保存したい場合、どのような権利処理が必要ですか?
A: 放送事業者や製作委員会など著作権者から複製・頒布の許諾を得るライセンス契約を結び、必要に応じてDRM実装、使用料の支払いなどが求められます。
A: 放送事業者や製作委員会など著作権者から複製・頒布の許諾を得るライセンス契約を結び、必要に応じてDRM実装、使用料の支払いなどが求められます。
関連キーワード: 著作権、複製権、DRM, デジタルコンテンツ、権利保護
設問2:〔ボックスのタスク構成〕及び〔タスク間通信〕について
(1)表1中のa〜cに入れる優先度を高、中、低から一つずつ選んで答えよ。
模範解答
a:高
b:中
c:低
解説
解答の論理構成
-
まず優先度決定のヒントとなる記述を抽出します。
• 「注1) 録画データが消失してしまわないように、レコーダから受け取った録画データを直ちに処理する。」
• 「注2) 遅延が最小となり、かつ、レコーダ制御タスクの処理を妨げないように設計されている。」
いずれも【問題文】表1の注記です。 -
高優先度を割り当てるべきタスク
「録画データが消失してしまわないように…直ちに処理する」必要があるタスクは “レコーダ制御” です。データ消失は致命的なためプリエンプションされにくい “高” が適切です。
⇒ a = 高 -
中優先度を割り当てるべきタスク
“無線 LAN 制御” については「遅延が最小となり、かつ、レコーダ制御タスクの処理を妨げないように設計」する必要があります。
• レコーダ制御(高)より下、他タスク(エンコーダ)より上であれば両条件を満たせます。
⇒ b = 中 -
残った “エンコーダ” タスク
エンコーダは 1 フレーム 6 ミリ秒+4フレーム毎に 44 ミリ秒と処理時間は長めですが、 • バッファA/B によりある程度の遅延吸収が可能
• レコーダ制御や無線LAN制御より優先するとリアルタイム性を損なう
したがって最下位の “低” が妥当です。
⇒ c = 低 -
以上より解答は
a:高 b:中 c:低
誤りやすいポイント
- 「処理時間が長い=高優先度」と思い込み “エンコーダ” を高にしてしまう。リアルタイム OS ではデータ欠落リスクの有無が主判断材料です。
- 注記を読まず “無線 LAN 制御” を低にすると、高負荷時に無線バッファが枯渇しスループット低下を招きます。
- 高中低を単純に「機能の重要度」で選び、録画予約の“番組予約”を高にしてしまう。実時間性が求められるのは視聴系タスクです。
FAQ
Q: エンコーダを低優先度にしてもブロック化の44ミリ秒で遅延しませんか?
A: 遅延はリングバッファA/Bで吸収します。また 30 ミリ秒周期で新フレームが来るため、高速処理タスクの邪魔をしないほうが全体の安定度が高まります。
A: 遅延はリングバッファA/Bで吸収します。また 30 ミリ秒周期で新フレームが来るため、高速処理タスクの邪魔をしないほうが全体の安定度が高まります。
Q: 無線LAN制御が高優先度だとレコーダ制御をブロックしませんか?
A: 「レコーダ制御タスクの処理を妨げないように設計」するため中優先度としています。高にするとプリエンプトが発生しデータ消失リスクが高まります。
A: 「レコーダ制御タスクの処理を妨げないように設計」するため中優先度としています。高にするとプリエンプトが発生しデータ消失リスクが高まります。
Q: 番組録画予約関連のタスクは平常時も動きますが優先度は低いままで良い?
A: はい。予約操作はリアルタイム性より確実性が重要で、タイムアウト処理も「1分を経過しても…」と長い猶予があるため低優先度で問題ありません。
A: はい。予約操作はリアルタイム性より確実性が重要で、タイムアウト処理も「1分を経過しても…」と長い猶予があるため低優先度で問題ありません。
関連キーワード: リアルタイムOS, タスク優先度、プリエンプション、バッファリング、無線LAN制御
設問2:〔ボックスのタスク構成〕及び〔タスク間通信〕について
(2)本文中のdに入れる適切な式をR,Wを用いて答えよ。
模範解答
d:R=W
解説
解答の論理構成
- 問題文はリングバッファの仕組みを次のように説明しています。
>「リングバッファでは、データを書き込むと書き込んだデータ長が書込みインデックスに加算され、データを読み出すと読み出したデータ長が読出しインデックスに加算される。」
ここで は書込みインデックス、 は読出しインデックスを示します。 - リングバッファが「空」であることを判定できなければ、読出し側は誤って古いデータを読み込んでしまいます。空状態を示す最も直感的な条件はインデックスが一致していることです。
- 問題文は続けて次の条件を提示しています。
>「リングバッファではデータを全て読み出したとき、書込みインデックスの値Wと読出しインデックスの値Rの関係はdとなる。」
すでに“データを全て読み出した”と明言しているので、書込み位置と読出し位置が同じ地点を指すはずです。 - インデックスが同じという関係は数式で と表されます。
よって d に入る式は R=W です。
誤りやすいポイント
- 「バッファが空」の判定と「バッファが満杯」の判定を混同する
リングバッファではどちらも になり得るため、実装では“あと1バイト空ける”など別途判定方法を用意するのが一般的です。本問は実装上の細部ではなく“読み出し済み=空”の理論状態だけを聞いています。 - モジュロ演算(バッファの折り返し)を意識し過ぎて複雑な式を考えてしまう
折り返しは 、 をバッファサイズで剰余した結果が同じかどうかで判断できるため、本問の答えは単純です。 - 「データを全て読み出した=読出しインデックスがバッファサイズの末端に到達」と誤解する
末端位置は関係なく、書込み側も同じ回数だけ増分していれば結局 と が一致します。
FAQ
Q: リングバッファが満杯のときも になりませんか?
A: 実装方法によっては同じになります。そのためプログラムでは「バッファの残りサイズ」や「フルフラグ」を別に保持します。本問は“空”の数理的状態だけを尋ねています。
A: 実装方法によっては同じになります。そのためプログラムでは「バッファの残りサイズ」や「フルフラグ」を別に保持します。本問は“空”の数理的状態だけを尋ねています。
Q: なぜ「」や「」ではなく を用いるのですか?
A: リングバッファは折り返し(モジュロ演算)を行うため と は常にバッファ長未満の値です。差分よりも“ポインタが同じ位置を指す”ことを直接示す が最も明快です。
A: リングバッファは折り返し(モジュロ演算)を行うため と は常にバッファ長未満の値です。差分よりも“ポインタが同じ位置を指す”ことを直接示す が最も明快です。
Q: 回答は と等号2つで書いても良かったですか?
A: 等価演算子ではなく関係式を尋ねているので が適切です。試験では代入と混同しないよう「イコール1つ」で示すのが一般的です。
A: 等価演算子ではなく関係式を尋ねているので が適切です。試験では代入と混同しないよう「イコール1つ」で示すのが一般的です。
関連キーワード: リングバッファ、インデックス管理、バッファ空判定、モジュロ演算、データフロー
設問3:〔インターネット経由の予約機能の追加〕について
(1)本文中のe、fに入るタスク名を答えよ。
模範解答
e:無線LAN制御
f:ボックス制御
解説
解答の論理構成
- 前提確認
- 追加仕様では「ボックスには、5分間隔でメールの有無をチェックする機能をeタスクに追加した。さらに、fタスクに、受信したメールから番組録画予約データを取り出して番組予約タスクに通知する機能及び処理結果のメールを生成して送信する機能を追加した。」と明記されています。
- どのタスクが“メールの有無をチェック”に最適か
- 表1で「無線 LAN 制御」タスクは
「無線 LAN からデータを受け取り、ボックス制御タスクに送る。」
「各タスクからデータを受け取り、無線 LAN 用のバッファに格納する。」
と、ネットワーク I/O を専門に扱っています。 - メールチェックはネットワークレイヤの受信処理のみでリアルタイム性も低いので、既存のネットワーク I/O 担当である「無線 LAN 制御」に載せるのが自然です。
- 従って e=「無線 LAN 制御」。
- 表1で「無線 LAN 制御」タスクは
- どのタスクが“メール内容の解析と結果返信”に最適か
- 「ボックス制御」タスクは
「無線 LAN 制御タスクからデータを受け取り、**に変換し、○○タスクに送る」
と、受信データの解析・コマンド化・タスク間転送を担うハブ役です。 - メールから番組録画予約データを抽出して内部へ通知する処理、逆に処理結果をメール形式へ変換する処理は同じ“データ変換/ルーティング”の性質を持つため、「ボックス制御」に追加するのが最小変更で整合的です。
- 従って f=「ボックス制御」。
- 「ボックス制御」タスクは
誤りやすいポイント
- 「メールはインターネット経由だから新しいタスクを起こす」と早合点し、既存タスクとの機能重複を見落とす。
- 表1の注記「遅延が最小となり、かつ、レコーダ制御タスクの処理を妨げないように設計」を読み飛ばし、「無線 LAN 制御」に負荷を載せて良いのか迷う。メールチェックは 5 分周期で極めて軽負荷なので問題ありません。
- 「ボックス制御」と「番組予約」を混同し、メール解析を「番組予約」に入れようとする。後者は予約コマンド生成が主目的であり、メール処理という I/O 変換を担当させるのは不自然です。
FAQ
Q: メールチェックの周期が短くなっても「無線 LAN 制御」に乗せて大丈夫ですか?
A: 本タスクはネットワーク I/O に特化し高優先度(表では b)です。周期が短くなるほど優先度の高い I/O タスクに置く設計方針はむしろ妥当です。
A: 本タスクはネットワーク I/O に特化し高優先度(表では b)です。周期が短くなるほど優先度の高い I/O タスクに置く設計方針はむしろ妥当です。
Q: 「ボックス制御」を拡張してメール返信まで行うと処理量が増えませんか?
A: メール本文の生成は文字列操作中心で短時間です。リアルタイム性が厳しい録画処理とは並列に動くため、中優先度の「ボックス制御」に載せても主要タスク(高優先度)の妨げになりません。
A: メール本文の生成は文字列操作中心で短時間です。リアルタイム性が厳しい録画処理とは並列に動くため、中優先度の「ボックス制御」に載せても主要タスク(高優先度)の妨げになりません。
Q: 「番組予約」タスクに直接メールを渡してはいけない理由は?
A: 「番組予約」は“コマンド生成・タイムアウト管理”が職務範囲です。メールフォーマットの解釈/生成はレイヤが異なるため、レイヤ分割の原則に従い「ボックス制御」が担当します。
A: 「番組予約」は“コマンド生成・タイムアウト管理”が職務範囲です。メールフォーマットの解釈/生成はレイヤが異なるため、レイヤ分割の原則に従い「ボックス制御」が担当します。
関連キーワード: タスク優先度、リングバッファ、ネットワークI/O, メッセージキュー
設問3:〔インターネット経由の予約機能の追加〕について
(2)端末が番組録画予約のメールを送信してから、ボックスが処理結果のメールを送信するまでの時間は最大で何分になるか答えよ。ここで、ネットワーク内での遅延及びボックス内のタスクの処理に要する時間は無視できるものとする。
模範解答
6
解説
解答の論理構成
-
メール到着からボックスがそれに気付くまで
【問題文】に「ボックスには、5分間隔でメールの有無をチェックする機能をeタスクに追加した。」とあります。
端末がメールを送信した直後にチェックが終わっていた場合、次のチェックは最長で5分後になります。したがって受信確認までの最大待ち時間は5分です。 -
予約コマンド送信後の待機時間
メールを受信した後、番組予約タスクにデータが渡されます。このタスクには
「番組の予約コマンドをレコーダ制御タスクに送ってから1分を経過してもレコーダ制御タスクからレスポンスが受け取れない場合、操作が失敗したものとみなし、処理結果をボックス制御タスクに送る。」
という仕様があります。レスポンスが最も遅れるケースでは、この“1分”がそのまま追加されます。 -
ネットワーク遅延・処理時間は無視
設問が「ネットワーク内での遅延及びボックス内のタスクの処理に要する時間は無視できるものとする」としているため、実際のメール送信/受信やタスク実行のミリ秒単位の時間は計算に入れません。残る要素は前述のポーリング間隔5分とタイムアウト1分のみです。 -
合計
最大時間 = 5分(メールチェック待ち)+ 1分(レスポンス待ち) = 6分
よって解答は「6」です。
誤りやすいポイント
- メールチェック間隔を“5分ごと”ではなく“5分以内”と誤解し、0~5分の平均値で考えてしまう。
- 「タスクの処理に要する時間は無視できる」と読んで、番組予約タスクの“1分待ち”も除外してしまう。
- レコーダが即時応答する前提で5分だけを合計し、最大ではなく最短ケースで答えてしまう。
FAQ
Q: レコーダが正常に応答すれば1分待たなくて良いのでは?
A: はい。しかし設問は「最大で何分になるか」を尋ねています。最悪パターン(レスポンスなし→1分タイムアウト)を考慮する必要があります。
A: はい。しかし設問は「最大で何分になるか」を尋ねています。最悪パターン(レスポンスなし→1分タイムアウト)を考慮する必要があります。
Q: 5分間隔のチェックは常に正確に行われると仮定して良いのですか?
A: 設問ではタスクの実行遅延を無視できるとされているため、ポーリング周期はぴったり5分で計算します。
A: 設問ではタスクの実行遅延を無視できるとされているため、ポーリング周期はぴったり5分で計算します。
Q: ネットワーク遅延が大きい場合でも6分以内に収まりますか?
A: 設問が「ネットワーク内での遅延は無視できる」と明示しているため、理論上の計算結果として6分と答えます。実環境では追加遅延が発生する可能性があります。
A: 設問が「ネットワーク内での遅延は無視できる」と明示しているため、理論上の計算結果として6分と答えます。実環境では追加遅延が発生する可能性があります。
関連キーワード: ポーリング、タイムアウト、メール通知、リアルタイムOS, タスクスケジューリング


