「ソフテックだより」では、ソフトウェア開発に関する情報や開発現場における社員の取り組みなどを定期的にお知らせしています。
さまざまなテーマを取り上げていますので、他のソフテックだよりも、ぜひご覧下さい。
ソフテックだより(発行日順)のページへ
ソフテックだより 技術レポート(技術分野別)のページへ
ソフテックだより 現場の声(シーン別)のページへ
私は入社12年目の中堅社員です。これまでいくつものPLC案件を手掛けてきましたが、今回は大規模構成開発案件での試験について紹介したいと思います。
今回私が担当したシステムの構成について説明します。前章でも記載しましたが、メインコントローラが1台とその下に最大100台の制御コントローラを構成します。コントローラは三菱PLCで、CC-Link IE Controlネットワークで接続されており、図1のようになっています。
図1. システム構成図
システム機能について説明します。このシステムはホストシステムからの指示を元に、メインコントローラ(Main)でシステム全体の制御出力値を計算します。
システム全体の制御出力を各制御コントローラで担っており、マスタノード(No.1)と呼ばれる1台の制御コントローラでスレーブノード(No.2〜100)の担当制御量を割り当て、それぞれ制御出力する事でシステムを実現します。図2がイメージ図です。制御出力の計算は単純に台数で等分するのではなく、それぞれの制御対象の周辺機器の状態、制御可能範囲によって変化します。
図2. 制御出力の流れ
それでは実際に行った大規模システム試験についていくつか記載していきます。
試験内容 | マスタノードで計算された各担当制御出力値に間違いはないか? |
確認項目 | 各スレーブノードの制御出力と、システムの制御出力値(各担当制御出力の合計値)に問題が無いことを確認します。 |
機能 | 各スレーブノードの制御出力はメインコントローラの指示値から等分するものではなく、スレーブノードの状態によって決まります。 |
デバック機能 | 今回の大規模試験ではコントローラはありますが、周辺機器はない為、模擬的に周辺機器から入力を与える模擬ソフトを用意しました。模擬ソフトは各スレーブノードの状態を変化させますが、複数選択も可能にし、一括で変更できるよう工夫し、状態変化を簡単に行えるようにしました。 |
異常系確認 | このシステムはある一つのスレーブノードで異常発生し、出力できなくなった場合には制御出力が“0”となり、異常ノードが出力する予定だった制御量を他の正常なスレーブノードで補う仕組みになっていますのでその試験も実施しています。異常時に出力できなくなるパターンは多数あり、それらすべての試験パターンを用意しました。 異常パターンの試験では、各種異常発生させる試験プログラムを用意して試験を実施しています。 |
試験内容 | メインコントローラからの指示値が末端のスレーブノードに通知され、出力されるまでの処理速度に問題はないか? |
確認項目 | メインコントローラからの指示値出力タイミングと、末端のスレーブノードに通知され制御出力するタイミングでそれぞれアナログ出力し、時間差を計測します。 |
システム仕様 | 今回のシステムではメインコントローラ指示から実際にスレーブノードより制御出力されるまでに数百msecで動作する要求仕様がありました。各ノード処理速度を意識して設計、製作しており、理論値上は要求仕様を満たしていましたので、実際に時間計測することで要求仕様を満たしている事を確認するのが、この大規模システム試験の目的の一つでした。 |
デバック機能 | メインコントローラからの指示値を出力するタイミングで、アナログ出力を行うデバック回路を入れました。これにより、メインコントローラのアナログ出力、末端スレーブノードのアナログ出力をサンプリングすることで、処理時間を計測することが可能です。 |
CC-Link IE Control とオシロスコープ |
制御出力の制御の流れは『メインコントローラ→マスタノード→各スレーブノードNo.2~100』という経路となり、Ethernet〜CC-Link IE Controlと情報のやり取りを行います。CC-Link IE Controlはリンク点数により、リンクスキャンタイム(※1)、リンクリフレッシュ時間(※2)はもちろんのこと、スキャンタイムにも影響します。処理速度の測定を行うのは、図2で示した通り、メインコントローラのアナログ出力〜末端の各スレーブノードのアナログ出力までの時間です。今回は正確に処理速度計測を行うためにオシロスコープを使用しました。 |
図3. 処理速度計測方法
試験を進める中で想定されない動きがありました。その際の現象について記載します。
現象 | リンクケーブル断線→復帰のタイミングで、すぐに出力を再開はせず、数百msec遅れて出力されました。 |
機能 | 今回のシステムでは接続台数が多く、リンク点数も1台辺りワードデバイス320点、100台で32000点と非常に多いリンク点数となります。 32000点のリンクリフレッシュ時間は13.3msecです。CC-LINK IEユニット機能の自動リフレッシュを使うと、13.3msecがプログラムのスキャンタイムに加算されます。しかし、このスレーブ側のリンク情報の更新時間は1秒周期でOKな為、自動リフレッシュはOFFにして、プログラムでリフレッシュ動作を行うことにしました。具体的にノード100台を25ブロックに分けて、1スキャンで1ブロックを更新する仕組みにしました。これにより、25スキャンで100ノード分の更新が行われることになりますが、それにより、スキャンタイムを高速化することができました。 |
原因と対策 | CC-LINK IEユニット機能の自動リフレッシュを使わず、ソフト側で4台ずつ順番に読み込みをすることで、リンク復帰後も全てのスレーブノードの情報を収集するのに、複数スキャンかかります。その結果、制御出力の計算にも影響が出ていました。 この点は設計考慮不足でしたので、対策として全てのノードの情報を収集してから計算する対策を行いました。 |
今回の大規模システム試験において、工夫したポイントや苦労した点について記載します。
まず工夫した点としてはデバック機能です。制御出力の確認のために、事象を作りやすいように一括でスレーブノードの状態を変化させる機能を準備しました。この機能のおかげで試験を効率よく進める事ができました。
また、実際の環境に近づけるために、出力状態によりスレーブノードの状態を変化させる処理も用意しました。このデバック機能を充実させたことで、当初の試験項目には用意していなかった『こんな時はどうなるのか?』などの追加試験にも臨機応変に対応することができました。
次に工夫した点としては試験機材の構成で、処理時間の計測を行うためにオシロスコープを使いました。メインコントローラ制御指示、スレーブノード各制御出力の波形をとることで、今回のシステムの要求仕様である処理時間を達成している事を正確に確認することができました。
想定された処理時間を超えるパターンがあり、なぜそうなったのか?タイミングだけの問題なのか?処理に問題があるのか?の切り分けが難しく、理論値を計算し、実際の試験結果は許容範囲に収まっているか?を都度確認しながら試験を進めました。
『4-3.異常発生時』で記載した内容の他に、想定外の動きとして、切断の異常検知が遅く、本来は切断されているのに出力してしまう動きをしているところがありました。この原因はコントローラ内部で他ノードのライフチェックを行っており、ライフチェックのタイムアップで出力を停止する処理にありました。これでは、タイムアップするまで異常検知できず、その間出力を続けてしまいます。この点はCC-LINK IEユニットのネットワーク状態も条件に追加することで、切断を即座に検知することができ、リンク異常時は制御出力を停止する対策をしました。
今回の大規模システム試験では、発生した現象に対してなぜそうなるのか?説明できない事象が複数発生しました。本来であれば、想定される動きになることを確認するはずの試験で想定外の動きをしたため、原因を追究するのに苦労しましたが、今回の試験をしたからこそ分かったことはいくつもあり、私にとってもとても勉強になりました。
まだまだ未熟者ではありますが、日々精進していきたいと思います。最後までお読みいただき、ありがとうございました。
(S.S.)
関連ページへのリンク
関連するソフテックだより