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

解答の導き方

誤りやすいポイント

• 表2にあるメッセージをすべて通信量に含めないようにします。定常状態で繰り返し発生するかどうかを、各メッセージの送信条件から判断します。
• プラグイン通知メッセージは子機の接続時に送信されます。接続時に一度だけ発生する通信と、定常状態で継続的に発生する通信を区別します。
• 通電制御指示メッセージは、通電・遮断を切り替えるためのものです。設問ではその変化が発生しないので、定常状態の通信には含めません。
• 電力量通知メッセージは、定格電力を超えたときではなく、接続機器が１Wh消費するごとに発生します。正常に動作している条件でも考慮が必要です。

FAQ

解答の導き方

1. PLCで使える通信量を求めます。
   PLCの実効伝送速度は「5,000ビット／秒」で、平均回線使用率を「80％以下」にする条件です。したがって、1秒当たりに使える通信量は
   $5,000\times 0.8=4,000$ ビットです。
   1時間を$3,600$秒として、1時間当たりの上限を求めると、
   $4,000\times 3,600=14,400,000$ ビットになります。
2. 定常状態で繰り返されるプラグ状態の確認通信を数えます。
   表2では、プラグイン確認を「２秒ごとにブロードキャストメッセージで確認する」とあります。ブロードキャストなので、子機が$x$台あっても、確認メッセージ自体は1回の確認につき1通です。
   1時間当たりの確認回数は$3,600÷2=1,800$回です。電文長は$320$ビットなので、確認メッセージの通信量は
   $320\times 1,800=576,000$ ビットです。
3. 各子機からの応答通信を数えます。
   プラグイン応答の電文長は$160$ビットです。プラグイン状態にある子機は確認のたびに応答するため、1時間当たりの通信量は、子機1台につき$160\times 1,800$ビットです。子機が$x$台あるので、全体では
   $160\times 1,800\times x=288,000x$ ビットです。
4. 消費電力量の通知通信を数えます。
   表2では、電力量通知は接続機器が「１Wh消費したこと」を親機に通知するメッセージで、電文長は$320$ビットです。子機に接続された機器の消費電力量の合計が$y$Whなら、通知の通信量は$320y$ビットです。
5. 通信量の合計を上限以下にします。
   定常状態では、通電・遮断の変化がなく、定格電力オーバもありません。そのため、通電制御指示やアラーム通知、接続時だけ送るプラグイン通知は、定常状態の繰返し通信として数えません。
   以上から、1時間当たりの通信量は
   $576,000+288,000x+320y$
   であり、これが$14,400,000$ビット以下となる必要があります。
   $576,000+288,000x+320y\le 14,400,000$
   両辺を$320$で割って$y$について整理すると、
   $y\le 45,000-1,800-900x$
   となります。したがって、式の定数項は$43,200$、$x$の係数は$900$です。どちらも整数なので、指定された四捨五入をしても値は変わりません。

誤りやすいポイント

• プラグイン確認を子機ごとに送ると考えてしまう点です。表2ではブロードキャストなので、確認メッセージは1回につき1通です。一方、応答は各子機から送られます。
• 消費電力量の通知だけを数え、定常状態でも繰り返されるプラグイン確認とプラグイン応答を見落とす点です。
• プラグイン通知を定常状態の通信に含める点です。これは子機を電源コンセントに接続したときに1回だけ送るメッセージです。
• 1時間当たりの確認回数を$3,600$回としてしまう点です。確認は2秒ごとなので、回数は$3,600÷2$です。

FAQ

解答の導き方

誤りやすいポイント

• 親機の場合と同じように、子機の場合もI/OタスクにLED点滅を指示すると考えてしまうことです。子機のLEDは、親機からの通知を受けて子機側で点滅します。
• 通電制御指示メッセージと混同することです。通電制御指示は通電・遮断の指示であり、定格電力超過の通知にはアラーム通知メッセージを使います。
• 電力情報タスクが子機へ直接メッセージを送信すると考えることです。子機とのメッセージ送受信を担うのはPLCタスクです。

FAQ

解答の導き方

誤りやすいポイント

