令和3年度 秋期 エンベデッドシステムスペシャリスト試験 午後Ⅱ 問題 問2 生産ライン可視化システムのタスク間通信と複数工場を連携させる機能拡張

図2「モデルの構成及び構成要素」 を確認すると、「工程に関する情報」ブロックの中に以下の情報が含まれています。

• 工程名
• 投入センサのセンサ情報
• 産出センサのセンサ情報
• [ a ] の識別ID
• 設備に関する情報

次に、図1「本システムの概要」 及び 表1「本システムの構成要素」 を確認します。工程に直接関連づけて設置されている要素として、投入センサ、産出センサ、状態センサのほかに、「出力ノード」 が存在します。状態センサは「設備に関する情報」内に定義されているため、「工程に関する情報」に直接含まれる識別IDは 「出力ノード」 のものとなります。

高得点のポイント

• システム構成要素のうち、工程に紐づくものが「出力ノード」であることを正確に特定できている。

表8「モデルの読込み処理」 のフラッシュメモリとSDカードの双方にモデルがある状態（表の右下）の処理について問われています。

表8の注記には「複数のモデルが存在した場合は，作成日時が最も新しいモデルを読み込み，RAMに展開する。」と明記されています。したがって、フラッシュメモリ上のモデルとSDカード上のモデルが存在する場合、両者の作成日時を比較し、より新しい方を読み込んでRAMに展開する処理を行うことになります。

高得点のポイント

• フラッシュメモリとSDカード上のモデルの「作成日時を比較する」ことに言及している。
• 「より新しい方のモデル」を選択して読み込み、RAMに展開することを明記している。

下線①の処理は「モデル又はドライバをSDカードから読み込んだ場合，当該モデル又は当該ドライバをフラッシュメモリに書き込む」というものです。

〔可視化装置の起動時等の動作概要〕 の(1)に「出荷時のフラッシュメモリには，... モデルは書き込まれていない。」とあり、初期状態ではSDカードからモデルを読み込む必要があります。しかし、(5)でフラッシュメモリに書き込んでおけば、次回以降の起動時には 表8「モデルの読込み処理」 に従ってフラッシュメモリから直接モデルを読み込むことが可能になります。これにより、起動のたびにSDカードを挿入しておく必要がなくなります。

高得点のポイント

• フラッシュメモリに保存することで、次回以降はSDカードが不要になる（フラッシュメモリのみから起動できる）という目的を正しく記述している。

表6「可視化装置が算出するロットごとの生産指標」 によると、工程生産能力は以下の式で求められます。
$工程生産能力 = 工程生産量 \div 工程の稼働状態が“工程動作”であった時間$

まず、図4のタイムチャート を用いて圧造工程の「工程動作」であった時間を求めます。

• 表4 より、設備の稼働状態が“設備動作”となるのは「全ての状態センサから得られる状態が“動作”」のときです。
• 圧造工程の状態センサは「振動センサ」と「電流センサ」です。
  • 振動センサが動作している時間: 8:30 〜 13:00 (4.5時間)
  • 電流センサが動作している時間: 8:00 〜 14:30 (6.5時間)
• 両方が動作している時間帯は 8:30 〜 13:00 (4.5時間) です。圧造機はこの1台のみなので、これが圧造工程の「工程動作」時間となります。

次に、工程生産量を求めます。

• 問題文より、1ロットは 10,000個 なので、工程生産量は 10,000 です。

したがって、1時間当たりの圧造工程の工程生産能力は以下のようになります。
$10000 \div 4.5 = 2222.22...$

小数第1位を四捨五入して、2222 となります。

表6 によると、ライン生産能力は以下の式で求められます。
$ライン生産能力 = ライン生産量 \div ラインの稼働状態が“ライン動作”であった時間$

まず「ライン動作」であった時間を求めます。

• 表5 より、ラインの稼働状態が“ライン動作”となるのは「一つ以上の工程が“工程動作”であり、かつ、一つも“工程異常”がない」ときです。
• 圧造工程の“工程動作”時間は 8:30 〜 13:00 です。
• 転造工程の“工程動作”時間を同様に求めます。
  • 振動センサが動作している時間: 8:30 〜 14:30
  • 電流センサが動作している時間: 8:00 〜 15:00
  • したがって、両方が“動作”である転造工程の“工程動作”時間は 8:30 〜 14:30 です。
