応用情報技術者 2013年 春期 午後 問07

解答の論理構成

1. 充電中は「電池残量の増分が充電時間に比例」と仮定して残り時間を算出する
   ─ 【問題文】「残り充電時間は、携帯機器の電池残量の増分が充電時間に比例すると仮定して算出する。」
2. 10 分で「43.0% → 49.0%」へ 6.0 % 増加した
   ─ 増分 6.0 % を得るのに 10 分かかった。
3. 1 % 充電に要する時間
   ─ $10\text{分}÷6.0=\frac{10}{6}\text{分}\fallingdotseq 1.6667\text{分}$
   （1 分 40 秒）
4. 残りの充電量
   ─ 現在「49.0%」、満充電は 100%
   ─ 100 − 49.0 = 51.0 % が未充電。
5. 残り時間
   ─ $51.0\times \frac{10}{6}\text{分}=85\text{分}$
6. 表示形式は “hh:mm”
   ─ 【問題文：表1】「表示形式は “hh:mm” とする。」
7. 85 分 ＝ 1 時間 25 分 → “01:25” と表示される。

誤りやすいポイント

• 6.0 % を 0.06 倍と勘違いし、単位換算を誤る。
• 10 分を時間単位（0.1667 h）に直して計算途中で桁を落とす。
• 表示形式を “1:25” や “01：25” としてコロンやゼロ埋めを誤記。
• 充電済み 49.0 % ではなく、充電残 51.0 % を使うことに気付かない。

FAQ

解答の論理構成

1. 優先度の基本ルール
   【問題文】では
   “タスクの優先度は 1～4 の4段階で、値が小さいほど優先度が高い。また、それぞれのタスクは異なる優先度をもつ。”
   と明示されています。したがって、4つのタスクに 1・2・3・4 が重複なく割り当てられる必要があります。
2. 既に決まっている優先度
   表3より
   ・“通信”タスクは 3
   ・“異常検出状態”タスクは 1
   が固定です。残る数字は 2 と 4 です。
3. “安全監視”タスクの要求
   “安全監視”は【問題文】で
   “500 ミリ秒ごとに起動し、充電テーブル … 異常発熱を検知した場合は、異常検出状態タスクを起動する。”
   とされており、安全確保のためになるべく早く CPU を得る必要があります。
   “通信”タスク（優先度3）より高く、“異常検出状態”タスク（優先度1）よりは低い順位が最適です。よって 2 が割り当てられます。
4. “メイン”タスクの性質
   “メイン”はステーション全体の制御を行いますが、開始直後に
   “通信タスクを起動”
   して結果を待たずに自らは待機や表示処理を行う流れです。もし“メイン”が“通信”より高優先度（2以下）だと、“通信”が動くタイミングが遅れ、1秒周期通信の要求を満たせません。したがって“メイン”は残る 4 が妥当です。
5. まとめ
   ・a（メインの優先度）＝ 4
   ・b（安全監視の優先度）＝ 2

誤りやすいポイント

• “安全監視”は500 ms周期だから低負荷と判断し、4を割り当ててしまう。周期が短い＝リアルタイム性が高いのでむしろ優先度を上げるべきです。
• “メイン”を中心タスクだから最優先と考えて1を付けてしまう。リアルタイム OS では制御タスクより安全・異常処理が上位になります。
• “通信”より“安全監視”を低くしてしまい、検温より通信が先に走る状況を許してしまう。温度監視の遅延は安全上致命的です。

FAQ

解答の論理構成

1. 【問題文】表3の説明より
   “安全監視タスク”は「500 ミリ秒ごとに起動し、充電テーブルに取り付けた c センサの値を読み込む。その結果、充電テーブルの異常発熱を検知した場合は、異常検出状態タスクを起動する。」と記載されています。
2. 同じく【問題文】“安全設計”では「充電テーブル上に携帯機器の他に金属異物があると、金属異物に電流が流れて熱を帯び、発火などの危険性がある。」と説明し、異常の主体は“発熱”であると明示しています。
3. 発熱を検知するセンサは温度センサが一般的かつ適切です。湿度センサや人感センサでは温度上昇を直接計測できません。
4. 以上から、c に入る語は「温度」と判断でき、解答群「ア：温度」が正解となります。

誤りやすいポイント

