「長年稼働しているシステムへの大規模な改造」

私は今年19年目の中堅社員です。
入社して現在まで、様々な分野のソフトウェア開発を経験しておりますが、一番多いのはPLCソフトウェア開発となります。

過去のソフテックだより「第380号（2021年6月16日発行）現場の声編『ソフトウェア開発の理想と現実』」では、新規案件の事例を取り上げ、開発現場の奮闘振りを紹介しました。
何も無いところから作り上げるという新規案件の特徴に対して、プログラムの標準化というアプローチで挑みました。

今回のソフテックだよりでは、これとは対照となる既存システムへの改造案件を取り上げます。
改造案件は新規案件とは違った難しさがありますが、今回取り上げる事例は、長年に渡って同じ仕様で稼働しているシステムに対する大規模改造という、筆者が経験した中で一位二位を争う難しい改造案件でした。
多くの反省点がありながらも、何とか成功に漕ぎつけることができましたが、その開発現場を紹介出来たらと思います。

今回紹介する事例は、筆者が入社間もない頃に初めて担当し、そこから15年以上の間、何度も担当してきた思い入れのあるシステムとなります。
主にPCとPLCで構成されるシステムで、PC 1台とPLC 13台で1つの製造ラインを制御しており、同じラインが合計3ラインあるシステムでした。筆者が経験してきたシステムの中では、5本の指に入るぐらい規模の大きなシステムでした。

図1.  システム構成

過去にPC、PLCと段階的にリプレースを対応しておりますが、基本的な制御仕様はずっと変わらず、ソフテックが関わる前から数えると、30年近く動き続けてきたシステムとなります。
長年稼働するシステムとなると、欲しい設計資料が残っていなかったり、過去に複数の人が改造を重ねたことで理解が難しいプログラムとなっていたりと、既設プログラムの解析に困難を極めるものが多いのですが、本システムもこの特徴にあてはまるものでした。

ソフテックが過去に担当したリプレース案件でも、ハードウェアの違いを吸収する程度の小規模な変更はありましたが、基本的に30年前のプログラム資産をずっと受け継いでいるシステムでした。
このシステムに、今回初めて大規模な改造を加えることとなりました。

今回の改造で、制御する機器の数が約2倍、そして制御に必要なデータ量は約4倍に増加することとなりました。
データ廻りの改造を筆者が担当しましたが、この部分が本案件一番のポイントであり難しい部分でした。

今回の改造で増加するデータは、全てPC、PLC間で共有が必要なデータでした。
PCが送信する設備パラメータや製造レシピデータ、PLCが送信する実績データなど、データを共有することで製造を行っていました。
このデータ共有の部分を既存システムの設計方針に沿った形で改造できれば楽だったのですが、それができないことがこの改造が難しい理由でした。

既存システムの設計では、CC-Link IE Controlユニットのサイクリック伝送機能を用いて、プログラムレスでデータ共有を行っていました。
しかし、今回増加するデータ量では、サイクリック伝送機能が扱うことができる容量の制限を超えることが分かり、データ共有方法を大きく設計し直す必要がありました。

代わりに採った方法は、トランジェント伝送機能。
この機能を用いると、必要なタイミングで必要なデータのみを送受信することが可能となります。
プログラムレスだったサイクリック伝送に比べ、自前でプログラムを製作する難しさはありますが、常時データ共有を行う必要がなくなるため、システム全体の通信負荷も減らすことができました。

現地で事前確認も行い、この方法で目的の仕様を実現できることは分かりましたが、ソフト変更ボリュームは大きく増加することとなりました。
トランジェント伝送を利用した通信処理の実装が必要となったことに加え、共通データを参照している箇所全てに対して改造を加える必要がありました。

改造対象のデータを漏れなく洗い出し、全てのデータにおいて取得タイミングが変わることで問題ないかの検証と、トランジェント伝送で取得したデータを参照するように参照先アドレスの変更を行いました。
１つ１つの作業内容は比較的単純ではありますが、数が多く、影響範囲も広く、難しい作業となりました。

一通り改造を終え、社内に構築したシミュレーション環境を使って試験を始めましたが、残念ながら多くのバグが見つかる結果となってしまいました。

社内試験でバグが続出する状態でしたが、見つかったバグを全て取り除き現地調整に臨むことができました。
それができた理由は、実際のシステムに可能な限り近付けたシミュレーション環境を構築し、本番さながらの試験を繰り返すことができたためでした。

システムの規模が大きく、既存プログラム全てを把握している訳ではないため、以前から本システムのシミュレーションは困難であることが分かっていました。
しかし、必要なPLC等の機材を集め、必要な既存プログラムの解析、シミュレーション用の回路の製作などなど、プロジェクトメンバーが分担して準備し、これを実現しました。

シミュレーションを1回動かすにも大変なシステムなのに、バグを多く出したデータ廻りの確認のため、何度も何度も試験に付き合ってもらいました。本当に感謝です。
これが無いまま現地調整を迎えていたらと考えるとゾッとします。

それ以外にも、極力人手によるコーディングミスを減らすよう、工夫できるところは工夫して作業を行っていました。
例えば、デバイスデータの転送を行う回路が大量にあるとすれば、転送元と転送先のデバイスアドレスを定義した設計書から、コピー&ペーストでラダー回路を入力できるようにするなどです。
デバイス置換など、PLCプログラミングツールの機能は積極的に活用しますが、Excelなど外部アプリケーションも駆使して、なるべく人為的ミスを減らすよう努力しています。

本件の例では、PLC間で共有している膨大なデータを、PLC内部の制御で使用する領域に取り込んだり、通信用の領域に転送したりと、データを転送する処理が多くありました。
ラダー命令では、BMOV(ブロック転送)命令を多く記述することとなりますので、設計書からExcelの数式を利用してラダー命令の文字列を生成するといった工夫を行っています。

幸いプロジェクトメンバーの協力のお陰で現地調整までにバグを潰すことができました。
社内試験でバグを多く出してしまった理由を振り返ると、以下の通りだったと思います。

1) 影響範囲の見極めがまだまだ甘かった

2) 設計時の考慮漏れの積み重ねが作業スケジュールを圧迫

筆者は多くのPLC案件を経験していますが、案件によって難しいポイントは様々だと思います。
今回紹介した案件は、既存の基本動作は極力変えずに改造するところが難しい点でしたが、本文で述べた通り、既存プログラムの把握と影響範囲の見極めがポイントでした。

これに対して新規案件は、また別の難しさがあります。
新規案件については、「第380号（2021年6月16日発行）現場の声編『ソフトウェア開発の理想と現実』」でも紹介しています。

改造案件、新規案件両方に共通して言えることは、上流フェーズの大切さであると思います。
改造案件ならば、改造の要求仕様をしっかり決めた上で、改造範囲を洗い出すこと。
また、要件定義、設計、製作、試験と進むソフトウェア開発フェーズのなかでも、最上流からしっかりと品質を作り込んでいくこと。
ソフトウェア開発で大切なのは、これに尽きるなとつくづく感じました。
今回の気付きを今後の開発に生かしていきます。