「分散型監視システムの通信検証」

ソフテックでは、PLC、マイコン、パソコンを組み合わせたシステムの提案や開発を行っています。
これらを組み合わせたシステムでは、各機器を通信により接続して構成するため、ソフテックの開発では、通信の知識が重要な要素となっています。

通信部分の開発については、他の「ソフテックだより」でも触れているため、今回は、最近、私が担当した分散型監視システムの通信の検証について紹介します。
文章構成は以下のとおりです。

1. 検証システムのシステム構成
2. 検証内容の検討
3. 検証作業
4. ヒートラン
5. 次の開発へのフィードバック

少し長文となっておりますが、最後まで読んで頂きたいと思います。

今回の検証対象システムは、Ethernet、HDLC、RS-485など様々な通信規格が利用されています。
以下にシステム構成の概要図を示します。

図1. 検証したシステムの構成概要図

システムは監視システム1から4で収集した情報を、情報管理部が一括管理して、監視状態を操作部へ通知します。また、操作部からの制御要求に対して、監視システムが必要な制御を行います。

監視システムの構成は省略しますが、パソコンと複数のマイコン基板で構成され、入出力制御やセンサ状態の収集を行っています。

監視システムと呼ばれる部分が4箇所に分散していることから分散型監視システムと呼びます。

ソフトウェアを検証する際には、プログラムを把握してテストする、「ホワイトボックステスト」とプログラムには依存せずに、外部仕様を満たしていることをテストする「ブラックボックステスト」があります。

ソフテックでは、開発者がホワイトボックステストとブラックボックステストを実施することが多いのですが、今回の検証では、システム規模が大きいため、第3者の視点でブラックボックステストを実施しました。
開発担当者がテストするメリットとして、仕様を深く把握しており、プログラムを作った立場から、仕様書に記載されていない細かな部分まで検証することが出来ます。
ただし、逆の視点で見ると、自分が作ったところ以外を考慮出来ていないこともあります。

1対1の小規模な通信であれば、開発担当者の確認でも良いのですが、今回のシステムでは通信仕様書だけで、11種類もあるシステムで、通信部分の開発に10人以上関係しているため、全ての通信仕様を把握した人が、テストする必要があります。
また、この通信仕様書もソフテックの3名で検討および設計してお客様へ提案させて頂いており、この仕様の整合が取れていることを確認することも検証の一環としていました。

今回の検証は以下の項目で実施しました。

1. 各機器の起動順序による依存がないことを確認
2. システムが正常な状態から、個々の機器を再起動した場合に正常な状態にリカバリされることを確認
3. 断線など通信異常が発生している状態でも起動することを確認
4. 通信異常が確実に検出されることを確認
5. 短時間に発生した通信異常は再送信でリカバリされることを確認
6. 異常状態か正常になった場合にシステム全体が正常状態にリカバリされることを確認
7. 通信負荷を上げた状態でも、情報が確実に通知されることを確認
8. 受信バッファまたは、送信バッファが一杯になった場合の動作確認
9. 正常状態でのヒートラン
10. ノイズなど悪環境を想定したヒートラン

通信処理は、通常は正しく動作しており、問題が内在していても表面化しません。
ただし、納入する場所によっては、ノイズ発生源が近くにあり、そのノイズによりデータが壊れる場合や、メンテナンスのために機器の一部を停止した場合などに、社内開発時とは違う状況となり、問題が表面化することがあります
このため、現場で発生する問題をどこまで想定して検証できるか？ということが検証のポイントとなります。
今回の検証では、通信全体の仕様を確認する視点と、上記のような納入先での運用という２つ視点で、検証項目をリストアップしました。

上記3．のa〜hの作業は、手作業と目視により確認しました。
通信経路ごとに、検証を実施しますが、パソコンを再起動させて、プロトコルアナライザでデータを眺めて、不適合の兆候がないか確認したり、様々なタイミングでケーブルを抜き差ししながら、異常の検出やリカバリがされることを確認するなど、時間がかかる地味な作業でした。

開発時もテストを実施しているため、今回の検証を進めても簡単に問題は出ません。
こうなると「センサの状態が遠隔監視まで届いているので問題ないのではないか？」という手を抜きたくなる気持ちも出ましたが、「一つでも問題点を見つけなければ自分の作業意味がない」と気持ちを自分で引き締め直しながら、検証を継続しました。

結果的には数点の問題点を発見することが出来ました。
通信システムの検証では、通信の特徴を理解して、正しく動作していると判断することも難しいのですが、それ以上に難しいのは、問題が発生した場合の修正です。

