エンベデッドシステムスペシャリスト 2017年 午後1 問02

解答の導き方

誤りやすいポイント

• 表2の照度データと移動平均値を取り違えないようにします。制御の判定に使うのは移動平均値です。
• 点灯条件の「50以下」と消灯条件の「55以上」は別々に確認します。50を超えた時点で直ちに消灯するわけではありません。
• 51～54の範囲は、照明の状態を切り替える条件ではありません。ここで状態を維持することが、点灯・消灯の頻繁な繰返しを防ぎます。

FAQ

解答の導き方

1. まず、保存対象となる画像の総数を求めます。本文には、カメラユニットが「1秒間に4フレームの画像を撮影する」とあり、圧縮された画像データは「6分間分」ごとにファイル化され、「240時間保存」されます。
   6分間は360秒なので、1ファイル当たりのフレーム数は次のとおりです。
   $4\times 360=1,440$ フレーム
2. 240時間分のファイル数を求めます。240時間を6分間ごとの区切りにすると、ファイル数は次のとおりです。
   $240\times 60÷6=2,400$ ファイル
   したがって、保存する画像の総数は次のとおりです。
   $1,440\times 2,400=3,456,000$ フレーム
3. 次に、1フレーム当たりの保存容量を求めます。元の画像データは1フレーム当たり1Mバイトで、圧縮後は元の1%です。
   $1,000,000\times 0.01=10,000$ バイト
   さらに暗号化によって、圧縮したデータの5%分だけ容量が増えます。したがって、暗号化後の容量は次のとおりです。
   $10,000\times 1.05=10,500$ バイト
4. 保存する全フレームの容量を求めます。
   $3,456,000\times 10,500=36,288,000,000$ バイト
   1Gバイトは$10^9$バイトなので、Gバイトに換算すると36.288Gバイトです。必要な容量は整数で切り上げるため、必要なフラッシュメモリ容量は37Gバイトとなります。

誤りやすいポイント

• 5%増えるのは元画像ではなく、圧縮後のデータです。圧縮後の容量に1.05を掛けます。
• 240時間を秒に換算してフレーム数を求めても、6分間ごとのファイル数を求めてから計算しても、同じ総フレーム数になります。
• MバイトとGバイトは、問題文の指定どおり10進数で換算します。$1$Gバイトは$10^9$バイトです。
• 36.288Gバイトを整数で求めるため、四捨五入ではなく切り上げます。

FAQ

解答の導き方

誤りやすいポイント

• 画像データの内容が重複する問題ではなく、時刻から自動生成されるファイル名が重複する問題です。
• 「日付時刻の設定」で必ず時刻が過去に戻るとは限りません。設定時刻によっては、既存のファイル名と同じになる可能性があることがポイントです。
• 日付時刻の設定時には、記憶済みのファイルだけでなく蓄積中の画像データも削除されます。ただし、問われている不都合はファイル名の重複です。

FAQ

解答の導き方

誤りやすいポイント

• [a]を照明の点灯・消灯に関する値と取り違えないようにします。画質調整は1秒周期、照明の制御は1分周期です。
• [b]は、その時点の照度データそのものではありません。現時点と過去4分間のデータ、合計5個の平均値です。
• [c]には画像処理タスクの名称ではなく、圧縮処理に使うアクセラレータの名称が入ります。
• [d]と[e]は、画像データの暗号化や新しいファイルの記憶ではなく、保存期間を過ぎたファイルを削除する処理です。

FAQ

解答の導き方

誤りやすいポイント

• 照度データを基に照明の点灯・消灯を決める処理と、照明そのものを制御する処理を混同しないようにします。前者は「照度」タスク、後者は「照明」タスクです。
• 画像データを圧縮・蓄積する処理と、暗号化してファイルに記憶する処理は別のタスクです。前者が「画像処理」、後者が「ファイル管理」です。
• 図4の矢印はタスク間のメッセージ通信の方向を示します。矢印の向きと、表1の「通知を受ける」「通知する」という処理内容を対応させます。

FAQ

解答の導き方

