お問い合わせ

03-3510-1616
受付時間 9:00〜17:00(土日除く)

コラム

IoT

事例から学ぶ!機器連携システムのトラブル考察

これまで多くのコラムで、色々な私見を述べて参りました。実を申しますと、今まで述べてきた助言・提言の多くは、私自身が体験し見聞きしてきた各種トラブルへの考察・反省でもあります。今回は、そうしたトラブル事例で印象に残る4例とそこから得られた教訓をご紹介します。
決して皮肉でなく申しますが、「トラブルは宝の山」です!もちろん、トラブルが起きないに越したことはありません。しかし、一度トラブルが発生しても徹底的に分析・対処さえすれば、対象システムだけでなく将来の類似案件をも助けることが可能です。

事例#1:システム⇔設備間の通信異常

<現象>
バッチプラントの運転管理パソコンと原料移送設備間を、RS-232の無手順通信で接続しました。何らかの通信異常のため誤って原料が移送され、高価な製品が規格外⇒廃棄となる問題が発生しました。
<原因>
通信プロトコルは、ITベンダーと設備ベンダーが共同で設計したものでした。その通信ロジックに一部不具合があり、ある特定の条件が揃うと不正な制御メッセージが送られていました。
<対策>
異常が発生する条件はすぐに判明しましたが、局所的なロジック変更だけでは終わりにしませんでした。念のために、当初のフローチャート的な通信仕様をステータス遷移図&通信マトリックスに書き直し、全てのケースを洗い出し徹底的に再検証しました。

<教訓>「分かり易い文書化」、「系統的な設計」、「網羅的なテスト」
今では、通信プロトコルをスクラッチ開発することは滅多になく、各種の通信規格・パッケージを組み合わせてカスタマイズ開発します。それによって相当な部分が標準化されて楽になりますが、だからと言ってそれだけで安心するのは危険です。どんなシステムの通信プロトコルでも、上位レベル(例:運転管理、バッチ管理、データ管理)の処理ロジックは一番重要です。

事例#2:想定外の運転条件

<現象>
某業界向けの運転シミュレータの客先検収テストを、二日間にまたがって実施しました。一晩中システムを稼働状態のまま置いておいたら、翌朝システムが反応しなくなりました。
<原因>
システムの中核部分に加算カウンターが埋め込まれ、各サブシステムに基準クロックを提供していました。ところが、元々シミュレータは日毎に立上げ・停止する運用が基本で、二日間に及ぶ運転は想定外でした。そのため加算カウンターの桁数が十分に取られておらず、数値リセット無しで長時間運転し続けたためオーバーフローしてしまいました。
<対策>
加算カウンターを倍長サイズに変更しました。

<教訓>「冷静になる」、「落ち着いて考える」、「お客様への説明」
想定外の運転条件もきちんと押さえる、という点だけが本事例の教訓ではありません。
お客様を前にしてのあり得ないトラブル発生に、関係者一同は(私も含めて)パニック状態に陥りました。すると、現場経験豊富なコンサルタントが「みんな落ち着け!テストを一時中断して良く調べ直しましょう。」と提案したため、他メンバーもようやく気を取り直しました。改めてお客様に状況を説明して何とかご了解を頂き、頭を冷やしてトラブル分析に取りかかることが出来ました。場数を踏む、というのはこういうことなのかと深く感銘を受けた次第です。

事例#3:多くの問題点の洗い出し

<現象>
大規模な物流制御システムの完成間近の時期に、プロジェクト管理者から「何かが変だ」との指摘を受けて調査を開始しました。その時点では、正確な問題点は誰にも分かりませんでしたが、調査が進むにつれて様々な問題点が出てきました。
<原因>
(発見順)検査データ遅れ⇒開発日程遅れ⇒開発管理ミス⇒作業手順ミス⇒文書化不十分⇒設計不統一⇒・・・
<対策>
当初は個別原因毎に対応していましたが、途中から設計開発チーム全体を再構築したうえ、システム設計・開発結果を最初から見直しました。

<教訓>「適切な指示・管理・報告」、「統一的な設計」、「詳細な文書化」
本事例で一番大変だったのは、プロジェクト状況(トラブル全体像)を正確に理解することでした。時間をかけて多くの関係者に聞き取り調査をした結果、断片的な情報からようやくどこに問題点があるのかが判明しました。大きなシステム構築案件では、機能別にサブチームを立てて開発・管理するのが普通です。各サブチームについて、統一的に同じレベルで指示・管理・報告する手順・方策が、プロジェクト管理側・サブチーム側の双方に強く求められます。

事例#4:新しいインフラに注意

<現象>
ファインケミカルプラントの運転管理パソコン(リアルタイムOS搭載)が、予定通りの処理機能を実現しませんでした。
<原因>
初めて使うリアルタイムOSだったため、その機能や制約を十分に理解して活用することが出来ませんでした。
<対策>
別途UNIXサーバを用意し、サーバ側:マスタ管理・データ記録・バッチ追跡などの管理機能、パソコン側:操作・監視機能などの対話型機能、と機能分担しました。

<教訓>「新しいインフラは慎重に」、「実用化前に事前チェック」
ソフトウエア、ハードウエア、ミドルウエア、ネットワークを問わず、日々新技術・新製品が発表されています。しかし、新しいインフラやパッケージを実プロジェクトに適用する前には、必ず十分に検証することが求められます。開発元/販売元の宣伝文句やネット上の口コミは、決して100%鵜呑みにしてはいけません。出来れば、開発サイトや実ユーザーを訪問してご自分の目で実地に確認しましょう。また、開発元または自社内に検証用システムを立ち上げて、実プロジェクトを想定した様々な条件でテスト運用してみて下さい。

特に印象に残っているトラブル4例とそれから得られた教訓をご紹介しました。皆様にも少なからず心当たりがあるのではないでしょうか。トラブルはつらいものなので、忘れ去りたい思いもありますが、考察・反省して次に活かすことで、「宝の山」に変えて下さい。

佐野 優治 氏
佐野 優治 氏
ITコンサルタント
キヤノン、東洋エンジニアリング、YMP-iを経て現在はITコンサルタントをしています。主な経験分野は、電子機器制御、ラボオート(LA)、連続プロセス制御・監視、バッチプロセス制御・監視、自動車製造ライン、製造管理システム(MES)、医薬製造向け現場連携・SCADA、生産管理システム、など。根っからの「現場好き人間」で、設備⇔システム融合をライフワークとしています。
著者メールアドレス: sano.yuji@mbm.nifty.com (ご意見、ご感想などお気軽にお寄せ下さい。)