• 赤色LEDの点滅と混同しないようにします。定格電力オーバを検出したときの処理もありますが、この設問で優先度の理由となるのは漏電時の遮断です。
• LEDの点滅やメインタスクへの通知を、最優先の処理と考えないようにします。表3では、I/Oタスクはまず遮断し、その後に表示と通知を行います。
• 優先度を高くする目的は、漏電を検出した後のタスク処理を遅らせないことです。優先度そのものが漏電の検出を行うわけではありません。

FAQ

解答の導き方

1. 子機は、電源コンセントに接続した直後から親機の通電制御指示メッセージを受信するまでは、コンセントを遮断状態にします。また、接続したときに親機へ一度だけ送信するメッセージは「プラグイン通知」です。したがって、空欄cに入るのは「プラグイン通知」です。
2. 表3では、子機のプラグ状態を管理し、その状態の変化をメインタスクに通知するタスクとして「プラグ管理」が示されています。プラグイン通知を受信した後、管理中のプラグ状態と照らし合わせるのはこのタスクなので、空欄dは「プラグ管理」です。
3. 親機は、プラグイン確認に対して2回連続で応答を受信できない場合に、子機をプラグアウト状態とみなします。再接続がその判定より先だと、親機が管理している子機の状態はまだプラグイン状態のままです。そのため、プラグ管理タスクは再び届いたプラグイン通知を、状態の変化がないものとして破棄してしまいます。
4. 表3によると、プラグ状態の変化はプラグ管理タスクからメインタスクへ伝わり、メインタスクから通電制御タスクへ通知されます。しかし、プラグ管理タスクが通知を破棄すると、この2つのタスクに子機の状態変化が伝わりません。よって、空欄eとfは「メイン」と「通電制御」です。
5. 通電制御タスクに変化が伝わらないため、再接続した子機へ通電を指示できません。したがって、通知されない変化を表す空欄gは「子機のプラグ状態」、子機に送信されないメッセージを表す空欄hは「通電制御指示」です。

誤りやすいポイント

• プラグイン通知とプラグイン応答を混同しないようにします。プラグイン通知は子機を接続したときに送るメッセージで、プラグイン応答は親機からのプラグイン確認に対する応答です。
• 子機を抜いた時点ですぐに、親機がプラグアウト状態を認識するとは限りません。認識前に再接続されると、親機が管理する状態と実際の接続状況にずれが生じます。
• メインタスクだけでなく、メインタスクから通知を受けて通電を制御する通電制御タスクにも、状態変化が伝わらない点に注意します。
• 子機が再接続後に遮断状態になるのは、通電制御指示メッセージを受信するまでは遮断する仕様のためです。

FAQ

解答の導き方

1. 子機を抜いてから親機がプラグアウト状態を認識する前に再接続すると、親機のプラグ管理タスクは、その子機をまだプラグイン状態として管理しています。再接続した子機は「プラグイン通知メッセージ」を送信しますが、管理上はすでにプラグイン状態なので、状態に変化がないものとして処理されてしまいます。
2. 子機は、再接続後、親機から通電制御の指示を受け取るまでは遮断状態です。一方、プラグ管理タスクからメインタスクへプラグ状態の変化が通知されなければ、メインタスクから通電制御タスクへの通知も行われず、子機に通電制御指示メッセージが送られません。そのため、子機のコンセントが遮断状態のままになります。
3. この問題を避けるには、プラグイン状態の子機からプラグイン通知メッセージを受信したとき、メインタスクに状態変化を確実に伝える必要があります。まずプラグアウト通知を送り、その後にプラグイン通知を送れば、メインタスクは「プラグアウト状態になった後、プラグイン状態になった」と順に扱えます。これにより、再接続後の子機に対する通電制御が行われます。

誤りやすいポイント

• プラグイン通知だけをメインタスクに送ると、管理上はすでにプラグイン状態なので、状態変化として扱われないおそれがあります。
• 通知の順序を逆にすると、プラグイン状態になった後にプラグアウト状態になったと扱われ、意図した制御につながりません。
• プラグ管理タスクが子機へ直接通電指示を送るのではありません。プラグ管理タスクからの通知を受けて、メインタスクや通電制御タスクが処理します。

FAQ