• “充電テーブル”という語から環境条件を連想し、誤って「イ：湿度」を選択するケースがありますが、湿度では発熱を直接検出できません。
• “人が触れる危険性”をイメージして「ウ：人感」を選択する受験者もいますが、問題は無人でも発生する金属異物の発熱リスクに焦点を当てています。
• センサの役割が「安全監視」であることを見落とし、タスク名だけで判断してしまうとミスにつながります。必ず検知対象（発熱）を確認しましょう。

FAQ

解答の論理構成

1. まず、[動作状態の説明]に「“異常検出状態” は『異常発熱、充電効率の低下などの異常を検出し、充電動作を停止している状態』」と明記されています。
2. 表3「異常検出状態」タスクの処理概要は、d 関数呼び出し ➔ “ERROR” 表示 ➔ 無限ループ、という流れです。したがって d には“充電動作を停止”させる関数が入らなければなりません。
3. 表4の送電制御関数を確認すると
   ・“Start_Power”：「送電回路に電流を流し、送電を開始する。」
   ・“Stop_Power”：「送電回路の電流を遮断し、送電を停止する。」
   ・“Get_Watt”：「送電…電力値を…戻り値として返す。」
   と定義されています。
4. 異常時に必要なのは「送電回路の電流を遮断」して充電を停止する処理なので、表4の「“Stop_Power”」が条件を満たします。
5. よって d に入る正しい関数名は「Stop_Power」です。

誤りやすいポイント

• “Start_Power” と “Stop_Power” を逆に選択する
  「異常検出状態＝何か新たな動作を開始」と誤解し、開始系の Start_Power を選びがちです。
• “Get_Watt” を選択してしまう
  「異常時は電力値を測定するのでは？」と考えがちですが、異常は既に検出済み。ここで必要なのは測定ではなく送電停止です。
• 表1の説明を読み飛ばす
  「充電動作を停止している状態」というキーワードを見落とすと、適切な関数を導けません。

FAQ

解答の論理構成

• 【問題文】の通り、メインタスクでは①条件で“STANDBY”を表示するかどうかを決めています。待機中とは「充電テーブル上に携帯機器が置かれるまで待機している状態」（表1「待機状態」の説明）です。
• 携帯機器が存在しないか認識できないかを判断する材料は、携帯機器情報に含まれる「機器 ID」です。表2には
  「機器 ID … 充電テーブル上の携帯機器が認識できない場合は、ゼロが設定される。」
  と明記されています。
• したがって、機器 ID がゼロならば“携帯機器なし”と判断し、待機状態（STANDBY）に遷移するのが自然です。
• 以上より、①条件で用いる判定は「機器IDがゼロ」となります。

誤りやすいポイント

• ステータスや電池残量割合を条件に選んでしまう
  → 満充電か否かは充電中かどうかを区別する情報であり、“機器が有るか無いか”の判断材料にはなりません。
• 「通信に成功したかどうか」を直接フラグで管理していると早合点する
  → 実際には通信タスクが携帯機器情報を設定し、その中の「機器 ID」がゼロか否かで判断します。
• 「受電電力が 0 mW なら携帯機器なし」と誤解する
  → 機器が置かれていても送電開始前は 0 mW になる可能性があるため誤判定になります。

FAQ

解答の論理構成

1. 異常検出では送電効率を算出します。問題文に「送電効率は、次の式で算出する。　送電効率(％) = 受電電力 ÷ 送電電力 × 100」とあります。
2. 受電電力は「携帯機器情報の受電電力」をそのまま利用するよう指定されています。
3. 残る送電電力を取得する方法を探すと、【表4 送電制御関数】に「“Get_Watt”　送電回路で送電している電力値をミリW単位で算出し、戻り値として返す」と記載されています。
4. したがって送電電力を得る最適手段は Get_Watt を呼び出す処理です。
5. 以上より、20字以内で表現する処理内容は「Get_Watt関数を呼び出す」となります。

誤りやすいポイント

• 送電電力を「Start_Power」や「Stop_Power」で取得できると勘違いする
  → 両者は開始・停止制御のみで電力値は返しません。
• 受電電力も Get_Watt で取得すると思い込む
  → 受電電力は携帯機器情報に既に保持されています。
• 送電効率計算において単位（％、mW）をそろえず計算誤差を招く

FAQ