• ライン内に異常を示す工程はなく、圧造工程または転造工程のいずれかが動作している時間帯は 8:30 〜 14:30 (6.0時間) となります。

次にライン生産量を求めます。

• 表6 より、ライン生産量は「ラインの最後の工程における産出量」です。転造工程からの産出量も1ロット分であり、10,000 となります。

したがって、1時間当たりのライン生産能力は以下のようになります。
$10000 \div 6.0 = 1666.66...$

小数第1位を四捨五入して、1667 となります。

表6 によると、工程間滞留量は以下の式で求められます。
$工程間滞留量 = 工程生産量 - 次の工程への投入量$

圧造工程の産出速度と転造工程の投入速度の違いから、滞留量が最大になるタイミングとその量を求めます。

• 注記より、圧造機は 1.5秒に1個、転造機は 2秒に1個を生産・処理します。
  • 圧造機の産出速度 = $3600 \div 1.5 = 2400$ 個/時間
  • 転造機の投入速度 = $3600 \div 2 = 1800$ 個/時間
• 圧造工程からの産出と転造工程への投入はどちらも 8:30 に開始されます。
• 圧造機の方が処理速度が速いため、圧造機の産出が続いている間は滞留量が増加し続けます。滞留量が最大になるのは、圧造機の産出がすべて完了した時点です。

圧造機が1ロット (10,000個) を産出完了するのにかかる時間は、
$10000 \div 2400 \approx 4.167$ 時間 (4時間10分) です。
つまり、12:40 に産出が完了します。（図4で産出センサの帯が13:00より少し前で終わっていることとも一致します）

この 12:40 の時点において、

• 圧造工程の工程生産量（累積） = 10,000個
• 転造工程へ投入された量（累積） = $1800 \text{個/時間} \times \frac{250}{60} \text{時間} = 1800 \times \frac{25}{6} = 7500$ 個
  （※4時間10分 = 250分）

したがって、工程間滞留量の最大値は以下のようになります。
$10000 - 7500 = 2500$

表9「制御プログラムの主なタスクの処理概要」 の「ドライバ」タスクの欄を確認します。

初期化処理について、「起動されると，生成時に受け取ったパラメタに従って，管理対象のセンサを初期化する。」と記載されています。センサを初期化するために必要なパラメタは、図2「センサ情報の詳細」 に定義されている情報（しきい値などのドライバ用の個別データ）です。したがって、「センサ情報」 またはその一部である個別データが必要です。

また、ドライバタスクはセンサから取得した値を変換した後、「工程タスクに通知する」役割を持ちます。タスク間のメッセージ通信（図3参照）を行うためには、通知先の情報である 「工程タスクのメールボックス」 等の通信先パラメタを生成時に受け取る必要があります。
なお、二つを解答する順序は問われません。

高得点のポイント

• センサを初期化するための「センサ情報（個別データ）」が解答に含まれている。

表9「制御プログラムの主なタスクの処理概要」 の「ドライバ」タスクの欄を確認します。

初期化処理について、「起動されると，生成時に受け取ったパラメタに従って，管理対象のセンサを初期化する。」と記載されています。センサを初期化するために必要なパラメタは、図2「センサ情報の詳細」 に定義されている情報（しきい値などのドライバ用の個別データ）です。したがって、「センサ情報」 またはその一部である個別データが必要です。

また、ドライバタスクはセンサから取得した値を変換した後、「工程タスクに通知する」役割を持ちます。タスク間のメッセージ通信（図3参照）を行うためには、通知先の情報である 「工程タスクのメールボックス」 等の通信先パラメタを生成時に受け取る必要があります。

高得点のポイント

• 変換した値を工程タスクに通知するための「通知先（工程タスクのメールボックス）」が解答に含まれている。

表9の「ドライバ」タスクの処理概要には、「取得したセンサ値について，[ c ] を基に，投入センサであれば投入量に変換し...状態センサであれば“停止”，“動作”又は“異常”のいずれかを示す値に変換し...」とあります。