通信は必ず通信相手が存在します。
このため、問題があった場合は、2名以上の開発担当者が存在します。
今回のシステムは通信経路が多く、通信仕様も階層化しているため、単純に送信側と受信側の担当者だけではなく、階層ごとの開発担当者やマイコン側のドライバ開発担当者まで必要になることがあります。
これだけの関係者がいると全員で調査する訳にもいかず、通信ログの解析をして、原因予測と根拠（証拠）を提示した上で、関係者を絞り込んで調査依頼をするまでが、私の担当となります。
ソフテックが開発依頼を頂くシステムの多くは通信を利用するシステム構成となっており、ほとんどの社員が通信を経験しています。
このため、問題が見つかっても、「こうなるべき」という意思疎通は社内で出来ているため、調査依頼した後は、正しく修正してもらえました。

ヒートランとは、ある特定の状態で動作を継続させるテストです。
今回は、センサから異常を出して、遠隔監視PCから定期的にシステムの復旧を行うことで、異常検出と復帰を繰り返す仕組みを作りました。

上記の状態を繰り返す以外にも、今回は通信の検証であることから、通信回線の断線と復帰を繰り返す仕組みも入れて検証を実施しました。
具体的には、図2のような仕組みをPLCで構成し、タイマーによりリレーのON/OFF時間を制御する仕組みを作りました。

図2. 通信回線の断線/復帰の仕組み

この仕組みでは、通信ラインが定期的に断線するため、通信データが断線のタイミングで破壊されます。
データが破壊されることで、異常なデータとなりますが、異常検出処理でデータを破棄し、再送信処理で復旧されることを確認します。
この仕組みは、ノイズなどの影響で、通信データが壊れやすい現場で運用したことを想定しており、システムの堅牢性を確認する作業とも言えます。

ヒートランは、夜帰宅する前にスタートし、翌朝の出社時に監視システムの動作ログや通信ログを全て収集してから解析を行います。

1回の解析では、約1万件の監視システム動作ログをパソコン6台分に対して実施します。
解析結果から、動作ログに異常が見つかると、通信ログの解析となります。
動作ログはエクセルなどを利用して集計しやすくなっていますが、関係者への社内報告の時間を含めると、問題が見つからなくても3時間程度はかかる作業となりました。

通信ログは1つの経路で1晩あたり10万件の通信情報が蓄積されています。
経路が多いため、どこの経路で情報がおかしくなったのか、各経路を順番に調べていく必要があります。
調査では、動作ログで問題が記録されている時刻と同じ時刻の通信ログを探し出して、何が問題であったのか調べることになります。

この調査の際に、動作ログの時刻と通信ログの時刻が1分でも違うと、情報が信用できず、対象となる時刻近辺のログを全て調査することになり、作業量が大幅に増加してしまうことがありました。
ヒートランの初期は、その解析の大変さが分からず、意識していませんでしたが、1度経験したため、時刻の同期ツールを利用し、全てのパソコンの時刻を合わせることで、それ以降の解析ではデータを絞り込むことが出来ました。

また、ヒートランの初期では、通信ログを収集するツールが保持できるデータ量が少なく、肝心な場所のデータが残っていないこともありました。
通信ログを収集するツールはソフテックで開発していたため、ログの保存量を増やす対応をしましたが、表示する時間が遅くなるなど、使い勝手が悪くなってしまい、何度か修正をしてヒートランに耐えるログ収集ツールを作成することも行いました。

このヒートランでも、1晩に1回程度しか発生しない、タイミングに依存する問題を発見することが出来ました。

今回の規模になると、通信に関係する開発担当者が多く、同じ仕様書を読んでいても、行間の読み方しだいでは、不適合に繋がる状況が発生してしまうことを経験しました。
また、通信のプロトコルが階層化されているため、その1つ1つの階層の信頼性を積み上げることが、通信全体の信頼性に繋がることも、再認識する機会になりました。

ソフテックでは、ソフトウェアや通信など信頼性を上げる試みを開発時に取り入れています。
今回の経験も、フィードバックしたいと考えていますが、その試みの例を紹介します。

ソフテックでは、通信部分を開発するのと同時に、シミュレータなど擬似的な通信相手を開発することが多々あります。このような時には、擬似的な通信相手に「通信異常を強制的に発生させる機能」を持たせます。
例えばCRC異常検出する仕組みをテストするためには、CRC異常を発生させる必要がありますが、通常の通信をしている環境でCRC異常を作りだすことは難しいことです。
このような場合は、擬似的通信相手にCRC異常を出す機能を事前に入れておくことで、CRC異常検出できることを確認することが出来ます。

最初にも書きましたが、通信は正常な状態で動作させるのが普通であり、異常な状態は簡単に発生しません。しかし、通信部分を設計する際は、簡単に発生しない異常を、どれだけ考慮しているか？ということが重要であるため、開発時にしか利用しない異常発生機能は重要な機能だと考えて組み込んでいます。

今後も、上記のような開発時のノウハウと効率良く信頼性を上げるノウハウの蓄積を継続して、良い製品を提供できるようにしたいと思います。