納入した装置と同じものが自社にない

客先へ装置を納入すると、自社には同じ構成の実機が残っていないことがあります。

不具合の連絡を受けても、確認できるのは客先から送られてくるログ、エラーコード、担当者からの聞き取りなどに限られます。

比較的単純な装置であれば、これらの情報から原因を推測できることもあります。

一方で、機械、センサ、モータ、通信、PLC、制御ソフトウェアなどが複雑に関係する装置では、どこに問題があるのか、すぐには分からないことがあります。

• センサの一時的な誤検出なのか
• 機械やモータの動作遅れなのか
• 通信のタイミングが原因なのか
• 制御ロジックやPLCプログラムの問題なのか
• 複数の条件が重なって発生したのか

原因を調べるために現地へ行っても、その場では不具合が再現しないこともあります。

また、客先の生産設備を使って、さまざまな条件を試すことも簡単ではありません。

自社で不具合を再現できないか

このような課題から、

客先で起きた不具合を、自社のシミュレーション環境で再現できないか

と考え、モデルベース開発を始める場合があります。

実際の装置の代わりとなるモデルを作り、制御ソフトウェアやPLCプログラムと接続します。

そして、客先のログや発生条件を参考にしながら、

• センサ信号の変化
• モータや機械の動作時間
• 通信の遅延や途切れ
• ワークの有無や詰まり
• 装置間の信号や動作順序
• オペレータの操作

などをシミュレーション上で再現します。

条件を一つずつ変えて確認することで、どの要素が不具合に影響しているのかを切り分けやすくなります。

複雑な装置では、装置全体を一度に調べるよりも、モデル上で構成要素ごとの動きを確認する方が、原因の候補を絞りやすい場合があります。

対策を現地へ持ち込む前に確認する

シミュレーション環境は、不具合の原因調査だけでなく、対策後の確認にも利用できます。

制御ソフトウェアを修正した後、同じ不具合条件をシミュレーション上で再現します。

さらに、

• 元の不具合が解消しているか
• 通常運転に影響がないか
• 別の不具合を発生させないか
• 異常停止や復旧が正しく動くか

などを、客先へ適用する前に確認します。

現地で初めて修正版を試すのではなく、自社で事前に検証しておくことで、現地作業の時間や客先設備を停止するリスクを減らせる可能性があります。

装置全体を精密にモデル化する必要はありません

このような取り組みを始める際に、最初から装置全体を精密にモデル化する必要はありません。

例えば、

• 問題が起きやすい一つの機能
• センサと制御ソフトウェアの関係
• 搬送動作の順序とタイミング
• 装置間の信号の受け渡し
• 異常停止や復旧のシーケンス

など、確認したい範囲に絞ってモデル化することもできます。

既存のC言語やPLCプログラムを残したまま、その周囲の機械やセンサだけをモデルとして再現する方法もあります。

保守の困りごとから始めるモデルベース開発

モデルベース開発の始め方は、会社や製品によってさまざまです。

設計期間を短縮したい、新しい制御方式を試したい、自動コード生成を行いたい、といった目的から始めることもあります。

一方で、

• 納入後の装置トラブルを自社で再現したい
• 複雑な装置の原因調査を効率化したい
• ソフトウェアの対策を事前に確認したい
• 過去の不具合を再利用できるテストとして残したい

といった保守・サービス上の課題が、モデルベース開発を始めるきっかけになることもあります。

まずは一つの不具合や一つの装置動作をシミュレーション上で再現する。

そこから少しずつ対象範囲を広げ、新しい装置の設計や事前検証にも活用していく。

このような始め方も、モデルベース開発を現場に定着させる一つの方法です。