図2「モデルの構成及び構成要素」 の「センサ情報の詳細」ブロックを見ると、「設備の稼働状態を判別するしきい値など，ドライバ用の個別データ」という要素が存在します。ドライバタスクは、センサ値を状態や投入量に変換・判別するために、このしきい値などの個別データを用います。

高得点のポイント

• ドライバがセンサ値を変換・判別するために必要なデータが「個別データ」であることを、図2のデータ構造に基づいて特定できている。

図5「メインタスクの状態遷移」 において、「準備中」から「保存中」へ遷移するためのトリガーは「準備完了 (条件1が真)」です。また、表10より「保存中」は「フラッシュメモリへの書込みを行っている状態」です。

〔可視化装置の起動時等の動作概要〕 の(5)の①を確認すると、「モデル又はドライバをSDカードから読み込んだ場合，当該モデル又は当該ドライバをフラッシュメモリに書き込む。」と記載されています。

したがって、フラッシュメモリへの保存処理（保存中状態）へ移行する「条件1」は、モデルやドライバをSDカードから読み込んだ場合となります。

高得点のポイント

• フラッシュメモリへの保存（書き込み）が発生する条件が、「モデル又はドライバをSDカードから読み込んだ場合」であることを正確に抜き出して記述している。

図5「メインタスクの状態遷移」 において、「準備中」から「展開中」への遷移条件は「準備完了 (条件1が偽，条件2が真)」です。また、表10より「展開中」は「フラッシュメモリから読出しを行っている状態」です。

〔可視化装置の起動時等の動作概要〕 の(5)を確認すると、モデルやドライバの処理に続く動作として「フラッシュメモリに収集情報及び分析情報が保存されている場合は，RAMに展開する。」と記載されています。

したがって、フラッシュメモリからデータを読み出して展開処理（展開中状態）へ移行する「条件2」は、収集情報および分析情報がフラッシュメモリに保存されている場合となります。

高得点のポイント

• フラッシュメモリからの読み出し（展開）が発生する条件が、「フラッシュメモリに収集情報及び分析情報が保存されている場合」であることを正確に抜き出して記述している。

図6「タスク間通信シーケンスの例」 における工程2のドライバタスク d, e, f を特定します。
工程2（転造工程）には、投入センサ、産出センサ、状態センサとして振動センサと電流センサの4つのセンサがあります（表3より）。図6にはすでに「振動センサ」が明記されているため、d, e, f は投入センサ、産出センサ、電流センサのいずれかです。

シーケンス図の下部、メッセージ (25) で d から工程2へ通知があり、その直後のメッセージ (26) で工程2から出力タスクへ「出力指示」が送られています。
表9「工程」 タスクの処理を見ると、「通知元が，状態センサのドライバである場合，設備及び工程の稼働状態を決定する。決定した稼働状態が“設備異常”の場合は，出力タスクに“出力指示”を通知し...」とあります。
つまり、「出力指示」の直前に通知を送ってきた d は状態センサでなければなりません。状態センサのうち振動センサは別にあるため、d はもう一つの状態センサである 「電流センサ」 となります。

各選択肢の解説

• ア (投入センサ): f が該当します（解説は q2_sq2_8 参照）。
• ウ (産出センサ): e が該当します（解説は q2_sq2_7 参照）。

図6「タスク間通信シーケンスの例」 における工程2のドライバタスク e を特定します。
d は電流センサであることが分かりました（q2_sq2_6の解説参照）。残る e と f は投入センサまたは産出センサです。

シーケンス図において、メッセージ (20) と (23) で f から工程2へ通知があった直後、それぞれメッセージ (21) と (24) で工程2から工程1へ通知 (g) を行っています。
表9「工程」 タスクの処理を見ると、「通知元が投入センサのドライバで，かつ，前の工程が存在する場合，通知された投入量を，前の工程の工程タスクに“投入量通知”で通知する。」とあります。
これより、前の工程（工程1）へ通知を送るトリガーとなっている f が投入センサであると分かります。

