Comments
Description
Transcript
第 35 回 2004 計装制御技術会議 セッション1「本音で語
第 35 回 2004 計装制御技術会議 セッション１「本音で語ろうＤＣＳ、ＰＬＣ計装 ∼ユーザの言い分・ベンダの言い分∼」 日時 2004 年 11 月９日（火）10：00∼17：00 会場 東京・港区・三田ＮＮホール パネルディスカッション 目次 コーディネータ、パネラー、コメンテータ・・・・・・・・・・・・・・・・・・・・１ （別紙 1：セッション概要とこれまでの経緯） ・・・・・・・・・・・・・・・・・・・２ （別紙 2：ユーザ要求仕様書のポイント）・・・・・・・・・・・・・・・・・・・・・４ （別紙 3：ユーザ要求仕様書に対するベンダ回答の共通点） ・・・・・・・・・・・・・６ Ａ．コスト・性能のバランス・・・・・・・・・・・・・・・・・・・・・・・・・・８ Ｂ．長期運用のためのシステムデザイン ・・・・・・・・・・・・・・・・・・・・２２ Ｃ．ＭＳ Ｗｉｎｄｏｗｓへの対応 ・・・・・・・・ ・・・・・・・・・・・・・・３１ Ｄ．リプレースコスト・・・・・・・・・・・・・・・・・・・・・・・・・・・・３７ Ｅ．プラントシステムのセキュリティ・・・・・・・・・・・・・・・・・・・・・４４ 新先生のまとめ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・５４ コメンテータのまとめ・・・・・・・・・・・・・・・・・・・・・・・・・・・・５８ 宮川セッションチェアマンのまとめ・・・・・・・・・・・・・・・・・・・・・・６１ 【 司会、パネラー、コメンテータ 】 司会： 新 誠一 東京大学大学院 ※2004 年 11 月 9 日現在 情報理工学系研究科 システム情報専攻 助教授 ユーザパネラー： 今任 邦治 三菱化学エンジニアリング㈱ 技術本部 システム設計部 制御技術グループ グループマネージャー 梶原 康正 ㈱カネカ 生産技術本部 エンジニアリング企画グループ 幹部職 高野 正利 トヨタ自動車㈱ プラントエンジニアリング部 企画室 第 1 システムグループ グループ長 服部 篤彦 東京ガス㈱ エネルギー生産部 生産エンジニアリンググループ基板技術チーム 主幹 水谷 元雅 新日本石油㈱ 製造技術本部 工務部 設備設計グループ チーフスタッフ 望月 俊之 味の素㈱ 生産技術開発センター 生産基盤技術部 基盤エンジニアリンググループ グループ長 安田 茂 ライオン㈱ 生産本部 生産技術部 主任部員 米田 稔 三菱化学㈱ 四日市事業所 設備技術本部 管理グループ グループマネジャー ベンダパネラー： 大庭 章 ㈱東芝 電力・会社システム社 電気・計測事業部 制御・計装機器技術部 主幹 澤近 房雄 ロックウェル オートメーション ジャパン㈱ プロダクトマーケティング 部長 中原 敏明 東芝三菱電機産業システム㈱ 産業第一システム事業部 産業システムソリューション技術部 技術第六課 参事 平瀬 清人 オムロン㈱ インダストリアルオートメーションビジネスカンパニー システム機器統轄事業部 アナログ・プロセスコントロール事業推進部 部長 多比良 誠 日立那珂エレクトロニクス㈱ 情報システム設計本部 システム開発センタ グループ長 笹谷 俊幸 富士電機システムズ㈱ 産業・交通システム本部 計測プラントﾄ統括部 計測技術第二部 部長 新井 弘志 ㈱山武 アドバンスオートメーションカンパニー 開発４部長 中原 正俊 横河電機㈱ ＩＡ事業本部 システム事業部 ＰＡソリューションセンター ＰＭＫ部 部長 古久保雄三 三菱電機㈱ 名古屋製作所 ＦＡシステム部長 エンジニアリング会社パネラー（セッションチェアマン）： 宮川 彰 東洋エンジニアリング㈱ 国内事業本部 電気計装設計チーム チームリーダー コメンテーマ 田中 可一 （社）日本電気計測器工業会 ＰＡ・ＦＡ計装制御委員会 委員長 （㈱山武 アドバンスオートメーションカンパニーマーケティング２部） 杉浦 彰俊 ジャパンバッチフォーラム 代表 （森永乳業㈱ 生産技術部 マネージャー） 1 別紙１ ２ 2 3 ICEC 2004(The Instrument & Control Engineering Conference) 【第35回】２００４計装制御技術会議 ユーザ要求仕様書 目的：ＩＣＥＣ「ユーザ懇談会」による継続的かつ異業種でのユーザ要求の提示とそれに基づくベン ダーとのディスカッションから，よりユーザ要求にマッチしたシステム開発，導入へとつなげる． ＩＣＥＣ：日本能率協会主催の計装制御に関する技術会議 ユーザ懇談会： 三菱化学エンジニアリング，カネカ，森永乳業， 東京ガス，新日本石油，東洋エンジニアリング，味の素， ライオン，トヨタ自動車 オブザーバ：東京大学 ‘０３ ＩＣＥＣユーザ要求 １．徹底的な低コストへの要求 ２．コスト-機能・性能のバランス ３．ライフサイクルでの保証（メンテナンス，継承性） ４．保守の容易性，ユーザビリティ ５．信頼性 ６．多様なユーザＩ／Ｆ ７．オープンとセキュリティ（水平/垂直での情報共有） 近々（05年度内）に解決を要するもの ０７年度までには必要となるもの ‘０４ ＩＣＥＣユーザ要求（０３要求への掘り下げ，追加として） 要求事項 （掘り下げ） ２．コスト-機能・性能のバランス 問題意識：DCSや2重化システムの信頼性が本当に高いのか．それに見合うコストなのか． （PLCの方が新技術へのキャッチアップが早く，機器レベルの信頼性の差は縮小していないか） ２−１． 定量的にその（DCSとPLC，シングルと２重化システム)違いを知りたく，シングルシステムと比較した 場合の定量値（割合などの係数でも可）などオーバーオールでの比較判断の材料となるデータをお 教えいただきたい． DCS信頼性に関する定量的な指標・データを提示いただきたい． ・PI/O，CPU，電源，バス，ネットワーク，HMIなどの各コンポーネント単位にて，２重化した場合の信 頼度及びコストをシングルシステムとの相対値として提示いただきたい． ・また，その２重化の仕組みについても図解などで解説（各機器故障時にどうバックアップされるか， ２−２． ２重化機器部分の信頼性についても説明）．→２重化システム故のボトルネック（リスク）をお教えい ただきたい． ・２重化の信頼性・コストなどの観点から，対象システムや使用環境別にユーザへのリーズナブルな 提案をいただきたい． ２−３． 生の意見 ・DCSの場合，２重化，防爆などの信頼性，応答性が必要な部分と オープンな部分との分離をしないとあまりにも高い買い物にならな いか．（絶対に止められない制御システムと何らかの回避ができる 部分との分離） イメージ的に、DCSの方がPLCよりも信頼性があるような気もします が、弊社の場合PLCは基本的にほったらかしでDCSは高額な費用 を払って定期メンテナンスをやっているので本当に信頼性があるの はどっちかといわれると、よくわかりません。 ①各ベンダーから、信頼性について定量的な指標を提示して欲し い。・DCSはPLCに比べ信頼性が高いと言われているが、具体的に DCS，PLCにおいて，設置環境の制約や運用想定年数などの，前提となる設計条件をお教えくださ この様な工夫をしているから、これだけ信頼性に違いがあるという い． 点が提示して欲しい。ex)PI/O、CPU、電源、通信、HMIレベルで、 信頼性の数値とその理由を理解したいと思います。 ・Ｐｉ／ｏカードレベル・２重化コントローラのバックアップの仕組みと レベル・制御用Net-Workの信頼性レベルなど、各メーカーから提示 されたシステム構成（DCS／PLC）で、各デバイスレベルが故障した 場合、システム全体がどうなるのかをメーカー側に説明をしていた だきたい． ２重化，防爆などの信頼性，応答性が必要な部分とオープンな部 分との分離可否とその対応方法・上記のため，現時点のコンピュー タ・ボード関連機器の信頼性の定量提示・この程度の使い方だと寿 命はこの程度・故障率の差異（２重化−通常システム） 以前は２重化システムが切り替わる際にトラブルを起こしたようなこ ともありました。本来はシンプルな機構が一番信頼できるのかもし れない ＡＩ、ＡＯ、ＤＩ、ＤＯが想定する異常状態になる確率 DCSの信頼性を保った状態で低コスト化できるシステムを提案いただきたい． ・例えば，制御部分の機器・ソフトウェアは従来の実績を持ったもので，それらがイーサネットなどに ・従来からのDCSが継承する信頼性・実績を引き継ぎながら，コスト ２−４． 接続でき，汎用HMIが使える仕組み ダウンできるシステム ・2重化に変わる新たな信頼性確保の仕組み ・WEB-HMIの現状とその信頼性 など 昔は二重化，現在はネットワーク化です．インターネットのように， 動的に経路を探すことで故障箇所を回避する仕組みを作ることが 重要． WEB−HMIの信頼性はどの程度か 「余分な機能」の候補（ユーザー側が抽出？）を選択可能な仕組み ができるのかメーカー側に確認することは如何でしょうか？ ７．セキュリティ ７−１． コモンクライテリア（ISO/IEC 15408）に即した形で，プラントシステムの運用状態別でのセキュリティ ガイドラインを提示いただきたい． プラントシステムの運用状態（イントラへの接続有無も含め）別によ （イントラネットへの接続／各種データの外部媒体での出力／設定機器がWindowsPCなどの場合分 るセキュリティガイドラインの提示は要求したいところです． けにより，どのようなハード／ソフト／運用が必要なのかのガイドライン） ７−２． 各プラントシステムにおける考えられている（もしくはすでに提供している）セキュリティ対応オプショ 一部に使われるWindows等のセキュリティホールへの対応，セキュ ンをお教えいただきたい．（システム面／サポート面） リティオプション化の状況 ７−３． 継続的なセキュリティパッチなどの対応が不要となるシステム（セキュリティに関する本質安全）に関 ・独自が故の脆弱性が問題になる時代 する提案，検討の状況などをお聞かせいただきたい． 4 （追加） ８．WindowsHMIへの対応（寿命，更新） WindowsHMI採用システムに関する寿命延長もしくは部分更新策の提示をいただきたい． ・特に，WindowsNT対応保証のハードウェアが調達できないため，システムのかなりの部分が更新 ８−１． になる現状に対して，部分更新（たとえばハードのみ）策の提示（ベンダーでの新ハードへの WindowsNTポーティング確認など）をいただきたい． ８−２． ８−３． ８−４． ・パソコン関連の保障期間の短さの問題（この系統のシステムが７ ∼８年経過し，耐用寿命超え？）例えば，WindowsNT4.0対応ハード ウェアが調達できず，全面更新になる．→部分更新案のベンダー からの提示（PCハードのみ，butベンダーの補償範囲の制限の提 示） ・Windows2003ServerなどでNT等の実行環境がサポートされており，それによる過去OS(WinNT）上 ・過去のWindowsHMIで上記に依存したシステムのハードのみの更 HMIソフトなどのエミュレートが可能と考えられる．それらへの対応による部分更新策など対応プラン 新策（WinNTシステムのままポーティングできるハードの確保など） を提示いただきたい． 「WindowsNT問題」に関係しており，過去のOSに対して動作する 上記対応のためにユーザが受け入れるべき制約条件を提示いただきたい．（機能拡張は不可，一 ハードウェアの確保，部分的な更新の考え方を聞きたいところで 部機能保証不可など） す．（ベンダーのこの分野への技術力の問題も含んでいますが） WindowsなどのOSや開発ツールについて上位互換のあるものを選択し，開発することが必要です． 要は採用するHMIソフト側に問題があり、WindowsのOSのバージョ それらに関する各ベンダーの設計方針をお聞きしたい． ンや最新のPCに問題があるとは言い切れないと考えます。 また，HMIソフトの自社開発に関するコンセプト/トレンドを合わせてお教えください． HMIソフトの作り方の問題ですが，実際それを採用しているユーザ にとっては，リプレース範囲の最小化は是非実施したい課題です． OSやベンダーアプリのVer.変更に左右されないものを望んでいま す。基本的には、最少の費用で上位互換してもらえる仕組みが必 要だと思っています。 MSをプラントシステムに使用するリスクについて、ベンダーに考え ていただければと思います。 ・今後の要求として，OSや開発環境のバージョンアップに対して， 影響が少ないソフト作り．バージョンアップ時に対応関数などが変 更になっても，コンバートする仕組み． ８−５． OS，ツールなどのベンダーフリーなHMIについて，開発方針をお伺いしたい． 異機種・マルチベンダー制御システムの共通HMIについて，開発方針をお伺いしたい． ベンダーの開発設計方針・姿勢 HMIの部分はどのメーカー・機種でも、同一環境で運転監視できる ことを私は期待しています。 プラントの特性により、コントローラは得意な領域の機種を選定 （PA：DCS、FA：PLC)するが、HMIは共通化したい・コントローラは、 メーカー・機種が混在してもHMIは共通化したい。 色々なメーカー製品を組み合わせた場合、その中の一部のOSを VerUpした時に、他のサブシステムがキチンと動作するかが不安な 点です。 「OSやメーカーに依存しないHMI」 ソフトウェアの互換性を高める工夫について ９．リプレース切り替え時間のスピードアップ リプレースにかかる時間の短縮方策について提示いただきたい．（リプレースによってベンダーが変 ９−１． 更になる場合などの工夫も含め） ９−２． FDTなどのマルチベンダー対応エンジニアリング環境などへの対応についてお伺いしたい． １０．予備品の状況・考え方 製造中止後の保守サポート期間内の主要DCS/PLC機種に関する予備品の保持数・供給（取り寄せ 交換及び故障品の修理にかかる時間）状況を提示いただきたい． １０−１． 製造中止∼保守期間∼保守打切後の各々のフェースでの対応内容・またその期間を提示いただき たい． さらに，延命化のための対応メニュー（ユーザ側の負担も含め）をお教えください． 工事段階では、現場配線切替とチェック時間がウェートを占めます ので，フィールド廻りの統一できればと思います。 エンジニアリングとデバッグの容易性 予備品の問題も討議してくれると幸いです． ・メーカー側に予備品在庫量の情報提供を要請します．ユーザー 側で予備品を保有するか否かの判定は悩みます。 １０−２． ハード/ソフトともにパーツ交換できるような開発設計への取り組みについて提示いただきたい． システムの構成部品がパーツとして、簡便に交換できること。 新製品開発や製造中止をアナウンスする際、代替カードを提供し て欲しい．15∼20年使用するシステムもあるので、延命化を図る為 には代替カードが多少Cost高になっても提供して欲しいと思いま す。 DCSの延命化はユーザーにとっては理想です。各ベンダーに、延 命化（Minコストで部分更新も含）について考え方や方法論について お聞きしてみたいと思います。 ソフトもハード同様、パーツ交換のようにできればいいのです が・・・。設計論としての標準化が必要ではないかと思います。 【ベンダ企業のパネラー・スピーカ決定について】 ７月末 ：ユーザ要求仕様書の概要の作成 ↓ ↓ ユーザ要求仕様書をベンダ企業へ提示 ●本要求書に対するご回答を８月３１日（火）までに事務局宛にＥメール ①日本能率協会よりベンダ企業に向けてユーザ要求仕様書を提示 にてご返信ください（Power Point １∼５枚程度）。〈５枚以上でも構いません〉 ↓ ②本会議関連３団体へ提示 ※日本電気計測器工業会、日本電機工業会、日本電気制御機器工業会 〈参考〉 ９月初旬：ベンダ企業からの回答後、パネラー・スピーカを決定 ・添付 「2003計装制御技術会議」ユーザ要求仕様書・ベンダ回答書をご参考ください｡ ∼末 事務局より、ご提示させていただきますのでご回答のほど よろしくお願い申しあげます。 ・ 2003計装制御技術会議ホームページ内（http://school.jma.or.jp/keisou/）に 「セッション１：DCSvsPLC計装∼ユーザ要求についてこられるかDCS,PLC∼」 がパネル内容が掲載されております。 ※詳細は、添付「ユーザ要求仕様書へのベンダ回答書作成スケジュール」をご覧ください。 5 7 （新） パネルディスカッションとしては、宮川チェアマンからご紹介がありましたよう に、五つの話題を話していきたいと思います。まず、 「コスト・機能・性能のバランスの追 求、」これをＡとします。それからＢとして「設計条件を考慮した予備品への対応」それか らＣとして「WindowsＨＭＩへの対応」それからＤとして「リプレース切り替え時間のス ピードアップ」それからＥとして「セキュリティ対策の討論」をさせていただきたいと思 います。 各討論、ベンダ回答として横河電機と富士電機システムズが午前中にご報告をされまし たので、ほかのベンダから５分ずつ回答を頂きたいと思います。そして、各項目 30 分ぐ らいを目安にディスカッションをさせていただきたいと思います。 それでは、コスト・機能・性能のバランスの追求ということで、山武のほうから５分間、 ご報告をお願いいたします。 （新井） ご紹介にあずかりました山武の新井です。まず１番め、コスト・性能・機能の バランスということです。お手元のところには、コスト・性能・バランスということでい ろいろ書いてありますが、幾つか書いてある内容にも触れながらお話しします。 まずは、今、コスト・性能というと、どうしても今日の話題の中では、ＰＬＣとＤＣＳ ということで比較対照されます。わが社は２系統と思われているユーザも多いと思います が、基本的には一つです。ＴＤＣＳ、ＡＰＳ系と、ハーモナス、デオ系という二つを持っ ていますが、ＰＬＣということで、イーサネットウインドウズをベースにしたハーモナス のシステム構成図、現在のシステム構成図でお示ししました。 コスト・性能のバランスということで、逆にいうとそれを追求して、1995 年の計測展で ハーモナスを最初に発表させていただきました。その当時イーサネットを二重化して、発 表した当時、Windows はＮＴの 3.51 だったのです。3.51 の Windows をベースにしたシ ステムということで、当時はハーモナス・コントローラという、真ん中にＨＣと書いてあ るもの一つで、あとはＨＳＳと書いてあるものを、Windows パソコンをベースに発表させ ていただきました。その当時から、上流工程はＤＣＳ、下流工程はＰＬＣということがあ り、あと異文化の統合も含めて、Ｉ／ＯとしてＰＬＣを使って、うちとしてはサポートし ていくことを発表してきました。したがって、ＰＬＣ対ＤＣＳというのは、去年、うちの マーケットの者が「うちの業態と合わない題目だ」と発表したことを覚えている方もいら っしゃるかもしれません。そういうことで、適材適所で使っていただいて構わないという 8 ことです。 その後、二重化のコントローラ、２アウト・オブ・３で冗長を組んだコントローラ。や はりこういう下工程も、例えば、ＰＬＣはもう機器に組み込んであるので、その情報もハ ーモナス上で見たいということで、そのまま使っている場合もあったのですが、逆にもっ と密接に上流工程と下工程をピア・トゥ・ピアでＰＬＣと結びたいといったご要望もあり、 ＰＬＣリンカーも開発しました。例えば、ハーモナス・コントローラとのピア・トゥ・ピ ア、コントローラ間通信もできます。幾つかユーザからご指摘がありましたように、やは り全点スキャンしますと、ＰＬＣの場合は性能に問題が出てくるということで、ここであ る程度セグメントを切って、あとはＤＣＳのネットワーク上のプロトコルで、全点スキャ ンしないで、一部アップデートができるような構成を取れるような格好にする。 そうするとだんだん、どうしてもＰＬＣのところも、こっちが二重化しているので、全 体を二重化したいというお客様もいらっしゃいまして、ここも二重化してくれと。三菱電 機の二重化のＰＬＣを使っているということも含めて、ここも全体で、こちらも二重化、 こちらも二重化というものも、お客様のニーズに則した格好で提供できるようなラインア ップを整備してきました。したがって、コントローラ系は、かなりスケーラブルで対応し ています。 昨年発表したハーモナス・フレックスは、もっと安く、ＤＣＳコントローラは高い、活 線挿抜できる、二重化もできる、Ｉ／Ｏの二重化もできるということで、それなりのＣＰ Ｕなり電子機器を積んでいますので、かなり高くなります。そうではなくて、監視専用な ので、そこそこでいいので、ＰＬＣと同等でいいよというお客様に対応して、一段とコス トダウンしたようなコントローラも発表しています。 コスト・性能比較では、ベンダサイドもこのようにいろいろスケーラビリティを保ちな がらやっています。それぞれのお客様で、ＰＬＣがよければＰＬＣを使っていただいて構 いませんし、ＰＬＣのラダーはどうしても大規模になってくるとメンテナンス性がよくな いというのであれば、ＤＣＳ系のブロック結線で自由に構築できて、そこそこのコストで 対応できるようなフレックスというコントローラもあります。どうしても２年、３年は止 められないということであれば、冗長化を組んでいただくということで、トータルでサポ ートさせていただいています。 あと、マンマシンのほうでも SCADA とか、配布資料に内容を書きましたが、やはりマ ンマシンの数が多いと、その分バージョンアップが大変、コストがかかるということで、 9 そういったお客様にはウェブベースで、operation anywhere ということで昨年発表させて いただきました。サーバーが、一つあれば、あとはお客様のラップトップパソコンでＩＥ が動けばいいですよというところで、コストの最適化を、お客様の運用で考えていただい て構わない。当然、サーバークライアントになりますので、これがダウンしますと全部見 えません。ＤＣＳのマンマシンのほうでは、そういうことは普通ないわけですが、そうい う場合はＨＳＳを一つ入れていただいてもいいですし、ＴＳＳをもう１台入れてもらって、 こちら側で数台、こちら側で別の複数台ということでサーバクライアントを組んでいただ いてもいい。それはお客様のニーズに合わせて組んでいただくことによって、初期投資を かなり抑えていただく。もしくは、バージョンアップの工数も抑えられる格好で考えてい ます。スケーラビリティを持ったシステムを、ベンダとしては、コストダウンも含めて、 常に考えているというのが１点です。 もう１点が、コストということで、ＤＣＳ、ＴＤＣＳ系のほうと、このハーモナス、デ オ系のほうは、ネットワーク・ゲートウェイで接続可能になっています。実績ベースでは 1975 年に発表したコントローラや入出力機器も、いまだに、現在約 30 年なのですが、私 は開発畑から来ているので、本当は保守をやめたくてしょうがなかったほうなのですが、 私のほうで保守しています。 そういう意味ではトータルコスト、きちっとお客様のニーズを把握して、長期間サポー トしていく体制を、代替品も含めてとっていることが、ＤＣＳベンダの一つの価値なのか なと思っています。以上です。 （新） ありがとうございました。それでは引き続き、東芝にお願いしたいと思います。 大庭さん、よろしくお願いします。 （大庭） 東芝の大庭です。まず、Ａコスト・機能・性能のバランスの追求に関して発表 させていただきます。 要求事項の中に、ＤＣＳや二重化システムの信頼性は本当に高いのかという質問があり ました。その辺の定量的なデータを提示いただきたいということでしたので、そこは一般 的な話、これはＤＣＳ、ＰＬＣということではなくて、一般的なコントローラを二重化し たときに、どのくらい信頼性が上がって、対価格比がどうなるかを計算したものです。 コントローラがシングルの場合のＭＴＢＦをこういうふうに仮定したとき、待機冗長系 10 で二重化を組んで、予備品を持って、ある故障が発生したときに、ある時間内、この場合 は 10 時間と仮定していますが、それで修復して、また元の二重化のシステムに戻すとい う二重化を組んだ場合は、ＭＴＢＦとしてはかなり信頼度は上がる。二重化して、あと共 通部もありますので、それの価格を２倍プラスアルファで割ったとしても、計算上は 8000 倍ぐらいに二重化することで、価格対信頼性比は上がるというのがコントローラです。 それから、マンマシンの場合は並列冗長を組むということで、２台置いての計算ですと、 同じように計算して約 5000 倍と。計算上はこういったふうに、二重化システムを組むこ とで、信頼性が上がるということです。 これは当社のシステムの二重化の考え方ですが、マンマシンの部分があって、ここは並 列で冗長しています。それから、制御ＬＡＮは標準で二重化、コントローラは待機冗長で 二重化しています。それから、コントローラの中のＩ／Ｏのとのインタフェースになるシ リアルＩ／Ｏのバスがあって、ここも二重化。それからＩ／Ｏに関しても二重化が可能と いう形で、すべての部分で二重化対応がとれて、信頼性を上げることが構築可能になって いる。最近、ＰＬＣも二重化対応の製品が出てきていますので、これに関しても、ＤＣＳ だからどうだ、ＰＬＣだからどうだというのではなくて、一般的なコントローラ、および そういったシステムは二重化することができることを、まとめて書いたものです。 コスト・性能のバランスというテーマですので、これが今回話題になることかと思いま した。これはテキストには入っていないのですが、汎用 SCADA＋ＰＬＣという左側のシ ステムと、従来型のＤＣＳと呼ばれるシステムで、いろいろなものを比較してみようと考 えました。 まずコストですが、これは去年、おととし、今年で３回めになりますが、ＤＣＳは高い と言われていますので、こちら側が有利かなと。 機能に関しては、ＤＣＳ特有の機能を考えると、いろいろな機能が豊富で、要らない機 能までついているというユーザの意見もありましたが、機能的には豊富なＤＣＳが有利か なと。 ３点めは個別性能ということで、これはＰＬＣとかＤＣＳの単体の性能は、ほぼ互角か なと考えています。ここはイコールです。ただし、システム性能、午前中の発表でもあり ましたが、例えばマンマシンから下に指令を出して、折り返してくるまでの性能であると か、そういったシステムとしての性能を考えると、ＤＣＳのほうが有利です。これも午前 中のユーザの発表にありましたが、エンジニアリングが、ＰＬＣでやってマンマシン、 11 SCADA のほうでやるというところで二重手間になるなどを考えると、一括してＤＣＳで 入れたほうが優位です。 それから、一括で見ますから、システム保証という点では、ＤＣＳはまとめてある、Ｐ ＬＣ＋SCADA は、それぞれＳＩがちょっと苦労する部分があります。 それから長期保守は、ユーザの要求とベンダの回答が少しずれているかもしれませんが、 こういうシステムとこういうシステムを比べたときには、ＤＣＳ側のほうが、現状、長期 保守に対応できているのではないかと。コスト・性能のバランスという意味で、ＤＣＳ対 ＰＬＣという構図をあえて描くと、こういう形になるかなというふうにまとめました。 （新） どうもありがとうございます。では、ベンダ側の最後としまして、三菱電機さん、 お願いします。 （古久保） 三菱電機名古屋製作所ＦＡシステム部の古久保と申します。メルセック計装 の課題ということでプレゼンテーションをさせていただきます。 メルセック計装の課題ということで、ＰＬＣ計装の好きでないポイントをまとめてみた つもりです。まず、左側からいきまして、ユニット品ぞろえ強化と制御ファンクションブ ロックの品ぞろえ強化。この辺は、ハードウェアのメニューとか、あるいはソフトウェア のメニューは、やはりＰＬＣ計装は不足しているのです。メルセック計装を発売したのが 2001 年１月ですから、２年ぐらいしか歴史がないです。それに比べて、ＤＣＳのほうは 20 年以上の歴史を持っているということで、ある意味で当然だと思います。ただ、ＰＬＣ のオープン性が、このメリットとして効いてきて、世界中のサードパーティーに、この辺 のメニュー強化に協力していただいています。ですから、５年後ぐらいには恐らく、メニ ューぞろえという点では、ＤＣＳに追いつくのではないかなと見込んでいます。 ここでいう「高信頼性」というのは、二重化ではなくて、いちばん問題にしているのは 自己診断のカバー率です。例でいいますと、ＰＬＣですか、特に最新機種ですが、高速大 容量のＳＲＡＭを積んでいるにもかかわらず、 パリティ・チェックもついていないのです。 ですから、そういった自己診断率をＤＣＳと遜色のないレベルまで持ってきたＣＰＵを、 リリースしたいなと。それは恐らく、06 年度以降になるのですが、こういった信頼面につ いても、ＤＣＳと遜色のないレベルに持っています。 下のほうに行きまして、統合エンジニアリング環境なのですが、これが午前中から再々 12 ユーザサイドのプレゼンで出てきました、プログラムの作りにくさなのです。やはりＤＣ Ｓライクに、コントローラ、ＣＰＵ、それとマンマシン、ネットワーク、そういったもの が三位一体型で、ソフトウェア開発できるような環境を構築することを、実は最優先課題 として取り組んでいるところです。現状では、午前中のプレゼンにもあったように、技術 レベルの高いユーザでないと、多分、今のＰＬＣ計装は使いこなせないはずなのです。具 体的にいうと、SCADA メーカーとのアライアンスがこれで実現するのですが、そのリリ ース時期に関しては、今年度中には発表できるかなと、まだそういう状況です。それであ と、ネットワークは粛々と高速化していく話なのですが、パートナーとの連携、アライア ンス、この辺がＰＬＣ計装の今後の発展のキーポイントになるかと思います。 これは短期的な機能強化ということで、本年度の開発状況をまとめたものですが、強化 ポイントの赤字だけご覧いただきたいと思います。 まずＱシリーズの二重化は５月に発売しています。それで、アナログ関係のメニューぞ ろえ、それが弱いので、とりあえず絶縁型の多点入力アナログ入出力、それを今年度中に リリースしようと。 長期的な機能強化ということでは、これは２年先ぐらいを目標にしているのですが、や はりエンジニアリング環境の強化。 ＣＰＵのバージョンアップというのは、先ほどの自己診断のカバレッジも含めたものを リリースしようと。 ネットワークの機能性の強化。 そして４番に書いてあるのですが、ＳＯＥ機能についても、タイムスタンプつきの入力 モジュールを作ることによって、ＤＣＳと遜色のないものにする。とにかくいちばん大事 なところが、真ん中に書いてあります、SCADA メーカーとの連携になってきます。SCADA 機能内蔵型ＧＯＴがリリースできれば、ですから少なくとも３年先ぐらいには、メルセッ ク計装も機能・性能・信頼面でＤＣＳと遜色のないレベルに持っていけるかなと、そうい うことを考えています。 以上、簡単ですが、プレゼンテーションを終わらせていただきます。ありがとうござい ました。 （新） ありがとうございました。 ベンダからの回答がそろったところで、討論に移っていきたいと思います。今、何人か 13 のかたからご紹介いただいたように、現在のＤＣＳとＰＬＣの違いと、それから将来にわ たっての違いがあると思います。現在の違いについては、ＤＣＳのほうもコストを下げて いくということですし、ＰＬＣのほうも信頼性を上げていくということですから、毎年毎 年変わっていくものだと思います。 両者の本質的な違いが幾つかあると思います。これは富士電機システムズの笹谷さんが 非常によくまとめられておりましたが、一つは、ＤＣＳというのは１社が全部面倒を見る、 システムを作り上げる、ソフトウェアもハードウェアもみんな面倒を見るというものであ る。ＰＬＣというのは、ユーザまたはシステムインテグレータがシステムを作るものだと いう、非常に明白な定義をしていただきました。 それに伴って、今のベンダ回答に対してユーザがどう思うかというお話を伺いたいので すが、ユーザに対して、一つ、私のほうからの質問は、自分のところでやるのか、任せる のかに対して、どうお考えになっているのかをお聞きしたいわけです。特に、今日の午前 中にご発表いただいたユーザは、どちらかというと、自分のところでやったというご報告 だったので、そういう姿勢の話になるかもしれませんが、その辺が非常に大きな問題だと 思います。 それからもう一つ焦点が当たっているのは二重化です。三菱は二重化にもＰＬＣを対応 させていくということでしたが、ハードウェアとしては、 二重化でコストが上がることが、 ユーザにとっては、信頼性とコストの問題で非常に悩ましいところである。二重化が必要 なところも認めていらっしゃると思うのですが、その二重化の内容が不透明であることが、 ユーザからの不信感ではないかという気がします。その一つは、二重化かそうではないか という選択だけを迫られているところが、気に入らないのではないかと思います。討議票 の中にも、そういうご質問があります。 「そういう二重化ではなくて、二重化は初期費用が かかってしまう。だから、通常時はネットワークやＣＰＵの負荷を分散させて、異常時だ けバックアップとして使えないか」。参加者からのご指摘なのですが、こういう形で二重化 のコストを吸収できないかというのがユーザの大事なポイントだと思います。 これは、カネカの梶原さんが午前中のご発表の中で、リスクマネジメントという言葉で おまとめになったところだと思います。横河がセブンナインという非常に高い信頼性を達 成されているということが片方にある。 「絶対倒れないシステム」という高い信頼性を誇っ ていらっしゃる一方で、リスクマネジメントという概念は、 「壊れてもいい、しかし壊れた ときの対策がちゃんとできている」という概念だと思います。どっちを取るかで、かなり 14 コストが違ってきます。絶対に倒れないシステムを求めるのか、それとも倒れてもいいけ れども、倒れたときに、ちゃんとだれかがバックアップしてくれるとか、被害が最小にな るような対策が施されているかどうかが、非常に大事ではないかと思っています。特にこ の２点が、これは私の個人的な意見ですが、ユーザとベンダの回答の間を埋める点ではな いかと。そういった観点も踏まえて、 ちょっとユーザのご意見をお伺いしたいと思います。 最初にカネカの梶原さん、お願いいたします。二つに限らず、ベンダの回答を全部お聞 きになって、信頼性とコストについて、梶原さんのお考えを聞かせていただけるとありが たいのですが。 （梶原） カネカの梶原です。先ほど富士電機殿から説明を聞き、非常に斬新なシステム だと感じました。 一つは、コントローラとして高機能ＰＬＣを採用されている。そして、ＰＡからＦＡ領 域までまたがってエンジニアリング環境を構築されているということで、非常にいいなと、 ユーザとしては思っています。富士電機もほかのベンダも同じなのですが、もともと富士 電機は、自社でＤＣＳをお持ちですが、今回は高機能ＰＬＣをご提案されています。 今日はＤＣＳ対ＰＬＣというテーマですので、富士電機の自社のＤＣＳに比べて、今回採 用された高機能ＰＬＣの、特に信頼性という面で、自社ではどういう評価をされているの か。 また、ほかのベンダも自分のところでＰＬＣを作っておられますが、恐らくＰＬＣとＤ ＣＳの設計思想は違うのではないかと思います。特に信頼性という面で、自分のところで 作られているＰＬＣとＤＣＳの信頼性の設計思想、特にどの辺が弱いのかということがユ ーザとしては聞きたい所です。できましたらその辺、ベンダのほうから、お答えしていた だければありがたいと思います。 （新） 笹谷さん、いかがでしょうか。 （笹谷） 今までのＤＣＳと今回私どもが発表したＤＣＳの違いということで、まずご回 答させていただきます。二重化できることに関しては、従来のものと今回の新しい MICREX−ＮＸで、基本的な考え方は変わりません。 ただ、大きく違ってくるのは、やはり今まで日本になかった考え方なのかなと一つ思う 15 のですが、やはりそれを実際の二重化で実現したときの考え方として、それを立ち上げた り、運用するところです。運用するところでも、信頼性を考えている。単純に従来の二重 化ですと、逆に何でもできるという二重化を、ユーザの要求で作り込んでいっているので す。例えば、片系だけ運転させて、片系止めてソフト上のシミュレーションをする。そう いったものができるとか、二重化にしてもユーザの要求によって、いろいろなことができ る形を追求して、逆にそれが足かせになってきて、重くなってきているという問題があり ます。 それに対して、今回の新しいシステムは何が違うかというと、そういうところをある意 味ではきっぱり切っています。切って、これが信頼性というものですよという形から追求 して、提供しているシステムであると私どもは考えています。ちょっとそこが違うかなと 思っています。 （新） ありがとうございます。もう一人ユーザにお聞きしたいと思います。ユーザ懇談 会の一員で、新日本石油の水谷さん、いかがでしょうか。特に水谷さんにお聞きしたいの は、ベンダにソフト作りからみんな任せるのか、自分のところでやるのか。 （水谷） 今日は会場に石油関係の方がいらっしゃらないようなので、勝手に述べさせて いただきます。石油精製業の中の工場というと、連続、大量、危険物、高温高圧、それで 例によって水より安いガソリンを作っているわけですが、工場の中のバッチ以外はＤＣＳ を使っています。それから、ＤＣＳは、ＤＣＳベンダがそうなのかどうかというよりも、 我々の体制というか体質として、ハードウェアもソフトウェアも込みでＤＣＳベンダ、も しくは装置、ライセンサーとか設計者がいますので、むしろそういう方達に、ソフトウェ アまで作ってもらうのがほとんどです。自分たちで設計したりするというよりも、こうい うものが欲しい、そのプロセスと装置と制御システムを一緒に納めなさいという形でやり ますので、ソフトウェアを自作するということはあまりないです。ただ、細かい日々の効 率化のための改造は自社でもできます、けれども大きく装置を作ったり改造したりすると きは、ベンダにお任せすることになります。 それで、特に信頼性とコストでは、例えば石油の工場などがトラブルで止まってしまう というのは、そもそも止まることが非定常状態になるわけで、危険度が増すわけです。そ れから止まってしまうと、バッチプラントでなければ、通常は数日間止めることになるわ 16 けですから、機会損失が大きい。例えば、１日本当は 1000 万もうかるはずの装置が１週 間止まってしまえば、7000 万の機会損失があるわけです。その間、熱いものが冷たくなっ て縮むわけですから、どこから漏れるのではないかと心配します。リスクが増す訳で、こ のリスクを 3000 万とすれば、１回止まってしまうと１億ぐらいあるわけです。 そうすると、年に１回止まるよりも、100 年に１回しか止まらない期待値のものが当然 いいわけです。コスト的にも、計装、ＤＣＳといいますか、制御装置が数億円としたら、 その中で１∼２億円は、そういう信頼性があれば問題にならないと我々は考えています。 ほかの石油会社の人がいないので、勝手に言っていますけれども。 ただ、我々が気になるのは、コストというのは、最初に導入するときは市場原理が働く のです。最初は東芝を使うの、山武を使うの、横河を使うのと、みんなで競争して安いと ころを出してきなさいよと言うかどうかは分からないですが、とにかく皆さん何となくそ れなりに、一応競争して安いからこのベンダになったのだと、技術的にも評価してこのベ ンダになったなというものがあるのですが、いったん入れてしまうと、その後、改造とか 増設したときに、幾らかかりますよと、これが分からないのです。市場価格が分からない のです。比べようがない。最初に入れた価格で入れてくださいと言うと、最初は競争でや ったから、そんなものでは納められませんよということでしょうか。高いというイメージ があるのです。 今日、午前中お聞きしたように、ＤＣＳベンダはユーザの連続運転対応を考えています。 それから、長期に保守することを前提にしています。そういうコストを計上して、商品価 格にしています。それから、うちの製品を使えば、どこと比べるとは言いませんが、他社 よりも１けた信頼性が確かに上がっているではないですかという話を、営業的にも技術的 にも言ってもらえればあまりこちらもびっくりしない価格になるのでしょうか。 （新） そういう意味では、更新のときによそのインテグレータやソフトハウスに頼める ような環境があるとうれしいわけですね。 （水谷） そうですね。ただ、インテグレータがなかなか発見できないことと、導入され るものに不安がもしあるとすると、やはりそれは選択できません。午前中の発表を聞いて いますと、三菱化学さんとか森永乳業さんは、分からないのですが、ちょっと止まっても いいよとか、そういうふうにも受け取れたので。やはりちょっと危険、高温高圧の石油と 17 か、あと社会的に非常に困る電力などは、多分、信頼性のほうがコストよりもというふう になるのではないかと思います。 （新） ありがとうございます。皆さんにお送りしました事前アンケートの集計結果を見 ますと、60％の方が、停止させることは考えられないという水谷派で、残りの 40％の方が、 すぐに復旧できれば問題ない、多少停止してもいいという方です。多分どちらに属するか で、ユーザがＤＣＳをお選びになるか、ＰＬＣ計装をお選びになるかが違ってくるという のが、非常に大事なポイントではないかと思います。 同じように、社会インフラ、事故が起きたら非常に困るという東京ガスの服部さんに、 特に先ほどの二重化の問題をお聞きしたいのです。セブンナインみたいな二重化と、それ からリスクマネジメントみたいな考え方でコストを下げる。これについて何かご意見はご ざいますでしょうか。 （服部） 東京ガスの服部と申します。弊社もＬＮＧの製造工場やガスの供給ネットワー ク等々、ＤＣＳシステムその他をたくさん使っています。特に、インフラとなる業種とい うことで信頼性が問われていますが、一方では、エネルギー間競争の激化につれ、より一 層のコストダウンが求められています。ＤＣＳの二重化を含めて、システムの信頼性は市 場命題だということで、特にガスソース等に影響の大きい設備に関しては、故障しても継 続的に運転のできるよう、バックアップシステムを設けるという形で対応してきています。 この方式は、長い歴史を持っているものです。 もともとＤＣＳの発祥時点からの歴史を追っていきますと、現在でこそＤＣＳのＣＰＵ 二重化があるわけですが、弊社も含めて、特に故障すると影響の大きいようなガス事業者 あるいは電力会社は、 そもそもこのＣＰＵ二重化、それすら故障してもいいという体制で、 さらにバックアップシステムを持っている事業者が多いです。持たない事業者もあります が、このような事業者では、実は大きなガスホルダーという、ガス溜めを持っていらっし ゃる場合が多いのです。ですから、極端なことを申しますと、別にシステムがダウンして も、ガスホルダーに畜圧されたガスによってしばらくはガスの供給が止まらないので、お 客さまは困らないということになります。このように、プラント側も含めた設備のバック アップ体制が担保されている事業者では、計算機システムを冗長化しないという場合があ ります。 18 弊社のような使い方で考えますと、ＣＰＵ二重化は大いに結構なことだと思います。横 河電機さんから、ＣＰＵの信頼性がセブンナインとかいうお話が出ましたが、それ自体は 良いことと思います。しかしながら、フォーナインまで落ちるとさすがに問題と思います が、何もセブンナインをエイトナインにしてくださいということは、別にそこまで考える ことはないだろうと思っています。 仮に富士電機のおっしゃるようなシステムも、お話しになられたことを信用すると、 （フ ォーナインになっては困るわけなのですが）信頼性は十分高いので、将来これが、保守体 制面等の問題がクリアになれば、十分に使用出来るものと思います。 懸念されることとしては、元がシーケンサベースのものなので、長い製品設計がされて いない点や保守体制が、製品の寿命設計が長く長期間保守体制がほぼ保障されているＤＣ Ｓと大きく異なる点かと思います。先ほど、 「製造中止から 10 年は、何とか面倒を見てい ただけるとありがたい」との話が出ていますが、これが突然、例えばシーメンスとの関係 が切れて３年で終わりになってしまうということでは、ユーザ側は困ります。また、エン ジニアリング開発環境がＤＣＳに比べて十分に整備されているとは云い切れず、ＤＣＳ専 用機に比べてエンジニアリングに要する工数が大幅に掛ると思います。正直なところ、今 の状況では横河電機のＤＣＳ開発環境のほうが、どう見ても優れているように見えてしま うのです。 しかしながら、これらの信頼性以外の点が解決されていけば、何もＣＰＵの信頼性がＤ ＣＳ専用システム程まで高くなくても、冗長化により信頼性は十分に高めることが出来る ので、非ＤＣＳ専用システムを採用する機会も増えていくものと思います。更に、計算機 システムがダウンしても良いプラント側の設備条件や運用条件が整っていれば、なおのこ と、基地トータルの信頼性は十分担保されているので、もはや信頼性の時代ではないと思 っている次第です。 横河電機が、富士電機の先ほどのシステム構成をご覧になって、果たしてどのようにお 考えになっているのか伺ってみたいと思っています。 （新） それは伺ってもいいですか。 （横河電機・中原） 富士電機のお話が入る前に、セブンナインという数字が若干一人歩 きしている向きがありますけれども。 19 （新） そうですね。それで、参加者から、 「稼働率実績にかかわる実績システム総数はど のぐらいか。また主な故障部位、ユニットはどこか」というご質問が出ています。合わせ てお答えいただけますでしょうか。 （横河電機・中原） 覚えている範囲で、先に答えられるほうからお答えします。セブン ナインは先ほどご紹介しましたように、実績ベースの数字でして、次の設計目標をエイト ナインにするかというのは、また別の話です。バックにあるインストールベースの話にな りますが、先ほど確認したところですと、制御ステーション数でいうと、１万 5000 本程 度の数字からの裏づけという形になっています。皆様のお話を伺っていますと、特に午前 中のお話でも、ユーザはいろいろ条件をつけて、こういう設備であればＤＣＳ、こういう 設備であればＰＬＣということで、我々ベンダ側がＰＬＣ、ＤＣＳをどのようにより分け ていこうかと悩んでいる先に、もう十分いろいろ判断をされて、最適なところに最適なも のを使っていこうという取捨選択をされているという意味では、非常に健全ではないかと 思っています。先ほどの数字に戻りますが、当然、１万 5000 の制御ステーションすべて 冗長化というわけではなくて、大体６∼７割程度がＣＰＵ冗長化ということで、そういう 意味では、 お客様自身も横河電機の製品を使っていただく中でも、やはり使い分けをして、 常に冗長化ではない、必要に応じてプロセスの重要度と財布のバランスを見ながら使って いただけているのではないかと思っています。 最後に、富士電機のシステムをどう思うかと。富士電機とはいろいろな形で協業もさせ ていただいていますので、というわけではありませんが、横河電機は CENTUM だけでは なくて、ＰＬＣ計装もやっていますし、STARDOM という新しいタイプのネットワークコ ントローラもやっています。非常にビジネス的に悩ましいところは、ＤＣＳベンダが、例 えばＰＬＣを担いで持っていくと、お客様から「ＤＣＳなんだよね」ということをさりげ なく言われるのです。 それは何を意味しているかというと、ハードウェアがＤＣＳかどうかということではな くて、お客様に対しての様々な広い意味でのサービスが、ＤＣＳという言葉を形作ってい る部分が非常にあります。我々としては、当然皆様がお思いになるような、重い、固い、 高い、高いと自分で言うのは語弊がありますが、ＤＣＳのビジネスだけではなくて、もう 少しコンポーネント・オリエントな形で、インテグレータ用に使っていただける制御コン 20 ポーネントというビジネスもやりたいと思っているわけです。 しかし、必ずしもお客様にはそういうふうに受け取っていただけない。 「横河が持ってき たのだから、当然ＤＣＳ並みのサービスをしてくれるんだよね」と。その辺にまだまだ我々 の、営業としてどういうふうに話を持っていけばいいかというところの努力不足もありま すし、ＤＣＳという言葉が、もう 30 年になるわけですが、市場に与えた影響力の大きさ に、ある意味、戸惑っている部分もあります。 そういう意味では、富士電機が今回採用されたスタイルは二つの面で、海外かどうかは 別にして、他社のコントローラを心臓部に導入している点、それから SCADA を含めて、 複数のコンポーネントを合わせてシステムとして統合していこうという点で、取り組みと して我々もぜひ見習いたい部分もある。同時に、営業的に見ると、かなりの困難をこれか ら乗り越えていかなければならないのではないかという気持ちも若干感じました。 （新） ありがとうございます。 それでは、この話題の締めくくりに、ＰＬＣ計装をやられたライオンの安田さん、ご意 見を伺いたいのですが。止まっては困るＤＣＳ派ばかりだったので。 （安田） 当社は国内で５工場が稼動しております。その工程はバッチ系や連続系。また 工程の一部に蒸留反応もあります。これらの工程を 1 回／月、工程シャットダウン日を設 けメンテナンスに充てております。その為に短時間でスタート・ストップできる工夫をし ております。これにより生産途中でトラブルが発生すれば無理をせず工程停止し、復旧・ 再スタートをすればよいと考えております。よってシステムを選定する際はシンプルで安 価なシステム・構成を心掛けております。 （新） もう一つ、ソフトは自社でお作りになっていらっしゃいますね。 （安田） そうです。コスト削減やオペレータ技術力向上等の目的もありますが、１番重 要だと考えているのは、先ほどお話した素早い復旧対応には欠かせない要件と考えており ます。 当社ではソフトを自作する為の人材育成を含めたシステム導入に取り組んでおり、それが できれば様々な改善もできますし、ＰＬＣ計装・ＤＣＳ等について更に深い議論につなが 21 ると考えています。 （新） ありがとうございます。ＤＣＳ、ＰＬＣの問題は、ちょっと話題を変えますが、 多分ずっと全体を通じての話題だと思います。 では、次の話題に移りたいと思います。設計条件を考慮した予備品への対応という非常 に大事な問題について、日立那珂エレクトロニクスさん、回答をお願いします。 （多比良） 皆様、こんにちは。日立那珂エレクトロニクスの多比良と申します。私ども の会社は、日立製作所計測事業部那珂工場を母体としています。2001 年 10 月に日立ハイ テクノロジーズとして分社し、その中で計装関係の開発、設計、製造を行う子会社として やっています。どうぞよろしくお願いします。 今回の回答について、二つに分けてご説明いたします。一つめは、長期運用を前提とし た設計条件についてです。二つめは、製造中止後の予備品の確保、延命化についてです。 その２点についてご説明いたします。 まず回答内容ですが、オペコン、それからコントローラ等は、このような条件で、運用 年数、製品寿命 10 年として設計しています。コントローラについては、キュビクル内収 納を条件としています。この０から 40 度というのはキュビクルの周囲の温度ですので、 実際には中はプラス 10 度、50 度までということになっています。 下の図に、私どものＤＣＳのリリース状況が載っていますが、1975 年にＤＣＳを発表し て以来、このようになっています。いちばん古いものですと、1976 年に納めたシステムが いまだに稼働して、ご使用いただいているという状況です。ですから、実勢的には設計寿 命は 10 年としていますが、15 年ないしは 20 年ぐらいのスパンに耐える製品であると考 えています。また、プラントの取り合いで、ＰＩ／Ｏが非常に重視されると思うのですが、 ＰＩ／Ｏのユニットに関しては、このような状況になっています。600 シリーズというユ ニットがあるのですが、これは 86 年に発売し、現在もまだ部品改廃対応等を行って、お 使いいただいています。ですから、リプレースのときにはＰＩ／Ｏを変えないで、当然、 工事配線もそのままで、そのままお使いいただけるという状況を、私どもはできるだけ整 えているということです。 次に、設計条件について、私どものオペコンの例についてご説明します。まず、長期安 定稼働のための第１条件としては、温度を下げるということで、冷却系を強化することを 22 やっています。また、長寿命、高信頼部品を採用するということで、例えばファン、電解 コンデンサといったところ、またプリント基板も耐熱性に優れた材料を使っています。そ れから、実はオペコンを止めないでメンテナンスできるということが、消耗品を換えられ ることが長期安定稼働につながるということで、オンライン・メンテナンスも充実させて います。例えば、ハードディスクは動かしたままで、片側ずつ交換できるという設計にな っています。そのほか、部品誘導を持たせるディレーティングとか、初期不良を撤去する エージング等、設計、製造検査をもちまして、長い駆動に耐えうる製品をお客様にご提供 しているということです。 ２点めの長期運用のための製造中止後の予備品の保存、それから延命化対応メニューで す。まず、オペコン、コントローラ等のＣＰＵ、ＣＲＴ、ハードディスク等のユニットに ついては、全国に約 40 か所ありますサービス拠点において、お客様のところに対してど のぐらいでサービスできるかといったことを念頭に置きながら、必要数を確保していると いう状況です。また、部品の長期保有、改廃対応にしても、製造中止後５年間供給するこ とを原則に対応しています。現実的には５年間を超えても、特に保守対応をさせていただ いているお客様に対しては、10 年といったスパンで部品を使っていただくことをやってい ます。延命化対応メニューですが、予備品をお客様に購入していただく、保管管理してい ただくことを基本としまして、そのうえに保守契約を持って、そのお客様に優先的にそう いった部品の供給をさせていただくといったサービスも行っています。 さて、部品の改廃対応ですが、現実問題として一月に数件のそういった部品の改廃とい う対応をせざるをえないという状況にあります。内訳ですが、その改廃対応が必要なうち の中の 50％は、後継部品に切り換える。30％は設計変更をして、別の部品に切り換えるこ とをやっています。それでも対応できない特殊な部品、手に入らない部品等は、生涯の製 作数を勘案して買いだめするという策に頼らざるをえないという状況です。このような対 応ですが、昨今はデバイスの統廃合、これは携帯電話など、最新機種がどんどん出てくる という状況で、激しくなっていますので、ますます厳しいかなと。 あともう１点は、環境規制対応ということです。ヨーロッパに輸出する際に、ある特定 の金属が含まれてはいけないというＲｏＨＳ指令対応が 2006 年７月からです。これと併 せて鉛フリー化に対応するために、使える部品が制限されてきています。新しいものはい いのですが、古いものの保守は、ますますベンダ側としては厳しい状況に追い込まれてい ると感じています。 23 産業用プラットフォーム維持としてのコンセプトですが、ここでは三つ考えています。 一つは、コントローラ用ＣＰＵの選定が重要だろうということです。産業用のコントロー ラはこれだというふうに作られたわけでは、正直いってありません。例えばゲーム機やＰ ＤＡ等に使われているＣＰＵを、当社も使っているわけですが、その選定に当たっては、 そのＣＰＵのシリーズ、開発ロードマップが明確で、長期間やっていけるといったものを 選定することが基本ではないかと考えています。 次に制御用ソフトですが、ＣＰＵが変わっても、できればオブジェクトレベルでの互換 性、そのまま既存のソフトが使えることを目標として、最低限でも移行ツールによる変換 でそのまま使えるということを基本に開発する必要があるということです。 それから、パソコンの場合、性能が上がっていますので、オペコンにも通常使われるよ うになってきましたが、これについては改廃を前提とした設計をするという対応をさせて いただいています。パソコンに使われる汎用ユニット品は、ユーザが直接交換できるよう なやり方、交換手順をご提供してまいります。当然、ハードが変わればそれに乗るＯＳも 変 わ って き ます ので 、一 つ のシ ス テム の中 で異な るＯ Ｓ 、例 えば Windows ＮＴ と Windows2000 が同時に混在することもあります。そこで、システムとしてはそういった ものも当然大丈夫であることを、保証する必要があると考えています。また、このような 汎用パソコンを選択するという選択肢のほかに、当社では自社製のオペコンを持っていま すので、長期稼働 10 年といったものが必要なお客様には、そういったものを選択してい ただくという手段も用意しています。 予備品の保管、計画の合理化ということで、こういうことも考えていきたいという内容 です。お客様のほうから回収した部品の腐食状況とか表面の状態等を解析して、それまで の温度とか湿度といったデータとともに、なるべくフィールドデータを集めるようにする。 そして、将来的にはこういったデータから、お客様のほうでどのぐらい予備品を保管すれ ばいいのかということも、算出できるようになるのではないかと考えています。 以上、我々としてはユーザに長い間使っていただくような施策を取り入れてやっていく 所存です。一方、ユーザにも、部品の改廃対応等、メーカーとしても厳しい状況であるこ とは、理解していただきたいと考えています。 （新） ありがとうございます。引き続き、オムロンさん、お願いいたします。 24 （平瀬） 皆さん、こんにちは。オムロンの平瀬と申します。よろしくお願いします。お 手元にお届けしている内容は配付資料という形にします。今日は発表資料ということで、 少し追加した内容も含めてご説明をしたいと思います。 この内容自身は今回回答した内容を出していますので、今回の２番めの項目には直接関 係ないということで飛ばします。ここから長期運用ということ、それから予備品の部分と いうことで、実は回答はこれだけでした。予備品の具体的な状況ということで、生産中止 とか、中止後はどうするのだとか、これらの疑問に対しての回答について説明したいと思 います。 まず、長期運用のためのシステムデザインということで、これは皆さんがご存じのよう なバスタブ曲線です。ＰＬＣ自身もいろいろな部品を使っていますので、当然ながら寿命 品も使っています。したがって、初期故障ですとか偶発故障ですとか磨耗故障などを、い ろいろな部分で、お客様のシステムの設計をアプリケーションごとに処置、点検を含めて 交換することが前提になるのではないかと思っています。ただ、交換といっても、故障が 起きてから交換するということではなくて、できる限り未然に防ぐということで、予防保 全という内容のことを推奨していきたいと考えています。 私どもは、ＰＬＣ計装を５年ぐらい前からやっているわけですが、ＰＬＣの交換年数と いうことで、これは推奨です。先ほど、富士電機や三菱電機からもありましたように、や はり設計の寿命みたいなものがあります。我々はＰＬＣですから汎用ということも踏まえ ながらいろいろな設計をしているわけですが、おおむね一般的な仕様でいいますと０−50 度ということで、内部的には、あとプラス何度を含めてという設計をするわけです。目安 として、40 度Ｃ24 時間稼働ぐらいで、電源だったら８年、ＣＰＵベースだったら 10 年。 交換というよりも、この辺のタイミングが定期点検の目安かと考えています。ここでいろ いろな状態を確認していただきながら交換するのも、一つの手段だと考えています。 我々メーカとしては、商品そのものをいったん市場に出した以上、やはり長期の維持生 産をやっていく必要があります。先ほども日立さんが言われましたように、電子部品の改 廃が非常に激しいです。私どもの三島の工場では、月に 80 件ぐらいの部品の変更が出て きています。この辺をやはり代替部品を実施して、製品の長期維持をやっています。もち ろん、よい商品を供給するとか、同じ商品を供給する。コピーイグザクトリーとかチェン ジコントロールと言われていますが、ＦＭＥＡなどのツールなり考え方を使いながらやっ ています。 25 その例としては、こういう代替部品を評価するとか、検討をしていくとかということで、 とにかく外に出ている商品と同じ機能、性能、これはカタログ仕様ではなくて、実力と考 えていただいていいのです。そこまで取り込みながら、データ、波形観測をしていったり、 それから評価試験をしていくという形で、部品の変更ということで延命をしています。 実績としては、これを出すのはちょっとはばかっていたのですが、ＰＬＣがスタートし てから、もう 30 年近くになります。これよりも古いＰＬＣはありますが、大型、中型で いきますと、Ｃ500 が 88 年 10 月から。やっと今年の３月に、大変申し訳ないのですが、 生産中止とさせていただきました。 こうやって見てみますと、ＣＰＵで約 20 年、Ｉ／Ｏで 25 年。これはアップ・アド・コ ンパチということも含めて、開発だけではなくて、生産のほうが継続・維持している、そ ういう内容です。ですから、やはり我々が世に出した以上、最低限の期間、例えば 10 年 とか 15 年とか、これはやはり供給し続ける責任があると考えています。そのためには部 品を変える。変える部品がなかったら、プリント基板も変更する。そんな形でやっていき たいと思っています。 ＰＬＣ計装として、今、対応しているのが、いちばん下のＣＳ１、ＣＪ１ということで、 これはまだまだスタートしたばかりです。それと今年、来年を踏まえて、ＲｏＨＳ指令対 応も含めて部品の変更などがありますので、これを機にブラッシュアップして、またまた 延命化を図りたいと考えています。 その延命化というものをやったうえで、やむなく生産中止をしなければいけない、これ が生産中止のプロセスです。細かくは言いませんが、約２年前に案内をして、生産中止と してからアフターサービスに変わります。基本は７年です。そこから５年間の延長という ことで、12 年ぐらいは何とかできるかなと。これは部品ありきと考えていますが、こうい う内容になります。 あとは、それをスムーズにやるために、こういう計画保全とか、そのための定期保全、 それから事後保全、電池や電源、ＣＰＵ、ＰＬＣの構成ユニットなどをターゲットにしな がら、保全計画をお客様の状況に合わせた形で対応いただきたいと考えています。 予備品については、交換ユニットにはこういうものがあります。あと、定期点検につい ては先ほど申し上げました。予備品ユニットとして、大体１個以上を用意していただいた らいいとは思うのです。これをやりきるに当たって、 何年も持っていることになりますと、 やはり保管の問題とか、いろいろなことがあります。これは、我々が生産し続けている以 26 上、注文を頂いてから即日ということも含めて、対応できるようにはなっていますので、 必要最小限の予備品のユニットを持っていただくことで、いいのではないかと思います。 あとは延命化のための対応メニューということで、保証期間の延長とか、そういう契約 等もあります。それから、安定稼働のためのシステム設計の支援ということで、いろいろ なお客様の企画のところから、こういう使い方をされると長期安定稼働ができますよとい う支援業務もやっています。 こういう内容を含めて今、対応しています。 （新） ありがとうございます。三菱化学の米田さん、今のご回答に対して、いかがでし ょうか。 （米田） 三菱化学の米田です。先ほどから信頼性でどのシステムを選ぶかという話があ りますが、僕の考え方は、基本的にはリスクマネジメントというか、リスクの評価です。 例えば、先ほどありました公共性があるようなプラントだったら、絶対に止めてはいけな いので、二重化とか、さらになるバックアップとか、当然見合うだけのリスクに対する投 資をしなければいけないかなと思います。ですから、私どもの会社でも、エチレンプラン トなどには、やはりきちっとした二重化システムなどが要ると思っています。 ただ、先ほど述べたようなプラントでは、バッチで、小型で、開発的な要素が含まれる。 そういうところには、別にそういうものは要らなくて、もっと重要なもの、例えば品質管 理などが必要なプラントもたくさんあります。そういう自由度を求めるために、我々はあ あいうものを手掛けているわけです。 今の長期運転に対する考え方ですが、同じようにメンテナンスでリスクを考えると、 我々 のところではリスク・ベースト・メンテナンスといい、要は部品というか物に対して、こ の部品が次のメンテナンスのタイミングまでに、ちゃんともつか、もたないか。そういう 判断基準がいちばん大事かと思っています。それがＯＫならばメンテナンスはしない、計 画にも入れない、だからコストがかからない。でも、必要なものはメンテナンスしていく という意味合いなのです。そういう考え方でいくと、メンテナンスにはブレークダウン・ メンテナンスＢＭ、壊れてからやる、あとタイム・ベースト、時間周期的にやる、あとコ ンディション・ベーストと、大きく分けて三つぐらいあると思います。 今、最後のほうにちょっとありましたが、理想は全部ＢＭで、自分たちが使っている間 27 は壊れない、寿命をまっとうさせてあげたいところもあるのですが、 そうはいかないので、 タイム・ベーストとかコンディション・ベーストで考えていかなければいけないわけです。 タイム・ベーストは割と電解コンデンサのような有寿命部品でやっているわけですが、実 際の基板の傷み具合とかそういうものが、先ほどちょっと事例が出ていましたが、実際に はよく分からないと思っています。そういうことに対して、ＤＣＳメーカ、ＰＬＣメーカ は、情報をあまり開示されていないのではないかなと。まれに私どももＤＣＳメーカと一 緒に、環境測定などをやって、データを作って、回帰式みたいなものを作りました。そう いうものがあっても、なかなか本当の環境と信頼性に対する情報は、お互いに共有してい ないのではないかと思っています。そういうものはこれから大事にしていきたいなと思い ます。 あともう１点、ハードウェアの寿命が来たから変えるというのはいいのですが、ときど き製造の時期によって、同じ型番でも機能が違ったりすることが多々あるみたいです。２ ∼３回、今までも経験があるのですが、そういうものがあると、どこかやり直さないとい けないとか、そういうことで手間がかかる。 仕様書のうえでは分からない時間がかかって、 変なものを使っているなというものが、何件か自分のところの経験でもあります。そうい う意味で、先ほど発表したときは、最低で 15 年、希望は 20 年のハードウェア、予備品を 使ってもソフトウェアがついていける範囲で、そういう保証をしていただきたいなと、そ れが希望です。ＰＬＣに関しては、そこぐらいまでかなと今思っています。 （新） ありがとうございます。三菱化学エンジニアリングの今任さん、いかがでしょう か。 （今任） 三菱化学エンジニアリングの今任です。三菱化学で開発しました「プラタナス」 は、当時、今日発表がありました米田が開発のリーダーで、開発したものの評価、それか ら更新、三つのワーキンググループを作って取り進めていたわけです。当時、私もそのメ ンバーでした。現在はエンジニアリング会社で、ＳＩという立場で仕事をやっています。 いろいろ話があったので、言いにくいところもあるのですが、当時、私もＰＣ／ＰＬＣ は推進派というか、やっておりました。やはりバッチ型、機能品を作っているようなプラ ントですと、そこの工場で作っている製品のライフが終わって、工場を改造して新しいも のを作れるようにするといった時、例えば反応缶の更新、それからその周りに附属してい 28 るバルブなどの更新は、経営サイドは何も言わずに投資するわけです。しかし、ＤＣＳに なると、「そんな高い金を使うのか」という話がしょっちゅうありました。 ＤＣＳの場合、缶を一つ二つやり換えるというだけでも、いろいろアプリケーションの 部分に手を入れないといけないので、ソフトウェアの開発費用が多くを占めてしまうとい う問題もありました。缶の周りについている自動弁や計器は捨てていいということであれ ば、缶ごとにＰＬＣを全部張りつける。それだったら、この部品として捨ててしまえばい いでしょうと。事業所のトップに対してはそういうふうに説明して、安くなりますよとい う話をしながら進めていきました。そういう意味では、計装エンジニアを含めて、どっち がいいかという議論もありますが、ちょっと頭の固い経営層の方に、どう理解していただ くかということも重要かなということを、当時感じながらやっておりました。 それからあと長期運用ということですが、日立はけっこうＰＩ／Ｏの部分を長く作って いただいているというか、作るべきものを作っているという面では、だいぶ助かったかな という気がします。あと、ソフトウェアのコンバージョンも、それなりにやれる形をとら れていますので、この辺がちょっと他社とは性格が違うかなと感じています。先ほど、新 日本石油の水谷さんからもありましたが、いったん安い価格で導入したのだけれど、後々 の改造とか更新のときが来ると、えらい高いお金が出てくるわけです。 今、エンジニアリング会社という立場で、三菱化学、それ以外の外販もやっていますが、 更新費用についてなかなか説明が難しいことがあります。 「なぜこういう金額なのか。エン ジニアリング会社だから安くするように交渉しろ。 」とよく言われます。そういうつらい面 がありますので、その辺のところをもうちょっとうまい営業をお願いしたいなということ が一つあります。 それと、三菱電機とかオムロンへのお願いです。 一つは、ＰＣ／ＰＬＣになりますと、ハードの価格はやはりＤＣＳに比べるとかなり安 いことは皆さん実感されているかと思います。しかし、やはりアプリケーションのマンア ワー・開発工数は、ＤＣＳよりも、先ほど東芝でしたか、エンジニアリング機能はＤＣＳ のほうが上だとありましたが、そのとおりだと思います。ハードウェアとソフトウェアに かかるコストの比率が逆転してしまいましたので、ユーザから見ると、今度は逆に、 「そん なにソフトに金がかかるのかよ！」という声が最近出てきだしています。ＳＩｅｒにとっ てはソフトの単価が下がることは死活問題ですので、その辺もやはり簡単に、効率よくで きるようなところをお願いしたいな、というのが一つです。 29 また、分散型制御システム、デジタル制御システムと言ったりするときもありますが、 ＤＣＳという名前がついているのに対して、いまだにＰＬＣ計装とか、ＰＣ／ＰＬＣとか、 そのもののハードの名前を呼んでいることがあります。ＤＣＳという名前が、先ほど横河 の中原さんの話でありましたように、文化になったように、例えばビールに対して、発泡 酒が市民権を得ましたが、そういう名前をぜひ皆さんでつけられたらと思います。 （新） ありがとうございます。それでは、東京ガスの服部さん、お願いします。 （服部） 今いろいろとご説明いただいたのですが、ＰＬＣの場合、基本的に予備品は、 ある特定の機種を作った場合、生産台数がたくさんあれば、かりに 10 年経とうがあまり 怖くないとも言われているわけです。そのような意味ですと、ＰＬＣ側の製品群というの はそれなりに魅力があるなと思っています。ところが、片やＤＣＳの場合ですと、そのマ シンに特化したものを作っているがゆえなのかどうか分かりませんが、どうしても十数年 経ちますと、どこまで本当か分かりませんが、本当に物がない、とアナウンスをされてし まうことが非常に多いと感じています。 すでに導入してしまっているものに対して言うのは、なかなか困難かもしれませんけれ ども、もし将来のことを考えますと、同じような宿命をたどることは必然ですし、将来経 年部品に対するユーザ側の需要が当然出てくるだろうと思いますので、これらに低価格で 対応して頂ける保守体制を確立して頂ければと思います。例えば、基板なり、あるいはほ かのハードウェア、電源装置なり、諸々一とおりはどのベンダも作っていらっしゃるし、 これらの保守対応実績等のデータもお持ちだろうと思います。今後もし製品を出されると すれば、将来ある特定の部品はこれぐらい壊れるだろうから、何ぼ持っていればよさそう だとか、そのような需要動向・故障実勢その他を考慮のうえ、ストックを計画なさるなり、 といった企業努力も、ぜひお願いしたいと思います。更には、部品だけではなくて、サー ビス体制に関しても同様に、長期的に面倒を見ていただけるような体制を、継続して構築 していただきたいと思っています。 （新） 私から質問したいのですが、そういうふうに将来を見込んでたくさん作ったり、 サービスをするとコストがかかりますよね。そのコストは、服部さん、払っていただける のですか。 30 （服部） なかなか払いたくないなというのが、本音なのですけれども。 （新） 値段が高くても買ってくれるのなら、やってくれるのではないかと思います。あ りがとうございます。 それでは、次の話に移りたいと思います。次は WindowsＨＭＩへの対応ということで、 最初に東芝から、ベンダ回答を頂きたいと思います。大庭さん、よろしくお願いします。 （大庭） それでは、WindowsＨＭＩの寿命延長、部分更新策という質問に対する回答を します。東芝の大庭です。 回答として、ここに書いてありますのでちょっと読みます。現状のパソコンおよび周辺 装置は、Windows のバージョンに追従した流れである。この流れに逆らい、旧バージョン の Windows に対応したパソコン、および周辺機器を作り続けることは無理ということで、 Windows がアップグレード、変わっていったら、それに追従していくというのが基本的な 考え方です。ただし、それはＯＳに追従する標準部のソフトなどの辺のところで、お客様 のアプリケーションソフトに関しては、互換でいくという考え方です。さらに、旧バージ ョンの Windows と互換性を保ち、同一制御システム内に新旧の Windows が混在して設置 できる方針で進めている。これは午前中の横河電機や富士電機も同じ方針だったと思いま す。 当社としては産業用パソコンを作っていますので、Windows の切り替わり周期よりも、 少し時定数を遅らせた形で、パソコンおよびＯＳを供給するという形を考えています。こ れがその絵です。 上側が汎用パソコン、半年ぐらいでどんどん次のパソコンが出てきますという絵です。 下側が産業用パソコン、基本的には５年間作って、その後７年保守する。最大 12 年とい う考え方です。ＤＣＳやＰＬＣ計装のヒューマンインタフェースのところには、この産業 用パソコンを使っているという形になっています。ハードウェアも絡みますので、半年ご とに、産業用パソコンはなかなか追従できないのですが、１年から 1.5 年ぐらいに次の機 種を出して、そのときの新しいＣＰＵを使ったりＯＳを搭載して、長く供給するという考 え方で作っています。 これはソフトの話とは異なりますので割愛しますが、産業用パソコンの一般的なスペッ 31 クです。要は、信頼性の面ではこれだけです。これは先ほどの日立の話の中にも出てきた ものかと思います。ダウンタイムを短縮するために、前面メンテナンスができるような形 になっています。これは、頑健性ということで、耐温度の強化のために空冷で寿命部品を 長くするという対策を行っています。 次が８−２項で、WindowsＮＴをＨＭＩソフトのエミュレートということで、エミュレ ーションソフトを使うことがあるかという質問に対する回答です。中身的には同じになり ますが、当社としてはそういったＯＳのエミュレーションソフトを使う予定はありません。 あくまで Windows を、ちょっと時期的にはずれますが、新しいものを使っていくという 方針で進めています。 最後の８−５、ベンダフリーなＨＭＩの開発方針ということです。現時点の当社の考え 方では、ＤＣＳというのはマンマシンとコントローラ一体で、システムとして提供してい ますので、複数のベンダで共通化されたＨＭＩを作るというのは現時点では難しいかなと 考えています。ただし、あるＨＭＩ、あるシステムがあって、そのシステムにほかのシス テムのデータをＯＰＣなどで取り込んで表示するという形では、これからも進んでいくの ではないかと考えています。さらに、ウェブ環境やリモートなどの考え方でウェブブラウ ザで表示するというシステムは出てきていますので、それはそういうデータサーバを各社 が提供することによって、ベンダフリー的なマンマンシができるのです。しかし、あくま でマンマシンのソフトの作法は、それを作っているメーカーに依存すると考えています。 これは２番めのところに書いていました、あるシステムがあって、他社のデータを取り 込む、ＯＰＣによる他社接続の考え方です。それから今度はそれの逆で、こちらのシステ ムからＯＰＣサーバを通して、他社のシステムにデータを与えるという形です。もともと のベンダフリーなＨＭＩとはちょっと違いますが、現時点で実現しているＨＭＩはこうい った形かなということで紹介させていただきました。 （新） ありがとうございます。引き続き、東芝三菱にお話を伺いたいと思います。 （東芝三菱電機産業システム・中原） こんにちは。東芝の後に東芝三菱電機産業システ ムということで、会場の中にはご存じない方もおられるかと思いますので、簡単に紹介さ せていただきたいと思います。 私どもの会社は昨年、ちょうど１年になりますが、東芝と三菱電機の産業部門が合弁会 32 社ということで一つになりました。実際やっているソリューションビジネスとしては、東 芝の製品や三菱電機の製品、それから自社開発したもの、それと市販ツールを使って、お 客様に最適なソリューションを提供することを、ビジネスとしてやっている会社です。 具体的には、ＤＣＳとかＰＬＣについては、東芝の製品については東芝のご発表内容、 それから三菱電機のＰＬＣについては、先ほどの三菱電機の名古屋の内容をご参照してい ただきたいと思います。私に与えられた今回の WindowsＨＭＩの対応というテーマについ ては、三菱電機のＤＣＳを主体にした内容でご説明させていただきます。 ユーザ要求の８番で、WindowsＮＴ対応マシンへの継続の提供というご質問が来ていま す。これについては、三菱のＤＣＳについては、いろいろな対応をやっています。一つに はＮＴの対応マシンを継続して提供する。これはＮＴを必ずしも置き換えればいい、追従 して、新しい Windows に置き換えればいいというだけではありません。マンマシンだけ に限ればそうかもしれませんけれども、システムの中には、Windows を変えることによっ て、例えばデータの管理をしているような機能がその中にありますと、オラクルが入って いたりしますと、Windows のタイプが変わると、オラクルまで上げないといけない。オラ クルが上がると、オラクルのクライアント機能で、アクセスしている場合には、その組み 合わせも変わって、オラクルが載っているマシンの更新だけではなくて、老朽化をしてい ないクライアント側の汎用パソコンなども、一気に変えざるをえなくなる。 そういうことで、Windows を更新することによる波及範囲が、システムによっては非常 に大きくなってきます。そういう場合には、Windows を新しくしたマシンをハードが老朽 化したからといって、更新するのは必ずしも得策ではないと、ユーザの更新のためだけの 投資を考えると、そう考えています。そういう場合には、その部分に関してだけは、ＮＴ をそのまま継続できるようなハード環境を継続して、提供させていただくという選択肢も 必要ではないかと考えています。それについては、例えばＮＴ4.0 のワークステーション の生産中止時期はもう決まっていますので、その後はエンベデッドタイプのＮＴでサポー トを検討することも考えています。 それから、２番めに書いてあります WindowsＮＴへの新バージョンへの移植として、メ ーカーとして、どこまで本当に追従が必要なのか。東芝は約半年遅れとかで追従されてい るということですが、それもやはり製品コストに跳ね返ってきて、本当にそれがユーザの メリットにつながるかどうか。これはやはり、メーカとしてはそこもよく見極めて、 Windows の市場性とか技術動向も見極めて、本当にどの Windows に適用させるべきかと 33 いうことをメーカとしても考えていかないといけない。また、それはユーザにも、最終的 にはコストに反映することを含めて、ご同意を得たいと考えています。 それと、ＮＴのエミュレーションの機能について対応しているかどうかというご質問が ありました。これは三菱のＤＣＳの一部のマンマシンで対応しています。確認中と書いて いますが、すでに対応しているものもあります。ほかのメーカは、特に性能とか、階層的 に複雑になることもありますが、一応、対応しているところは、かなりエンジニアリング の機能についてもソフトのボリュームが大きい。そういうことで、移植をするよりはエミ ュレーションの上で動かしてみて、問題ないということであれば、特にオペレーション等 の性能に影響を与えなければ、一つの選択肢ではないかと考えています。よって、ＮＴの エミュレーション機能の上で、エンジニアリング・ツールを動かすといったオフライン的 な使い方での適用をしています。 それとあともう一つ、ＨＭＩの製品開発のスタンスというご質問がありました。これに ついては、先ほど申しましたように、適用したＯＳは、基本的にはハード環境も含めて、 製品寿命の延命化を図る。これがいちばんユーザに対してはメリットになるのではないか と考えています。それでもどうしてもできないということであれば、やはり最新のＯＳを 含めたものに追従する。そのためにはやはり市場の動向ですとか、その Windows がどこ まで今後伸びていくかも含めて、あとユーザニーズを見て、機種ごとに検討していく形で、 三菱の今後のＤＣＳはＮＴの対応をしていると考えていただいていいかと思います。 あと、この WindowsＮＴをＤＣＳに採用したときには、皆さん、ユーザも含めて、オー プン化というメリットを享受して、その代わりにマイクロソフトの戦略に乗ってしまった というデメリットもあります。そこはやはり、ユーザとメーカが一緒になって、マイクロ ソフトに追従するだけではなく、今後のお互いのメリットを検討していきたいと思ってい ます。どうもありがとうございました。 （新） ありがとうございました。 それでは、ユーザを代表して、トヨタ自動車の高野さん、ご意見を伺えるとありがたい のですが。 （高野） ３点お聞きしたいことがあります。まず、今の東芝三菱さんの、過去の遺産に 対するリーズナブルな見解に共感しております。これを本当にベンダのかたとしては、ど 34 う提供されるのか。ぜひお聞きしたいところです。これは見解ではなくて、どう実現され るのかという話をお聞きしたいと思います。 ２点めは、ぜひ山武さんと横河さんにお聞きしたいのですけれども、横河さんもちょっ とおっしゃっていました Windows などのＯＳが変わっていくつどに、それに皆さんは徹 底的に追従していかなければいけない。これはそうなのでしょうけれども、もう１歩上を 考えて、アプリケーション側のミドルウェア思想によるシステム開発を重視する時期にき ていると考えます。これは多分、どんなＯＳを使ってもバージョンアップは必須だと思い ますし、開発ツールは若干は変わっていく。 例えば、横河さんも、ご苦労されていると はおっしゃっているのですが、ただ単純にアプリケーションを追従すると、これはものす ごい苦労になってしまうと思うのです。ベンダの方々が苦労すると、ユーザにとって得な ことは全くないと我々は思っています。この辺の設計思想について、ぜひお聞きしたいと 思います。 もう１点、これは最初に聞きたかったことなのですが、富士電機さんのほうで Windows のハードウェアも含めて、中止後 10 年間保証すると言われたと思います。これは本当に できるのだろうかということを、ぜひお聞きしたいと思います。 （新） すみません、全ベンダに聞いている時間がないので、山武、横河、富士電機への 質問にお答えいただきたいと思います。 まず、富士電機システムズさん、10 年間保証ということに対してお答えいただけますか。 （笹谷） 基本的にパソコンの 10 年保証ということで、ハードとソフトという形で分け るわけですが、基本的にハードは 10 年間確保して提供するような体制を作りたい。それ をしないと、今言った 10 年なりという形では対応できないだろうと考えて、やはり 10 年 は保守しようという形に現実的に体制を整えようとしています。 あと、現実的には、ソフトが変わっていった場合は、やはりそのソフトに応じた、東芝 などの形にもありましたように、１年遅れ、何年遅れでそういったものをキャッチアップ していく。そういう形をとらないと、現状、幾ら保守という面を考えたとしても、いちば んのユーザの評価ポイントが、Windows の機能なり、新しいＯＳの機能であるからです。 ということで、DCS ベンダとして、保守品をかかえながら新ＯＳ対応への開発行為をやっ ていかなければならないというベンダとしての板挟みはかなりあります。 35 （新） 山武さん、ミドルウェア化はちゃんとやっているかということです。 （新井） 口で「やっています」と答えるのは簡単なのですが。確かにＮＴ3.51 から 4.0、 2000、当社では先日発表させていただきましたが、ＸＰのＳＰ２ということで、ハーモナ スをずっと、デオも含めて、アップデートしてきているわけです。その中で、基本的なア プリケーションは、上位互換を保ってきています。ただし、一部のユーザ様で、ハーモナ スが最初に出たところで、まだその当時はパソコン、ＤＣＳとかいう名前、今も言ってい ますが、小規模システムメーンというところ、小規模のアドレス空間しか持っていなかっ たものですから、それを今はほとんどフリーなアドレス空間に拡張していますので、そこ の部分での互換性を保てない部分があります。そこの部分はＲＯＭ交換ということで対応 する部分は、コントローラサイドでお願いするところもありますが、あとは基本的には上 位互換を保っています。最新のＸＰ版は、Windows2000、WindowsＮＴとも共存可能な ように設計をしています。そういう意味で、お客様のアプリケーションの資産を、できる だけ保護していきたいという設計思想のもとでやっています。 この辺は、言うのは簡単なのですが、けっこうテストも含めて、メーカサイドは、先ほ ど横河さんもおっしゃいましたが、多大な工数をかけて、互換性のチェック、およびパッ チのチェックをしていることも、ぜひユーザにはご理解いただきたいと思います。 （新） 中原（横河電機）さん、お願いします。 （中原・横河電機） 私の説明が若干悪かったのかもしれないのですが、まず、お客様が 実際に運転に使っているアプリケーション・ソフトウェアを、 一つのエンドユーザが持つ、 資産としてのソフトウェアと位置づけたときに、ＤＣＳが持っている設計ツールは、ミド ルウェアだろう。そういう位置づけにおいて、ミドルウェアのインタフェースを守ります よというのが、私が先ほどご紹介した趣旨です。 高野さんがご指摘になられた、確かに我々がソフトウェア開発にすごく汗水を流すとい うことは、結果的にコストとして、お客様に跳ね返るという意味では全くおっしゃられる とおりです。我々は今 Windows の上にベタにものづくりをしていますが、今後は、例え ば本来の意味での Java の仮想ＯＳみたいな形の上で、そういうツールを作っていくとい 36 う取り組みが必要だと思っています。また、一部ではそういう活動を始めていることは確 かにあります。ただ、まだ全面的な商品として展開できるところまでは、行っていないと いう事実があります。 （新） 高野さん、回答を頂きましたが、いかがでしょうか。 （高野）今、中原（横河電機）さんがおっしゃられたように、Windows にベタに作ってし まうと、これは非常に大変なことです。これはユーザもよく分かっているので、これを無 理に、例えば早くＸＰが欲しいから何とかしてほしいというのは、今の作り方だと非常に 無理があるのだろうと思います。そういったものを踏まえた上での、アプリケーションの ミドルウェアの設計が要る。今後も Windows をＨＭＩのＯＳとして使っていくのであれ ば、そういうことをやらないと、２∼３年スパンで繰り返さなければいけない状況になっ てしまいます。これはユーザにとってもベンダにとっても、非常に損な状態にあるという ことが言いたかったわけです。 （新） ありがとうございます。 ∼中断∼ Ｄ．リプレースコスト （新井） Ｉ／Ｏとコントローラ間のバスも大きく変えておりませんので、その辺も含め て最大限流用できるようになっています。ハーモナスで一時期、別型のＤＩＮレール取り 付け型のＩ／Ｏを出しましたが、旧来のＴＤＣＳ系のＩ／Ｏも含めてすべて、サポート可 能になっています。 あとは先ほどちょっと申し上げましたが、制御ネットワークでの相互通信が可能ですの で、あるユニットのある部分だけを、ＴＤＣＳ系ですとネットワークが幾つか違うのです が、次のネットワーク、最新のネットワークに切り換えたり、イーサネットのものと相互 接続ができるようなゲートウェイを開発しています。また、上位をいったん介して、情報 系制御、ネットを介しての相互通信は、他社システムを含めて、これは実際にかなりの実 績を現在持っています。 コントローラに関しては、今までのＩ／Ｏをそのまま使って、今、ＣＰＵだけかなり高 37 機能になっていますので、今まではＣＰＵ４枚必要だったものを１枚で可能にする。ただ し、リダンダンシーの部分が気になると思われますが、その辺は三重化コントローラ、２ アウト・オブ・３のコントローラが、今、ＴＤＣＳ系でもハーモナス系でも使えるような 形になっています。 あと、ご質問のほうに、マルチベンダ対応のエンジニアリング環境ということがありま すが、これはエンジニアリングメーカも含めて、ときどきいろいろな形でお話をする機会 が多いのです。現在は、弊社のエンジニアリング環境、特にコントローラドローイングの 関係、ループの関係をある程度オープンにして、どういう格好でうちの制御ドローイング がされているかを、テキストファイル形式に吐き出すようなことも今、可能にしています。 では、他社のエンジニアリング環境にそれが移植できるかとか、その辺は現在ではまだ難 しい状況であるのかなと。幾つかのトライはいろいろなところでしていますが、なかなか 難しいかと思っています。 逆に他社のコントローラの情報を、弊社のコントローラのほうにコンバートすることも、 それなりのツールなりトライは、各社も同じ現状だと思いますが、やっています。ただし、 タグ構造とかポイント構造が、各社で違っているので、こうなっているので、こうすると うまくいく、うちのＤＣＳにリプレースしていただければこうなりますよ、といったガイ ダンスを出せる格好にするのが精一杯かなというところです。あとは、エンジニアリング 環境との統一は、まだまだ今後の課題であるかと感じています。 （新） ありがとうございます。続きまして、オムロンさん、お願いいたします。 （平瀬） それでは発表いたします。お手元のページでいきますと 56 ページになると思 います。リプレース切り替え時間のスピードアップというところから考えますと、リプレ ースという件については、私どもはＰＬＣ計装をやってから５年ですので、リプレースと いうタイミングはありません。したがって、ＤＣＳからＰＬＣ計装、もしくは将来を含め たＰＬＣからＰＬＣへのリプレース、そういうタイミングがあるかなと思っています。 また、だんだん変わっていますリプレース・コストから考えますと、単にこのハードウ ェアとかソフトウェアの置き換えだけでなく、リプレースを計画してから実行するまでの 時間、それから実際にハードウェアの工事を含めた置き換えの時間、それからその後、実 際にオペレーターの方々が、従来の操作と変わりなく対応できるか。そういうところの、 38 トータルのリプレース・コストが出てくると思います。したがって、今回の発表の中では、 コストというよりも、その前に私どもが何をしなければいけないのかというところから、 少しご説明をしたいと思っています。 ＤＣＳからＰＬＣ計装へのリプレースとなりますと、当然ＤＣＳが持っている機能、性 能がキーになります。これをＰＬＣで実現しようとすると、午前中からいろいろ言われて いますように、やりにくいとか、そういうことがあります。ですから、ループ制御とかシ ーケンス制御のファンクションブロックの言語や、シーケンステーブルの言語などをでき る限りＤＣＳの言語に近づけていって、コンパチになるのがいちばんいいのでしょうが、 お客様の使われ方を含めた形で、置き換えやすいような対応をしていくことがまず一つか なと思っています。 したがって、私どものＰＬＣ計装はラダーのエンジンを持っているＣＰＵと、ループコ ントロールという制御をする別のＣＰＵの、２ＣＰＵを持っています。ラダーについては ＰＬＣ−ＰＬＣですので、アップ・アド・コンパチということで、命令語はそのまま使え ます。もしくは、仮に使えないものがあったとしても、プログラムの変換ツール等を使い ながら変更ができる。そういう対応を、ソフトウェアのところはしていっています。 ハードウェアについては、どんどんコントローラ自身が小さくなっていきますから、置 き換えようとしますと、やはり端子台等の置き換えの部分が変わっていきます。したがっ て、Ｉ／Ｏカードを実際に配線されているコネクタをそのまま使いながら、端子台の変換 ユニットを作る。そういう形で、工事の期間などを短縮できる形をとろうとしています。 中にはないのですが、当然ながらＰＬＣ計装という部分での基本機能はＤＣＳの機能を 持ってきます。それから、当たり前ですが、ここにあります八つの大きな基本機能を着実 に実現していきます。今というのではなくて、リプレースする５年、10 年ぐらい前、もっ と前ですか、その辺の機能のＤＣＳの常識というか、 「少なくとも最低限これぐらいの機能 を持っていないとＤＣＳとは言えないね、プロセスと言えないね」というものは、きちっ とＰＬＣの中にも取り込んでいかなければ、リプレースが容易にできないと考えています。 私どもは、そのために、こういう小型のＣＪのＣＰＵとか、ＣＳ二重化を使いながら、 ループ制御とか、ツールなどを着実に作り、改善しながら、またいろいろなお客様の声を 聞いて、それをこの商品に反映しながら置き換えやすいものづくりをやっていきたいと考 えています。以上で終わります。ありがとうございました。 39 （新） ありがとうございます。ライオンの安田さん、いかがでしょうか。 （安田） 製造設備に比べシステムは短命です。その為にシステム検討段階からリプレー スを意識しています。同じ投資をするのであればリプレース時にハードのみの更新に留め、 ソフト資産はそのまま活用したいのですが現実はそのように行きません。つまりハードと 併せてソフトも大幅修正や再構築をしなくてはなりません。なんとかこの辺を解消できな いかと考えております。さらに欲を言うと他社のＤＣＳへの移行やＤＣＳからＰＬＣ計装 への移行等。また、その他のニーズがユーザにはあると思います。この様なことが実現す ればユーザにコスト低減やソフト信頼性確保・納期短縮等の数々のメリットが出てきます。 私は各社のお話が拝聴できるとディスカッションを楽しみにしておりました。 そこで、横河電機の中原さんと富士電機の笹谷さんに質問があります。まず、中原さんへ 質問ですが、御社製品に CENTUM とカテゴリーの異なる STARDOM があるとおっしゃ いましたが、CENTUM から STARDOM に移行する際、CENTUM で構築したソフトは そのまま活用できるのですか。それとも、再構築をしなければならないのですか。同じベ ンダでカテゴリーの異なる製品の設計思想をどの様に考えておられるか、また今後はどの 方向に進もうと考えておられるかをお聞きしたい。 （新） では、一つずつやってみましょう。横河に限らないのですが、各ベンダは、ＤＣ ＳからＰＬＣまで広い商品を用意しておいて、ユーザに選択していただくことを割とおっ しゃっていました。そこに、安田さんはシームレスに移行ができるのかという非常に大事 なポイントを出されたと思います。いかがでしょうか、中原（横河電機）さん。 （中原・横河電機） 私、実は STARDOM の開発責任者を過去にやっておりまして、そ ういう意味では両方分かっているつもりです。ビジネス的にいうと、今、ＤＣＳを使って いただいているお客さんには、営業は STARDOM を持っていかないはずです。それは、 できるかどうかという以前に、 やはり我々も商売をしているので、お客様に対する継続性、 何を言っていったらいいかという観点があります。当然、同一シリーズの製品を継続して 使っていただくことが、いちばんコストミニマムで済むという考え方に基づいています。 ただ、今、ご指摘があったように、そうはいっても同じ会社の製品のエンジニアリング 環境が違うのはなぜという観点は、非常に耳が痛いご指摘なのです。部分的には、グラフ 40 ィックとかそういうＨＭＩ系に関しては、できるだけソースファイルレベルの統合を図っ た形で、流用性がある形で実現しています。ただ、やはり制御の構築に関しては、当然 CENTUM には CENTUM の文化があるのです。一方、ＰＬＣをベースにしてきた IEC61131-3 という構造化の論理言語も、今もう言われて久しいのに、なかなか根づかな い部分もありますが、海外では確実に定着しつつある。そういうところに移行しようとす ると、ある部分、割り切らなければいけない部分があって、すんなりと互換性を持つとい うよりも、何らかの変換ツールを用いながら移行して、よりよいエンジニアリング環境に 持っていくという立場も必要ではないか。そういう割り切りを、STARDOM のときにはし ました。 そういう意味で、そのままの互換性はないですけれども、ビジネス的に必要があるとい う判断があれば、当然、変換ツールなどを用意した形で、対応する形になると考えていま す。 （新） よろしいでしょうか。はい、どうぞ。 （安田） 次に富士電機の笹谷さんにお伺い致します。当社の工場で数年前にＵＰＯＳか らＦＯＣＵＳにリプレース致しました。今回のお話は MICREX−ＮＸということで、ＦＯ ＣＵＳとカテゴリーは同じと考えますが、開発思想や機能が随分違うように思います。私 どもも新しい機能を取り入れたい気持ちはあるのですが、一方で自社開発したソフトを抱 えております。そこで、MICREX−ＮＸに移行する際、どの様な配慮をされているのか、 開発したＦＯＣＵＳのソフト資産がどこまで生かされるのかお聞きしたい。 （新） では、笹谷さん、お願いします。 （笹谷） ＦＯＣＵＳのシステム、下は、コントローラは何ですか。ＳＸですか。まず、 ソフトウェアのコンパチという話なのですが、現実的に私どもは MICREX−ＳＸ（ＰＬＣ） 、 それから従来機種でいけばＭＩＣＲＥＸ−ＡＸ（ＤＣＳ） のＡＣＳという機種のシステム、 エンジニアリング・ツールにおいて、ケース的なイメージで記述式のＨＥＡＲＴという機 能を一応提供しています。それぞれのソフトは、ＳＸはＤ300win というツールですし、 ＡＣＳはＦＰＲＯＣＥＳというツールです。それそのものは互換性はありませんので、や 41 はりその上でツール的な要素で、例えば汎用のマイクロソフトのソフト、エクセルやビジ オといったものを使って、それが、例えばＳＸとかＡＣＳに対してそのまま同じに使える ＨＥＡＲＴというシステムを提供しています。 今回のＮＸという形に、現時点ではＨＥＡＲＴは対応はできないのですが、将来的には 記述式という形を統一的に考えて、資産をそのまま使えるという開発思想は持っています。 （安田） 私はシステムを選定する以前にベンダ思想を考慮します。例えば、過去から現 在までの製品に対するハード･ソフトの機能を含めた継続性やその後の部品調達・保守の考 え方等です。長期間製品の返遷を眺める事でベンダの製品に対する考え方が窺えます。 では、何故この様なことを考える必要があるかと言うと、製造設備はシステムの 2 倍以上 の寿命がありますから、システムだけのリプレースは必ず来ます。その際、ハードは更新 してもソフトはそのまま継承して早期安定化やコスト低減を図りたいのです。一方でハー ドは革新的な進歩を遂げていますから、その時代の最適製品を選択したいと考えています。 是非、継続性も含めて各社が統一化・標準化を推進して頂きたい。 （新） その思想とおっしゃっているのは、具体的にはＤＣＳとＰＬＣで、同じ開発エン ジニアリング・ツールが使えるとかそういう思想ですね。場合によっては、ベンダを変え ても同じ・・・。 （安田） できればそうしたい。 （新） リプレースができるということですね。そういう対応をされているベンダがいら っしゃったら、どうぞご発言をお願いしたいのですが。今みたいな思想でやられていると ころ。どうぞ。 （大庭） 東芝の大庭です。ほかのベンダとは違う自社での取り組みの話なのですが、リ プレースのときに、お客さんのアプリケーションを変えないという思想に、当社は立って います。テキストでいうと 6-47 ページになります。この話は１年前にエミュレーションと いうことで、杉浦さんといろいろお話しした件です。 要は、東芝としてはコントローラを新しくして、アプリケーションソフトはそのまま、 42 オブジェクトがそのまま動く、それをエミュレーションで動かすという形を実現していま す。これでアプリケーションは全然変わりませんので、その辺の変換、コンバージョンな どをやりますと、100％コンバージョンできないと、試験がまたかかる、手が入るという こともあります。ですから、既設のソフトがそのまま動く環境を、ハードウェアおよびフ ァームウェアで実現したという形で、今、製品化が終わっています。 これは１機種前のＰＣＳというシリーズを新しく、ハードウェアとしては統合コントロ ーラＶシリーズのハードウェアの上に実現しています。ですから、ハードウェアは新しく なって、既設のソフトウェアはそのまま動く。この次のバージョンでもう一つ前、TOSDIC というコントローラがあるのですが、それも同じようにエミュレーションで動くというも のを開発しています。 （新） ありがとうございます。多比良さんのところも先ほどユーザから、コンバージョ ンのソフトで、ＤＣＳの世代交代に対応されているということで評価していただきました が、ＰＬＣとＤＣＳの間はどうなのでしょうか。 （多比良） 日立の多比良です。ＤＣＳについては旧機種から新しい機種へのコンバージ ョンを用意していますが、ＤＣＳからＰＬＣとなりますと、オブジェクトレベルに近い、 例えばラダーからＤＣＳ、あるいはその逆といったものは用意しておりません。 私どもの考え方としては、もう１段階上位レベルでの互換性が取れたらなと考えていま す。例えばＩＥＣ61131 という標準的な言語がありますが、その中にはラダー、アセンブ ラレベルもありますが、その１段上のＳＦＣという規格があります。それですと、ある程 度大まかな、マクロ的な記述ができて、ＰＬＣとＤＣＳでやり取りができるといったこと もあります。また、ループ制御においては、例えば指示調節系の何とかタイプ、非線形何 とかタイプといったように、区分けができると思います。そういった表レベルから各々の ＰＬＣ、ＰＬＣだけではなくて、他社ベンダにも展開できるといった方法が、望ましいな と。完全ではないですが、そういった方法が第１段階かなと現在考えています。 （新） ありがとうございます。それでは、どうぞ。 （新井） ＰＬＣとの統合ですが、まずコントローラのアプリケーションに関しては、当 43 社では 1981 年にＴＤＣＳ系で出したプロセスマネジャーと呼んでいるコントローラがあ ります。そのコントローラの資産を、現在までハーモナス、デオまで、アッパーコンパチ で機能拡張していますが、そのまま使えるような格好で開発をしてきています。先ほど、 ＰＬＣに関しては、ＰＬＣリンカーというコントローラというか、ゲートウェイを構成図 で示させていただきました。それに関しては、 ＰＬＣをＩ／Ｏとそのまま定義するだけで、 我々はコントロールウェアと呼んでいるのです。同じコントロールウェアが、ゲートウェ イ上で動くことによって、全く同じような制御、ＤＣＳのエンジニアリング環境で、Ｉ／ ＯとしてＰＬＣが使えるような環境は用意しています。ぜひ、ご評価いただければと思い ます。 （新） ありがとうございます。 それでは、最後の話題に移りたいと思います。プラントシステムのセキュリティという ことで、日立那珂エレクトロニクスさん、お願いいたします。 （多比良） 日立那珂エレクトロニクスの多比良です。プラントシステムのセキュリティ について回答させていただきます。これが回答内容ですが、今回これを下の三つのカテゴ リー、システム運用セキュリティ、ネットワーク、ウイルス対策の三つに分けてご説明し ます。 初めに、プラントに対するセキュリティの全体像ですが、いちばん近くにあります操作 室内のシステム運用セキュリティがあります。ユーザ認証、操作権限管理、それから何を 操作したかが記録されるオーディオトレイル等、操作室内でのシステム運用セキュリティ があります。それから、この操作室から離れて、他システムとつながったり、あるいは情 報系のシステムとつながるときは、それを切るためのネットワークのファイアウォール、 アイソレートするための装置が必要になることがあります。 また、ネットワークの世界では各サイト間を使えるように、セキュリティが比較的高い 方式が現在次々とできてきまして、その一つにＩＰ−ＶＰＮとかインターネットＶＰＮと いった方式があります。これは後ほど説明させてもらいます。あとは、システムそのもの のセキュリティの中にウイルスという問題があり、これをどうやっていくかといった問題 も含んでいます。 まず、システム運用のセキュリティですが、当社ではＥＸシリーズという、ＤＣＳの中 44 で医薬品におけるＦＤＡ、パート 11 対応に適用できるだけのセキュリティ機能、これを オプションで用意しています。操作者のＩＤパスワード、どんな権限を持たせるかという レベル分け、それぞれ細かく計器とかグラフィックとか画面、どういった操作ができるか という細かい設定ができるようになっています。また、操作をしたことが記録されること が、プラントのセキュリティにとっては非常に重要ですので、そういった記録を取ること もできるようになっています。必要に応じて、このようなセキュリティの管理用サーバ、 記録の管理用サーバというものもつけて、対応できるようになっています。 次にネットワークですが、ネットワークについては、プラントで運転される機器と、そ れから一般のパソコン、ＩＴで使われるものとは使い方が異なることを、皆さんは十分ご 存じでしょうけれども、肝に銘じる必要があると考えています。ですから、操作室からつ ながる箇所は限定して、限定したところからファイアウォールを介して情報系につなぐ、 あるいは、他のサイト、他のシステムにつなぐことを、徹底することが大事なことではな いかと考えています。ファイアウォールにもいろいろな方式があります。安いものではス イッチングハブ、ルータ、さらには、独立したさらに高機能なファイアウォールといった ものもあり、現在、それが選べるようになっています。 それから、遠隔でプラントの状態を監視したいというユーザの要求が増えてきました。 最近ではインターネットＶＰＮ、あるいはＩＰ−ＶＰＮといった、セキュリティの高い通 信方式をご提案しています。インターネットＶＰＮの場合ですと、中身は全くインターネ ットになっており、この出入りをこのＶＰＮルータという暗号化機能を備えたルータによ ってつなぐという恰好になります。ＩＰ−ＶＰＮについては事業者、回線側が責任を持っ て渡すといった違いになっており、価格的にはインターネットＶＰＮのほうが安いけれど も、セキュリティはどうかというところがあります。 私どもとしては、こういったセキュリティの高いシステムであっても、絶対に大丈夫だ ということはなかなか言えないということです。その辺は、ユーザがセキュリティポリシ ーを持って、対応していただくことが必要になるのではないかと思います。例えば、監視 だけに限定するとか、もし操作をやるならば、そのときのリスクはどうなるかといったポ リシー、あるいは対策チームを編成したうえでやることが考えられるかと思います。 ３番めのウイルス対策ですが、私どものシステムはリアルタイムで 24 時間運転という システムですので、一つ大きな問題点があります。世の中にウイルス対策ソフトはいろい ろあるのですが、それらのウイルス対策ソフトを常駐しておきますと、例えば夜中に勝手 45 に動きだすことがあります。そのときに、ただ動いていればいいのですが、ＣＰＵパワー、 メモリ等を消費してしまって、最悪の場合、機械が止まってしまうとか、あるプログラム を止めてしまうといったことにも陥りかねません。 現在は、こういったウイルスソフトは、オペレーターズコンソールの中には入れないと いうことで運用していますが、ユーザとしては、それについてかなり不安をお持ちのかた もあるかと思います。一つご提案なのですが、こういったリアルタイムを要求される機器 とは別に、ウイルスチェック用の管理用パソコンを置く。これはファイルの共有方式とい うのですが、そこからファイルを検査するといった方式が考えられます。これは定期メン テナンス等では、私どももやっているのですが、実際、ご心配なユーザは、１台こういっ たものを接続することも一つかなと考えています。 それからもう一つ、マイクロソフト社の Windows のセキュリティパッチという問題が あります。これが実は非常に厄介な問題です。まず、私どもとしては、マイクロソフト社 から提供される情報によって、それがどれだけの障害があるものかをまず判断します。そ して、必要に応じてパッチを当てて、それから検証という作業が必ず必要になります。た だ単にパッチを当てるだけでは、リアルタイムのシステムなので、どういった影響がある か分からないということで、数週間ないし１か月をかけて検証するということになります。 必ずしもセキュリティパッチが提供されたからといって、すぐその検証ができるという状 況にはないのですが、ある程度の周期でそういったことをやりながら、新しい revision 修 正版なりに反映させるという運用をやっています。 重大なそういったパッチが必要になった場合、我々としては、その内容をユーザに公開 するという方法を考えたい。全部が全部ではありませんが、そういうことが必要になると 考えています。 （新） ありがとうございます。 続きまして、ロックウェルオートメーションジャパン、澤近さん、お願いします。 （澤近） ロックウェルオートメーションジャパンの澤近です。どちらかというと、私の ほうからは、私どもロックウェルオートメーションの商品に実装されているミクロ的な、 どういう技術的な要素でもってセキュリティを確保しているかという紹介を簡単にさせて いただきたいと思います。 46 大きくセキュリティの確保の方法として、四つの要素を想定しています。 一つがコントローラでのレベルのセキュリティ。 それから、コントローラに接続するプログラミングツールに対して、セキュリティをか ける。 メンテナンスサーバとか、セキュリティ対応のサーバを１台置いて、人がプログラムの 改ざん等がないような監視を常に行うようなシステムを作る。 それから、これは汎用の技術を応用するものなのですが、先ほど日立のほうからもご紹 介がありましたが、ネットワークセキュリティの部分の技術。 この四つの要素に関してセキュリティの製品を提供させていただいています。 英語のままで申し訳ないのですが、まず、コントローラのセキュリティ対応としては、 三つのレベルがあります。 左端に書いたのですが、これが先ほどご紹介させていただいたコントローラのレベルの セキュリティ。それから、ソフトウェアによるセキュリティのレベル。それと認証サーバ によるセキュリティ。 こういうシステムですと、例えばここに私どものコントローラ、コントロールロジック スという商品があります。基本的にはＰＬＣの制御もＤＣＳの制御も、これ１台でやって しまおうというコントローラです。この中に、要はパスワードを設定しましょうと。それ で、こういったプログラミングツール、パソコンからこちらにアクセスする。もしくはこ こについているボードにそのままノートパソコンを持っていって接続する。そのときに、 この中のプログラムを見ようとすると、パスワードに対する要求が行われます。これはハ ードウェアの中に、不揮発性のメモリによって記憶されており、必ずパスワードを入れな いとプログラムの中身を見ることすらできないものになっています。ですから、完全にコ ントローラがブラックボックス化されることになります。それによって、一つはプログラ ムの改ざんを防ぐという目的がありますが、もう一つは、特に高度制御を使用されるよう なお客様の知的所有権を守っていく。そういった目的もあります。 それから、ツール側で、コントローラレベルのセキュリティは、コントローラ全体につ けられるものです。ですから、パスワードがないと何もできないです。何も中身を見るこ とができないという状況なのですが、先ほど２番めの項目で説明しましたプログラミング ツールによるセキュリティを簡単に紹介します。 今度はツールのほう、Windows で動作するソフトウェアになるのですが、この中で動作 47 しているプログラムごとに、パスワードを設けることができます。それから、ここの中で、 Windows のファイルになるのですが、キーと呼ばれるファイルを生成して、そのキーをフ ロッピーディスクで管理するなり、ＵＳＢのメモリで管理する。またはそういったものの サーバで管理するという方法によって、プログラムごとのセキュリティ管理をすることか できるという方法があります。これによって、特定のプログラムに関しては、その責任者 が管理を行うことによって、この中に入っているマルチプログラムのシステムの中で、あ る人はここからそれにアクセスする。ここの中にはそのキーがある。ここの中には別のキ ーがあって、そのキーを使えばその人はここにアクセスできるという権限を、各個人に与 えて、その個人の責任の範囲内で、プログラムの変更や管理ができるようなセキュリティ システムを構築することができます。 もう一つはメンテナンスサーバを使用したセキュリティの確立です。それは、こちらに ＲＳ-Ｍac というシステムがあります。そのサーバ、この図ですと１台ここにコントロー ラが並んでいるだけですが、プラント全体を想定して、すべてのコントローラの最新のプ ログラムの情報がこの中に入っています。何らかの改ざんが行われれば、必ずそれを記録 するという履歴の管理も、このサーバの中で行うような形になっています。これは、私ど もロックウェルオートメーションのコントローラだけではなく、シーメンスとか、ご要望 に応じて必要なコントローラのための設定をこちらで行うこともできます。それによって、 だれがどういうふうにプログラムを変更したかという履歴を、全部ここで管理することが できます。それから、それが不当な変更であった場合、このシステムが自動的に正しいプ ログラムをダウンロードして稼働させるといった、自動的にプログラムの更新を行うなど の機能も、このサーバに設定を行うことによって可能になります。 以上が、私どもの商品によるセキュリティ、どういう要素でもってセキュリティを確保 しているかという簡単なご紹介です。 あともう一つはネットワークセキュリティです。最近一緒シスコシステムズに仕事をす ることが多くて、ほとんどシスコの営業マン状態になっています。それだけこういったオ ープンな技術が、我々オートメーションの業界にも下りてきているということです。あの 方々と、いろいろ話をしていると勉強になるというか、目からうろこがはがれるような話 ばかり聞けて、なかなか楽しいです。 余談はさておき、大体ウイルスによる攻撃とか、それからサイバーテロの攻撃は、ほと んど 100％ネットワークから行われるということになっています。それで情報の漏洩、ラ 48 イン・ネットワークの厳密なコントロールが必要である。悪意、不意のネットワークアタ ックの防止とか、それから各種ネットワークセキュリティの機能を、中央制御、監視制御 する仕組みが、大体シスコをはじめとする、こういったネットワークの機器のサプライヤ ーのほうから提供されている。私どもの基本的な考えとしては、こういう汎用のイーサネ ットの機器のサプライヤーの技術をフルに利用して、イーサネットによる制御システムを 確立していこうということを考えています。 重要なのは、ここで変なネットワークの考え方を入れないということです。何が変で、 何が変ではないかというと、基本的にはＴＣＰ／ＩＰをサポートしているかどうかという ところが重要です。よくマックアドレスの上に直接制御のための高速性を確保するために プロトコルを書いたり、いろいろそういった対応をされているベンダがいらっしゃるので す。基本的に私どもの思想としては、リアルタイムの制御も全部ＴＣＰ／ＩＰの上でやる ことが非常に重要であると。なぜかというと、セキュリティの確保とか、リアルタイムの 性能確保などを、こういった汎用の機器によって確立することができる。逆に、この人た ちが次の世代の技術へ移行する際にも、ＴＣＰ／ＩＰをサポートしていれば、それへの移 行が保証されるところもあり、その辺が重要なのかなと。その辺が私どもの考えの背景で す。具体的には、こういった 802.1Ｘとか、そういった認証サーバによるアクセスの制限 とか、そういったことが汎用のレベルで行われています。 聞いた話では、ネットワークに対する不正アクセス、ファイアウォールがこの辺にあり ますが、その７割ぐらいが、こういった構内のイーサネットのタップからアクセスするそ うです。例えば、来客用の会議室から入るとか、いろいろなパターンがあります。それを いかに制限していくか、敵は内側にありという形で、それを汎用の技術でやっていこうと いうのがコンセプトです。 各々紹介していきますと、時間が５分では足りなくなってくるところもありますので、 また最寄りのシスコの営業のかたでも呼んでいただいて、話をお聞きいただければいいか と考えています。私の説明は以上です。 （新） ありがとうございました。では、高野さん、お願いします。 （高野） プラントシステムのセキュリティについては、最初のユーザ要求のときにも若 干申し上げました。プラントシステムもインターネットと接続するなり、いろいろな媒体 49 を通してコミュニケーションをするという機会が、とても多くなってきております。セキ ュリティを避けては通れない状態になっていることは確かだと思います。ユーザとして、 難しいことをどこまでやるかということは、よく考えなければいけない問題だろうと思っ ています。 何点かお聞きしたいことがあるのですが、今の澤近さんのプレゼンにもありましたが、 例えば 802.1Ｘとかを実装するのは、非常に大変です。プラントシステム側のコンピュー タもそうですし、ＯＡ系のいろいろなものもサーバを立てないと成り立たないわけで、す ぐできる話ではありません。また、いろいろな運用とかセキュリティポリシーを厳格にや るのは、非常に大変でありすぐできない。さらに、それをコストをかけてやってどこまで うれしいのだろうと、これは皆さん必ず直面する問題だと思うのです。 私は、セキュリティは大きく二つ考えられると思います。今の話は、プロのクラッカー への対策だろうと思います。これはやらなくていいという話ではないのですが、実際問題 として、プラントシステムで今すぐスタートする話ではないと考えています。 （まずは世に まんえんする既知のセキュリティ脅威から確実に、かつ手間をかけずに守ることが、今、 非常に重要になっていると思います。） 例えば、マイクロソフトさんは、毎月必ずセキュリティの脅威を発表されています。 （そ れらに対する対策をユーザが怠るとインターネットから感染・クラックの被害を受ける可 能性が高くなります。 ） あと、皆さんも経験されたと思うのですけれども、以前のブラス ターみたいなものだと、自分も知らない間に加害者になってしまいます。まずは、こっち を防がなければいけないだろうと思うのです。 （しかし、 毎月プラントシステムにセキュリティ対策を打つことは非常に困難ですから、 ） まずは、第１ステップとしてユーザの立場では年１回考えれば済むようにしたい。私がい つもほかのところで申し上げているのは、最終的にプラントシステムにとっては、５年に １回考えれば済むようにしたいと。そういうアプローチをぜひ考えていただきたい。これ はいろいろな方々が、いろいろなアイディアを出されていますが、例えば年１回にすると いうアプローチは、そんなに難しい話ではないと思うのです。 Windows のデフォルトインストールのまま、ＨＭＩとして使われるというケースが非常 に多い。これを直すだけでもかなり違うということです。あとは、ベンダのコンフィギュ レーションにとっては、非常にうれしいツールで、例えばファイル共有などは、セキュリ ティリスク低減のためにインストールしないなどの工夫が必要です。 50 例えば、そういうものを徹底的に外すだけで（去年あったブラスターなどもＤＣＯＭサ ービスなどを事前に外していたら）、その時に何もやる必要はなかったわけです。そういう ことだけでも全然違う。トヨタのプラントシステムは今、こういうふうにやってあるので すが、 この半年間いろいろなセキュリティ脅威を見ていて、プラントシステムにとっては、 これはやらなくていいですねという確認で済んでいます。これは非常に大事なことです。 これは皆さんのところも同じだと思いますが、プラントシステムのソフトウェアをバージ ョンアップすることは非常に大変な話ですし、止められないですから、すぐにはできない ということもあります。 それともう一つ、これはぜひベンダさんにお願いしたい話なのですが、ちょっとパッチ を当てるとかバージョンアップするのに、ものすごい動作保証の期間とコストがかかる。 ユーザは高いリスクにさらされたままになり、改善すべき点だと感じています。この辺の 時間とコストをどう下げるか。これはベンダさんに、体制の問題もあると思いますが、ぜ ひ考えていただきたいところです。 最初に申し上げましたが、我々がまず必要としているのは、 （プロのクラッカー対策では なく、 ）一般的なセキュリティ脅威への事前対策と常時ウォッチし問題ないか確認する仕組 みです。さらに、バージョンアップ保証対応など、例えばユーザのサイトのいろいろなシ ステムの状況がこうなっているから、今回のセキュリティ脅威に対しては、Ａ社さんはや らなくていいよと。そういったサービスをしてもらえると、これは非常にありがたいと思 います。この辺の見解を、ぜひお聞かせ願いたいと思います。 （新） 高野さん、どの方にお聞きすればいいですか、具体的に。 （高野） 横河さん、その辺の体制を築かれていると何回かお聞きしていますので、ぜひ ご披露いただければと思います。 （新） 中原（横河電機）さん、いかがでしょうか。 （中原） 今、もう高野さんに非常に分かりやすい形で整理していただけたので、何も付 け加えることはありません。先ほど、Java の話をちらっとしましたが、特に動作保証の話 は、やはりソフトの作りと非常に密接に絡んでいて、ベタで作っているという話とミドル 51 ウェアという話が先ほどありました。やはり、そこら辺のところを突破口にしていかない と、いつまでたっても Windows の呪縛から逃げられないなという感覚は非常に強く持っ ています。そこに対しての取り組みは、非常にコストはかかるのですが、やっていかなけ ればいけないかなと思っています。 それから、Windows を選択したということは、ある意味、ベンダ側から見ると、そこを 選択せざるをえなかったという部分も、正直いうとあります。当然その結果、ユーザから 見ると、少なくとも初期導入コストが、ＤＣＳという過去のものに比べると圧倒的に下が っていることは、否定できない事実としてあると思うのです。それはやはり逆に言うと、 システムの運用責任をどなたが持つかということも、クローズアップされてくるべき問題 だと考えています。 何を言いたいかといいますと、当然ベンダとしては健全な稼働をお客様に保証するとい う意味において、様々なセキュリティに関する施策をとっていかなければいけないのは、 使命ではあるのです。しかし、運用責任を持たれるお客様自身も、ベンダと手を取り合っ てというと語弊があるかもしれませんが、ぜひ知恵を出し合って、うまい解決策をとって いかないと、やはり我々だけでは解決できない問題が出てきます。 特にシステムの問題は、ベンダが納めるシステムで、非常にクローズしたものには、も うとどまらなくなってきていますので、その中で全体としてセキュリティを確保するとい うスタンスに立たないと、なかなか局所的に幾ら頑張っても、解決できないという部分が あります。その辺はもう少し、ベンダ側とユーザ側が、今、別に敵対しているわけではな いですが、歩み寄った形で、いろいろな協力関係を取らせていただきたいなと。これはあ る意味ご提案なのですが、そういう感触を持っています。 （新） ありがとうございます。ほかのベンダの方で、先ほど言いましたが、Windows のデフォルトで出荷していなくて、セキュリティ対策をされていらっしゃるところがあり ましたら、何か一言お願いしたいのですが。具体的には多分ＩＰのポートを、例えばアク ティベックスは使わないとか、どこそこは開けていないとか、そういう対策をされている ところはありませんか。 （新井） 山武の新井です。今、横河さんがほとんど言われたのですが、まず、昨年のＭ Ｓブラスターで、かなりベンダ、ユーザとも痛い目に遭って、現在、うちのほうはすべて 52 閉じた格好で、工場を出荷しています。ただし、ＯＰＣのゲートウェイを入れれば、com のポートが開いてしまいます。ＯＰＣを使いたいというと、そこが開くというところがあ ります。そこはどうしても、ユーザにご理解いただかないと。com を使っていると、その ポートが開くことをご理解いただく。その危険度の理解もまだまだで、メーカーサイドか らの、どういう危険度があるのかという告知という意味でも、まだ足りないのかなと最近 思っています。 この辺は、日本人は特にそうだと思うのですが、 「水と安全はただ」だということで、セ キュリティは今までは「ただ」だったのですが、とにかくインターネットでつながってし まっていますので、危険は毎日あります。弊社のほうとしても、毎月のいつものようなマ イクロソフトのアナウンスが出た途端に、ガサガサと、どういう問題があるのかをチェッ クしはじめるわけです。そうすると、大体、今１か月後にウイルスが発生するというのが パターンですので、発表から１か月間がけっこう勝負になります。その間で、うちのシス テムの危険性をアセスしないといけないということは、現在取り組んでいます。 逆にいうと、ＤＣＳベンダとしては、そういうコストは、５年前、10 年前にはなかった コストです。各社、ＤＣＳベンダは、それをやっているのではないかと思いますので、そ の辺は、逆にそういうサービスに対しては、ある程度コストがかかっているのだというこ とも、ご理解いただきたいと思います。 （新） 高野さん、いかがですか。 （高野） 今の件にコメントさせていただきたいのですが、コストがかかるのは、私も確 かにやむをえないと思います。コストが例えば指標で 100 かかるとすれば、先ほど私が最 初に申し上げましたが、Windows のいろいろなサービス、デフォルトについているサービ スなどを取ってしまうだけで、かなり防げることがあるのです。それは多分１で済むと思 います。もしかしたら、初期にしっかりそうやってインストールして持ってきてもらえれ ば、ただとは言いませんが、初期インストール、プラスアルファの費用で、できるのでは ないか。ぜひそんなことを考えていただきたい。 あと、ご回答いただけなかったのですが、そういった情報サービス、例えば「Ａ社のこ のシステムはこういう設定になっているから、 今回のセキュリティは大丈夫ですよ」 とか、 そういうサービス。そんなに高くならないと思うのです。そんなことを考えていただける 53 と、コストがかかるといっても、最小限のところで抑えられて、防げるのではないかなと 思います。ぜひそんなサービスを立ち上げていただきたいと思います。 （新） というわけで、お金は払うそうですから、これは新しいビジネスの種ですので、 各ベンダ、お考えいただきたいと思います。 一応全項目、全体をなめさせていただきました。時間の都合であまり議論をできなかっ た項目もあります。そういったことも考えて、私のほうでまとめさせていただきましたが、 ライオンの安田様をはじめ、 「思想」という言葉がたくさん出てきました。また、セキュリ ティに関して「ポリシー」という言葉が出てきたのですが、やはりユーザもベンダも両方 ポリシーを持たなければいけない。そのポリシーの選択で、ここに出てきましたコスト・ 性能のバランスとか、長期運用のためのシステムデザイン、ＭＳWindows への対応、リプ レース・コスト、それからセキュリティの問題が、かなりはっきりするのではないかと思 います。 最初に議論されたことは、停止していくシステムか、そうでないシステムか。事前アン ケートの結果でご紹介しましたが、事前アンケートにお答えいただいたかたの３分の２ぐ らいは、停止は困るということです。停止してはいけないとなると、選択肢が制限される ことになるかと思います。それから、たとえ停止してはいけないというシステムであって も、ご承知のとおり、停止することがあります。だから、やはり停止したときの対策がち ゃんとできているかどうか。この思想、ポリシーは非常に大事だと思います。停止しない システムだということに甘んじていると非常に危険だという気がします。 これはセキュリティも同じで、ゲートウェイがあるから、外部から侵入できないという ことに甘んじていますと、内部につながれたシステム、メンテナンス用のシステムで、ブ ラスターがまんえんしてしまうという、最初の高野さんのご指摘のような形になります。 殻を作れば安全だというわけではないことは、肝に銘じるべきだと思います。停止しない システムでも、停止したときの対策がなければいけないと思います。また、逆にその対策 があるという前提ですと、またもう１回停止してもいいのではないかという考察に、戻れ るのではないかと思っています。 次に、ユーザのポリシーとして、システムはだれに任せるのか。設計から、作るところ までを、ライオンの安田さんや三菱化学の米田さんからご紹介いただいたように、自分の ところでエンジニアリングとして持っていたいのか。それともベンダに全部作ってもらう 54 のか。またはインテグレータに任せるのか。それで、やはりＤＣＳかＰＬＣかということ が、変わってくるのではないかと思います。 これは、笹谷さんからご紹介いただいたように、ハードからソフトまでまとめて作るも のがＤＣＳで、ユーザにシステムを作ってもらうものがＰＬＣだというご定義をされてい らっしゃいました。そういった点からも、だれが作るのか。特に、先ほど水谷さんを代表 に、石油関係では自分のところで作る気はない、ベンダに作ってもらいたいというご意見 だったし、安田さんや三菱化学さんの場合は、自分のところのエンジニアリングとして持 っていきたいと。それでまたポリシーが変わってくるのではないかと思います。 それから、WindowsＨＭＩへの対応、そしてリプレースへの対応と考えていったときに、 新陳代謝できるシステムかどうかということが、非常に大きなキーワードだと思います。 ユーザとしては、不具合な部分だけを取り替えていきたいという、部分更新を望んでいら っしゃることは明白です。ベンダが部分更新に対応できるかが大事だと思います。事例に ついては、例えば古いＩ／Ｏを維持したまま部分更新されるだとか、それから東芝からご 紹介があったように、エミュレータを入れて更新をされるとか、そういう事例はあるわけ です。そうなりますと、各ベンダがちゃんと部分更新に対する思想、ポリシーをお持ちか ということが、安田さんの問いかけだったと思います。 具体的にどういうことかというと、まずハードやソフトがモジュール化されているか。 全部を作り込んでいるのではなくて、部分更新に耐えられるような作り方をしていらっし ゃるのかということが、一つ問われると思います。それから、モジュール化されたときに、 その接続条件、プログラムですとアプリケーションプログラム・インタフェースになりま すし、ハードウェアですと接続のコレクターの規格だと思います。こういったものが専有 されているのか、またはあるグループで共有されているのか、またはオープンにされてい るのか。これで随分状況が違ってくると思います。もし、その接続関係がオープンにされ ている場合は、よそのベンダが部分更新をすることができるようになると思います。また 特に、三菱のＰＬＣの場合、協力関係の会社が多数いらっしゃいます。そこの間で情報共 有していることは、三菱さんのＰＬＣを使って、いろいろなベンダが競争をしながら、そ のシステムをインテグレートできるということです。そういう接続関係がオープンになっ ているかどうかは、非常に重要だと思います。 それから、プラットフォームは非常に大事だと。ＯＳの更新に対してどうかということ と、マイクロソフトの支配に入りたくないというお話がありました。来年はマイクロソフ 55 トもお呼びして、議論をさらに深めていきたいと思います。 非常に大事なことは、ソフトウェアの設計思想が、プラットフォーム・インディペンデ ントに作られているかどうかということです。それはＯＳやネットワークに依存しない形 のソフトウェアの作り方をされているかどうか。これはベンダの思想、ポリシーに非常に 依存してくると思います。できれば、ユーザとしては、ＣＰＵなどにも依存しないものに してくれると、時代の変化についていけるシステムということになると思います。基本的 にユーザがお使いのＰＡやＦＡのシステムの計測制御というところは、時代が変わっても 基本的に変わらない。データを集めてきて処理して、ＰＩＤコントローラ何なりで動かす だけの話です。そこをＯＳの変化やネットワークの変化で、作り直さなければいけない、 そこに金を払うのは嫌だというのが基本的な方針ではないかと思います。 セキュリティについては、オープンということを前提にしたセキュリティを考えなけれ ばいけない。今まではクローズドで、どこも接続しない、だから安全だ、またはセキュリ ティ対策をしなくてもいいという考え方だったのですが、それでは不十分であると。 「いろ いろなものにつながれている悪いやつもいる、だけどうちのシステムは大丈夫だ」という 作り方をしてほしいということが、非常に大きかったと思います。 それから予備品ですが、この辺は私の目から見ますと、ユーザもかなりわがままなとこ ろがあるという気がします。予備品をどこが持つかということで、ここまでの話はベンダ が持つということを、前提に話をしているわけです。しかし、ベンダがそれを持っていれ ばコストがかかるわけで、そんなに必要なものだったら、ユーザが自分で持っていろと言 いたいところもあるのではないかと思います。この予備品をユーザが持つか、ベンダが持 つか、またはサードパーティーが持つかということは非常に重要です。例えばサードパー ティーが持つことを考えると、それは新しいマーケットができて、ビジネスが起きること になります。今でも８インチ単密度が欲しいやつがいたら、高いけれど売ってやるよとい うような商売が、もしかしたら成り立つかもしれません。各ベンダごとに予備品が持てな い場合、その全体を考えた商売もありえるのではないかと思います。その意味で、ユーザ 対ベンダ、またはＤＣＳ対ＰＬＣの対立というよりは、その矛盾が、次に向けての新しい ビジネスになるという考え方のほうが正しいような気がします。 ユーザがお望みのもう一つは、ＯＳやネットワークに依存しないだけではなく、ベンダ フリーという言葉が出てきましたが、いつでもベンダを変えたいという意識があります。 実は討議表の中でも、今後生き残っていくＤＣＳメーカはどこでしょうかというご質問で 56 す。背景は勝ち馬メーカに乗りたいということです。生き残らないところのＤＣＳメーカ に更新したら、自分が後々困るから、今入れて 20 年生き残るメーカはどこかというご質 問ですが、20 年間生き残るということは、だれも保証できないと思います。 そういったことを考えたときに、あるベンダと心中する気は、多分ユーザは、どこもな いと思います。ユーザとしては、いつでもリプレースができる、できるだけ安くできる、 そういう環境を望んでいらっしゃるというのが事実だと思います。それと同時に、ある程 度シェアを持っていて、シェアを維持したいベンダは、ベンダフリーということは非常に 大きな抵抗感があって、多分おやりにはならないだろうと考えられます。ということは、 本当にユーザが望んでいるベンダフリーを実現するためには、ユーザが団結して、ベンダ フリーのための思想、またはアーキテクチャを作らざるをえない。それをやらない以上、 ベンダに縛られるのはしょうがないかなというのが、ユーザでもベンダでもない立場とし ての意見です。 ただ、全体として情報技術が発達してきて、一つは日立が高く評価されたと思いますが、 ソフトウェア互換性を保つような変換プログラムを、常に用意していくことが一つの方法 です。もう一つは、ラダーについて、それより上位の規格、ＳＦＣみたいなもので表現し ていく、それによって非依存性を高めていくのが、大体の技術のトレンドだと思います。 そういった観点から見ていくと、全体はベンダフリーの方向に加速する方向で情報技術は 手助けしているのではないかと思います。 特に会社でお使いのイントラネットの場合、マイクロソフトやリナックスだとかソラリ スだとか、そういう特定のＯＳに依存しないからイントラネットでやって、みんなウェブ ブラウザでおやりになっていらっしゃる。今の情報技術の発達から見ていくと、こういう フィールド機器のウェブブラウザで、イントラネット的に使うというのが、今言った、ベ ンダフリーへのいちばんの近道という気がします。そういった動向をとらえながら、メー カが変わっても使えるシステムがユーザにとって大事なシステムとなるわけです。そして、 ベンダにとってシェアを拡大していくとき、ユーザの希望は非常に大事なポイントになる のではないかと思います。 以上、ちょっと時間を超えましたが、パネル討論の時間は過ぎましたので、これでまと めさせていただいて、残りはチェアマンの宮川さんにバトンをお戻ししたいと思います。 よろしくお願いします。 57 （宮川） どうもありがとうございました。大変有効な時間を過ごすことができたと思い ます。あと残り 10 分ほどになっています。最後にまとめなのですが、今日コメンテータ として、ベンダ側として、ＪＥＭＩＭＡの田中さん、ジャパンバッチフォーラムのほうか ら杉浦さんに、ユーザ側の立場ということでコメントを頂くことになっています。 最初に田中さんのほうからコメントを頂ければと思います。よろしくお願いします。 （田中） 日本電気計測器工業会の田中です。今日は長い間いろいろな発表、それからパ ネルディスカッション等を聞いておりました。私は電気計測器工業会ということで、完全 にベンダ側ということで、 やはりそういう立場になります。今日のタイトルにあるように、 「本音で語ろうＤＣＳ、ＰＬＣ計装∼ユーザの言い分・ベンダの言い分∼」の今年２回目 ということで、去年より、もっと本音の部分が出てくるかなというところなのですが、ま だ皮をかぶっているなという感じが、正直あります。 それで、ちょっと乱暴な言い方の部分はあるかと思うのですが、三つほど、私のほうか らのコメントとしたいと思います。 まずコストの比較、あるいは信頼性の比較が一つテーマとしてあります。要するに提供 価格、そのコストの低減努力は、ベンダとして永遠の課題である。これは当然のことだと 思います。ただ、そこでこの議論をするときに、では一体何を基準にして討議するのかと いうところを、もう少し絞っていかないといけないという感じをすごく受けます。 今日の発表、それから討議の中にリスクマネジメントという言葉が出てきました。やは り究極のところ、ここで評価し、ＤＣＳ、ＰＬＣ、信頼性だ、あるいは二重化というとこ ろの採否を決めていくしかないのだろうと思います。そうした場合、ユーザサイドとして みれば、必要とする投資と、必要としない投資、そのコントラストをやはり明確にお示し いただくのが重要かと思います。逆にベンダ側で言えば、それに対して非常にコントラス トの効いた選択肢を提供していく。現在のところ、これは力関係の構図の中の結果と私は 思いますが、ややベンダ側はあいまいに表現しているのではないかなという気がします。 二つめは予備品等の話が出てきたことと絡みますが、ファシリティの寿命、要するに設 備あるいはプラント、ファシリティの寿命と、それからそれを支援するためのシステムの 寿命に関してです。これはもうすでに、かなり前の時期からそういう状態に入っていると 思うのですが、この寿命というのは、完全に一致しない時代に入ってきている。皆さん、 頭の中はそれで納得されているかと思うのですが、頭で納得したからといって体で納得す 58 るところまで行っているかというと、まだそこまで行っていないのではないか。 これはベンダのほうから見ると、二つあると思います。一つは自社開発製品、自社提供 製品、要するに自社で踊れるものと、自社で踊れない世界、その組み合わせの中で現在の 製品を提供していっている。そうした場合に、自社で踊れるものをプランし、マネージで きるものに対して、我々はどうやっていくのかをはっきりさせる。それから、もはや自分 たちの及びのつかないものに対しては、どうしていくのか。そういうことを、はっきり分 けてコントラストをつけていく必要があるかなと思います。 この状況は、多分この後どんどん加速されていって、昔の状況に戻ることはありえない と思います。したがって、システム構成機器の短命化、これを前提にした議論を、さらに 突っ込んでやるべきかなと思います。ここにおいてもコストダウンについては、ベンダの 使命としてやはり追求していかないといけない。それから、ディスカッションの中にもち らっと出てきましたが、コスト負担に関しては、やはりユーザの使命というか、ユーザの ご負担という、役割をそのぐらいにはっきり分けて考えることが、もっと現実的な話にな るのではないかという気がします。 最後ですが、これはマイクロソフトの話とＨＭＩのところにも絡んでいく、セキュリテ ィにも絡んでいきますが、技術の進歩、あるいは変化への対応の姿勢は、大きく切り換え ていく必要があると思います。やはり我々が求めていくもの、ユーザに発展していただく ことは、ベンダにとって最大のビジネスチャンスになるわけです。その進歩、変化がもた らしてくれる可能性の拡大、それで生産システムを成長させることが、まずいちばんベー スにあるべきだと思います。先ほどのファシリティの寿命、あるいはシステム寿命とのア ンマッチングのところを合わせて、ここについてはよりしたたかに、たくましく現在の技 術、可能性を使いこなし、その果実を確実に取っていく。しかも早く取っていくというこ とが必要なのではないか。 これについては、先ほどセキュリティのところでも出てきましたけれども、非常に今ま で出くわしたことのない状況の中に、我々はいるわけです。これを打開していくことを、 ユーザ、ベンダ双方の共同作業として実施していく。その姿勢がない限り、そこに到達す ることは無理なのではないかと思っています。 （新） ありがとうございました。続いて、杉浦さん、お願いします。 59 （杉浦） 今、田中さんのほうから、ベンダのお立場でお話がありました。今度、私はジ ャパンバッチフォーラムという、バッチのユーザのグループです。世界ではワールドバッ チフォーラムというグループがあり、その中で、日本ではジャパンバッチフォーラムとい って、バッチを研究するグループがあります。バッチとＭＥＳの部分の研究をするという グループなのです。今の田中さんのお話の後を受けて、マイクロソフトのテクノロジーの 話から入ります。 実は 30 年から 35 年前、計装制御の世界は同じように、ＩＢＭのテクノロジーに支配さ れていたわけです。何も変わっていないではないか。ただ、ＩＢＭの事務用計算機のＯＳ がマイクロソフトに変わっただけではないか。それはなぜかというと、計装制御をやって いるメーカから、革新的なアイディアが出てきて、それに合致するようなソフト構成が出 てこないから、それに対応するＯＳソフトが出てこない。30 年前はまだミニコンという世 界があったので、ＩＢＭと違う、対抗するものを使うということは可能だったわけです。 今は、値段とコストのことを考えると、マイクロソフト以外に選択肢がないという時代に なっています。ですから、使わせていただくという態度に終始する限り、これは全然変わ らないのではないかと思っているわけです。 では、どう変えればいいのか。今、田中さんのお話の中に何度も、ファシリティの寿命 とコントローラの寿命が全然違うというお話があったのです。これに対して、一つはバッ チの世界の中で、ＩＳＡ−Ｓ88 という規格が、実はバッチの規格であります。その中で今、 パート５という規格が、だんだん立ち上がろうとしています。これはどういう考え方をし ているかというと、スキット・コントローラという考え方をしています。これはどういう ものかというと、ハードウェアと一体化したコントローラがある。これがオブジェクトと して動いて、上のコントローラから見たら、そのオブジェクト以外は見えない。そして、 オブジェクトの中の構成自身も、またオブジェクトで考えるという作り方をするという仕 組みです。 ただ、こういう形をすると、例えばポンプを１台追加した。単にポンプを置いたら、そ れが、すべてのコントローラから認識して動けるぐらいの仕組みがあってもいいのではな いか。それで動かしたいときに、その名前を定義すればそれが勝手に動いてくれて、異常 が起これば、簡単に異常だよと言ってくれるぐらいの仕組みがあれば、今やっているよう な面倒くさい仕組みは、本来要らないのではないだろうか。これからユーザとして、なん でこんな面倒くさいことをやらないと、制御システムが動かないのかというのが、一つの 60 感覚になるわけです。それで、オブジェクトの中で動いてくれるコントローラ、それがあ くまでも賢くて、履歴も管理して、今やっている仕組みと同じような情報を自分から発信 できれば、今やっている面倒くさい本当のソフトを作る作業が要るのだろうかと。 例えば、何か動かしたいとき、どこかのハードウェアにプログラムを書かないと動かな い。そうではなくて、どこかに論理的にプログラムが定義されれば、勝手に動いてくれる。 それがどこのハードウェアの中で動いていようが、そんなものは知りませんよと。という のは、製造工場は壊れないで、まともに動いてくれて、非常に安定して動く。それで更新 するときは取り払って、それの代わりを入れれば、まともに動いてくれる。こういう世界 が本当は欲しいのではないかという感想を、前回、今回、２回とも持ちましたが、非常に 強く印象として持っています。 こういう夢のような話ができる仕組みは、何だろうかと。今のＣＰＵのレベルも足りな い、ネットワークも足りない、ハードウェアに関しても、寿命とかそういう意味で全然足 りない。だから何とかそこら辺を解決してできるような仕組みを、できればベンダには考 えてもらいたい。そうすると、ユーザは非常に楽にプラントコントロールができるし、保 守もできる。こういう時代が作っていけるのではないのかなという感想を持ちました。 ちょっとコメンテータとしては変なコメントになりましたが、こういうコメントで私の コメントを終わらせていただきます。 （宮川） どうもありがとうございました。 あと１∼２分だけお時間を頂きたいのですが。 要は、計装制御技術会議として、来年に向けてということになります。 テキストに１ページあるのですが、それは見ていただかなくてかまいません。ユーザ懇 談会を今年度設立したのですが、これは一時的なものではなくて、継続的、恒久的な組織 として作っています。別に、この計装制御技術会議が今回終わったからといって、活動を 停止するわけではありません。 それで、ぜひお願いしたいのは、今日いろいろ聞いていただいて、もっと聞きたいこと があるとか、来年はこういうことに絞ってほしいとか、そういう要望があれば、ホームペ ージで、事前アンケートにいろいろ書いていただいていると思うのですが、事後でもあそ このアンケートは書けるようになっています。そこにぜひ、今年を各参加者に反省してい ただいて、来年につなげる何か一言でも書いていただければ、それを糧にユーザ懇談会も 活動を続けていくことになると思います。それをぜひお願いしたいと思います。去年もや 61 りましたが、今回のパネルディスカッションの内容は、ホームページにまとめてアップロ ードしますので、ぜひ参考にしていただければと思います。 長い間ご清聴ありがとうございました。これで本日は終わらせていただきます。 62 ６３