「ソフテックだより」では、ソフトウェア開発に関する情報や開発現場における社員の取り組みなどを定期的にお知らせしています。
さまざまなテーマを取り上げていますので、他のソフテックだよりも、ぜひご覧下さい。

ソフテックだより（発行日順）のページへ
 ソフテックだより技術レポート（技術分野別）のページへ
 ソフテックだより現場の声（シーン別）のページへ

ソフテックだより第３９９号（2022年4月6日発行）
技術レポート

「大規模システム試験」

1. 初めに

私は入社12年目の中堅社員です。これまでいくつものPLC案件を手掛けてきましたが、今回は大規模構成開発案件での試験について紹介したいと思います。

2. システム構成

今回私が担当したシステムの構成について説明します。前章でも記載しましたが、メインコントローラが１台とその下に最大100台の制御コントローラを構成します。コントローラは三菱PLCで、CC-Link IE Controlネットワークで接続されており、図1のようになっています。

図1. システム構成図

3. システム機能

システム機能について説明します。このシステムはホストシステムからの指示を元に、メインコントローラ(Main)でシステム全体の制御出力値を計算します。
システム全体の制御出力を各制御コントローラで担っており、マスタノード(No.1)と呼ばれる１台の制御コントローラでスレーブノード(No.2～100)の担当制御量を割り当て、それぞれ制御出力する事でシステムを実現します。図2がイメージ図です。制御出力の計算は単純に台数で等分するのではなく、それぞれの制御対象の周辺機器の状態、制御可能範囲によって変化します。

図2. 制御出力の流れ

4. 試験内容

それでは実際に行った大規模システム試験についていくつか記載していきます。

4-1. 各担当制御出力確認

試験内容	マスタノードで計算された各担当制御出力値に間違いはないか？
確認項目	各スレーブノードの制御出力と、システムの制御出力値（各担当制御出力の合計値）に問題が無いことを確認します。
機能	各スレーブノードの制御出力はメインコントローラの指示値から等分するものではなく、スレーブノードの状態によって決まります。
デバック機能	今回の大規模試験ではコントローラはありますが、周辺機器はない為、模擬的に周辺機器から入力を与える模擬ソフトを用意しました。模擬ソフトは各スレーブノードの状態を変化させますが、複数選択も可能にし、一括で変更できるよう工夫し、状態変化を簡単に行えるようにしました。
異常系確認	このシステムはある一つのスレーブノードで異常発生し、出力できなくなった場合には制御出力が“0”となり、異常ノードが出力する予定だった制御量を他の正常なスレーブノードで補う仕組みになっていますのでその試験も実施しています。異常時に出力できなくなるパターンは多数あり、それらすべての試験パターンを用意しました。異常パターンの試験では、各種異常発生させる試験プログラムを用意して試験を実施しています。

4-2. 処理速度測定

試験内容	メインコントローラからの指示値が末端のスレーブノードに通知され、出力されるまでの処理速度に問題はないか？
確認項目	メインコントローラからの指示値出力タイミングと、末端のスレーブノードに通知され制御出力するタイミングでそれぞれアナログ出力し、時間差を計測します。
システム仕様	今回のシステムではメインコントローラ指示から実際にスレーブノードより制御出力されるまでに数百msecで動作する要求仕様がありました。各ノード処理速度を意識して設計、製作しており、理論値上は要求仕様を満たしていましたので、実際に時間計測することで要求仕様を満たしている事を確認するのが、この大規模システム試験の目的の一つでした。
デバック機能	メインコントローラからの指示値を出力するタイミングで、アナログ出力を行うデバック回路を入れました。これにより、メインコントローラのアナログ出力、末端スレーブノードのアナログ出力をサンプリングすることで、処理時間を計測することが可能です。
CC-Link IE Control とオシロスコープ	制御出力の制御の流れは『メインコントローラ→マスタノード→各スレーブノードNo.2~100』という経路となり、Ethernet～CC-Link IE Controlと情報のやり取りを行います。CC-Link IE Controlはリンク点数により、リンクスキャンタイム(※1)、リンクリフレッシュ時間(※2)はもちろんのこと、スキャンタイムにも影響します。処理速度の測定を行うのは、図２で示した通り、メインコントローラのアナログ出力～末端の各スレーブノードのアナログ出力までの時間です。今回は正確に処理速度計測を行うためにオシロスコープを使用しました。