消去法により、残った e は 「産出センサ」 となります。

各選択肢の解説

• ア (投入センサ): f が該当します。
• イ (電流センサ): d が該当します。

図6「タスク間通信シーケンスの例」 における工程2のドライバタスク f を特定します。

シーケンス図を見ると、メッセージ (20) や (23) で f から工程2へ通知が送られ、その直後にメッセージ (21) や (24) で工程2から工程1へ通知 (g) が送られています。
表9「工程」 タスクの処理概要には、「通知元が投入センサのドライバで，かつ，前の工程が存在する場合，通知された投入量を，前の工程の工程タスクに“投入量通知”で通知する。」と明記されています。
したがって、自工程からの通知を契機として前の工程にメッセージを中継している f は 「投入センサ」 となります。

各選択肢の解説

• イ (電流センサ): d が該当します。
• ウ (産出センサ): e が該当します。

図6「タスク間通信シーケンスの例」 において、メッセージ g は工程2から工程1へ送られています。

工程2において、ドライバタスク f（投入センサ）から値を受け取った直後に送信されています。
表9「工程」 タスクの処理概要を見ると、「通知元が投入センサのドライバで，かつ，前の工程が存在する場合，通知された投入量を，前の工程の工程タスクに “投入量通知” で通知する。」とあります。

したがって、後続の工程（工程2）から前の工程（工程1）へ送られるメッセージ名は「投入量通知」となります。

高得点のポイント

• 投入センサからの通知を契機として前の工程に送られるメッセージが「投入量通知」であることを正確に抜き出している。

図6「タスク間通信シーケンスの例」 を見ると、メッセージ h は、タッチパネルからメインタスクへ「ボタン押下（中断）」が通知され、メインタスクが生産ラインタスクへメッセージを送った後、生産ラインタスクから各工程タスク（工程1、工程2）へ送られているメッセージです。

表9「生産ライン」 タスクの処理概要には、「メインタスクから“中断”，“再開”を受けると，全ての工程タスクに転送する。」とあります。
このタイミングでは「中断」ボタンが押下されているため、生産ラインタスクが工程タスクに転送するメッセージ名は 「中断」 となります。

高得点のポイント

• メインタスクからの「中断」指示が生産ラインタスクを経由して工程タスクに転送される際のメッセージ名が「中断」であることを正確に抜き出している。

図6「タスク間通信シーケンスの例」 を見ると、メッセージ i は、タッチパネルからメインタスクへ「ボタン押下（再開）」が通知され、メインタスクが生産ラインタスクへメッセージを送った後、生産ラインタスクから各工程タスク（工程1、工程2）へ送られているメッセージです。

表9「生産ライン」 タスクの処理概要にある通り、「メインタスクから“中断”，“再開”を受けると，全ての工程タスクに転送する。」という動作に従っています。
このタイミングでは「再開」ボタンが押下されているため、転送されるメッセージ名は 「再開」 となります。

高得点のポイント

• メインタスクからの「再開」指示が生産ラインタスクを経由して工程タスクに転送される際のメッセージ名が「再開」であることを正確に抜き出している。

図1「本システムの概要」において、工程はラインの上流から下流へと配置されています。表2によると、S工場の生産ラインでは圧造工程の次に転造工程が行われるため、圧造工程が上流（前の工程）、転造工程が下流（次の工程）となります。

図6「タスク間通信シーケンスの例」 を見ると、工程2から工程1に対してメッセージ g（投入量通知）が送られています。
表9「工程」 タスクの処理概要において、「前の工程が存在する場合，通知された投入量を，前の工程の工程タスクに“投入量通知”で通知する。」とあります。
工程2が「前の工程」である工程1に対して通知を送っていることから、工程1が上流の圧造工程、工程2が下流の転造工程であることがわかります。
したがって、圧造工程は 工程1 です。

各選択肢の解説

• イ (工程2): 工程2は工程1へ通知を送っている主体であり、下流にあたる転造工程です。

工程1が圧造工程である理由は、タスク間のメッセージの向きから判断できます。

