第 34 回 2003 セッション１ 計装制御技術会議 DCSvsPLC 計装 ∼ユーザ要求についてこられるか DCS,PLC∼ 日時 2003 年 11 月 12 日（水） 場所 東京ビックサイト・会議棟６F パネルディスカッション 目次 司会及びパネラー............................................................... 2 （別紙 A：ユーザー要求仕様書） ................................................. 4 （別紙 B：ユーザー要求仕様書に対するベンダー回答の共通点） .................... 10 論点の抽出.................................................................... 15 ユーザの立場(更新の理由――老朽化、部品供給のストップ) ........................ 19 ユーザの立場（最適なシステム、情報の共有、体制及び組織） ...................... 22 ユーザの立場（減価償却期間と製品サイクルの違い） .............................. 26 ユーザの立場（IO 関係の切り替えのないシステム更新） ........................... 27 ベンダの立場（ベンダはどこも利益を出していない） .............................. 28 ユーザの立場（いざとなっても設備を止められない） .............................. 29 ベンダの回答（PLC を IO として使用、オープン化した場合のサポート体制） ......... 30 ベンダの回答（PLC の信頼性向上） .............................................. 32 ベンダ回答（信頼性とオープン化） .............................................. 33 ユーザの立場（本当に止めていけない設備を理解して制御システムを決める） ........ 34 ベンダ回答（PLC の採用は適材適所で） .......................................... 37 エンジニアリング会社の立場（マルチベンダでの対応） ............................ 37 エンジニアリング会社の立場（コスト、エンジニアリングツール） .................. 39 ベンダの回答（コスト、エンジニアリングツール） ................................ 41 ユーザの立場（自動車飛行機モデル､サポートの方向性､ｴﾝｼﾞﾆｱﾘﾝｸﾞﾂｰﾙ） ............. 42 ベンダの立場（IO としてでなく、適材適所で使える PLC） .......................... 45 新先生の閉め.................................................................. 46 まとめに代えて（ユーザ､ｴﾝｼﾞﾆｱﾘﾝｸﾞ会社及びベンダの制御ｼｽﾃﾑへの要求、試案） ..... 47 パネラーの回答、意見（試案「エンジニアリングツールに関して」） ................. 50 1 司会及びパネラー 司 会： 新 誠一（東京大学大学院 情報理工学系研究科 システム情報学専攻 助教授） ユーザパネラー： 内田 努（キリンビール㈱ 樋本 勉（参天製薬㈱ 生産物流本部 バリデーション室 室長） 安田 茂（ライオン㈱ 生産本部 高野正利（トヨタ自動車㈱ 生産本部 生産技術部エンジニアリング担当 部長代理） 生産技術部 主任部員） プラントエンジニアリング部企画室 グループ長） 服部篤彦（東京ガス㈱ 生産部生産エンジニアリンググループ 基盤技術チーム） 杉浦彰俊（森永乳業㈱ 生産技術部 マネージャ） ベンダパネラー： 白井俊明（横河電機㈱ 制御システム海外事業本部 システム事業部 PCS センター長） 中島千尋（富士電機システムズ㈱e−ソリューション本部 計測新事業統括部統括部長） 大庭 章（㈱東芝 電力・社会システム社 制御・計装機器技術部 主幹） 布野俊彦（㈱日立ハイテクノロジーズ 情報・生産技術統括本部 情報・制御営業本部 事業企画部 専門部長） 岩崎雅人 （㈱山武 アドバンストオートメーションカンパニー マーケティング２部長） 西元朗雄（東芝三菱電機産業システム㈱ 産業システムソリューション技術部 技術第６課 参事） 八尾尚志（三菱電機㈱名古屋製作所 FA システム部 メルセックソリューションセンタ センタ長） 米倉康人（オムロン㈱ インダストリアルオートメーションビジネスカンパニー システム機器統轄事業部 アナログ・プロセスコントロール事業推進部 部長） 澤近房雄 （ロックウェルオートメーションジャパン㈱ プロダクトマーケティング部長） エンジニアリング会社パネラー： 刑部道博（日揮㈱ エンジニアリング本部 制御設計部 第５グループ マネージャ） 2 宮川 彰（東洋エンジニアリング㈱ 国内事業本部 エンジニアリング技術グループ 電気計装設計チーム チームリーダー） 本パネルディスカッションに入る前に、 −「ユーザ要求仕様書」の説明（参照 別紙 A） −「ユーザ要求仕様書に対するベンダ回答の共通点」の説明（参照 別紙 B） −各ベンダからの補足説明 を実施しております。 3 （別紙 A：ユーザー要求仕様書） 4 5 6 7 8 9 （別紙 B：ユーザー要求仕様書に対するベンダー回答の共通点） 10 11 12 13 14 論点の抽出 それでは、論点の抽出に入らせていただきます。プログラムにありますように、私のこ の論点の抽出の後、パネルディスカッションをさせていただいて、最後にチェアマンの宮 川さんにまとめていただくという段取りになっています。 同時に、先ほどの休憩時間に、皆様から討議票を頂きました。最初に、この討議票をご 紹介させていただきたいと思います。後ほど、前にいるパネラーの皆様がた、最低１回は 必ず発言をする機会があるように運営したいと思いますので、そのとき、ちょうど関連の 質問があったら、併せてお答えいただけるとありがたいと思います。すみませんが、時間 が限られていますので、そのように運営させていただきたいと思います。 さて、この計装制御技術会議は、伝統的にプラントオートメーション寄りということも あり、皆さんがたから頂いたアンケート、これは杉浦さんからご報告いただきましたが、 DCS の機能にはあまり問題がない、問題は値段だと。DCS が PLC 計装並みの値段になれば、 だれも PLC など考えないというお答えがあったかと思います。それに対して、DCS 側と言 っていいのかどうか分かりませんが、DCS 側のかたは、トータルコスト・オブ・オーナー シップ、20 年とかライフサイクルで考えたら、場合によっては DCS のほうが安いという形 の反論をされてきたわけです。 それに対して頂いたご意見は、かなり辛辣で、参加者 A さんからは、「DCS のメンテナン ス費用は高い。ライフサイクルコストでも、高いのではないか。オーバーメンテの印象を 受ける」というご意見を頂いています。 逆に「PLC 主体はノーメンテナンスであるという理由は一体何だ。キャリブレーション やシステムの健全性をどのように考えているのか。PLC だってメンテナンスがいるだろう」 というご意見です。 それから、参加者 B さんからは、 「最近の DCS の HMI は PC そのものであり、機能も製品 寿命も差はないのに、価格が一桁違う。PLC と DCS、特に HMI に限っていうと、機能に差が ないのに、値段が一桁違う。DCS は高価格体系を取り続けるのか」。B さんの目から見ると、 高いという印象だと思います。 それから、参加者 C さんからも同じご意見を頂いており、 「15 年間の稼働を前提とした うえで、その期間中のイニシャルコスト、およびメンテナンスコスト、すなわち TCO をユ ーザに具体的費用として提示いただけるか」 。これは DCS、PLC の両方に対して、こういう ご意見が出ています。 15 多分、いらっしゃるかたは、DCS は十分低コストだという DCS 側の意見に対して、納得 していないというご意見だと思います。PLC 側も、イニシャルコストが安いことは理解で きるけれども、では本当に 20 年使うときに安いのかという、非常に悩ましい状況におられ ることが、ご質問から伺えると思います。 それから、参加者 D さんからは、参天製薬の樋本さんのお話の中で、「DCS のソフトにつ いては、メーカ依存で、PLC のソフトはユーザでも可能だというご発表があった。けれど も、自分の立場からすると、最近は DCS もユーザが十分開発可能ではないか」というご意 見です。これは後ほど、お時間の中でお答えいただければよろしいかと思います。 同じく D さんから、「PLC 対 DCS ということで、DCS 側は信頼性、サポートについて評価 されているけれども、最近の DCS の HMI はパソコンを使用したものが多く、ウィンドウズ の OS で動いていることからも、トータルサポートという面で本当に可能なのか。それは PIO の部分は、各社が作り込みされているから、それなりの信頼性は分かるけれども、ウ ィンドウズ・パソコンはそんなに信頼性があるのか。ということは、計装システム全体と して、そんなに信頼性があると言ってもいいのか」というご意見です。これはコストの問 題、先ほどの A さんからのご指摘ともつながることだと思います。 それから、参加者 E さんからは、 「PLC のハードはオープン化が進んでいるが、ソフトの 開発ツールがメーカごとに違っており、ハードがオープン化されたメリットをユーザ側は 十分受けられない。ソフト開発ツールの共通化の可能性はないのでしょうか」というご質 問があります。 これは、ご承知のとおり、現在は PLC を買ってきた場合、三菱の PLC や日立の PLC など、 PLC ごとに開発ツールが違います。このツールが何百万円かするわけです。しかも、加え てネットワークがフィールドバス対応か、または MELSEC 対応か、または FL ネットか、そ のネットワークごとにまた開発ツールが違っている。ユーザさんにとっては、ネットワー クごと、PLC のメーカごとに開発ツールが違う。それを全部そろえるのも大変だ。それで よいのか。IEC161131-3 対応で、それでいいのかというご指摘だと思います。 それから、参加者 F さんから頂いているご質問は、東芝の大庭さんに対してのご質問で すので、後ほど大庭さんにお答えいただきたいと思います。F さんが非常に関心を持たれ たのは DCS のリプレースで、「IO はそのままで、上の DCS だけをリプレースされた、こう いうアプリケーションソフトの完全互換が、非常に強いアピールポイントになるのではな いか。本当にこれで、信頼性などは大丈夫なのか」というご質問です。お考えいただきた 16 いと思います。 それから、参加者 G さんからは、 「現在、汎用 PC の採用が増え、情報 LAN への接続が一 般的になっていく。こういった動向の中で、ウイルス対策などのセキュリティと、ウイル ス対策だけではなく、侵入（ハッキング）に対する防止も必要だと思う。オープン化と、 こういう危険性は表裏の関係にある。この辺をどう考えるのか」というご質問を受けてい ます。 以上の中で、論点抽出として私がまとめたいことの一つは何かというと、この中でも、 メーカによって、いろいろ色合いが違い、DCS 側に立ったお話もありましたし、PLC 側に立 ったお話もありました。午前中のユーザ２件の、 キリンビールと参天製薬からのご発表は、 この分野では、DCS と PLC の区別は考えないというお答えでしたし、それから、メーカの 中にも DCS と PLC はトータルに考えるというメーカが、かなりいらっしゃいました。それ から、実際の運用において、表示器と PIO、peripheral（周辺機器）のインプット・アウ トプットの組み合わせという専用の PIO から、代わりに PLC を使うという事例が、非常に 増えてきているというご報告もありました。 こういったことから考えて、確かに PLC 対 DCS という競合で論じる状況には、もう既に ないというのが正しい認識だと考えています。ですが、あえてそういう立場に立って考え ると、先ほど申し上げたように、DCS の低コスト化をどう考えるのかが一つの論点だと思 います。 DCS と PLC についての非常に大きな違いを、宮川チェアマンがまとめられました。例え ば PLC については、アップグレードや修理を、ソフト単位ではなく、ハード単位で考えて いらっしゃる。ご承知のとおり、モジュールを付け加えたりすることによって、アナログ IO を加えたり、通信のモジュールを加えたりすることが PLC ではできますが、DCS では、 まとまった形でしか提供されていない。その中の、ソフトウェアのアップグレードしか DCS 側は考えていない。大きな単体という世界をそのまま維持した形に対して、PLC 側は、ハ ードまで分解した形の組み合わせを考えている。それが多分、PLC 側の一つの利点だと思 います。 もう一つは、PLC 側の三菱電機の八尾さん、オムロンの米倉さんからお話がありました が、出ている個数が、DCS に比べて PLC は一桁多い。たくさん造れば造るほど安くなると いうのが大量生産の論理である。だから、PLC のイニシャルコストは安いというご意見が ありました。この辺を DCS 側がどうお考えになるかということは非常に大事だと思います。 17 それからもう一つ、今度は逆に PLC 側に立って話を進めると、イニシャルコストが安い のはいいのだけれども、問題は信頼性である。DCS ほどの寿命がないことをどう考えるか。 三菱電機の八尾さんからは、二重化をするとか、MTBF を延ばしていくということがあり ましたが、多分、信頼性を上げていくという方向は、コストが上がる方向だと思います。 ユーザは低コストというところに魅力を感じているのですが、信頼性を上げていくと、結 局 DCS とコストが変わらなくなる可能性がある。特に、八尾さんが大規模、小規模と分か れて、大規模に手を出さないのはコストメリットが出ないからだというお話をされていま した。ユーザは、信頼性も低コストも両方取りたいということですが、それはどこか両立 しないものもあるかもしれない。その辺をどう考えるかが、非常に大事になっていくので はないかと思っています。 もう一つ、サポート体制があり、24 時間 365 日サポートをするか。これが杉浦さんがお 出しになった要求項目の５番に対応します。これに対して、DCS 側はサポートする。それ に対して、PLC 側の三菱のほうは、現状、サポートはしない。オムロンは窓口対応をして、 電話で対応して、必要なら SI の会社に連絡をする。ユーザにとってはあまり十分な対応で はないと思いますが、こういうお答えでした。 ですから、昔は DCS や PLC というハードだったのに対して、現在はご承知のとおり SCADA なども含めた、ソフトが大事だという意識に変わりつつあります。それに加えて、ユーザ は、サービスまたはサポートもお求めになって、ハード、ソフト、サービス、サポートと いった、トータルとして自分のところにメリットがあるかどうかを一つ議論されるのでは ないかと思います。 これに対しては、杉浦さんのアンケート結果にもありましたが、特に PLC に対しては、 ユーザとの間にシステムインテグレータが入る。申し上げたいのは、DCS についてはユー ザに直接、対応することをご報告いただきましたが、PLC については、間にシステムイン テグレータというワンクッションがあって、ある意味で PLC は部品供給のメーカという立 場でお仕事をされている。だから、DCS と同じようなサポートはしない。オムロンの場合 も、SI の会社にお取り次ぎになる。ということは、逆にいえば、この SI（システムインテ グレータ）のかたが 24 時間サポートをするかどうかということではないか、聞く相手が違 っているのではないかという気がします。 または、ユーザ側とメーカ側に、幾つかのそご（齟齬）がある。要求事項という形で七 つ出しましたが、その間には相矛盾する要求もあり、メーカ側が七つの全部の要求にこた 18 えられない。低コストと高信頼性は、ある意味で相反するものです。そういった狭間の中 で、食い違いがあるということは、実はビジネスチャンスがあるということで、今のよう なメーカを超えた形で 24 時間 365 日のサポートの会社を興せば、 ユーザは非常にうれしい。 安い PLC を投入されるということだと思います。 それから、ご質問にあった、それぞれ PLC ごとにエンジニアリングツールが違うのであ れば、みんな同じような、それぞれ違った PLC に対して、一つのエンジニアリングツール で設計や保守ができるのであれば、そういうソフトはユーザはみんな欲しい。そこにはビ ジネスチャンスがあるということだと思います。 ですから、ここでユーザ側とメーカ側、または DCS 側と PLC 側の現在の対立点、または 互いに補えないところを明確にしていきたいと思います。それは、ユーザがわがままだと 責めるつもりもありませんし、メーカ側が仕事を十分していないと責めるつもりもありま せん。ここで共有したいのは、今何が必要であるかということと、それを裏返せば、それ がビジネスチャンスである。そういうビジネスをどなたがおやりになるか。そういったこ とを、皆と一緒に情報をシェアしていきたいと思います。 問題抽出にはなっていないかもしれませんが、今のような、 要求項目が七つもあります。 それを全部まとめるのは難しいわけですが、多面的な形で、それぞれのユーザ側、メーカ 側、それから DCS 側、PLC 側、そういった縦と横の狭間の中で、いろいろな矛盾点、解決 法といったことを考えていきたいと思っています。 前のパネラーの中には、まだ発言をしていただいていないかたがいらっしゃいますので、 そのかたからご意見を伺いたいと思います。 どうしましょうか。すみませんが、安田さんから、ユーザの立場で今日これまでお話を お聞きになって、ご意見を伺えればとありがたいと思います。 ユーザの立場(更新の理由――老朽化、部品供給のストップ) （安田） はい。ライオンの安田と申します。今までのメーカ、それからユーザのいろい ろなお話の中で、私はユーザの立場ですので、ユーザの視点で聞かせていただき、要求仕 様を含めていろいろ考えるところがあります。その中で、特にお話がなかったなと思った ところが、１点あります。 まず、ユーザから見ると、今はこういうご時世ですから、新規のものというよりも、む しろ既存のシステムに更新をかける。更新をする際に、パソコン PLC やパソコン計装、あ 19 るいは PLC 計装や DCS など、いろいろな選択肢があるわけです。けれども、その前に、こ れだけ技術が進歩しているにもかかわらず、既存のシステムを更新しなければいけない。 つまり、その理由は、老朽化や部品供給できないなど、いろいろな事情で更新に至るわけ ですが、それを補うような部品なり設計なりは、十分進歩しているわけですから、できる のではないか。そうすると、今の部品がないということに対する設計のし直しは、できる のではないか。 例えば MMI でいうと、ブラウン管のようなものは大体、先ほど DCS のほうがトータルコ ストでは安いとおっしゃっているのは、本当かなと私も思っているのですが、現実的には ７∼８年ぐらいで、けっこう大きな保守をかけていかなければいけない。そういうものと 比べていくと、けっこうお金がかかるということがあるのですが、そういうところでも、 ブラウン管がだめであれば、別のものが持ってこられるということができるのです。けれ ども、IO や AIO などになると、なかなかメーカのかたは設計しないで、次の更新と言われ るのです。 そういうことが、やる前に、そういうことができないかということを強く感じた次第で す。そういうことも含めて、ご質問等、後でさせていただきたいと思います。 （新） 今の部品の保守というところでは、東芝の大庭さんがディスクリートな部品を一 つのチップにまとめて、新しい技術で、同じものではなく対応していくということをお話 しになっています。それは例えば今、ブラウン管の代わりに、それがなくても液晶があれ ばいいとか。 （安田） そういうことですね。要するに、その機能を代替するものがあって、今の既存 の設備に付く。そうすれば、そのところだけで済むのですが、実際には DCS でいうとパッ ケージになっていますから、なかなかそうはいかないということがあって、全取り替えと いう話になります。部分的に更新ということも、ご提案の中にありましたが、ただ、けっ こうな費用になるということで、そういうことも考えられないかなと思いました。 （新） ありがとうございました。 今、大庭さんの名前が出ましたが、例えばメモリの世界だと、大きい PCI のメモリがあ って、それがコンパクト・フラッシュなど、小さいものでもみんな対応がつくような、途 20 中にかませればいい。ソフトウェアの世界ではラッパーといいますが、特に世の中、部品 はみんな小型化に向かっています。 ああいう形ではなく、 まとめてもいいのですけれども、 そういう形で、古い PCI のバスだって、最新のコンパクト・フラッシュや SD カード、ミニ SD カードなど、そういう使えるような形という発想はありうると思います。 何かそういう意味で、少しお話が中途半端だったかなという気がするのですが、いかが でしょうか。 （大庭） 東芝の大庭です。新しい技術で既存のシステムのある部分を、新しいものに置 き換えるという方向は、我々は「延命」と呼んでいます。今の設備を更新するのではなく、 とにかく長く使いたいということへの解として、我々ベンダとしては、今の例えば部品が なくなったと。先ほどのユニット、例えば CRT、ブラウン管ならブラウン管を、液晶パネ ルに替えるとか、プリンタももう製造中止になったら、同じ機能の新しいプリンタに替え る。ただ、プリンタですと、ソフトが介在しますので、その間にソフトの変換なども入れ ることが、場合によっては出てくると思います。 OHP のシートで出したのは、そのいちばん小さなレベルの基板に乗っている部品が製造 中止になって、ただし基板を全部再設計し直すのは大変なので、それと同じ大きさで新し い部品を使って、さらに長い間供給できるようなものを開発し、それでシステムの延命を 図るというような対応をしています。 （新） そうですね。それで、ああいうディスクリートな部品を１チップにすると、また 信頼性が向上しますね。それは非常に正しい方向だということになりますね。 （大庭） （新） はい、そうですね。 ついでに、F さんのご質問にお答えいただければ、ありがたいのですが。 （大庭） 質問の回答として、エミュレータという形で言いましたけれども、昔のコント ローラを新しい機種に替えるときに、例えばそのエンジニアリングするプログラムが少し 変わっていたりしますと、よく今までやられていたのは、コンバーターをかけて、その新 しいコントローラで動くようにするというやり方なのです。 しかし、 コンバーターも、100％ 21 コンバートできないと意味がないというか、かえってエンジニアリングがかかるというこ ともあります。 そこで今回ご紹介したのは、アプリケーションソフトのオブジェクトが、そのまま新し いハードウェアで動くようなものを作って、要はオブジェクト・レベルで、新しいコント ローラがそれを解釈して、昔のコントローラと同じ動きをする。そのような解を提案した のが、 「PCS エミュレータ」と呼んでいるものです。 （新） それはもうかなりアプリケーションの事例は多いのですか。そうやってリニュー アルというのは。 （大庭） いえ、これからです。開発が終わったような状況で、これからどんどん。今、 対象としているのが、まだ 10 年少々前の機種で、まだリプレースはこれからもう少し先な ので、これから 15∼20 年たってくると、そういった要求が出てくると思って、開発してい るものです。 （新） はい。では、そういう要求に、もう今から準備をされているそうですから、該当 製品をお持ちのかたは、５年後でもけっこうですから、大庭さんのほうにお願いしていた だきたいと思います。どうもありがとうございました。 それでは元の順番に戻って、すみません、高野さん、お願いいたします。 ユーザの立場（最適なシステム、情報の共有、体制及び組織） （高野） トヨタ自動車の高野と申します。私なりに３点ぐらいお聞きしたいことをまと めました。 １点目が、午前中のユーザの方の発表に非常に共感したのですが、我々の中でも DCS と PLC の区別などは全然考えていません。いいもの、合ったものを使うという観点で、機器 を選んでいるという状況になっています。そういった意味から考えると、今の世にいう DCS というのは、きっともっと安くなるのだろうなと考えます。先ほども低コスト化をどう考 えるかという話がありましたが、ここはぜひもう少し突っ込んでみたいと思います。また、 我々もいろいろなベンダのかたと、もっと安くなるでしょう、もっと小さくなるでしょう ということを、だいぶ議論をさせてもらっていますので、ここの場でもう少し掘り下げら 22 れればと思っています。 ２点目が、やはり情報の共有ということが非常に重要だろうと思っており、先ほどもあ りましたが、水平と垂直での情報共有ができれば、よりもっと現場になじんだ改善の積み 重ねができるのだろうと考えます。そういったところに対して、セキュリティを持った情 報共有の基盤をどのように考えておられるのか。この辺、 少し議論してみたいと思います。 ３点目が、それをやっていただけるベンダの、これは当然、人が造るわけですから、そ の辺の組織体系はどう変わっていくのだろうか。多分、旧来の組織体系のままだと、なか なかそこから脱却できないのではないかという気がしており、一部には変わってきている という兆しを感じているのですが、その辺を少しお聞きしてみたいと思います。 （新） ありがとうございます。 高野さんからは、DCS の低コスト化、情報の共有プラスセキュリティ、それから組織体 系という三つの題を頂いたのですが、DCS の低コスト化がいちばんここにふさわしいので、 少しそれを掘り下げたいと思います。 今日のお話、ユーザ仕様書に対する回答の、特にオープン化を、各 DCS メーカから頂い たわけです。そのオープン化は、ほとんどが OPC で接続できるという、オープン・コネク ション、接続性だけなのです。多分、ユーザ要求仕様の２にあった、必要十分な機能が欲 しい、それから時代が変わるとともにアップグレードしていきたい。そういう非常に大事 なポイントを考えていくと、ソフトウェアのオープン化も必要です。 それは、ソフトウェアを部品化して、必要なものだけ組み合わせていく。今まで DCS と いう「ドンガラ」があったわけですが、先ほど PLC の話でもしましたけれども、いつまで もその「ドンガラ」を大事にして、外と接続できるからオープンだというのでは、不十分 である。必要な機能を入れたり出したりできるような、中をソフトとしても切り刻めるよ うにする。または、PLC のようにハードも切り刻めるようにする。そういったことが、ユ ーザの要求ではないか。 そういうことを通して、低コスト化が可能ではないか。現在は、ある意味で必要以上の 機能が付いてきてしまう。それが、杉浦さんの要求仕様の中に表れてきたということで、 多分高野さんがおっしゃりたいのは、現在の機能や信頼性を維持したまま、もっと低コス ト化の努力をしろということだと思います。 それに対して、いかがでしょう、 白井さん （笑） 。 23 （白井） 横河電機の白井です。低コスト化というのは、一番辛い課題だと思います。特 にハードウェアだけ取り上げますと、オムロンの方が仰ったように、DCS は PLC に比べて やはり製造ボリュームが二桁違います。そうしますと、ハードウェアだけを取り上げる限 り、確かに DCS の方が高いといえると思います。 ただ、例えばコントローラのところですと、今日の午前中のお話にもありましたが、ハ ードウェア、あるいはソフトも含めてもいいですが、そういうコアのところのコストだけ ではなく、これからはやはりそこに組み込むお客様の資産、いわば魂であるシステムの制 御のやり方などを含めたコストを考えねばなりません。そこをインテグレーションするコ ストは、結局、イニシャルコストに非常に利いてくると思います。そういったところで、 DCS は、簡単に作れるとか、比較的大きな、複雑に組み合わさったものでも作れるという、 コストメリットをまず持っていると思います。 それから、ハードウェアのコストに関しても、例えばコントローラのところよりも、IO のところが注目されていると思うのです。IO のところで、DCS と PLC ではやはりコスト差 が出てくるのではないかと思います。そういったところについても、DCS 側としては、オ ープンな素材をどんどん使って、一つ一つのハードウェアを安くしていくなど、コストを 下げていく努力をしています。 あとは、先ほど少し感じたのですが、今のシステムには余計な機能がいっぱい付いてい るのではないか、非常に多機能なものが一気に詰め込まれているように感じるというお話 がありました。これは DCS の良さでもあって、かつてはオール・イン・ワンで何でも全部 揃いますと言ってきた。今の世の中は、機能が多くなりすぎて、やはり必要な機能を必要 なだけというのが当然、お客様の要求として出てきたのだと思います。 そういう絶対に必要な機能とそうでないものとの切り離しという意味で、好むと好まざ るとにかかわらず、DCS の世界では HMI（ヒューマン・インターフェース）の部分が切り離 されてきたと考えています。HMI の部分では、今は汎用のコンポーネントを使って、自由 に組み合わせていくことができるようになってきました。 では制御の部分はどうなのかということですが、やはり制御の部分は、私の話でも恐竜 の DNA と言いましたが、一種 DNA の部分があると思うのです。システムのインテグリティ （一貫性）や広い意味での信頼性などを守るために、やはりコアの部分として、きゅっと 固めてしかるべきところがあると思うのです。そういうところに関して、いい意味で保守 的な考えで持ち続けることも必要なのではないかと思っています。 24 （新） ご質問が三つあったのですが、先ほどフロアから、HMI のところはパソコンだろ う、だから全部ソフトを面倒を見ると言っているけれども、確かに今、白井さんが話で分 けた HMI の部分と制御の部分があって、今、制御の部分は非常に大事で作り込んでいる。 HMI の部分はそういう汎用品を使って、低コスト化に努力されている。ご質問は、「その HMI が、例えばウィンドウズ OS 上での HMI だったら、全部そこまで横河が責任を取れないだろ う」というご指摘がありましたから、ちょっとそこをお答えいただけるとありがたいので すが。 （白井） そうですね。ハードウェアの面に関しては、HMI は、確かに今は汎用品を完全 に使っています。 しかし、例えばハードウェアでも、お客様がどうしても非常に手厚いサ ポートが必要と要求されるのであれば、汎用の PC を売るのではなく、横河が推奨する長期 のサポートが得られるハードウェアをお渡しする、ということもやっています。 それから、ソフトウェアに関しては、ウィンドウズの内部の世界というように、我々が パッチを当てるわけにもいかない、そういう世界があります。正直な話、「こういうバグが まだあってもいいのか」というものもあります。極端に言えば、もうマイクロソフトのソ フトというのは、バグがあってしかるべきと認めざるを得ないのです。それをいかに使い こなすかというところで、結局、我々は設計に工夫を凝らし、いかにそのバグがあるとこ ろを回避して使っていくか。そういうところでの検証を非常に多くやって、最終的な、お 客様に出ていく機能としては、保証できるようにしています。それが逆に、今度はプロプ ラエタリー(proprietary)なソフトを作るという、その裏腹なところがありますから、難し いのですけれども。 （新） プロプラエタリーであると同時に、コストが上がってくるということですね。 B さんが、普通のパソコンなのに一桁違うというのは、今のような厳しい作り込みをや っているからということが、一つの理由になっているのですね。 （白井） そのとおりです。 （新） それで、すみませんが、もう少し待ってください。もう少し白井さんをいじめた 25 いのですが（笑） 、それは DCS 側に立っていらっしゃるので、論点を明らかにするために非 常に大事なのです。 何をいじめたかったのかというと、横河の、特に制御系の信頼性というのは、皆非常に 高く評価していると思います。やはり、MTBF が 20 年以上というのが、例えば PLC ではど うしても追いつけない世界です。そこにすごいノウハウがあると思うのですが、今日の内 田さんや樋本さんのお話を聞いていると、本当にユーザは 20 年というような寿命を欲しが っているのかということを、少し疑問に思ってきたのです。建設の時代から、リニューア ルの時代というお話が非常にあった。そして、昔と比べて、情報技術が非常に日進月歩で どんどん変わっていく。こういった中で、もう少し信頼性が低くてもいいから、安くして もらいたいというのが、ユーザの本音ではないかという気がするわけです。 ですから、やはりこの質問は、もしかしたら白井さんにするよりは、ユーザにしたほう がいいかもしれないですね。どうでしょう。ユーザはどう思っているのか、逆に聞いてみ ましょうか。 ユーザの立場（減価償却期間と製品サイクルの違い） （樋本） 参天製薬の樋本です。20 年で減価償却というのは、イニシャルのコストを単に 計算して、減価償却で税金処理して計算で出していただいただけなのです。ユーザ側から の減価償却というのは、その期間、使いたい期間の償却年数なのです。あるものによって は、製品のライフサイクル５年、３年で見ていて、このプロセス・オートメーションのシ ステムを使いたいのであれば、３年で償却できるものを入れたいわけです。 ですから、経営的にビジネスで見る場合は、このお金はこれで償却できますと言われて も、困るのです。私たちも売っているメーカですので、いろいろあると思うのですが、必 ずしも「これを売りますから、これはこのくらいで償却できますよ」という理論は、残念 ながら、今は通用しなくなってきていることを、少しいじめの議論とさせていただきたい と思います。 （新） ありがとうございます。 内田さんも何かご意見ございますか。 （内田） キリンビールの内田です。私は大体 DCS は 15 年というお話をしたのですが、今 26 日いろいろお話を聞いていると、20 年というのが一般常識なのかなと思いまして。 （新） いえいえ、15 年でいいです（笑）。 （内田） これからは 20 年でお願いしようかなと思っているのですが、実は、大体なぜ 15 年と言っているかといいますと、ビール関係の設備など、大体老朽化の更新の時期とい うのは大体、30∼35 年といわれています。それであれば、30∼35 年コンピューターがもつ ということは、考えられないなと。大体その半分の時期で、１回ぐらいは更新が必要かな ということで、おおよそのめどで、今まで 15 年というお話をしていたのですが、長期にも つにこしたことはないので、なるべく使えるものは使おうと。最近、この不況の時代です から、 そういう形では動いていますので、ぜひともよろしくお願いしたいと思っています。 （新） そこでちょっと内田さんにお聞きしたいのですが、B さんのご指摘だと、DCS と PLC だと、寿命も違うのだけれども、値段も一桁違うということですね。そうすると、30 年とか 60 年やるときに、１回更新するのと、10 回更新できるのと、10 回更新できたら、 ６年でいいわけですね。 （内田） そうですね。 （新） どうなのでしょうか。そうしたら、常に６年ごとに、最新の車に乗り換えられる ほうが、15 年ずっと引っ張るよりもいいのではないかという気がするのですが、いかがで しょうか。 ユーザの立場（IO 関係の切り替えのないシステム更新） （内田） ハード的に見れば、確かにそのとおりだと思います。IO 関係の切り替えさえし なければ、それほど工事期間もかかりませんから。ただし、そのときに、あくまでもその ソフトウェアやアプリケーションが継続して使えるという条件のもとであれば、ハードは もう IO はそのまま使って、上の部分だけ、HMI やコントローラの部分は最新に替えていく ということは、順次やっていきたいのです。けれども、あくまでもアプリケーションの継 続性が確保されれば、と考えています。 27 （新） （内田） そういう意味では、東芝の大庭さんの話は面白かったですね。 （新） そうですね。 ありがとうございました。 中島さんが先ほどから発言したそうなので、どうぞ、よろしくお願いします。 ベンダの立場（ベンダはどこも利益を出していない） （中島） 大した話ではないのですが、富士電機システムズの中島です。コストの問題と いうか、プライスの問題は、ちょっと私たちがベンダとして、実感として感じていること と、それからユーザさんたちからの要求とのギャップは極めて大きい。多分、ここにいる ベンダの各社日本の市場で、DCS でもうけているところはどこもいないという感じが非常 に強くしています。このギャップの大きさを、まず実感として知っていただきたいと思い ます。努力が足りないと言われれば、それまでなのですが、今日も非常に強くそのことを 感じたということです。もっと努力すべきであると思います。 ただ、一例として、ちょっとうちの例を申し上げますと、先ほど PLC をベースにした DCS という話をしたのですが、最近開発した製品です。これは、例えば二重化といっても、汎 用の PLC は当然二重化できますが、我々が DCS で使おうとすると、単純な二重化では、お 客様には満足いただけない。そうしますと、例えばタスク同期をするとか、データを完全 にコピーしていくなど、そういう機能を追加しなければいけない。 それから、白井さんの IO の話がありましたが、多分ハードウェアのコストの大半は、IO なのです。IO も、汎用の PLC の IO ももちろん安いし、使えるのですが、最終的にお客様 の選択は、 やはり現場に強い、従来の DCS が要求してきたような IO を、ぜひ作ってくれと。 そうしますと、 メニューをそろえているのですが、 いつも価格は安くなければならない。 けれども、それを提供しても、それは使っていただけなくて、やはり従来の DCS 並みの信 頼性や機能、性能を当然求められる。そうすると、おのずと我々はそれに見合った開発費 もかけていますし、そういうことがあり、お金を提示するのですが、最終的にはなかなか、 我々の提示したお金では商談はまとまらないという状況があると。これだけ申し上げたか ったということです。 28 （新） 今のお話は非常に重要なご指摘で、DCS でもうかっていないとおっしゃっていま す。ある意味で、ユーザの要求というのは、相反する要求があると思います。それは信頼 性やメンテナンスもしながら、安くしろと言っているわけですから、メーカからいえば「冗 談じゃない、どちらかにしろ。または、そのトレードオフを明確にしろ」というのがメー カ側がおっしゃりたいことではないかと思います。 現実に、日本の経済はあまり元気ではないので、ユーザもそうなのですけれども、今話 題にしたようなメーカ側は、かなり組織が変わっています。今日もお話がありましたが、 西元さんのところは、「東芝三菱電機」、一昔前では考えられない組み合わせです。DCS を 中心にやられていたメーカも、かなり PLC または DCS＋PLC という方向に、シフトされてい らっしゃる。富士電機も少し PLC を含む側に移られている。今日のお話だと、横河と日立 ハイテクノロジーズが、割と現在 DCS に頑張っている感じがするところです。 業界別に、今この産業システムは東芝三菱ですが、ご承知のとおり、鉄の製造装置のほ うは日立三菱、いろいろなライバルと思っていたメーカが、急に仲良くなって一緒になっ てしまうという形です。 逆にいえば、ユーザにとって、日立はずっと続くとか、東芝はずっと続くと思っていて、 30 年の保守などとおっしゃっていたわけですが、それでもっと安くしろ、安くしろといっ て、結局 DCS はもうからない。どこかで、もしかしたら DCS はもうやめてしまうといって 投げて、選択の余地なく、パソコン計装か何かに移ってしまうかもしれないという危険な ところまで、実はユーザは来ているというのが現状ではないかと、私は思うのです。 そういった中で、やはり大ユーザの一人の東京ガスの服部さんに、少しお話を伺わなけ ればいけないと思います。すみませんが、順番ですので、お願いいたします。 ユーザの立場（いざとなっても設備を止められない） （服部） 東京ガスの服部と申します。午前中にキリンビールから設備を使う前提という 話が出ました。基本的にはいざとなれば止められますよ、というご発言があり、これは、 非常に重要なことだなと思いました。私どもの会社も、いざとなれば止まってもいいとい う言葉を言えればどんなにいいことかなと思って聞いておりました。絶対に止められない 設備がある、という業界故の特殊事情がありますので、本音としては、なるべくシステム・ リプレースや、機会があるごとに、PLC 等も使えればそのほうがいいなという希望は持ち 29 つつも、どうしても先ほどのご発言にありましたように、最終的に本当に大丈夫かなとい う懸念が捨て切れない訳です。いざというときには、ちゃんと動いてくれなければいけな いのだという条件で、やはり今までの実績のある DCS を、しかたなくなのかも知れません が、選択しているというのが実態かと思っています。 そこで、メーカ側にお尋ねしたいのは、今後の方向として、例えば PLC と DCS の垣根が 少なくなってきているということですが、その PLC ベースの IO 装置なりハードウェアの信 頼性を、DCS に近づけていこうという動きは無いのでしょうか。 今のご発言ですと、もうもともと商売にならなくて、あんなもうからないものはやりた くないということですが、方向として、PLC の信頼性を、もう少し別な観点から担保でき る（我々が要求している信頼性と申しますと、基本的には壊れても継続運転ができる、継 続運転の意味合いとしては、プロセスの状態がそのままの状態で、最低限、動かせればい い）ものにして行くような画期的なことにチャレンジしようという動きがあるかどうかと いうことを、お尋ねしたいと思います。 それからもう１点、今度はオープン化ということで、どんどん使われていく、あるいは 先ほど選択肢の一つとして、DCS との組み合わせにおいて IO の手足の部分を PLC なりに置 き換えていく、という動きがあるというお話がありました。我々としても、そういう考え 方を導入しようと思っているのですが、例えば、手足の部分を PLC に置き換えるというこ とであれば、いろいろなメーカのものを使うという選択肢があろうかと思います。 頭となる DCS の部分と組み合わせで使った場合、もし障害が起きた時に、果たしてその サポートというのは、現実にはどういう形になるのか。基本的にはユーザ側でどちらが悪 いのかという切り分けをして、最終的にはあちこち２社なり３社なり連絡をしてやっとや ってもらうというのが実態なのか。あるいは、もう少しうまい方法で今後まとめていこう というメーカがいらっしゃるのかどうか、その辺についてお尋ねしたいと思っています。 （新） 今２点ですが、どなたかお答えになるかた。なければ岩崎さんを指名してしまい ますが（笑） 。すみません、お願いいたします。 ベンダの回答（PLC を IO として使用、オープン化した場合のサポート体制） （岩崎） 山武の岩崎です。１点目の PLCIO の信頼性について、DCS ベンダがかかわって、 信頼性を上げる方向にというご質問でよろしいのですか。実際は、そういう指導力を、DCS 30 ベンダが PLC のベンダのかたに影響を及ぼすということは、現状難しいと考えております。 ただ、こういった活動はやっています。PLC 計装という話題で、実際三菱殿が各ソリュ ーション・ベンダを集めてビジネスアライアンスを結んでいくことをおやりになっていま す。その中には、弊社も入らせていただいて、どういう形で、その PLC の計装が今後、発 展しながら、では我々が逆にシステムインテグレーションという作業を実行する際に、ど ういうところをチェックポイントにしてやっていったらいいかという研究は続けています。 それが第１番めということです。 ただ、我々もコントローラに対する思い入れは、かなり大きいところがありますので、 その PLC 計装でユーザの方々はどういうことをやられるかを研究させていただきながら、 我々が今後、作る商品へフィードバックさせていただくことになります。 それから、二つめのオープンシステムでのメンテナンスの方向性について述べます。組 み合わせ障害を、どう切り分けてどのようにサポートしていくかが課題ですが、現実には PLC は、 基本的に我々の DCS システムの中のコンポーネントとして入ってくるというのが、 ほぼ日常です。その中で、お客様からの障害対応に対する要求というのは、一応、弊社で 全部一次対応を含めて見ておりますし、逆に我々のデポセンターの中にも、主要部品を置 かせていただくというプログラムもやっています。 それから、これは PLC だけではないのですが、いわゆるコンビナート地区のお客様は、 一括のメンテナンスというご要求が最近、当然増えているわけです。一括メンテナンスと いう、いわゆる定期保全のプログラムの中には、我々がプロジェクト・マネジメントをし ながら、その複数のベンダのものが入っているシステム全体、あるいはフィールドも含め たところを、一括保全というプログラム化を実施しています。今後は、ある程度、障害対 応を含めた形で、マルチベンダシステムのメンテナンスを請け負っていくという作業形態 が主流になるのではないかなというふうには思っております。 、そのプログラムは用意して、 我々から提供させていただいているというのが実情です。 （新） はい、ありがとうございます。お話の中でお分かりだと思いますけども、山武は 自分のところの DCS をお持ちですが、PLC は三菱の製品をお使いで、システムインテグレ ートをされていらっしゃいます。それで今のようなお話になったと思います。 そういう意味で、三菱電機は、24 時間 365 日のサポートはしないと、先ほど八尾さんが おっしゃっていました。DCS を組み合わせる山武がインテグレートした部分については、 31 岩崎さんのところで 24 時間 365 日サポートしている。これからは、そういうビジネスが大 きくなるだろうと言われていたと思います。これは一つの回答ですね。 澤近さんの前に、八尾さんにちょっとお話を伺いたいのですが、服部さんからのご質問 の最初の部分は、PIO が大事だ、絶対止まってはいけない。それに対して、それだから DCS を使っているのだというお話でした。DCS とは違うやり方で、これだけ情報技術が発達し たのだから、そういう信頼性を PLC に、同じやり方をすると、DCS と同じコストになって しまいます。何かうまい方法で、DCS の持っている PIO の信頼性と PLC の低コスト化を両 立させてくれると、ユーザはみんな喜んで、PLAUDIA シリーズを使ってくれるというお話 だったのですが、何かご意見があったら、よろしくお願いします。 ベンダの回答（PLC の信頼性向上） （八尾） 三菱電機の八尾です。PLC の信頼性を DCS 並みにしてほしいと。これは計装を やっていくうえで、確かにごもっともなことだなと考えております。 明確な答えになるかどうか分かりませんが、MELSEC で計装をやるために、実際はコンポ ーネント供給ではありますが、昨年２月に MELSEC 計装という格好で発売しております。当 然、計装はアナログ IO が中心になってきますので、特にアナログが多点になったときのコ ストダウンと信頼性向上は、当然我々も、製品開発、供給、かなり意識をしています。シ ーケンサーが、もともと自動車メーカを中心とするリレー制御盤を、ソフトウェア化する ところから始まった。そこには IO として、アナログはほとんどないのですが、デジタル IO というところで、かなり点数をお使いになる。 当初、シーケンサーが出た歴史的なところから申しますと、最初のデジタル IO というの は、今考えればコスト高で、信頼性も DCS に比べるといまいちだったかなと。そこはある 年月を経て、信頼性もかなり上げて、コスト的にも非常にチャネル当たりの単価は下げて いったことを考えてみますと、やはり計装をやる以上、アナログにつきましても、はっき りいって今、MELSEC の絶縁型のアナログなどを出していますが、まだまだチャネル単価は 高い。あと、多点のものが品揃えとして、ない。ここはやはり、多点化ということと併せ て、コストダウンと信頼性向上を、製品開発の中で鋭意やっている状況です。 実際、信頼性を上げながらコストダウンしていくそのやり方を、昔、自動車メーカでお 世話になったように、いろいろなユーザ、先ほど山武の岩崎さんからご紹介がありました が、実は、MELSEC 計装のシステムインテグレータを中心として 22 社、 「MELSEC 計装パート 32 ナー」を今年６月に発足しております。計装ノウハウを持っておられる 22 社のインテグレ ータと一緒に、いろいろご相談させていただきながら、ご提案も頂きながら、いいものを 作っていこう、そのために一つの活用の場としても考えております。 ということで、あまり回答にはなっていないのですが、デジタル IO に次ぐコストダウン と信頼性向上、あとは計装パートナーによる連携した製品力強化、そこをぜひやっていこ うと考えております。 （新） アナログ IO についても、デジタル IO と同じだけの信頼性を出していきたいとい うお話でした。澤近さん、どうぞ。 ベンダ回答（信頼性とオープン化） （澤近） 信頼性とオープン化ということでご質問を頂いていると思うのですが、まず信 頼性について、これは PLC だからとか DCS だからということで、切り分けて語る問題では ないなと。コストや長期保証できるかどうかも、PLC に依存する問題でもないし、DCS に依 存するものでもない。これは去年もお話ししたかと思いますが、むしろベンダの基本的な お客様に対する、カスタマーサティスファクションへの姿勢の問題だなと考えます。です から、PLC だから、DCS だからだめでしょう、いいでしょうという議論は、先ほどからお聞 きしていて、ちょっと当たらないかなと思います。 まず、信頼性について、では PLC として、先ほど「PLC やめました、ロジックスです」 と言っておいて、PLC と言うのはおかしいのですが、ロジックスのシステムとして、どう いった対応をしているか。これは完全に二重化のシステムを提供する。それによって信頼 性を向上させる、DCS 並みのシステムの信頼性を提供する。 それは、単なる PLC の二重化といった切り替えというだけではなく、自動的なメモリの 転送といったことも含め、あたかも１台のコントローラであるかのように、プログラミン グできる。DCS と同じようなタグの共有ができる。そういったことを満たしていないと、 信頼性だけとやかくいっても、苦労すると信頼性を保てますが、そういったソリューショ ンというのは、認められないのではないか。そういうことで、DCS 並みの信頼性を、PLC も実装しなければいけない。 それから、CPU だけではなく、電源の二重化ですとか、そういったことも含め、明日で も、会場に商品を展示しておりますので、ご覧になっていただければいいかと思います。 33 （新） システムコントロールフェアの会場ですね。 （澤近） システムコントロールフェアの会場で、ご覧になっていただければよろしいか と存じます。 それから、オープン化について問題の切り分けということなのですが、これは非常に難 しい問題で、オープン化ということは、ある意味でリスクである。例えば、当社の商品と オムロンの商品とをデバイスネットでつないで、いきなり動かなくなったというとき、ど っちが対応するのかとなると、やはりどちらかが対応するということになります。その辺 も、オープンがいい悪いという議論ではなく、対応するベンダ側の、CS に対する基本的な 姿勢だということです。私どもの場合ですと、デバイスネットのレベルの支障については、 私どものサービス部門がそういったことに対応することになります。 本当に、そういったオープン化による問題を回避したいというお客様がいらっしゃるの であれば、それはまことに申し訳ないのですが、要は、いろいろな組み合わせをして、い ろいろな会社のいいところだけをつまみ食いしてやってしまおうということになると、そ の辺のリスクが全部、お客様のところに行くことになると思います。ですから、 （そのよう なお客様には）シングルベンダでのソリューションを、お勧めすることになると思います。 ユーザの立場（本当に止めていけない設備を理解して制御システムを決める） （新） ありがとうございます。ここで樋本さんにお聞きしたいのですが、なぜかという と、今日のご発表の中で、薬を作るということに対して、非常にバリデーションが大事で あるということでした。そのとき、各工程に分けて互いに混じらないようにとか、トレー サビリティや、FDA のパート 11 の話をしていただいたのです。それは薬づくりだけではな いと思うのです。皆さんがやっているような、いろいろな製品もありますが、そういった 制御機器についても、同じようなことが必要だと思うのです。 ハードについても各部品がちゃんと動いている、それがちゃんとつながって動く。ソフ トウェアについても、それぞれ個別に自律的に動く。それがつながったときに、ちゃんと 動く。障害が起きたときには、ちゃんとデータを取って、トレーサビリティをたどってい って、どこのだれが悪かったのか。複数のベンダが、あるシステムだったら、ちゃんとそ 34 れが追跡できて、どこが悪かったかデバッグできるような、そういう考え方が必要だと思 うわけです。 特に、バリデーション関連の部署もお作りになって、リスクマネジメントが大事だとい うことをお話しになっています。それがちょうど、今の澤近さんのカスタマーサティスフ ァクションにつながるという気がするので、一言頂けるとありがたいのですが。 （樋本） 先ほど、ユーザ、ベンダのご意見を頂いて、やはり若干議論がずれているとい う感じがします。東京ガスのように、ライフラインでどうしても止められない、一瞬確か にそうですねと思える。我々も医薬品を供給する、止められません、なくなったら困ると 思うのですが、我々の中でも、本当に企業の中でも、本当に止められないところはどこで すかという話を、徹底的に議論しているかというと、しないのですよね。 ユーザニーズ、ユーザニーズと皆おっしゃるのですが、キツネのユーザニーズとトラの ユーザニーズがあって、 「お客様の品質が大事だ、大事だ」と言っているのですが、自分で 勝手に「お客様の品質」にしている人がいたりするのです。それは、ベンダの営業もあっ たり、我々も勝手にそうやったりする。 午前中の最後のほうで、ピラミッドで表層機能と必要な機能というところを分けました が、絶対譲れない機能というところを、ユーザ側が徹底的に絞り込み、それに対してシス テムインテグレータでもベンダでも、メーカでも、ソフトウェア屋でもハードウェア屋で も、商社でも何でもいいのです。それは、これによって、こんな選択がありますと。 もう一つ大事なのは、タイミングと時勢ですよね。今成し遂げたいことと、１年後、３ 年後にしたいこと。それから、イベントがあって替えたい。ユーザニーズはやはり変わる。 でも、ユーザはわがままであると同時に、本質的にどんどん、何が大事で、何が付加価値 かというのを見るようになってきている。 それに対して、今まで、やはりユーザは、システムを受けて使う立場なので、ベンダが 「こういうものを作りました」と持ってこられても、「はい、そうですか、すごいですね」 と言っているのに、徐々にそれから脱却しつつある。 先ほど信頼性の話もあったのですが、 本当に PLC の信頼性は悪いのか。確かに、よく見ると PLC のほうがトラブった事例はあり ます。ただ、ボリュームの中で、PLC がすごくたくさん使われる。IO の世界にしても、リ レーIO から、トランジスタ IO になったときに、何万回と高速にオン・オフしているよう なものがある。あれを DCS でやったら本当に耐えられるのかというと、そんなニーズはな 35 いからという話になってしまうのです。 ですから、信頼性という話は、結局リスクに落とすケースなので、自分たちがどのよう に本質的に使いたいのか。そのために、ここは止まってはいけない、これは譲れないとい うところを、リスクアセスメントし、それを明らかにするのが、バリデーションの行為に なるということなのです。 午前中申し上げた例、パート 11 とかいろいろ言っているのですが、結局、最終的に世の 中の皆様の、クオリティ・オブ・ライフやライフサイクルのために、製品やサービスを供 給させていただくわけです。それに対して、譲れない機能と付加価値に対して、我々はシ ステムをどう使うかを出していく、そういうことがバリデーションの本質なのです。 ですから、その辺を、本当はこういう会議を含めて、ベンダ、システムインテグレータ、 ぎっちり議論させていただくと、いろいろな種類の提案があって、ユーザもいろいろなタ イミングと、いろいろな使い方ができるようになる。そういう時代に少しずつなりつつあ るのではないかと考えます。 （新） 具体的にこのシステムの中で、リスクアセスメントして、止まってもいいところ と止まってはいけないところ、また、止まっても何分で回復すればいいところ。 （樋本） そうです。止まってはいけないところと、止まっても、24 時間 365 日サポート ですといって、かけた瞬間に「はい、直りました」というのは、まずない。では、ネット ワークをつないでおいて、ベンダのサポートセンターみたいなところがあって「調べます」 と。でも、大概それは、私の知る限りハードウェア屋の専門は並んでいるのですが、ソフ トの障害だと。特に最初に立ち上げたとき、実はソフトの問題だった、もしくはユーザの オペレーションのせいで起こってしまっている障害で、 「それは分からないですね」などと いう世界になってしまう。そうすると、DCS の 24 時間 365 日サポートというのも、本当に ユーザが必要としているのかということから、選ばなくてはいけない。ところが、セット で来てしまうという話になると、先ほどの「コストが高い」という話になってしまうので す。 「要らない」といえば「保証しません」と言われてしまう。そんなに差が激しいのか。 コストの話も、コスト・オブ・クオリティなので、ユーザが、「幾ら高くても、非常にい いですね」と求めれば、それは高くないのです。そのように、コストのほうも、ただ高い、 高いという価値ではない。バリデーションのほうも、リスクによって、何に費用と労力を 36 かけるかということになると思うのです。 （新） ありがとうございます。非常に明確なご示唆だと思いますが、布野さん、どうで すか、DCS の立場から。 ベンダ回答（PLC の採用は適材適所で） （布野） 日立の布野です。おっしゃることは、そのとおりかなと思っております。それ で、私どもは PLC の採用に、ちょっと後ろ向きのような、先ほどご発言があったのですが、 基本的には、我々も実は PLC、IO、あるいは、一部のローカル制御でかなりの数を使って おりまして、それで全然そういうことは考えていない。要するに必要なところに必要なも のを、やはり提供しなければいけないだろうと思っています。 それから、我々が作ればいいのではないかという話があるかと思いますが、多分、今要 求があるようなレベルの、 DCS に近いレベルの IO を我々が作っても、多分安くはならない。 それは、先ほどおっしゃった、我々にしてみれば、ハードのコストは実は非常に低くて、 そのための設計だとかいろいろかかっていることが一つです。 もう一つは、似て見えるのですけどけっこう違うところがあります。それは先ほど、横 河から、 我々は飛行機をコントロールしているのだという話があったのですが、要するに、 落とさないためにはどうするか。ですから、飛びつづけるために、壊れたところが分かる ことと、オン・ザ・フライで直せる。そのためのコストが非常に大きいということで、多 分 PLC の IO は、私などが見ますと、最近のものは１チップか２チップで多分できています。 それに対して、DCS のものはかなりごついなというのは皆さん、思っておられると思いま すが、技術的にそういう背景があるということです。 ですから、やはり我々としては、ある意味でベンダでもあるし、SI 屋でもあるというこ とで、お客様に了解していただいたところは、コストの安いものを使いますし、必要なと ころには必要なものを持っていく。これがいちばん大事ですし、これを忘れると、計装屋 として非常にまずいなと思っております。 エンジニアリング会社の立場（マルチベンダでの対応） （新） ありがとうございます。樋本さんのおっしゃっていることも、パッケージでぽん 37 と来られて、サポートが要るか要らないかというのでは、困る。ユーザ要求書の中でもあ りますが、人に応じた機能という形ですから、いわばハードもサービスもサポートも、み んな幾つかに分解して、それをユーザが選べるような環境を整えてほしいということだと 思います。 それには複数のベンダやユーザ、システムインテグレータが共同していく、場合によっ ては、アライアンスを組んで進めていくことが不可欠な時代に入っているのではないか。 そういうことを日常的になさっているのは、多分エンジニアリング会社で、刑部さんのと ころではないかと思うのです。 先ほどの服部さんの「複数のマルチベンダを集めたときに障害が起きた、それはオープ ン化の一つの大きな問題である」というご指摘もあり、そういった問題を割と日常的に扱 われているのではないかと思うのです。そういうところでご発言いただけると、ありがた いのですが。 （刑部） 日揮の刑部でございます。私どもは今、新先生からご紹介いただきましたよう に、あるときはメーカサイドに立ち、一生懸命エンドユーザに対して説明し、説得するよ うな立場です。それから、あるときはメーカに対して、エンドユーザのわがままを一生懸 命伝える、そういう立場です。今、新先生からキーワードを頂きましたので、まずそれに お答えした後に、ちょっと私のほうで気になっているところをお話しさせていただきたい と思います。 まず、マルチベンダという話なのですが、やはりマルチベンダに関しては、いろいろな 私どもの仕事の中で、いちばん頭の痛いところです。メーカの中には、マルチベンダへの 対応を今後、実施されていくというご発言もありますが、実質的なところは、やはりマル チベンダで、だれかがそれを取りまとめるとなると、主役となるところ以外のベンダのシ ステム、あるいはベンダの機器については、やはりサポートが弱くなってしまう、これは 事実です。 それは、私どものほうも今まで何度か経験しておりますし、国内のみならず、海外も扱 っておりますので、国内で調達したもの、あるいは海外で調達したものが、ぐるっと世界 一周回ってきて、最終的なメーカなり、そういうところまで問い合わせていかなければい けない。それを途中でやっていると、時間がかかってしまうので、しょうがないからダイ レクトにやってしまう。間を飛ばして直接コンタクトしてしまう。そのようなところもあ 38 ります。 ですから、今、メーカから、ベンダからそういうことをやるのだというお話がありまし たが、実際のビジネスとしては、非常に厳しいものがあるのではないかという印象を持っ ております。 （新） そういうことをやるには、やはりそれなりのお金を払ってもらいたいわけですね。 エンジニアリング会社の立場（コスト、エンジニアリングツール） （刑部） もちろんそうです（笑）。ここには多分エンドユーザも、たくさんいらっしゃる と思うのですが、前のほうに座っておられるエンドユーザも含めて、サポートやサービス に対して、お金、対価が伴わないと、勘違いされている皆さんがいらっしゃいます。今、 メーカの立場に立って話をさせていただいています。そういうところは、きちんと対価を 支払うという前提での対応が必要になるかと思います。特に、海外ベンダの場合は絶対に 動きませんので、そのあたりはご理解いただきたいと思っています。 続いて、私のほうで、この会議で気になっていたところ、２∼３点ありますので、述べ させていただきます。このような DCSvsPLC という会議そのものが開催されるということは、 やはりコストだと思うのです。DCS、PLC、両サイドから、それぞれコストはそんなに高く ないのだという発言もありますが、 エンドユーザに対して、きちんと説明しきれていない。 それが最大の原因かと思います。 特に今、リプレースの時期に入りまして、私の立場ですと、あるときはメーカサイドに 立ち、メーカからいろいろな資料を頂いて、エンドユーザに「今、リプレースの状況はこ うなっています」という説明をしに行きますが、やはりそこから出てくる言葉は「高い」 、 特に「DCS は高い」という言葉が第一かと思います。やはりそのあたりが一つのポイント です。 高いという理由の一つは、印象として、「自分たちは余分なものも買っている」 。一つは 機能です。先ほど、いろいろなものがそろっているのは、メリットだというお話もありま したが、使う側からすると、「余分なものにまで金を払って、買うつもりはない」というの が、おそらく本音だと思います。しかも、高い買い物であれば、そういう事情に到達する かと思います。これが一気に安くなれば、例えば「安ければ、何でもそろっていていいよ」 というところにまで落ちてくるのであれば、それはそれで、いろいろ付いていたほうがい 39 いのでしょうけれど、それに到達するほどには、まだコストが至っていないという印象で す。 それから、声の大きなユーザのわがままというのが、おそらく開発費に乗っかって、そ れが DCS 本体の価格にオンされているのではないかという疑心暗鬼が、やはり多くありま す。そういう意味で、コストダウンのアイディアです。ユーザの要求仕様には細かく書い てありますが、一つのアイディア的には、専用のシステムを作るとか、そういうものを機 能分けしてメニューを増やすとか、ほかにもいろいろアイディアがあるかと思いますが、 そのようなものをもっと、新しいものを考えていってほしいなと思っています。 ２点目、やはり気になるのはエンジニアリングのツールです。これは各メーカばらばら というのが現状で、実は日揮も十数年前、DCS に対してシステムのソフトの構築まで手掛 けようということで、グループで対応しようとしていたことがあるのです。やはり、私ど もは一つのメーカだけに絞れませんので、いろいろなメーカのソフト構築をやろうとする と、いろいろなことを勉強しなければいけないのです。それがとてもマンパワー的に対応 できないということがあり、今ではそこまでやっていないのです。 そういう意味では、統一したエンジツール、今日のユーザからは、単にエンジツールと いうことではなく、ソフトの入れ替えをするときに、仕様書レベルからすぐにソフトにま で至るような、道具を開発してほしいということがありました。そういうところまで、私 どもも本来は望みたいところかなと思っています。 そういう意味では、１点目、２点目、このようなものは、どちらかというとメーカ側か らのお仕着せ、押し付けられているなというのが、エンドユーザ側の印象かなと思ってい ます。ですから、コストもそうなのですが、エンドユーザの立場からすれば、やはり押し 付けられているものは要らないよというところがありますので、そのあたりを払拭できる ような対応を、DCS メーカ、あるいは PLC メーカに期待したいと思っています。 （新） ありがとうございます。今のエンジニアリングツールの統一ですが、FA の分野で は、 製造科学技術センターがサポートしている FA オープン推進協議会というコンソーシア ムがあります。この中の一つの専門委員会が、ISO15745 に基づいてエンジニアリングツー ルを統一するという活動を始めています。これは、すべてのデータを XML で表現して、入 出力を合わせるという活動です。今、実証が始まっているところで、まだ実際にできては いないのですが、FA の分野ではそういう活動が既に始まり、PLC とネットワーク、そうい 40 うのに依存しないで一つのツールでできるようなことをしたい。そういうことをご報告さ せていただきます。 今度は西元さんにお聞きしたいのですが、刑部さんがおっしゃったことについて、どう お考えになるか聞かせていただけるとありがたいのです。 それと、二つの会社の部門が一緒になって、これから今まで三菱と東芝がなさっていた こと、両方をサポートしなければいけないというのは、ある意味で、肌の段階でマルチベ ンダをやっているようなところもあるかと思いますが、そういう点も含めてお話しいただ けますか。 ベンダの回答（コスト、エンジニアリングツール） （西元） まず、二つの会社が一緒になったということで、まだ内容的に混乱していると ころもあるのですが、大きな方向性は決めておりまして、それに向かって一丸となって対 応していくということで、そのあたりは社内でもすっきりしていると考えております。 先ほどのコメントでありましたコストの件なのですが、ユーザとベンダ側のコストの認 識が異なっている、余分なものを買わされているというところは、確かにあるかと思いま す。コストの内訳で、コンポーネントで見たとき、ハードウェアについては、私の立場と しては MELSEC を応用したシステムということで、ハードウェアはシーケンサーを採用して、 そこを下げていくということで対応しています。ただ機能的に、先ほど信頼性の話もあり ましたが、従来は信頼性の面でも問題があった。ところが、近年どんどん信頼性も向上し ており、PA の世界でも使える範囲がどんどん広がっていく方向にあると思います。 ソフトウェアのコンポーネントのコストですが、どちらかというと、ソフトウェアです から、メーカサイドの開発費用の回収ができる価格設定というところが根底にあると思い ます。今のソフトウェアのコンポーネントは、いろいろな機能が入り込んだ一体型になっ ておりますので、我々としても、例えば実際にスキャダメーカはそうですが、適用する規 模に応じてコスト設定を変えたり、あるいは、中の機能を一部、取り出して外すことによ って価格設定を変えたりする。そういった形で、必要最小限の機能の場合に安く買える。 そういったところは考えていきたいと思います。 もう一つ、エンジニアリングツールですが、国際標準仕様に準拠していくことで、最終 的には各ベンダのエンジニアリングの環境が、統合される方向に向かっていると考えてい ます。まずは、我々も IEC 61131-3 に準拠という製品を出しております。ただ、オブジェ 41 クトベースで互換というところには、まだ至っておりませんが、目指すところはやはり国 際標準仕様というところで取り組んでいきたいと思います。 （新） ありがとうございました。では、杉浦さんを除いて皆ご発言いただいたと思いま すので、ユーザ要求仕様書をまとめていただいた杉浦さんに、いろいろご意見を伺いたい と思います。よろしくお願いします。 ユーザの立場（自動車飛行機モデル､サポートの方向性､ｴﾝｼﾞﾆｱﾘﾝｸﾞﾂｰﾙ） （杉浦） 森永乳業の杉浦です。昨年はメーカとユーザ両方の立場で話をし、今日はごり ごりのユーザという立場から話をさせていただいたわけです。一つ、内田さんのおっしゃ った、大小モデルで DCS と PLC 計装を見るのではなく、自動車飛行機モデルで考える、こ れは非常にいい考えではないか。大小で考えるのは、どうもそぐわないのではないかとい うのが、私がまず一つ思ったことです。 それから二つ目、オムロンか横河だったか、サポートに関して、担当の技術者を、ソリ ューションパートナーの契約を結べば、自動的に割り当てる、ダイレクトに担当者に電話 できるという仕組みを設けている会社があるという回答を頂きました。これが一つの今の サポートのレベルで、高いレベルを保持するいい方法ではないか。今回どなたも発言され ていないのですが、確かどこかの会社のかたが、それを回答されていたと思います。 次が、モジュール化することによって、DCS の価格が下がるのではないか。これは、SAP という ERP のソフトが、実はこういうことをやっているわけです。業界向けのソリューシ ョンパッケージを提供することによって、従来の３分の１ぐらいの価格で提供しているわ けです。本来、これと同じことを DCS がやるのが、正しいのではないか。医薬品を作ると ころの要求仕様が、一般食品を作るところや、公共をやるところと、同じであるとは到底 思えないわけです。 樋本さんもおっしゃったように、業界によって、トラでありキツネであり、それぞれ違 う要求を持っているはずですから、要求仕様を一本にして大きいものを提供するのは、や はり本来おかしいのではないか。これによって、実は SAP という会社は、ERP の中でトッ プシェア、 アメリカでも大きいマーケットを取ってきたという流れがあります。ですから、 これを考えれば、DCS のメーカもこういう方向にやはり走るべきなのではないかと考えま した。 42 三つ目、日本の DCS メーカは、一社ももうかっていない。当たり前です、規模が小さす ぎます。これでもうかるわけがない。ですから、本来もっといいサポートを、安い値段で 受けることができるわけです。 例えば、日本に DCS メーカは１社しかない。そうすると、Microsoft になってしまうか もしれません。でも、少なくとも、拠点に対して、技術者が出てくる距離というのははる かに短いわけです。そうすれば、コストとしては下がる。本来、日本の DCS メーカは、２ 社ぐらいでいいのかもしれません。 最初の要求仕様の中に、組織体まで考えてほしいと言った理由はそれです。ユーザは安 い値段が欲しい。メーカは、今のは適正コストです。確かに、今の体制でやる限りは、こ の値段は適正か、安すぎるのではないかと思っています。PLC メーカも、サポートレベル が上がっていったら、今の価格では多分できないだろうと思います。 利益があがらないと事業を継続できませんので、適正レベルの価格で技術提供をしてい かなければならない。ですから、DCS メーカ、今回のアンケート結果を見る限りでは皆さ ん、適正価格だと言っているのが、本当に妥当なのかどうか。樋本さんがおっしゃるよう な、事業の要求する価格と合っていないけれど、今のやっていただいている内容からいけ ば、これは適正と考えなければいけないというふうに、非常に優しいかたが多かったので はないかと思いました。 それから、東芝の IO やエミュレーションの機能は、やる必要があるのか。これは声の大 きなユーザの言うことを聞いたのではないか。ですから、これがコスト転嫁されて、ほか の一般ユーザがこの費用を負担するのではないかというおそれを、やはり感じました。 ただし、例えば、Microsoft の Excel や Word を買ったとき、古いバージョンのソフトで も一応読めますね。セーブするときに、古い形でセーブしますか、新しい形でセーブしま すかと聞いてきます。これと同じぐらいのことが、今のハードウェア、パソコンでも、PLC もどんどん機能が上がっていますから、古いものを許容して、エミュレーションとはいわ ず、 その機能を自動的に実行してくれるように、 作ってくれてもいいのではないだろうか。 それが私の感じたところです。 それと、統一ツールの問題に関して、新先生のおっしゃることを、ちょっと否定的に言 うのは心苦しいのですが。 （新） どうぞどうぞ。 43 （杉浦） 実を申しますと、ハードウェアの中、メモリが、ある意味ではラッチやオルタ ネートなど、いろいろあるのです。それで、ツールだけが同じになったからといって、正 しく同じ動きはしてくれません。ですから、本来ツールが一緒になってしまって、同じ動 きをすると思って、同じようにハードウェアをハンドリングすると、大事故を起こす危険 性があります。ですから、ツールを決めるだけではなく、ツール以外の、いわゆるメモリ ハンドリングを含めてすべてきちんとそろえないと、危なくてユーザは使えないだろうと いう感じがします。 （新） ツールを統一して、プラグインに。 （杉浦） はい。それで、私は IEC 61131-3 級の言語は、非常に素材レベルのものだとい う考え方をしており、IEC 61131-3 で生産性など上がるわけがないというのが、基本的な 考え方です。 私どもが今やっているソフトがありまして、オムロンのシーケンサーを使っても三菱の シーケンサーを使っても、そこの中間言語体は全く一緒です。ですから、開発ツール、パ ソコン上でアプリケーションを開発して、データがダウンロードされるのですが、データ の形が全く一緒なのです。 そういう意味では、マルチベンダに持っていくのは IEC 61131-3 レベルではなく、もう 一つ上のレベルで共用すべきではないか。そうすれば、統一ツールでも間違いがない制御 が作れるだろうと思いますし、そこの言語自体を業界向けのパッケージという形で、ある 業界に向いた特殊な言語のパッケージ形式をとる。これは異常処理などのハンドリング方 法が、例えば東京ガスであれば止められないわけです。そういうところに集まらないよう な作りのパッケージを提供しますし、内田さんのところのように、止めたほうがいいとい うところには、止めるパッケージを提供する。そういう形での対応をしていくべきもので はないか。 こういうやり方は、コアの部分は共通で持てますので、そうすればシーケンスの統一、 再利用は非常に進んでいくのではないかと感じた次第です。 （新） ありがとうございます。ちょっと不手際で、オムロンの米倉さんに発言をしてい 44 ただいてなかったので、杉浦さんの話も聞いたうえで、ちょっと話しにくいかもしれませ んが、お願いいたします。 ベンダの立場（IO としてでなく、適材適所で使える PLC） （米倉） オムロンの米倉です。我々はこの事業を６年前に始めるにあたり、最初にPLCに何が欠けて いるのかというのを分析し、商品開発を進めました。そのときに、計装ファンクションと いうものが、PLCはもともとPID命令として一部あったのですが、エンジニアリング性が弱 いという部分で、PAアプリケーションから相当学びまして、まずはそこで使っていただけ るエンジニアリングツールを取り急ぎ作ったのです。またPAアプリケーションプログラム を載せるループエンジンを、既存ＰＬＣにアドオンできる形で開発しました。 もう一つが、やはりIOです。八尾さんもおっしゃったのですが、PLCのアナログIOという のは、元々FAアプリケーションに対応できるように発展させてきたようなアナログIOだっ たのです。やはり計装系のお客様に満足いただけるような、要はDCSのシグナルコンディシ ョナーから、コネクタ・トゥ・コネクタで渡せるような、変換機能も盛り込んだようなプ ロセスIOを開発する必要がありました。八尾さんから、コストが高いのではないかという 発言がありましたが、変換機能をまるごと入れておりますので、やはり若干高いわけです。 今、我々はこれを多点化したり、コストダウン化を図ることに取り組んでおり、年末、来 年と発売いたします。そういう意味で、我々は計装のお客様に満足いただけるプロセスIO をより安く提供していくことで、DCSリプレースでいちばん手間のかかるIOのコネクティン グの問題を、PLC計装として安価に解決できていると認識しています。実際、DCS案件は、 もうかなり受けてきておりますので、そこは安心してお使いいただければと思っています。 信頼性の話で、トータルのシステムをどう考えていくのかは、昨年、三菱化学の馬場様 が、黒崎事業所の事例を説明されました。私どものPLC計装を３年間ぐらいずっと評価いた だいて、そのような結論を出されたのですが、７割ぐらいのシステムは、二重化しなくて も通常のPLC計装システムでいけるというのを発表されたわけです。 今日の発表でもあったかと思うのですが、やはりリスクマネジメントですね。全部のシ ステム本当に二重化する必要があるのか。そういうものが部分的であるならば、使えると ころはシングルでやるとか、IOのオンライン脱着だけができればいいとか、いろいろ選択 できる中で、採用いただける形になればいいのではないかと思っております。 45 そういう意味では、我々はCPUの二重化、電源の二重化、ネットワークの二重化までは対 応しましたが、IOに関してはコストパフォーマンスを追求するという部分で、オンライン で交換できるコンセプトでPLCの安さは維持するという考えで発売していますし、それがお 客様に受け入れられているのではないかと思っております。 また、PLCメーカとしては、PAのアプリケーションだけでビジネスモデルを回すのは、や はり大変です。FAのユーザで大量にPLCを使っていただいているおかげで、PLCとして安く ハード提供できるができるのが強みと認識しております。 冒頭に、新先生が「PAからFAが学ぶこと」とおっしゃったのですが、私はPAで学んだこ とを、FAや、PAの中でも組み込み系でPLCを数量的に必要とするアプリケーションに、どれ だけ使っていただけるかに取り組んでおりまして、我々のシステムの半分ぐらいは機器組 み込みで採用いただいております。そういうところでの数量確保をしながら、コストは常 に下げつづけることができるようなビジネスモデルを、我々メーカとしてはやっていきた いと思っております。 新先生の閉め （新） ありがとうございました。最初の基調講演で、PA から学ぶ、FA から学ぶという話 をさせていただきました。 全体の印象は、やはり今 PLC 側が DCS を攻めていることもあり、 PLC メーカは DCS をよく研究されていると思います。ユーザからは、PLC は、まだ DCS 並み になっていない、まだ勉強が足りないということはあると思いますが、熱意は非常に感じ るところがあります。 それに対して、DCS 側が PLC をまだ十分研究しつくしていない、ただ攻められているだ けで、守るのに精いっぱいだということです。DCS の信頼性を保持したまま、また、サポ ート体制を保持したまま、PLC のものを飲み込むようなつもりで、逆に攻めるようなつも りでやられるというのも、一つの方向かなという気がいたします。 同時に、杉浦さんもご指摘になりましたが、樋本さんが口火を切られた、ユーザ側は何 を望んでいるのか、低コスト信頼性といっているけれども、どういうトレードオフで臨ん でいるのか。それが難しかったら、どの部分は絶対信頼性が必要で、どの部分は低コスト 化が可能か。それは今、米倉さんがご紹介してくださった三菱化学の馬場さんから、去年、 PLC、DCS をどう使い分けるかというガイドラインを報告していただきました。それになら えば、７割ぐらいは PLC で十分である。それから、DCS でなければいけないところは、ど 46 うしても DCS でなければいけない、そういうお話だったと思います。そういうところをち ゃんと厳しく色分けしたうえで、システム構築やリニューアルを考えなければいけない。 そして、トータルのコストとして、信頼性と低価格を両立させるという方向が正しいので はないかという印象を受けました。 そろそろ時間ですので、このパネルディスカッションを含めた全体のセッションのまと めは、宮川チェアマンにお願いしておりますので、宮川チェアマンにマイクをお返しした いと思います。よろしくお願いいたします。 パネラーの皆様、どうもありがとうございました。 まとめに代えて（ユーザ､ｴﾝｼﾞﾆｱﾘﾝｸﾞ会社及びベンダの制御ｼｽﾃﾑへの要求、試案） （宮川） どうもありがとうございました。まとめに入らなければいけないのですが、こ れをまとめるのは至難の業で、とてもできないと思っているのですが、先に進む前に、私 としてできることは何かというと、今、ユーザサイドからのご発言がベースで、話として は進んできたわけです。 刑部さんから、エンジニアリング会社としての発言も出たのですが、その辺を踏まえ、 最終的に将来の方向性はどうしていったらいいのかを考え、私が一つ私案を提示します。 ですから、それに対して各メーカなり、受けてくれなくてもいいのですが、何らかの方向 性を示す。せっかくこの会議に出ていただいたのですから、その方向性がいいかどうかは 別にして、提示したものに対して、どう考え、自分だったらどうするかを発言していただ ければと思います。 単純に私のほうで考えている内容を、簡単に説明させていただきます。今日は、制御シ ステムに対して、ユーザサイドから考えると、どのように進むかという話になったと思い ます。ただ、制御システムをうまく運用しようとすると、ユーザだけでできるわけではな く、システムインテグレータとエンジニアリング会社、ベンダ、各メーカ、そういうかた がたも一緒になって作っているという形になると思うのです。 ７つの要求というのが、ユーザから出てきた形になるのですが、エンジニアリング会社 やベンダはどのように考えているか。少なくともエンジニアリング会社は、アンケートに もあって意を強くしており、さらに刑部さんからも同じような話が出てきたのです。ユー ザの前に常に私どもはさらされ、ユーザから何を言われるかというと、安くしろという話 で、特にこのごろはそれしか言われない。 47 そういう中で、エンジニアリング会社として、どのような対応を期待したいか。それに 関していうと、一つ目、やはり安価なシステムという、耳にたこだと思いますが、そのよ うな状況です。 もう一つ、エンジニアリング会社からいうと、変更は日常茶飯事で、変更をエンジニア リング会社が自分たちで組まないとすると、それはすべてベンダに対して、こういう変更 が出たから安く変更してくれということを、常に言っていかなければいけない。そういう ことがあるので、変更が容易であることが一つの条件になってきます。 それと、再利用という問題なのですが、私どもがいつも使う DCS や PLC のベンダは１社 に限っているわけではなく、お客様のご要望によって、いろいろなメーカとつきあわなけ ればいけない。それに対して、準備をどうするかということになると、必ずしもそういう 準備ができるような状況ではないというのが現状です。エンジニアリング会社の立場とし ては、そのようなことが言えます。 あとはベンダ、制御システムを構築しているところですが、そこはどう考えているか。 これは想像で、アンケート結果などを見て感じたのですが、要は、ベンダとしては利益重 視という形になると思います。どうやって利益を出すかという話になると、一件一件の利 幅を大きくする。そうでなかったら手数をかけない。あるいは、量が出ること、このよう なことを満足しなければ、DCS メーカ、PLC メーカも、なかなかうまく回らない、利益が出 ないという状況になる。 それで、どのようにしたらいいかということで、メーカからの回答にもありましたよう に、ベンダとしていちばん強く出ていたところは、１番目に書いてある項目ですが、強み を生かしたベースの差別化です。例えば、東芝三菱の世界はシーケンサーという強みを持 っている。そのシェアを武器に、どのように利幅を持っていこうかということで、PLAUDIA など先ほどのシステムが出てきていますが、そういうことをやっています。 もう一つ、手数をかけないようにするということですが、どこのメーカもやっているこ となのかどうかは分かりませんが、このごろ、ソフトを組む部隊を全部子会社にして、親 会社としては、なるべくソフトを中で作らないで、子会社に持っていくということがある と思うのです。それはトータルとしては、どうなるか分からないのですが、制御システム を作っているメーカとしては、手数を省くという方向にだいぶなるのではないか。 ３番目にやっていることは、量を出すということです。メーカによっては、海外展開し て、いろいろ仕事をされているところもあると思うのです。先ほど、国内では２社しか生 48 き残れないのではないかという話もあったのですが、どうにかして量を出すことをしなけ ればいけない。それが現状ではないかと思います。 こういう状況で、私がここで提案というのも何ですが、僭越ながら話をさせていただき たいと思います。私のイメージですが、三者丸く収まればいいのですが、なかなかそうは いかないので、どういうことをしたらいいか。エンジニアリング会社側からいえば、どこ のメーカのハードもソフトも、要は一つの統一した環境で扱いたい。そういうところがベ ースにはなっているのですが、そうすることにより、ユーザやベンダに対してどういうメ リットが出てくるか。 基本的には、このような手続きをすることによって、少なくともエンジニアリング会社 のツールとしては、利益が出るという言い方はよくないのですが、先ほどの三つの期待に 関しては、だいぶ近づくということです。ユーザに対しても、エンジニアリング会社なり システムインテグレータが、前面に立ってできるものですから、ある意味でお客様に対し てメリットを出せるのではないか。 それはどういうことをするかというと、単純には、DCS は閉じた世界でツールがある。 そこに関して、エンジニアリングツールの部分、エンジニアリング環境だけは、開放して ほしい。各メーカが開放することにより、CASE ツールとありますが、設計の段階から実装 まで含めてできるような一つのツールを作り、それをもって運用していくということです。 こういうことをすることにより、ベンダはどのようにならなくてはいけないかというこ とになると、基本的には、ハードウェアに対する特化と、高度の制御に対する特化という 形になる。なぜそうなるかというと、いろいろなソフトを使っていると、ハードウェアの 特殊性がどうしても残る、一般的な部分と特殊な部分がどうしても残ってしまうと思うの です。そこで今、流れとして出しているのは、あくまでも一般的にできるようなことは全 部そのツールで、特殊なことや高度なことは、こういうツールで全部取り込むのは現実的 に不可能だと思いますので、それは別の考え方をする。このようなことで、ある意味で少 しベンダに対しても、メリットが出るのではないか。エンジニアリング会社にとっては、 もっとメリットが出ることになるかもしれませんが、お客様の前に行って、コストも多少 安くなってくる。 なぜ安くできるかということになると、一つの手としては、エンジニアリング会社とし ても、ソフトの資産を蓄積していくことができることになります。これはシステムインテ グレータも同じだと思いますが、どういうメーカを指定されても、それなりのソフト資産 49 があれば、それを何回か使っていくことによって、かなりこなれたものになる。信頼性も 上がりますし、コストも下げられる。そういうものを、お客様に提供できる環境が残ると いう可能性が出てくるわけです。 三者が全部丸く収まるかどうかは分からないのですが、こういうことを実現することに よって、少し今の環境を打破できるのではないか。これが私の考えた方向性で、今の不況 に対する回答になるのですが、あくまでも私案ですから、各メーカが、ユーザでもいいで すが、賛成でも反対でも、私はこう考えるというのを一人一人に発表していただき、皆の 参考になればと考えております。 それで、いろいろなコメントが出たのですが、それに対して、答えられる範囲でいいの ですが、どういう形で今日の議論に対して方向性を出せるかを、一言ずつ話していただけ ませんか。布野さんから、よろしいでしょうか。 パネラーの回答、意見（試案「エンジニアリングツールに関して」） （布野） 日立の布野です。実は、我々もこういうことを考えておりまして、理由は二つ あります。一つは、先ほどアップグレードパスという話をしたのですが、やはりオブジェ クト互換というのは、 捨てられないということです。 杉浦さんに言うと怒られそうですが、 過去の財産を持ちながら、よりお客様に分かりやすい形にするには、こういう形で何か中 間にかますしかないかなと思って、いろいろ検討しているところです。そういうところに ユーザの共通認識として、こう書けばちゃんとものが動くんだよということが提示されれ ば、我々としては非常にやりやすいと思っていまして、ぜひ進められたらなと考えており ます。 もう一つ、できそうな裏づけとして、制御の低いレベルの書き方は、メーカによって全 部違うのですが、もう少し上のレベルになると、例えば最近、運転支援というのがけっこ うはやっているのです。各社で、ほとんど同じような表現になっているのではないか。や はりユーザから言われたのですが、記述のレベルが上がってくると、ほとんど統一的にだ れでも分かるような書き方ができるのではないか、というお話もありました。こういうこ とが、現実にできるのではないかと考えております。 （大庭） 東芝の大庭です。この答えの前に、先ほどエミュレータについて、DCS、PLC と いうのではなく、供給するメーカとして、継続することが非常に大事だと思っています。 50 ですから、機種が変わってもどんなことがあっても、とにかく継続して供給しつづけるの だという信念の下に、そうするためにいちばん開発費がかからなくてやれることは何かを 検討したうえで、エミュレーションという技術でやろうということですので、ご理解くだ さい。 それから、CASE ツールですが、基本的な、技術的にどうこうという話もなくて、あとは 方針、あるメーカ間である方針が立ってという話であれば、もしかしたら進む話かもしれ ません。その辺の土壌づくりからいけば、悪い話ではないかなと今のところは思っていま す。 （宮川） ほかに解決策、例えば今日出た議論において、東芝としてどのように解決する か。別の解決策があれば、提示していただければいいのですが。 （大庭） 今はちょっとありません。 （宮川） はい。中島さん。 （中島） 基本的にこの着眼点は、我々が今取り組んでいるところと同じであるという認 識を持っています。我々のビジネスの大半は置き換えていくとか、既存をうまく利用して いく、資産を生かす。そういう意味において、ソフトウェアの特にエンジニアリングのと ころ、ソフトウェアの互換性をどう持つかは、極めて大きな問題だと思っています。特に エンジニアリングツールという意味でいうと、いちばんここの取り組みが、最終的にはお 客様のコスト要求に応える意味でも、ハードウェアとともに非常に大事なファクターだと いう認識は、言うまでもないことです。 その取り組みの一つとして、 言語のレベルではなく、もう少し抽象度の高い表現レベル、 仕様書など、我々もそういう開発を終えて、今それを展開しているという状況です。ここ で提案されているように、それをもう少し共有できるような、うまく全体のコンセンサス を得られるということが当然、前提なのです。多分、分野やアプリケーションを、まず絞 り込むことからやっていくだろうと思うのですが、提案されたようなことは大いに可能性 があり、我々メーカとしてもありがたい話ではないかという印象を持っています。 51 （白井） 横河電機の白井です。今までオープン化というのが、通信のオープン化、OPC や、ファウンデーション・フィールドバスなど、時々変化するデータをお互いの交換する 手段のオープン化でした。これからやはり、例えばエンジニアリングデータのように、そ れぞれのシステムが持つスタティックな情報のオープン化が必要だと感じております。 そのとき、特にこれは OPC やフィールドバスでもそうでしたが、インターオペラビリテ ィを保証できるレベルまでの互換性を作ることが重要です。決してインターチェンジャビ リティを狙わない、完全に一緒にしてしまわないこと。これをしてしまいますと、確かに 使われる方には一つのシステムみたいに見えますから非常に便利なのですが、逆に、メー カ側の論理からいうと、開発の意欲がなくなってしまうのです。 やはり、差別化すべきところを差別化できるようにして、それで強みをどんどん持ち込 めるような、そのうえでのオープン化が必要だと思うのです。ですから、そういう意味で、 ベンダ固有のハードウェアは、高度制御といった付加価値を付けられるところについては 残っていくだろうけれども、コモデティになってしまっているような部分については、で きるだけ共通にしていこう。そういう動きが非常に大事だと思っております。 それから、この場は計装制御技術会議ですから、国内の中で考えていますが、オープン 化を議論するときにぜひ考えていかなければいけないこととして、国際的な共通化をして いくことがあります。国際的なオープン化していかないと、これから通用しないと思いま す。 そのときにすごく大事だと思いますのが、ユーザ側の声なのです。今まで、いろいろな 国際的な標準化団体、あるいはコンソーシアムを見ていましても、やはりユーザの声が、 最後はいちばん強く出てきます。ですから、日本のユーザにもこういう国際標準化をする ときに、できるだけ声を大きくあげていただきたいと思っております。 （杉浦） 東芝の大庭さんの先ほどの件なのですが、私が言いたかったのは、日立の布野 さんが言われたのは、アッパーコンパティブルのパスを用意されて作られている。それに 対して、大庭さんのは、一品生産で作ったような感じの発言だったと認識しているわけで す。ですから、一品生産のコストはあくまでも一品生産で、カスタマーに負担させるべき ものではないかというのが、私の言った趣旨です。 中島さんの言われている抽象化と業界向けパッケージというのは、この CASE ツールを設 ける場合、絶対重要なポイントだと思います。それが、白井さんの言われる国際化や、メ 52 ーカの意欲をそがないという意味で、非常に重要だろうと考えています。 それで、IEC 61131-3 が本当にターゲットになるのかという意味からいくと、これは非 常に否定的に見るべきだろうという考え方です。ですから、これは脇道のほうの CASE ツー ルであって、メインのルートは、やはりユーザが直感的に理解できるような形でものを生 成できる、製造システムを構築できる、異常処理が作れる。やはりそういうツールを、CASE ツールとして準備すべきではないか。ですから、業界向けで抽象化するというのが、非常 に重要なポイントなのではないかと思います。 （あとで、大庭さんより杉浦さんにエミュレーションは一品生産ではなく、 標準的なリ ニューアル提案であることを説明） （樋本） ユーザとして、宮川チェアマンのおっしゃる話は理解できるのですが、ちょっ と違う視点で、もっとマクロに広げますと、ここの中に、日本の産業が今、活性化が盛ん にいわれるのですが、産官学の官の政治のところを、逆にリーダーシップまでされて、日 本の産業を支えるシステム産業として、どのようにこういうものをされるか。それはなぜ 言っているのか。こういう会は、リーダーシップが大事なものですから、官がいいとは言 いませんが、日本が今、いろいろな規制があったり、いろいろなことがあって、既成産業 のためのシステム産業であったりすると困るので、官も視野に入れていただければいいと 思うのです。 さらに、このケースでは二極化する話があって、メーカ独自の競争による差別化は、逆 に萎える可能性があるのです。一方では、オープンになっていく環境で、応用でエンジニ アリング会社をはじめ、我々ユーザが受ける恩恵で、物を作る産業界としてはメリットが あるかもしれないということで、そこのバランスとタイミングが難しいかなというのが、 私の感想です。 （内田） お考えは非常に賛同いたします。ユーザから見れば、CASE ツールがあって、一 つの教育を受ければ、扱えるという話にはなると思うのです。しかし、これがあまりにも 大きなものになりすぎると、あまりにも汎用的になりすぎると、反対に使いにくいかなと いうところです。食品業界など、ある程度、分野のターゲットを決めて、この分野にはこ ういう CASE ツールという形で分割してやっていただけると、非常に使いやすいものになる 53 のではないかと思いました。 （岩崎） 山武の岩崎でございます。この構想そのものを、実際にいろいろ試そうという 機会は今までもありました。我々DCS のベンダと言いながら、最初にやはりエンジニアリ ングの環境をどうやって整えるかというところに着手してまいりました。例えば、その中 にどのように PLC のロジックをカプセル化するツールも含めて提供できるかなどのトライ アルです。当時は杉浦さんにも、少し補強していただいたところもあります。 そういう意味合いでは、トライをするということは、多分、我々だけではなく、ベンダ、 ユーザのかたがた、やられているのではないか。ただ、それがうまくいかないというのは、 どういうことか。今後どうすればいいのか。この手法は今、ちょっと浮かばないところが あります。 産官学という樋本さんのご提案ももっともだと思います。それから国際規格というとこ ろで、白井さんと、ファンクションブロックなどのときには一緒に、IEC のワーキンググ ループに出ました。そういう経験も少し思い出しながらやっていくと、そういった中での 日本のリーダーシップという面で、どれくらいのことが、こういう構想を掲げてやってい くのに必要だろうか。少し具体的に考えてみて、思い浮かべると、10 年くらいの私の歴史 がむだに終わってしまったかなという、残念な思いも少しあります。 ただ、これは基本的に CASE ツールとは書いてありますが、これが成り立つのは多分、日 本国内で全部やるのだというコンセンサスがあって始めてできるのではと思います。そし て製造業のかたがたも、国内にとどまって、すべてこの競争力で生きていくという大前提 があるとすると、一刻も早く手を着けるべき内容であると改めて思います。 ただ、具体的な手法は、なかなか今のところ浮かばないという部分がありますので、我々 としては、こういった動きをしながら、少しでも助けになるような環境を、ある部分から でも提供していくという努力をさせていただいて、その成果で、ここにいるかたがたに評 価していただけるような成果事例を出していきたいと思った次第です。 （西元） 東芝三菱電機の西元です。CASE ツールということで、我々も、メーカ独自のこ ういうレベルのツールというのは、以前に開発したことはあるのですが、メーカの中で閉 じた形にとどまっていた。こういう考え方は、確かに理想に向かった動きということで、 ぜひとも取り組んでいきたい。 54 岩崎さんのお話にもあったと思うのですが、具体的にどういう形で、だれが音頭をとっ てまとめ上げていくかというところが、これからの課題だと思います。ただ、我々もこの 動きに向かって、積極的に取り組んでいきたいと考えております。 （八尾） 三菱電機の八尾です。昨年も、エンジニアリング環境の統合化というところに つきましては、いろいろ議論され、少なくとも PLC ベンダの中でさえ、IEC6131-3 に一応 対応していながら全然、中間コードでさえ互換性がないという、いろいろご指摘がありま した。IEC61131-3 は、一つの手段だと思うのです。 それで、去年と同じようなことを言うかもしれませんが、ベンダによるエンジ環境の開 放や統一化というところで、本当は言語だけではなく、マンマシンを作る環境も含めてと いうことにはなるのでしょう。けれども、まずは言語だけでも、61131-3 を、これだけ世 界的にいろいろなメーカ、ベンダがツールを出している以上、一つ、IEC 61131-3 の世界 で中間コードあたりで（先ほど、XML や ISO のほうで規格化が進みつつあるというお話が ありましたが） 、まずは中間コードレベルで統一化する。 あと、ベンダとしては何で稼ぐのかというところは、高度制御の部分やベンダが持って いるノウハウを、例えばファンクションブロック化するとか。そういったところで何か著 作権を持たせたようなファンクションブロックを作り、そこで商売していく。手っ取り早 くは、そういうところを、海外も巻き込んで何かできるのではないか。 実際、海外に行きますと、特にモーション制御、駆動系の制御の場合、既にファンクシ ョンブロックの、かなり中間コードまで含めた標準化・統一化がどうも進行しているよう です。計装、PAS、FA の世界も、それにぜひともついていかなければいけないのではない かと思います。 （米倉） オムロンの米倉です。まさにこれは私どものビジネスモデルそのものです。ソリューショ ンパートナー様でのパッケージ商品とか、CASE ツールであったり、上位のアプリケーショ ンに対しては、常に我々はオープンで、開放しながら接続性を図っていくスタンスで取り 組んでおります。積極的に、こういう動きに対して協力していきたいと思っています。 （安田） ユーザの立場で言わせていただきますと、選択肢が増えるということで大歓迎 55 です。併せて、例えば DCS や PLC 計装、そういう意味では、その世界でクローズになって いる部分を、もっとオープンにしていただいて、上のツールとハードを自由に組み立てら れるような仕様になれば、さらにいいかと思います。 （高野） ２点だけコメントさせていただきたいと思います。ソフトウェアの生産性とい うのは非常に悪く、制御の分野だけではなく、過去、UNIX が出てからずっと 30 年ぐらい たってもまだまだ悪いわけです。その中で、このテーマは非常にロングスパンのテーマだ ろうなと思います。 まず、ぜひお願いしたいのは、例えば、タグなど基本的なものの情報交換ができるよう にするなどのベーシックなところの検討からだろうと思います。これは多分、製造業の XML 推進協議会だとか、その辺が担っていかなければいけないと思います。 もう一つコメントしたいのは、ぜひ DCS の開発方式やコンセプト、その辺のパラダイム チェンジを考えていただきたい。これはどういうことかというと、今までの日本型という のはインテグラルクローズドなので、すり合わせの世界です。これをぜひモジュラーオー プンに持っていく。そういうことで、特にソフトウェア、杉浦さんもコメントされました が、ばらばらにして組み立てられるようなソフトウェアが、制御の世界ではできるのでは ないかと思っています。そういったことで、ユーザの要求に答えていただく。そんなこと を、ぜひ考えていただきたいと思います。 （服部） お話を伺っていまして、このような CASE ツールなりがあれば、かなりメリット としては出てくるかなと思っております。たまたま、ガス業界ですとか、シンプルなプロ セスが非常に多い業種にとっては、基本的な共通化されたツールだけ使えば、ほとんどの 部分が実現できると考えられますので、ソフトウェアに関しては大歓迎です。 一方、ハードウェアに関しては、一部のプラントに関しては、若干ガードが固くなる方 向になる。その分が特殊化されて、結果的には割高になるということになるかもしれませ んが、トータルとして安くなれば、いい方向に行くのではないかと考えております。 （澤近） 宮川さんのほうで準備されたスライドについて、開放のところなのですが、基 本的に、私どものシステムはオープンにしているということで、インターフェースの部分 を XML であったり、Microsoft の技術、COM の技術であったり、そういう形でオープン化を 56 図っているといった対応になっています。 コメントを幾つかさせていただくと、まず、IEC 61131-3 については、杉浦さんからコ メントがあり、まず使い物にならないということでしたが、逆に IEC 61131-3 をサポート していないような PLC は、PLC ではないと言ってもいいのではないか。それぐらいの最小 公倍数的なお話ですので、逆に「本当にそれ（IEC 61131-3）だけで満足しますか？」と、 ユーザに質問したいというところになります。逆にそれを拡張しようとすると、各社その 辺から（実装上の）個性が出てきて、結果的には共有の資産という形にはならないのでは ないかと考えます。 オープン化の方向としては、S95 や S88、それに XML での標準インターフェースを加えた ような形のものや、本命としては OPC やその辺の技術がある。OPC も拡張を続けて、XML を取り入れたり、必ずしも、Microsoft のプラットフォームに依存しないような形にもな ってきましたので、これは非常にいい傾向ではないかと考えています。 東芝に対するコメントがいろいろありましたが、 （お客様の試算を大切にするという）基 本的なベンダの姿勢としては非常に尊敬に値すると思います。方法論的には、いろいろあ ると思うのですが、逆にそういった姿勢が、昔の I/O が共有できるとか、新しいシステム でも使えるとかということに対して、皆さんがびっくりされるということに、逆にびっく りするような状況です。私どもは、30 年ぐらい前に提供した I/O の商品も、いまだにサポ ートしていますし、20 年ぐらい前に出ましたリモート I/O の通信プロトコルも、いまだに サポートしています。先ほど紹介させていただいた最新のコントローラで、そういったも のの制御ができます。 それから、産官学共同で何かをやろうという、コンセプトは非常にりっぱなのですが、 結局、また IEC 61131-3 と同じような、最小公倍数的な話になるだろう。その辺、日本で の取り組みとして、FL-Net などの成果も出ているのですが、ただ、性能面でいうと、本当 に最大公約数をねらったものかなと。結果的には最小公倍数で、逆に、採用すると性能が 落ちるといったことにならないか。そういうところがやはり気になるところで、オープン 化の技術とプロプライアトリー（独自技術）でやるところの兼ね合いで、バランスをとる ところが、 （つまり）仲間を引き入れなければいけないところはオープンにして、 （それに 対して）独自の技術で優位性を保つところはクローズにする。その辺の兼ね合いが、ベン ダとして判断していかなければいけないところではないかと思っています。 57 （刑部） 私ども日揮は、やはりエンジニアリング会社の立場ですので、同じエンジニア リング会社の立場である、東洋エンジニアリングがまとめていただいたのは、先ほど私が 途中でコメントさせていただいたもの、それを一つ整理していただいたかなという気がし ています。 こういうアイディア、やはり賛成なのですが、一つ、こういう CASE ツールというものを 開発するに当たり、２∼３点コメントさせていただきます。一つは、やはり何といっても ユーザ、 エンドユーザも含め、エンジニアリング会社もシステムエンジニアリング会社も、 システムインテグレータも含めてユーザなのですが、ユーザが使いやすいものを用意する ということが、いちばん重要ではないか。 先ほど、トヨタの高野さんから、モジュラーオープンという言葉が出ました。これから のツールそのものは、今までのツールの延長線上にあっていいかということについては、 もう一度議論をして、考え直す必要があるのではないかなと思います。 ２点目ですが、こういうものを用意することによって、私の立場でいちばん心配します のは、逆にコストアップにならないようにする。こういう開発をしたということが、どこ かに潜り込んで、コストのプラスの要因になっていないよねというところを、いちばん気 にします。本来安く提供するためのアイディアですので、そういうところが逆にならない ようにというところを、お願いしたいのです。 ３点目は、逆にちょっと問いかけというか、もう一度、問題提起みたいな形になってし まうのです。今日の議論もそうなのですが、PLC の話というのは、やはり今、DCS の後追い を前提とした議論になっていると思うのですが、本当にそれでいいのか。DCS は DCS とし て、ある程度熟したシステムになってきているのかもしれません。PLC 計装はこれからと いうことで、単に DCS を追っかけるという姿勢でいいのか。そういうことをもう一度、メ ーカに問いかけたいと思います。ありがとうございました。 （宮川） ありがとうございました。手短に１点だけ言わせていただきますと、これの作 り方なのですが、DCS 側や PLC 側が、全部これを開放していただいて、開放した状態で、 だれでもいいのですが、手を挙げていただいて、何社でもいいのですが、そういうところ がこういう CASE ツールなり、オープンな環境で何か作っていただく。その中で切磋琢磨し 58 ていただいて、いいものを作っていけばというイメージで私はこれを説明したのです。ち ょっと説明が足りなかったかもしれませんが、そういうイメージです。 最後に新先生、お願いします。 （新） 宮川チェアマン、ありがとうございました。PLC 側では MESX という形で、こうい うツールの開発を始めております。ベンダの中には、FA 部門の人たちはみんな参加してい ますので、そこに PA 部門の人たちも参加していただければよろしいわけです。そういった 意味で、会社の中で、まだ FA 部門と PA 部門があるのがおかしいというのが、ここの結論 ではないかと思っています。 それから、日本の業界団体が、やはり FA 部門と PA 部門とに分かれているというのは非 常に大きい問題です。国際標準化も、例えば FA 部門は製造科学技術センター、IEC の PA 部門に関しては JEMIMA というふうに分かれています。ですから、こういうことをやるには、 JEMIMA と MSTC を一緒にする、国際計測展と SCF を一緒にすることも、考えないといけま せん。FA 側はもう開放に向かってどんどん進めますので、JEMIMA のほうでもお考えいただ くと、樋本さんのおっしゃった産学官ということが実現できると思います。 （宮川） どうもありがとうございました。 最後にもう一言だけ言わせていただきますと、 私が出した試案は、あくまでも議論のたたき台にしようとしたのですが、ちょっと間延び した形になってしまいました。新先生がうまくやってくださったパネルディスカッション の結果は、今度、ホームページを作ってそこにしっかり書きます。それが皆さんの何かの お役に立てばと思っておりますので、よろしくお願いします。 時間も過ぎておりますので、この辺で終了させていただきます。長い間、ご清聴どうも ありがとうございました。 59
© Copyright 2024 Paperzz