1. 問われているのは、図4で時刻情報を更新するタスクではなく、時刻情報を読み出して処理に使う二つのタスクです。図4の注記では、破線の矢印はメモリへの書込みを表し、メモリからの読出しは省略するとされています。そのため、読み出すタスクは表1の処理内容から見つけます。
2. 表1の「画像処理」には、「時刻情報を基に時刻画像を作成」するとあります。画像に合成する時刻画像を作るために、時刻情報を読み出す必要があります。
3. 表1の「ファイル管理」には、ファイル名を「時刻情報から自動生成」するとあります。ファイル名を作るためにも、時刻情報を読み出します。

誤りやすいポイント

• 図4で時刻情報につながる破線を見て、更新する「メイン」を読み出すタスクとして選ばないようにします。破線はメモリへの書込みを表します。
• 時刻情報の使い道を一つだけで考えないようにします。画像に合成する時刻画像の作成だけでなく、ファイル名の生成にも使われます。
• 図4ではメモリからの読出しが省略されているため、表1の各タスクの処理内容を確認して、時刻情報を使うタスクを特定します。

FAQ

解答の導き方

誤りやすいポイント

• 「ファイル化要求を受けたこと」だけを条件と考えないようにします。要求を受けても、暗号キーが設定されている場合に限り処理します。
• 「画像データが6分間分蓄積されていないこと」と混同しないようにします。画像データが蓄積されるとファイル化要求が通知されますが、ファイル化を行うかどうかは暗号キーの設定状態で決まります。
• 暗号キーの設定は、画像データを暗号化するための前提です。ファイル化要求の有無とは別に確認する条件です。

FAQ

解答の導き方

誤りやすいポイント

• スイッチの機能に「時刻の補正」とあるため、取付け時に正しい時刻へ設定することだけを目的として答えると、設問の視点から外れます。
• 電柱への取付け時に注目すべきなのは、設置場所で標準電波を受信できるかどうかです。
• 受信状況の確認だけでなく、受信状態に応じてアンテナの向きや受信ゲインを調整できる点も、目的を考える手掛かりになります。

FAQ

解答の導き方

1. まず、標準電波受信タスクに受信開始を指示し、受信結果を受け取る既存タスクを考えます。標準電波受信タスクは、受信を終えると、受信開始を通知したタスクに受信成功・失敗と時刻データを通知するためです。
2. 表1では、メインタスクが「RTCの制御を含め、防犯灯全体の制御を行う」とされています。標準電波による時刻補正では、受信を始めるタイミングを判断するだけでなく、取得した時刻をRTCに反映する必要があります。そのため、既存タスクのうち変更するのはメインです。
3. 受信開始の契機は、追加仕様にある二つの事象から分かります。「1日1回、設定された時刻」になることと、「強制的に標準電波を受信」するための時刻補正スイッチが押されることです。したがって、メインは補正時刻になったときと、時刻補正スイッチが押されたときに、標準電波受信タスクへ受信開始を通知します。
4. 受信に成功したときは、受信した標準時刻をRTCに設定します。それだけではなく、表1には、RTCに日付時刻の情報を設定するときに時刻情報も更新するとあります。図4でも、メインから時刻情報への書込みが示されています。画像に合成する時刻などに使われる情報も正しく保つため、受信した時刻データをRTCへ設定し、時刻情報にも書き込みます。受信表示器を緑色で表示する処理は、これとは別に行います。

誤りやすいポイント

• 標準電波受信タスクは受信処理を担当し、受信開始を通知したタスクに結果を返します。受信を開始する契機や、RTCへの反映までを受信タスクの役割と考えないようにします。
• 受信開始の契機を補正時刻だけに限定すると、時刻補正スイッチによる強制受信を見落とします。
• 受信成功時の処理として、受信表示器を緑色で表示することだけを書くと不十分です。受信した時刻データをRTCに設定し、時刻情報も更新する必要があります。
• PCとの通信に関係するため無線タスクを選びたくなることがありますが、時刻補正後のRTCと時刻情報を扱う役割はメインにあります。

FAQ