表9「工程」 タスクの処理概要に、「通知元が投入センサのドライバで，かつ，前の工程が存在する場合，通知された投入量を，前の工程の工程タスクに“投入量通知”で通知する。」と規定されています。
図6のシーケンス では、工程2から工程1に対してメッセージ（投入量通知）が送信されています。これは工程1が「前の工程（＝ラインの上流にある工程）」であることを意味します。
表2の順番から、上流の工程が圧造工程であるため、工程1が圧造工程となります。

高得点のポイント

• メッセージ（投入量通知）が後続工程から先行工程へ送られる仕様を理解している。
• 図6において「工程2から工程1へ通知が送られている」という事実を端的に記述できている。

破線（ア）の直前のシーケンスを確認します。
メッセージ (25) で d（状態センサである電流センサ）から工程2へ通知が送られ、その直後のメッセージ (26) で工程2から出力タスクへ「出力指示」が送られています。

表9「工程」 タスクの処理概要によると、「決定した稼働状態が“設備異常”の場合は，出力タスクに“出力指示”を通知し...」とあります。したがって、この時点で工程2内にある設備（転造機1台）の稼働状態が「設備異常」であると判定されています。

次に 表5「工程及びラインの稼働状態を決定するための条件」 を確認します。工程の稼働状態について、「工程内の一つ以上の設備が“設備異常”」である場合、その工程の状態は “工程異常” と決定されます。
したがって、工程2の稼働状態は「工程異常」となります。

高得点のポイント

• 出力指示が出ていることから、設備の稼働状態が「設備異常」になっていることを正しく特定できている。
• 表5の条件に当てはめ、一つでも設備異常がある工程は「工程異常」となることを導出できている。

破線（ア）のタイミングにおけるラインの稼働状態を求めます。

設問の条件として、工程1（圧造工程）の稼働状態は“工程動作”であると与えられています。
また、q2_sq2_14の解説の通り、工程2（転造工程）の稼働状態は“工程異常”となっています。

表5「工程及びラインの稼働状態を決定するための条件」 において、ラインの稼働状態を確認します。
「ライン内の一つ以上の工程が“工程異常”」である場合、決定されるラインの稼働状態は “ライン異常” となります。
工程2が“工程異常”であるため、この条件に合致し、ライン全体の稼働状態は“ライン異常”となります。

高得点のポイント

• 工程2が「工程異常」であることを前提として、表5のラインの稼働状態決定条件を正しく適用できている。

新システム導入に伴う、S工場のモデルデータの増減バイト数を計算します。

元々のS工場のモデルは、自工場が担当する2つの工程（圧造工程、転造工程）の情報を保持していました。新システムでは可視化装置に「他工場の工程情報をサーバから受信する機能」を追加するため、モデルに他工場が担当する熱処理工程と表面処理工程の情報が追加されます。

〔モデルの変更点〕 を基に増減を計算します。

1. 共通の追加分:
   • 作成日時の次に「サーバへの接続情報」として 64バイト を追加。
2. 他工場が担当する工程（熱処理工程・表面処理工程）の追加分:
   • 追加される工程数は 2工程 です。
   • 他工場の工程では、投入・産出センサ情報(各264)、設備数(2)、設備情報が記述されません。
   • 記述される構成要素は、図2の「工程に関する情報」から削減対象を除いたものです。
     • 工程名: 32バイト (先頭に"@"が付加されるがバイト数変更の言及なし)
     • 工場ID: 4バイト (新規追加)
     • 出力ノードの識別ID: 4バイト (削減リストに含まれていない)
   • したがって、1つの他工場工程あたりのバイト数は $32 + 4 + 4 = 40$ バイトです。
   • 2工程分で $40 \times 2 = 80$ バイトとなります。

これらを合計すると、$64 + 80 = 144$ バイト増加します。
よって答えは 144 となります。

表6「可視化装置が算出するロットごとの生産指標」 に列挙されている指標について、各工場の工程タスクで算出できるかを確認します。

表6の中で、「工程間滞留量」は「工程生産量 − 次の工程への投入量」という式で算出されます。
U工場は「表面処理工程」を担当しており、表2の工程一覧を見ると表面処理工程はラインの「最後の工程」です。
最後の工程であるため「次の工程」が存在せず、その結果として「次の工程への投入量」を受け取ることができません。