図3. 処理速度計測方法

4-3. 異常発生時

試験を進める中で想定されない動きがありました。その際の現象について記載します。

現象	リンクケーブル断線→復帰のタイミングで、すぐに出力を再開はせず、数百msec遅れて出力されました。
機能	今回のシステムでは接続台数が多く、リンク点数も1台辺りワードデバイス320点、100台で32000点と非常に多いリンク点数となります。 32000点のリンクリフレッシュ時間は13.3msecです。CC-LINK IEユニット機能の自動リフレッシュを使うと、13.3msecがプログラムのスキャンタイムに加算されます。しかし、このスレーブ側のリンク情報の更新時間は1秒周期でOKな為、自動リフレッシュはOFFにして、プログラムでリフレッシュ動作を行うことにしました。具体的にノード100台を25ブロックに分けて、１スキャンで１ブロックを更新する仕組みにしました。これにより、25スキャンで100ノード分の更新が行われることになりますが、それにより、スキャンタイムを高速化することができました。
原因と対策	CC-LINK IEユニット機能の自動リフレッシュを使わず、ソフト側で４台ずつ順番に読み込みをすることで、リンク復帰後も全てのスレーブノードの情報を収集するのに、複数スキャンかかります。その結果、制御出力の計算にも影響が出ていました。この点は設計考慮不足でしたので、対策として全てのノードの情報を収集してから計算する対策を行いました。

5. まとめ

今回の大規模システム試験において、工夫したポイントや苦労した点について記載します。

5-1. 工夫した点①

まず工夫した点としてはデバック機能です。制御出力の確認のために、事象を作りやすいように一括でスレーブノードの状態を変化させる機能を準備しました。この機能のおかげで試験を効率よく進める事ができました。
また、実際の環境に近づけるために、出力状態によりスレーブノードの状態を変化させる処理も用意しました。このデバック機能を充実させたことで、当初の試験項目には用意していなかった『こんな時はどうなるのか？』などの追加試験にも臨機応変に対応することができました。

5-2. 工夫した点②

次に工夫した点としては試験機材の構成で、処理時間の計測を行うためにオシロスコープを使いました。メインコントローラ制御指示、スレーブノード各制御出力の波形をとることで、今回のシステムの要求仕様である処理時間を達成している事を正確に確認することができました。

5-3. 苦労した点

想定された処理時間を超えるパターンがあり、なぜそうなったのか？タイミングだけの問題なのか？処理に問題があるのか？の切り分けが難しく、理論値を計算し、実際の試験結果は許容範囲に収まっているか？を都度確認しながら試験を進めました。
『4-3.異常発生時』で記載した内容の他に、想定外の動きとして、切断の異常検知が遅く、本来は切断されているのに出力してしまう動きをしているところがありました。この原因はコントローラ内部で他ノードのライフチェックを行っており、ライフチェックのタイムアップで出力を停止する処理にありました。これでは、タイムアップするまで異常検知できず、その間出力を続けてしまいます。この点はCC-LINK IEユニットのネットワーク状態も条件に追加することで、切断を即座に検知することができ、リンク異常時は制御出力を停止する対策をしました。

6. 最後に

今回の大規模システム試験では、発生した現象に対してなぜそうなるのか？説明できない事象が複数発生しました。本来であれば、想定される動きになることを確認するはずの試験で想定外の動きをしたため、原因を追究するのに苦労しましたが、今回の試験をしたからこそ分かったことはいくつもあり、私にとってもとても勉強になりました。
まだまだ未熟者ではありますが、日々精進していきたいと思います。最後までお読みいただき、ありがとうございました。

（S．S．）

[注釈]

※1: ネットワークの各局が順番にデータを送信し、1周するのに要する時間です。
リンクスキャンタイムは、データ量やトランジェント伝送要求などにより変動します。
※2: CC-Link IE ControlネットワークユニットのリンクデバイスとCPU ユニットのデバイス間のデータ転送を行う処理の時間です。
リンクリフレッシュは、CPU ユニットのシーケンススキャンの“END 処理” に行われます。