したがって、U工場の工程タスクでは「工程間滞留量」を算出することができません。

高得点のポイント

• 表面処理工程がラインの最後の工程であり「次の工程が存在しない」という関係性から、工程間滞留量が計算不可能であることを導き出せている。

転造工程の工程間滞留量の算出式は、表6 より「工程生産量 − 次の工程への投入量」です。

S工場の転造工程の「次の工程」は、T工場が担当する熱処理工程です。
問題の条件で「S工場が稼働し，T工場が休業している」とされています。
T工場が休業しているため、熱処理工程への投入が行われず（投入センサが反応せず）、サーバを経由して送られてくる「次の工程への投入量」はゼロのまま増加しません。

一方で、S工場の転造工程は稼働し産出し続けているため、「工程生産量」は時間とともに増加し続けます。
引かれる数（次の工程への投入量）が変わらず、引く元の数（工程生産量）が増えるため、結果として工程間滞留量は「数値が減少しない」、「数値が増え続ける」または「工程生産量と同じとなる」状態として表示されます。

高得点のポイント

• T工場（次の工程）が休業しているため投入量が増加しないことを理解している。
• S工場が稼働しているため工程生産量のみが増加し、結果として滞留量が増え続けるという計算結果を論理的に表現できている。

表11「制御プログラムのタスク変更概要」 において、工程タスクが新たにサーバ接続タスクに対して通知するようになった内容 j が問われています。

新システムでは、各可視化装置は自工程の情報をサーバに集約させる必要があります。
表9「制御プログラムの主なタスクの処理概要」 において、工程タスクは従来「1秒ごとに，工程情報を生産ラインタスクに“工程情報通知”で通知する」という処理を行っていました。
この生産ライン全体の稼働状況や表示更新に必要な情報群（工程情報通知）をサーバにも共有することで、他の工場が情報を取得できるようになります。

したがって、工程タスクがサーバ接続タスクに対して送信する通知も「工程情報通知」となります。

高得点のポイント

• 工程タスクが定期的に生成・通知している情報が「工程情報通知」であることを既存仕様から正しく抽出できている。

表11「制御プログラムのタスク変更概要」 における他工場工程タスクの処理「また，[ k ] 場合，投入量を転送する。」の条件を考えます。

表9「工程」 タスクの既存の処理概要を確認すると、「通知元が投入センサのドライバで，かつ，前の工程が存在する場合，通知された投入量を，前の工程の工程タスクに“投入量通知”で通知する」とあります。この仕様の目的は、前の工程が「次の工程への投入量」を使って「工程間滞留量」を計算できるようにすることです。

他工場工程タスクは、サーバから取得した他工場の工程情報を扱います。もしその「他工場が担当している工程」の直前の工程を「自工場」が担当している場合、自工場の工程タスクは工程間滞留量を計算するためにその投入量データを必要とします。
したがって、投入量を自工場の生産ラインタスク（または工程タスク）へ転送しなければならない条件は、「前の工程が存在し、かつ、その前の工程を自工場が担当している場合」となります。

高得点のポイント

• 投入量通知の目的が「前の工程での滞留量計算」であることを理解している。
• 「前の工程が存在し、それが自工場の担当である」という条件を過不足なく記述できている。

表11「制御プログラムのタスク変更概要」 におけるサーバ接続タスクの処理条件 l を考えます。
「[ l ] でない場合，無線 LAN I/F を介して，サーバと通信する。」とあり、サーバと通信を行わない条件を記述する必要があります。

〔モデルの変更点〕 のリストを確認すると、「サーバに接続しない場合は，“サーバへの接続情報”の先頭バイトを0にする。」と明記されています。
したがって、サーバ接続タスクがサーバとの通信処理をスキップする条件は、モデルデータ内の「“サーバへの接続情報”の先頭バイトが0」である状態となります。

高得点のポイント

• モデル変更点の定義に基づき、サーバ接続が無効化されている判定条件を「“サーバへの接続情報”の先頭バイトが0」と正確に記述できている。