第 36 回 2005 計装制御技術会議セッション 3「DCS、PLC 計装ベスト

第 36 回 2005 計装制御技術会議
セッション 3「DCS、PLC 計装ベストミックス
∼ケーススタディによるバーチャルコンペ∼」
日時：2005 年 11 月 18 日(金)
10：00∼17：00
会場：東京・港区・三田 NK ホール
パネルディスカッション
目次
（別紙 1：セッション概要）････････････････････････････････････････････ 1
司会、パネラー･････････････････････････････････････････････････････ 2
1.
PLC ベンダコメント････････････････････････････････････････････････ 3
2.
信頼性・保守･････････････････････････････････････････････････････ 8
3.
ライフサイクルでの保障、継承性････････････････････････････････････ 19
4.
情報セキュリティ･････････････････････････････････････････････････ 28
5.
WindousHＭＩ･････････････････････････････････････････････････････ 37
6.
リプレース･･･････････････････････････････････････････････････････ 44
7.
ユーザーコメントまとめ･･･････････････････････････････････････････ 50
0
計装制御技術会議 S3
DCS、PLC 計装についてのユーザ要求仕様の作成、ならびにベンダ回答によるセッションは今回で３回目と
なります。今回は、本会議参加の各ユーザの次期更新計画により役立つように、ユーザ要求仕様は「信頼性」
「保守対応」
「継承性」等の視点から、下記の二つのケースを想定しました。
1. 高信頼システムのケース（※抜粋:信頼性）
① 使用期間中の全体システムダウンは許容しない。
② 部分的なシステムダウンは極力発生しないような、高い信頼性のシステム（必ずしも２重化システ
ムである必要は無い）
。
２.
標準廉価システムのケース（※抜粋:信頼性）
① 使用期間中のシステムダウンは許容する。
② 全システム停止時の MTTR は８時間以内。
上記の二つのケースについて、各ベンダより３年後に稼動（更新）するプラントシステムを念頭に、前回、
前々回のユーザ要求を踏まえた上で、ユーザ要求（本仕様）に対してのシステムを事前に提案いただきます。
本セッションでは、各ベンダからの提案を、機能面の特長を中心にベンチマークできる形に整理し、ユー
ザが自社の要求に合う３年後のシステムを検討できるように、講演・解説とユーザ・ベンダのパネルディス
カッションをとおして情報提供します。
（高野正利）
1
計装制御技術会議 S3
2005 計装制御技術会議∼計装制御がもたらすユーザ利益∼
セッション３「ＤＣＳ、ＰＬＣ計装
●日
時：
ベストミックス∼ケーススタディによるバーチャルコンペ∼」
2005 年 11 月 18 日（金）
●場所：
東京・港区・三田ＮＮホール
◆４．パネルディスカッション「ＤＣＳ、ＰＬＣ計装ベストミックス」
司
会：新
誠一（東京大学大学院
情報理工学系研究科
システム情報学専攻
助教授）
〈ユーザ懇談会〉
Ｐ：高野
正利（トヨタ自動車（株）プラントエンジニアリング部企画室
第１システムグループ
Ｐ：梶原
康（
（株）カネカ
グループ長）
生産技術本部
エンジニアリング企画グループ基幹技師）
Ｐ：服部篤彦（東京ガス（株）エネルギー生産部生産エンジニアリンググループ基盤技術チーム
Ｐ：今任
邦治（三菱化学エンジニアリング（株）技術本部システム設計部
主幹）
次長
制御技術グループマネージャー兼ソリューションセンターＳＩ事業グループ次長）
Ｐ：杉浦
彰俊（ジャパンバッチフォーラム代表）
Ｐ：千田
総雄（新日本石油（株）
）
Ｐ：西條
和彦（ライオン（株）
生産本部
生産技術部
主任部員）
〈ベンダ〉
Ｐ：奥住
Ｐ：中川
康（富士電機システムズ（株）機器本部
雅造（
（株）ノーケン
制御統括部
システムエンジニアリング部
電力・社会システム社
営業企画部
取締役
ゼネラルマネージャ）
Ｐ：大庭
章（（株）東芝
Ｐ：多比良
誠（日立那珂エレクトロニクス（株）計測制御システム設計部
システム開発グループ
Ｐ：岩崎
雅人（
（株）山武
部長）
府中電力・社会システム工場計測制御機器部
主幹）
総括主任技師）
アドバンスオートメーションカンパニー
ソリューションマーケティング部
部長）
Ｐ：中原正俊（横河電機（株）ＩＡ事業部システム事業センターＰＡソリューションＰＭＫ部部長）
Ｐ：浪江
正樹（オムロン（株）アナログコントローラ事業部
Ｐ：廣田
喜胤（三菱電機（株）名古屋製作所
商品開発部
専門職技師）
ＦＡシステム部メルセックテクニカルセンター専任）
2
計装制御技術会議 S3
（高野）それでは、パネルディスカッションに移らせていただきます。最初に私から２点コメントをさせ
ていただこうと思います。
今回、ＰＬＣベンダのかたにシステム提案をいただけませんでした。システム全体のスペックということ
で、今回の要求仕様書ができており、コンポーネント単位での提案はなかなか難しかったと考えます。ユー
ザ懇談会としても、もう少しＰＬＣとＤＣＳをいろいろな意味で使い分けるような、スペックを考えていか
なければいけないと思っています。これはまた、次年度以降のユーザ懇談会側のスペックの改善課題とさせ
ていただきたいと思っております。
あともう１点、20 年の稼働というのは、そもそも要求が無理なのではないかというご意見を頂いておりま
す。これはいろいろな見方があると思います。
まず一つは、ユーザの気持ちとしては、生産システムも含めてということですが、トータルでリスク管理
したうえで、生産の形態を 20 年止めないようにして運転していきたい。そういうことが一つ根底にはありま
すので、午前中に山武さんからもご提案いただきましたが、制御システムだけではなく、生産システム全体
として見た場合に、いかに止めないように生産供給をお客様に対してしていくか。これを念頭に考えていま
すので、これはベンダのかただけではなくて、ユーザも、そこでどこをリスクとして取るのかも含めながら、
議論していく必要があると考えています。
パネルディスカッションの司会は東京大学の新先生です。よろしくお願いします。
（新）今、ＰＬＣが応募しにくかった理由を、仕様書を作った側からのご意見を伺いましたが、受けた側
からのご意見を伺うことで、パネルディスカッションを始めたいと思います。
パネルディスカッションとしては、一応、先ほどユーザ懇談会の皆様がお話になった最初に信頼性、保守、
それからライフサイクルでの保証継承性、それから情報セキュリティ、WindowsＨＭＩ、それからリプレース
などという順番で話をしていって、最後に総合的な討論をしたいと思います。
それでは、今ＰＬＣ側が応募しにくかった理由ということですが、パネラーとしては三菱電機さん、オム
ロンさんに来てもらっていますので、両者にご意見をお伺いしたいと思います。しかし両者だけではなくて、
ＤＣＳ、ＰＬＣ両方持っているメーカーさんも、ＤＣＳ中心で出されたので、ＰＬＣ側のご意見もお伺いし
たいと思います。
それでは廣田さんから、すみませんが、応募しにくかった理由を言っていただけるとありがたいと思いま
す。
（廣田）
三菱電機の廣田と申します。よろしくお願いします。
まず応募しにくかった理由ですが、やはりＰＬＣベンダとしては、基本的にコンポーネントの提供となり
ますので、システムとしての全体的な保証は、エンドユーザさんやＳＩさんになってしまうということもあ
3
計装制御技術会議 S3
ります。
ただ、ＰＬＣにおいてもＭＴＢＦにおいて、おおむね 10 年以上の性能は持っていますし、当然二重化に関
してもベースだとかＣＰＵ、電源、ネットワークユニットに対して品ぞろえもあります。ですから、今回、
ケース１、ケース２がありましたが、ケース 1.5 ぐらいのところまでは、シーケンサ、いわゆるＰＬＣでも
十分対応できるような形になっているかと思います。
今回どちらかというと素材産業向けの仕様書ではなかったかという気はしているのです。ＰＬＣの持って
いる特長が生かせる、特に素材とディスクリート（discrete）の間ぐらいで、特に駆動系との連携や、最近
「表示器」という現場ＨＭＩとの連携も含めて、当社としては統合エンジニアリング環境を進めています。
ですから、３年後という意味においては、当然ＰＬＣの得意といたしますシーケンス制御、プロセス制御、
駆動制御、あとフィールドネットワーク、当社の場合ですとＣＣリンクというオープンなフィールドネット
ワークを推進しているのですが、約 700 機種の製品がありますので、
そういったものをうまく使っていくと、
素材とディスクリートの間のところは、かなりＰＬＣで提案できると考えています。
先ほど言いましたように、３年後という意味においては、そういったシーケンス、プロセス、駆動、表示
器を含めて統一的な環境で、エンジニアリングできることが必要であると考えています。多分、次の機会に
は、素材というよりは、もう少しバッチ的なところの提案を含めて仕様をご提示いただければ、ＰＬＣベン
ダとしては、非常に特長が生かせるような提案ができるのではないかと思っています。
（新）
ありがとうございます。それでは、浪江さん、続けてよろしいでしょうか。
（浪江）オムロンの浪江です。どうしてエントリーをしなかったかということですが、先ほどチェアマン
の高野さん、それから三菱電機の廣田さんが最初におっしゃったことがいちばんのポイントです。ＰＬＣ計
装としては製品の信頼性や性能以外に、やはりシステムで提供するのをメインとするか、コンポーネントで
提供するのをメインとするかの違いが大きいかと思っています。私どものＰＬＣ計装の場合も、オムロンと
して、システムを受けるというケースもあるのですが、やはり標準的には、システムインテグレータさんに
システムを受けていただきます。私どもが提供するのは、
ハードウェアと標準のエンジニアリングツールで、
ＨＭＩについても一応、当社のオリジナルのものは持っていますが、実態を見ますとやはり８割以上の場合
は、市販のＳＣＡＤＡを組み合わせますので、システムトータルでの今回の要求仕様に対しては、提案をし
にくいというのが理由です。
コントローラのところだけで見た場合、二重化の機能も持っており、ＣＰＵ、電源、ネットワークあたり
の二重化まではできます。けれどもやはり今日の各社さんの提案を見ていても、ケース１についてはＩ／Ｏ
の二重化までが要るのは当然だと思います。私どもＩ／Ｏの二重化まではやっておりませんので、そういう
意味でコントローラとしてケース２は大丈夫ですが、ケース１は、やはり少し適用しにくいかなと感じてい
4
計装制御技術会議 S3
ます。
（新）ありがとうございました。大体総じて見方が出てきましたが、コンポーネントをＰＬＣベンダさん
は割と提供されていて、システムは、ほかのところがおやりになるということで、提案が少なかったという
ことだった思います。
実はそういう意味では、梶原さんが富士電機さんのことを評価されていましたが、システムという形で、
ＰＬＣをくるんでくれて出されると、うれしいということですね。
（梶原）
はい。
（新）それでは、続いて横河の中原さんに、同じ質問をしたいのですが、例えばＳＴＡＲＤＯＭで作って
いただけると、今回の仕様はもうちょっとお安くできるのでしょうか（笑）
。
（中原）基本的には考え方は同じでして、我々は今ＳＴＡＲＤＯＭを第２世代のＰＬＣということでプロ
モーションをかけていますけれども、ＳＴＡＲＤＯＭを使っていただくケースの場合は、インテグレータが
横河外のケース、お客様ということで、今回の納入時のシステムの全体の性能をだれが責任を持つのか、こ
の観点で言わせていただくと、横河電機はほとんどのケースはＤＣＳの丸請けということは多くやっている
のですが、ＳＴＡＲＤＯＭは非常にレアケースである。今回はそういうポイントと、やはりケース１とケー
ス２の比較を、ある程度フラットに際立たせるという意味では、同一製品の品ぞろえの中で表現したほうが、
内輪の事情ですが、時間的な余裕から見ても若干、楽だったところもあります。そういう判断で、今回は同
一製品でやらせていただきました。
（新）ありがとうございます。非常に短い期間でやっていただきましたので、ＳＴＡＲＤＯＭもＣＥＮＴ
ＵＭもということが大変だったということで、比較のためにはＣＥＮＴＵＭのほうが分かりやすいだろうと
いうお話だったと思います。
山武さんは、発表は吉田さんでしたが、パネラーとして岩崎さんもお呼びしています。どちらがお答えい
ただいてもけっこうですが、特に山武さんの場合、非常に特徴的なのは、ＰＬＣとしては、三菱電機さんの
ものをお使いで、ある意味でインテグレータとしてやられています。そういうことを踏まえて、この問題に
ご意見を頂けるとありがたいのですが。こういうふうに振られるとは思っていなかったですか。すみません
（笑）
。
（吉田）
問題のとらまえ方をどのようにしたらいいかが、いちばん難しいのですが（笑）
。
5
計装制御技術会議 S3
基本的には、我々が今お客様とおつきあいさせていただいている中で、特に心がけているのは、基本的に
データをマネージするという環境は、もちろん弊社のＤＣＳのコントローラを使っていただくのは、一番好
ましい姿なのですが、お客様のアプリケーションによっては、ＰＬＣを使われたほうがより使いやすい、あ
るいはアプリケーションとしてもうでき上がっているという場合が多々あります。そういう意味で、その間
をどのような形でシステムアップしていくかを含めて、混在型のシステムがかなり多くなっていることは事
実です。
ただ、今回の仕様というのは、山武も一応すべて自社製品で賄える範囲でしたから、当然のことながら、
我々のプラットフォームの上で評価させていただいたということで他意はないです。新先生に何と答えれば
いいですと、逆に聞きたいのですけれども。
（新）いやいや、別に他意はなくていいのですけれども（笑）、分かりました。横河さんと同じような事情
で、比較しやすいということですね。
多比良さんはいかがでしょうか。
（多比良）日立那珂エレクトロニクスの多比良でございます。私どももＰＬＣをつないで使うシステムと
いうのはありまして、スキャナシステムとして使うわけですが、ＰＬＣ自体を当社で作っているわけではあ
りませんので、長期保守という面で、今回の 20 年という保守の長さに対してできるかなということで、ＤＣ
Ｓのほうを選んだということです。
あともう一つは、今回のシステムはどちらかというとプロセス用ということで、ループ制御があります。
そういった面では、やはりＤＣＳのほうが使いやすいのかなということでやろうと思えばＰＬＣでもよかっ
たかなということです。
（新）ありがとうございます。そうですね。全体にアナログ系なので、ＰＬＣよりはＤＣＳの方がなじみ
が多いというご意見と、やはり 20 年というのは非常にネックで、フロアからも、20 年は長すぎるだろうと
いうご指摘がありましたが、ユーザとしては、別にコントローラは途中で取り替えてもいいわけですね。い
わゆるトータル・コスト・オブ・オーナーシップが縮小されれば、かまわない。そういうふうに、仕様書を
読んでいただいても、よかったということですね。モニターが皆さん５年とか、パソコンも 10 年という形で
取り替えるシステムをお出しになっていらっしゃいましたから、コントローラも取り替えていただいてもけ
っこうだと。何でもいいから信頼性があって安いほうがいいというのが、こちら組の要望みたいですから（笑）
。
今度これを踏まえて、さらにそういう視点も入れていきたいと思います。
大庭さん、いかがでしょうか。
6
計装制御技術会議 S3
（大庭）私のところも、先ほどの答えとあまり変わらないかもしれないのですが、ちょっと難しいのが、
先ほどの私の発表で言いましたように、コンポーネントを我々東芝と三菱電機さんが、システムインテグレ
ータとなっています東芝三菱電機産業システム（ＴＭＥＩＣ）のほうに供給して、そこでシステムアップす
るという形になっています。
ですから今回企画側からの希望としては、きっとＤＣＳのほうは東芝のコンポの提案をＤＣＳでやって、
それから、ＴＭＥＩＣさんからは安型としてＭＥＬＳＥＣで提案してもらったら、一番この企画に合ったの
かなと今思っています。
最初このシステム仕様を見てＴＭＥＩＣさんと相談したときに、これは、ではＤＣＳで行こうとそのとき
に決めたので、三菱さんのＭＥＬＳＥＣを使ったシステムは今回、提案には盛り込めなかったというのが実
際のところです。
（新）
ありがとうございます。それでは、中川さん。
（中川）今日お配りした２枚のいちばん後ろのＰＬＣのスペックを書いたところを見てもらいたいのです
が、ＰＬＣ計装は、点数が少ないところだけかなと思われると思うのですが、ここにあります 417-4 という
のは、メモリが 10 メガバイトもあるとか、スピードが速い。それから、そこに点数が書いていますね。
実際私たちがやった見積もりでは、空港のユーティリティの設備で、２万点に及ぶ設備の見積もりをした
ことがあるのです。これはどうするかというと、一つのＣＰＵで、一つの工程で、これ全体をつなげて、48
台のＣＰＵをつなげてというものをやりました。
今日は触れませんでしたが、これから安全計装が言われてくると、一つの工程ごとのＳＩＬ（Safety
Integrity Level：安全度水準）
、この工程はＳＩＬ３とかいうことになって、どうしてもＣＰＵを分けなけ
ればいけなくなってくるのです。安全のほうは、それぞれＣＰＵはＳＩＬ３の認定を取っていますので、あ
るいは上のプロトコルはＰＲＯＦＩ safe というＳＩＬ３を取っていますので、そういう安全計装から見て
もかなり大きなシステムでもできる。
シーメンス自身は何年か前まで、ＵＮＩＸ系のＴＥＬＥＰＥＲＭ−ＸというＤＣＳを持っていたのですが、
これは今はもうやめて、ＰＣＳ７に置き換えようということで、世界的にはかなり大きな設備に入っていま
す。私たちも 3000 点の実績があるということで、だから、スピードとか容量とか、それから先ほどの安全計
装につなげるということで、今のＰＬＣ計装を、さらに先ほどの最初のほうで、何年か先のことを見せてと
おっしゃいました。そういう製品になっていることを付け加えたいと思います。よろしくお願いします。
（新）
ありがとうございます。どうぞ、奥住さん。
7
計装制御技術会議 S3
（奥住）富士電機システムズですが、私どもはＰＬＣとＤＣＳは、非常にボーダレスに向っていると考え
ています。ＰＬＣとＤＣＳについて、コントローラに限っていえば、もちろん二重化とかそういう問題はま
だありますが、ＰＬＣかＤＣＳかというよりは、ハイエンドの機種なのかローエンドの機種なのかというシ
リーズの中で、違いが出てきているのだろうと。
もう一つは、最初に三菱さんが言われましたが、
ＰＬＣとＤＣＳはそもそものビジネスモデルが違います。
ＰＬＣは、まず製品を単体で売ることでビジネスが成立していて、責任とか保証が、はっきりある意味で限
られたところでまず一回ビジネスが成立しています。ＤＣＳは、システム全体の責任になりますので、ここ
の違いがいちばん大きいと思います。
（新）富士電機さんの場合、ＦＡ部門とＰＡ部門というのは一緒にやっているのですか。ベンダとして垣
根はないのですか。
（奥住）ベンダとして、まず汎用ＰＬＣの部隊と私どもの電機システムの部隊というのは、３年前にホー
ルディング化したときに分社化し、今、事業会社としては富士電機システムズと別会社になっています。
（新）何が言いたいかというと、割とユーザのほうはＦＡとＰＡの境目がなくなってきているのに、まだ
ベンダはＦＡとＰＡがみんな違っていて、そこにミスマッチがある。同じ会社でも、どちらの事業部の担当
かによって上がってくる仕様書が違うのです。だから、多分ユーザの要望としては、ベンダに対してＰＡ系
とＦＡ系をもっと融合させて、ここのバーチャルではなくて、実際の要求に対してベストミックスな提案を
してほしいと思うのです。これは富士電機さんだけに申し上げるのではなくて、やはりベンダ全体に多分ユ
ーザ全体からの要望だと思います。そういうことでユーザさん、よろしいでしょうか。ありがとうございま
す。
というわけでまとめますと、最初、高野さんがおっしゃったように、ここの仕様書全体がどちらかという
とＤＣＳ向きだったというので、ＰＬＣ側が応募をしにくかったという理由があります。それから、本当に
ＰＬＣを作っているところは、割とコンポーネント販売で、それからインテグレータというワンクッション
があるので、ＤＣＳは全部まとまっている。それがメリットとデメリット両方を含んでいるという形で、応
募がしにくかったとご理解いただきたいと思います。この会議全体としてはベンダの事業の体制も含めて、
ユーザは本当のベストミックスを求めているとご理解いただいていいと思います。
よろしければ、いよいよ次の話題に移り、保守ということです。この信頼性、保守に入る前に、まずユー
ザに答えてもらいたいことがあります。それはカネカの梶原さんに日本ベーレの市川さんからのご質問で、
ハードウェアとかシステムは分かったけれども、上のアプリケーションソフトはだれが作るのだというご意
見でした。カネカでは、７対３か、６対４ぐらいで内製されているというお答えだったのですが、今ヒアリ
8
計装制御技術会議 S3
ングしてきましたら、これはユーザによって全然違うらしいです。お話しできるところはちょっと話してい
ただきたいなと思いまして、西條さんのところはどういう感じでしょうか。
（西條）うちの場合、基本的に入っている機器は、ＤＣＳ系が横河さんのＣＥＮＴＵＭで、ＰＬＣが安川
さん、三菱さん、オムロンさん、キーエンスさんみたいな形で入っているのです。うちの業界の流れとして、
非常に製品の入れ替わりが早いこともあり、基本的には自社 100％でシーケンスなどを組んでいる状況です。
（新）
あそこは 100％だそうです。では、新日石さんはいかがでしょうか。
（千田）うちは、石油精製というのは石油精製設備のプロセスは大体決まっていますので、初期にベンダ
に作ってもらったものを、そのまま運用しているのが実情で、基本的には 100％、ベンダさんに作ってもら
っているという状況です。
ＤＣＳの基本的な部分は 100％作っていただいているのですが、アドバンスト制御みたいなところでの効
率化で、情報システム系、サーバ系の上のほうでやるところについては、それは共同でソフトを作っていく
ところも若干あるとは思います。
（新）
ありがとうございます。杉浦さん。
（杉浦）昨年までいた森永乳業でのお話になるのですが、森永乳業は、先ほどライオンの西條様がおっし
ゃったように、やはり製品の切り替えが非常に多いことと、1986 年からずっと自社システム開発したもので
動かしていることもあり、100％自社でソフトを作るという体制で動いています。ただ、自社といっても、長
い間、構内常駐だとか、関係会社、森永エンジニアリングという会社もそうなのですが、このような関係し
ている会社のメンバーを含めて 100％自社という形になっています。
このシステムは外販もしているのですが、外販のほうは実際、自作しているユーザは大体 30％弱というと
ころで、残り７割はフルターンキーという形で、全部アプリケーションを請け負って作っているという状況
になっています。
（新）
ありがとうございます。今任さんのところも。
（今任）私どもは、エンジニアリング会社ということで、ＳＩ’er の立場でやっていますが、三菱化学とし
てという見方をした場合、旧三菱化成のころは基本的には 100％計装のエンジニアがアプリケーションを作
っていました。例えばＣＥＮＴＵＭ−ＸＬが出たときも三鷹に３か月ほど詰めて、ハードのバグ出しからや
9
計装制御技術会議 S3
っていました。
昔はそうしていましたが、会社の方針として、いわゆるエンジニアリング部隊を三菱化学エンジのほうに
全部移してということで、今、会社としては違いますが、基本的には人が移ってやっています。三菱化学社
内のアプリケーションは、機種やベンダによって違いますので、現状、大体６割ぐらいは三菱化学エンジを
含めたオーナーワークでやっている。残りは、やはり外注という形でやっています。
その一つの理由として、要員と仕事の量の関係があります。もう一つはスキルの問題です。どんどん新し
いものをベンダがいろいろと出していって、それにまだついていけていない機種の場合は、外注する形を取
っています。
（新）
ありがとうございます。では服部さん、お願いします。
（服部）当社の場合も、三菱化学さんと大体事情は近くて、基本的にはソフトウェアのソースレベルのフ
ローチャートやＳＦＣ等のフローに近い部分ですとか、ループ構成までは、すべて自社 100％で対応してい
ます。
コーディングするワークはどうするかについては、例えば新規にＤＣＳ全体を構築・更新する場合やある
程度まとまった設備改造の大規模なワークになりますと、社員が総出で全部作るのは効率が悪いので、専門
職に任せたほうがいいでしょうと考え、外注することが多いかと思います。小規模な場合でしたら、自社で
そっくり直してしまうという対応になろうかと思います。
その場合、メーカーに任せて大丈夫かという点については、装置の重要性を勘案した上で、最終的にシス
テムが適正に動くかどうかの機能確認を、すべて自社で責任を持って確認するという前提で行っている状況
です。ガス会社の中には、ソフトウェアの作成等を外注化している例もあるように聞いています。
（新）
ありがとうございます。
梶原さん、何か付け加えることはありますか。いいですか。高野さん、ありますか。
（高野）私のところは、物にもよりますが、基本的なシステムソフトの制作は、ほとんど外注にしている
という状況です。
特色的なところは、
スペックをかなり詳細にインハウスで書いているところだと思います。
我々が課題だと思っているのが、制御のソフトウェアの部分の標準化を、もう少しやらないと、よりマル
チベンダで対応していくことはできないということで、ちょっとその辺は課題として今とらえています。
（新）というわけで、会社によって随分差がある。０から１００％まであるとご理解いただきたいと思い
ます。
10
計装制御技術会議 S3
ご質問として、インテグレーションの責任はだれが取るのかというのがあるのですが、アプリケーション
を多分、全部内製しているところだと、最終的に自分で責任を取らざるをえないというのがあると思います。
１００％外注しているところは、自分では取らないと思いますので、そういう解答になるかと思います。
これを踏まえたうえで、信頼性、保守ということで、今度はベンダさん側にお聞きしたいと思います。幾
つかご指摘があり、それを踏まえてお答えいただきたいのですが、一つは、今任さんからコスト、特にケー
ス１、ケース２、高信頼性システムと標準的なシステムとのコスト比が、会社によってずいぶん違うことが
ありました。これは会社の戦略もあると思います。
それからご質問で、東京ガスの木村さんから、各社のシステムの他社より優れている点をご教授ください
という点の裏返しになるかと思います。自分のところだけではなく、他社の回答も見たうえで、そのコスト、
日立さんで 100 対 68 ですか。東芝さんで 106 対 100。そういった大きな差が出てくるところを、ご説明いた
だきたいと思います。
それから、カネカの梶原さんから、お金の話が出たのだけれども、信頼性の対比が出ていない。これは要
求仕様書に書いたのだけれどもということで、コストは分かったけれども、信頼性はどうか。ケース１とケ
ース２を比べて、何対何と、もしお答えできるのであれば、お答えいただきたいと思います。
併せて、ほかのユーザさんから各個別にご質問があったと思いますが、この機会に自社の製品の特徴と併
せてお答えいただければよろしいかと思います。もし忘れているようでしたら、私が追加で質問させていた
だきますので、よろしいでしょうか。
それでは、今度は奥住さんからお願いできますか。
（奥住）言い忘れてしまったので今言いますが、コストについては、ハードとシステムソフトウェアだけ
で、当社の場合はＭＩＣＲＥＸ-ＮＸという同じ機種で見積もっていますので、高信頼性のものと廉価システ
ムは、100 対 50 です。
それから、
信頼性の指標については、
これは計算してこなかったので申し上げることができないのですが、
かりに計算したとき、例えば１対 50 だとか 100 だとかいう数字が出たときに、どういうふうに使われるのか
ということを、逆にお聞きしたいと思います。
（新）信頼性ですね。それでは、逆に質問なのですが、富士電機さんの場合、非常にいろいろなところが
二重化されていて、いろいろなパターンがあるというご発表をされたのです。質問の中で、ではそれをどう
使い分けたらいいのか、ちょっと戸惑っているところがあるのです。だから、いろいろなバリエーションを、
なぜ提供しなければいけないのかというのと、例えばそのバリエーションの中で、どういう尺度でこの範囲
を選んだらいいのか。そのあたりを、ちょっとお答えいただけるとありがたいのですが。
11
計装制御技術会議 S3
（奥住）基本的に、当社はシステム全体を取りまとめて、責任を持ってお納めすることを主体にビジネス
をしていますので、その辺のエンジニアリングを含めて、当社のエンジニアが判断します。
もちろん指定してもらってもけっこうですが、例えばコントローラとＩ／Ｏを非常に距離を置いたときは、
当然そこの間のケーブルはリスクが高まるわけですから、場合によってはリング構成にして、経路を変えた
り、二重化したりということが、エンジニアの判断としてあると思います。
（新）ユーザさんの要望がそれだけ多様化しているから、それにおこたえになる製品をお作りになってい
るということですね。
（奥住）
そうですね。要望と、使われ方が千差万別だということです。
（新）それは山武の吉田さんがお話になっていましたが、生産の場だけではなくて、それが止まったとき
の社会的影響まで考えて、どこを二重化するかを決めなければいけないと言われました。そういうふうに、
やはり個別に決めないといけないということですね。
梶原さんにちょっと質問を振りたいのですが、それが最初のねらいで、聞きたいのは、いちばん信頼性が
高いところと低いところを押さえておいて、その間のいろいろなバリエーションがあって、それを梶原さん
が状況に合わせて選びたい、ということが本音ですね。
（梶原）
（新）
はい。
というわけで、そういう意味で評価されているのだと思います。ありがとうございました。
中川さん、いかがでしょうか。
（中川）シーメンスの場合は、世界に 180 か国を超えるネットワークがあり、私たちも海外の仕事が多い
のですが、ジョブを見積もる段階から現地のシーメンスに連絡が来て、連絡を取り合って、納めたあとは現
地の法人が対応する形を取っています。日本では、日本のＳＫＫに 30 名のサービス部隊がいるので、そこが
あとをサポートすることになっています。
二重化のところは、値段が高くなっている要因でもあるのですが、今回の場合はＩ／Ｏモジュールまで二
重にして、一つのアナログ入力に対して、二つのアナログモジュールを設けてありますので、倍になってい
る。
現実には、そこまでやるお客さんは非常に少なくて、ネットワークの二重化まで、リモートＩ/Ｏのところ
のネットワークの二重化、電源の二重化、もちろん上のＣＰは二重化するのですけれども。それは考え方で
12
計装制御技術会議 S3
ありまして、高くなるほうに進んでいきます。
あと、海外の場合は日本と違って、定期的にメンテナンスというやり方はないので、ユーザが決められる
のです。シーメンスの場合は、ＰＬＣのそれぞれのコンポーネントの診断情報が上がってきますので、それ
をリモート・メンテという形で、現地の各法人がつかんでいて、適宜それによってメンテに出かけるという
形を取っています。
（新）
ありがとうございます。
ちょっと休み時間の間にお聞きしたのですが、富士電機のシステムとノーケンはどちらもシーメンス・ベ
ースで、どう住み分けているのかとお聞きしたのです。日本語化対応は富士電機と考えて、そういう形の住
み分けだということですので、ちょっと補足まで。
すみません。大庭さん、お願いします。
（大庭）東芝の大庭です。価格の定義がちょっとあいまいなまま、数字だけ 106 対 100 だと言われてちょ
っと困るのですけれども（笑）。システムということで、筐体とか今回必要なＵＰＳの値段も含めて、システ
ム価格という形で 106 対 100 になったのです。午前中の話の中でもちょっと言ったのですが、コントローラ
のところが二重化とシングルのところだけが違っていまして、その部分ですと 100 対 75 という形です。
あとマンマシンのところがあるのですが、マンマシンは当社の場合は産業用コンピュータを使うという前
提で、高信頼型も廉価版も同じマンマシンを使っていますので、そこには差が出ないことになります。
これもその理由ですが、先ほど、ほかのメーカーさんからも、汎用コンピュータだと５年で換えるとか、
産業用コンピュータだと 10 年で換えるという話がありました。今回は 20 年ということで、先ほどライフサ
イクルで考えると、１回換えればいいということで産業用コンピュータにしています。汎用コンピュータで
すと、イニシャルとしてはきっと安くなるのですが、20 年間を見たときに、例えば４回換えるとなると、全
体を 20 年間で考えたら、そんなに変わらないのではないかと思っています。
もし、かりにマンマシンの部分を汎用コンピュータにして、コントローラを二重化とシングルにすると、
日立さんや横河さんと大して変わらない 100 対 60 とか 50 とかいうレベルになると考えています。
（新）ありがとうございます。そういう意味では、仕様書がちょっと甘かったということですね。だから、
信頼性システムを出したのですが、ノーケンさんの場合も入出力を二重化しなければ、もっと安くできるだ
ろうと思いますので、どこをちゃんと二重化するかという形の仕様書までしないといけない。コンピュータ
も、汎用でいいのか、産業用にしなければいけないのかという、細かいところまでしてくれないので、各ベ
ンダさんが自分のところで解釈されて出したので、いろいろとばらつきができた。
だから、皆さんがこの比率を見られるときには、どこまで二重化されているか、コンピュータはどういう
13
計装制御技術会議 S3
ものを使っているのか、どれぐらいの保守期間をお考えになっているのか。そういうところまで、総合的に
見て判断をしていただきたいということだと思います。
でも、ユーザ仕様書をまとめる段階では、こちらもまとめる時間がなく、答えていただく時間もなくて、
ちょっとそこまで煮詰めきれなかったのですが、具体的にこういうバーチャルコンペをやって、仕様書もい
いかげんだということが分かりました。もし来年やるのでしたら、もっと煮詰めた形で仕様書を考えさせて
いただきたい。そこら辺は誤解がないようにというご指摘だったと思います。
それでは、多比良さん、お願いします。
（多比良）私どものシステムでは、ケース１が 100 で、ケース２が 68 とシステム全体でなっていまして、
高いというご指摘もあったのですが、ひょっとしたら相対値ですので、
ケース１も安いのかもしれない
（笑）。
コントローラの場合ですと 100 対 63 になっていまして、これはほぼすべてのモジュールが二重化ですので、
約２倍となっています。
あとＰＩ／Ｏのところで、資料に誤解が生じそうなので補足説明します。共通部二重化としていますが、
正確にはモジュール部分も二重化していますので、具体的にはＡＤ変換や通信を二重化しています。二重化
していないのは、最後の出力のところだけ、変換器のところだけです。
それから、特に価格が違っていますのがヒューマン・インタフェースのところで、専用ハード、それから
汎用ハードの違いで、100 対 54 の違いになっています。違う理由は、専用ハードの場合は 10 年保守という
ことで、10 年間はマザーボードを含めて修理できる体制を取ることにしています。要員、それから交換部品
等でコストがかかってくるので、そこが大きく変わってくるところです。
それから、ＭＴＢＦを提示していないのですが、別件の資料で、標準的なシステムでシングルの場合がＭ
ＴＢＦ10 年、それからコントローラ単体で二重化の場合がＭＴＢＦ100 年という値を出しています。今回の
システムですと、ＰＩ／Ｏ、それからオペコン等が入ってきますので、ちょっと出してみないと正確には言
えませんが、シングルの場合には多分ＭＴＢＦ数年、それから、二重化の場合には二十数年ぐらいになるの
ではないか。これは計算してみないと分かりませんが、大体それぐらいではないかと考えています。
（新）日立さんのシステムの場合、ユーザ側でこれも話題になっていましたが、シンクライアント（thin
client）と、梶原さんがちょっと評価されていました。そういう思想で作ったので、割と標準と信頼性との
間のコスト比が劇的に下がっていないのではないかと私は思うわけです。逆に言えば、今のＭＴＢＦを計算
したときにケース２の場合でも、あまり劣化しないのではないかと思うのですが、そう考えてよろしいでし
ょうか。
（多比良）ちょっと違いまして、ケース１、ケース２で冗長化のところも比較の対象だったのですが、他
14
計装制御技術会議 S3
に長期保守が重点です。ケース２のほうは、一つの端末にシンクライアントを使っていまして、ハードディ
スクレスをうたっています。ハードディスクレスですから、確かに信頼性はある程度高くなるのですが、記
憶するハードだけではなくて、マザーボード等もありますので、トータル的に考えると、ケース１のほうで
はハードディスクを使った、しかし、長期保守ができるというタイプを選んでいて、その面でケース１のほ
うが高くなった。ケース２はハードディスクレスで、信頼性は悪いとは思っていませんが、結果的に安くて
信頼性が高めになっているということです。
（新）やはりこちら側のご指摘にあったように、コスト比だけではなくて、信頼性比みたいなものも出し
てくれないと、先ほど申し上げたように、どこを二重化して、どこを二重化していないかは会社によって違
うので、比較はできなかった。だから、信頼性比まで出してくれると、ここはここまで二重化を考えたもの
を、標準ケース２と考えていらっしゃるのかと考えます。
コストの中で、ノーケンさんがリング型になっていて、リング型にすると、どれだけ信頼性が上がるか。
標準品でもリング型をお使いでしたから、ある意味でコストアップになっていると思うのです。割とこちら
は貪欲で、細かいところまで比較したい。そのうえで選びたいというのが本音だったのではないかと思いま
す。ありがとうございました。
それでは、山武さんはどちらが？
（吉田）
山武は２人でずるいのですが、回答の件なので私から答えさせていただきます。
一つは先ほどの金額の相対比較なのですが、ちょっと私はプレゼンテーションの時間の使い方がまずくて、
あの場で申し上げられなかったのですが、資料の中にありますように、ケース１が大体 1.5 にすると、ケー
ス２がトータルで１ということでしょう。逆に比率を直しますと、大体 60％強がケース１に対するケース２
の比率ということになります。私はなぜこれを 1.4 から 1.5 と書いたか、ちょっと忘れてしまったので申し
訳ないのですが、1.5 ぐらいでとらえてください。
その中で一つだけ申し上げると、ＨＭＩの部分は、私のほうはケース２のほうで工業用のパソコンを使っ
ていまして、特に 20 年間維持するのは、両方共通の仕様として挙げられていました。できるだけ一度お納め
したものを、長期的にお使いいただくという形のほうを重視して、そういう形になっています。ハードウェ
アの価格としては、もしかしたら汎用ＰＣをこちらに使われたベンダさんに比べると、ちょっと差が開く形
になるのではないかと感じます。
それから、２点めの信頼性なのですが、これも非常に難しくて、ちょっと申し訳ないのですが、私も計算
は今回さぼっていました。一応これまでの実績値といいますか、経験値等から言いますと、大体シングルに
比べて冗長化した場合の信頼性の向上度は、10 倍のオーダーです。恐らく 100 倍にはいかないと思います。
この辺はＩ／Ｏの構成ですとか、細かい構造によって変わってまいります。
15
計装制御技術会議 S3
注意は、これをやるうえでは、一つはまずどの点をシステムダウンと見なすのかという定義が必要です。
１ループの縮退を許すのか、２ループ以上は許さないのか。２ループ以上は許すけれども、４ループでシス
テムダウンと見なすのか。Ｉ／ＯはＯＫだけれども、ＣＰＵがとにかく止まったときを、システムダウンと
見なすのか。これによって、信頼性値が非常に変わってくるというのが１点です。
それから、もう一つはもしこれを横並びに各ベンダで比較しようとすると、ここで使うべき信頼性を計算
するための、部品の故障値を統一しないと、実際に横並びの比較というのは絶対的にはできません。残念な
がらこの値は、実は世界的に見るとある統一した規格があるのですが、その値が非常に保守的で、ユーザさ
んにお見せするとびっくりするぐらいです。逆にメーカーの実績からすると、なぜこの部品がこんな故障率
を持っているのだという値になってしまいます。
その辺は、ある程度、経験値を踏まえた形で、自社での運用と、あとＧＥでの運用と、その辺を踏まえた
形でやっているのが実情で、ちょっとこの辺の横並びが、実はユーザから見るとご不満かもしれないのです
が、なかなかベンダは横並びでは比較しにくい形になっているのかなというのが実情です。
したがって、これを比較されるうえでは、私がほかのベンダさんのことを言うのは非常に差し出がましい
のですが、各ベンダ内の、山武であれば山武の中の、例えば旧システムと新システムでの比較とか、もしく
はシングルと冗長化した場合の比較ですとか、そういうところを相対的にとらえていただくのがよろしいか
と考えます。
（新）私は、すごく吉田さんの話が面白かったのは何かというと、ケース２だったら保守はしない。ＢＭ
対応だという形の提案をされて、だから居直っているところがあって、すごく面白かったです（笑）
。
それは日立さんもそうで、先ほど言ったシンクライアントにしているということで、ここは倒れないとい
う冗長化をしているところを、ここは二重化しているから倒れないという前提でシステムをお作りになって
いる。そこが単なるコストアップの二重化と違って、二重化したからにはとことんしゃぶり尽くそうという
感じがあったので、２社は方向性は違うのですが、そこら辺は、それぞれの会社の特徴ではないかと思いま
す。
だから、単に信頼性はコストアップだけではなくて、ここは倒れないようにお金をかけたのなら、それを
ベースに使おうとか、信頼性がそんなに必要はなくて止まってもいいのであれば、保守もそれなりの保守に
しようという形でコストをお考えになればいいという、非常に前向きな提案を２社はされていたのではない
かと思います。やはりそういう味わいかたをしたほうがよろしいですね（笑）
。
それでは、中原さん、お願いします。
（中原）費用については、大体２対１という形で提案していますが、他社さんがご指摘されているとおり、
特にＰＣをインダストリアル系のものにするか、汎用ものにするかというところも含めてやらせていただい
16
計装制御技術会議 S3
たので、これだけの差が出ています。
ちなみに、パソコンの場合、リプレースの費用が発生するわけですから、その費用は保守側に入っている
ということで、保守費用がそんなに差が出ていないのは、ケース２の場合は汎用パソコンのリプレース周期
は、インダストリアル系よりも短いだろうという想定が含まれているのも事実です。
それから、冗長化の定量的な指標に関しては、一応、ＭＴＢＦで 70 倍と示していますが、最初にお話しし
たとおり、かなり両極端に振った構成になっていますので、実際には、ネットワークの二重化は標準なので
すが、それ以外の部分で、電源を二重化するか、あるいはＣＰＵを二重化するか、あるいはＩ／Ｏまでやる
かというのは、今、申し上げた順番に、やはり二重化する割合は下がってきているのが実際のケースです。
そういう意味では、お客様もある判断をされて、どの部分を二重化するかは、ケース・バイ・ケースでチ
ョイスされているのではないか。当然我々もそれにお答えする形で、システム構成であれば、ＭＴＢＦはど
れぐらいになりますという計算式は示しています。ですから、それなりに判断基準は出しているのではない
かと考えています。
最後に、保守費の差がそんなに出ていないという話もありましたが、ご存じのとおり保守費のコストの中
身は、基本的には人件費がかなりのシェアを占める部分もあり、ケース１、ケース２、予防保全をするか、
あるいは故障が起きた時にだけ対応するかという差はありますが、基本的に両方ともオンサイトのサービス
になっています。ですから、それなりのコストがかかるのは事実で、そういう部分も見て判断していただき
たいと思います。
そういう意味では、先ほどどなたかがケース２のものを２セット持って、ケース２の保守費用も払わない
でというお話もありました。当然そういう形態も可能ですが、そうなると、カードの交換や、一切合切の作
業自身がお客様の中でやっていただくことになりますので、その辺のことも踏まえた判断が必要かと思いま
す。
（新）横河さんは今日ご紹介いただいたように、非常にきめ細かい保守をされるわけですね。だから、言
いたかったのは、システム自体の値段だけではなくて、保守はどこまでやっているかも見ないとケース１、
ケース２のコスト比較は段順にはできない？
（中原）そうですね。特に保守の場合は、セッションの１日めの中で細かくご紹介しましたが、計画的に
保全したら、どれぐらい稼働率が上がるかというのは非常に難しいのです。要は、オンタイムで動いている
話ですから、過去の横河が納めたシステムの実績はこうですよというところから評価していただくしかない
のです。カードを洗浄するとか、あるいは保守時に汚れ具合を顕微鏡レベルで調べるということは、ある範
囲では有効性を持って効いているのではないか。ただ、お客様が持っている全設備の中で、それがどれぐら
い意味があるかという議論は、当然また別にあるとは思います。
17
計装制御技術会議 S3
（新）横河ウォッチャーとしては、私の個人的な意見ですが、システムの販売から保守でもうけようとい
う方向に向かっているような気がするのですが、いかがでしょうか。別に肯定も否定もしなくてもいいので
すけれども（笑）
。
（中原）当然ビジネスの方向性としてはそういう部分があります。なぜかというと、特に国内においては
新設プラントがもうない中で、要はリプレース需要しか基本的にないという判断をしています。
その中で、そうするとどうしても、インストール・ベースを増やすことはできませんので、なかなかボリ
ュームを増やすことができないのです。そうすると海外に行くか、海外で新しいお客様を獲得するか、ある
いは保守というある意味新しい分野で、ある意味お客さんの設備の一部の保守行為をアウトソーシングして
いただくという形で、ビジネスサイズを広げるという、その二つがあるかとは思っています。
（新）というわけで、割と戦略的にやられているようです。そこまで含めてコストというのは考えなけれ
ばいけないということです。
廣田さんと浪江さんには、二つの観点からお答えいただきたいところがあって、一つは、ＰＬＣの信頼性
も、昔に比べてこんなに上がっているよという形のことがあると思うので、ひとつご説明いただきたい。
それから、今日のベンダさんの回答は、例えばＨＭＩのところは５年で換えるというご回答もありました
から、ではＨＭＩに併せてＰＬＣも一緒に交換してしまう。本当に 20 年もたなくてもいい。その代わり、ト
ータルコストとしては安くなるという回答もあると思います。ユーザさんは、それでもかまわないのではな
いかと思いますので、二つの観点からお答えいただけるといいと思うのです。では、浪江さんからお願いで
きますか。
（浪江）まず信頼性の件ですが、やはり定量的に信頼性を表す数値としては先ほど来出ていますＭＴＢＦ
ぐらいしかないと思います。この数値については、私どもはＰＬＣのユニットごとに計算値を持っていて、
それを使って計算をします。二重化の場合についても計算ができますので、それは個別の商談、お問い合わ
せの中でお答えすることは可能です。
それから、信頼性に関してもう一つは、市場の実績というところを見ていただきたいなと思うのですが、
計装のアプリケーションにＰＬＣを使うという試みは、それほど古くないかもしれません。けれども、同じ
ハードウェアを使って、ＰＬＣはＦＡ分野で非常にたくさん使われていますので、皆さんの工場の中でもい
っぱい稼働しているかと思います。そこのこれまでの稼働率を見ていただいて、ご判断いただくのも一つの
指標かと思います。
それから、更新の周期については、私どものＰＬＣの場合、基本的に 10 年、計画保全される場合は、10
18
計装制御技術会議 S3
年ごとの交換をご案内していますが、ただ、電源ユニットについては、これだけは少し短めの８年というの
をご案内しています。
（新）
ありがとうございます。それでは、廣田さん、お願いいたします。
（廣田）まず信頼性に関してですが、ＰＬＣに関しても、部品数はかなりＡＳＩＣ化して減らしています
ので、従来に比べるとＭＴＢＦは２倍以上で、基本的にＭＴＢＦとしては 10 年以上をおおむねクリアしてい
るという状況です。
あと、今回の新先生のご質問にはなかったのですが、価格に関しても、なるべく保守費用の削減というこ
とで、当社の二重化に関しては、ベースとかユニットは、すべて標準のものが使える。二重化のＣＰＵ以外
はすべて標準品が使えるということで、メンテナンス費用、いわゆる保守にかかる費用に関しても、考慮し
たような製品になっています。ちょっと付け加えさせていただきます。
あとＨＭＩの関係なのですが、パソコンは中央で監視するために使うのですが、ちょっと視点を変えて、
最近、表示器、いわゆるグラフィック・オペレーションターミナルというのがあるのですが、現場で使うケ
ースがかなり増えてきています。また当社においては、15 インチサイズの表示器もありますので、けっこう
そういったものが中央にも使える環境も出てきています。うまくパソコンと表示器を組み合わせて、更新の
サイクルを長くすることも可能ではないかと考えています。
やはり、ＰＬＣの場合、先ほどオムロンさんが言われたように、基本的には 10 年が一つの目安になると思
いますので、その辺で一つの更新を考えていただければと思います。
（新）ありがとうございます。今のような形で、ちょっとユーザ仕様書のほうにも要求書のほうにも十分
書いていないことがあって、ばらつきが出たとお考えいただきたいと思います。それで大体、信頼性保守は
よろしいでしょうか。
それでは、続いて杉浦さんが提起した継承性に移りたいと思います。今回の要求仕様書は 1000 点という形
で、プラントとしてはかなり小規模なもので、杉浦さんは「10 万点になると話が違うだろう。すなわち、シ
ングルベンダではだめだろう」ということで、データの継承性とワイヤリングの継承性をおっしゃったので
す。中原さんのご意見にもありましたが、プロセスオートメーションの世界、計装という言葉をよく使われ
る世界では、だんだん新しいところを新設するよりは、現在のものをリプレースしていくという形態が多い
と言われ、そのとおりではないかと思います。
ただそのとき、今のコントロールのところだけではなくて、杉浦さんはＰＩというデータベースの話をされ
ましたが、ＰＩを使っているところもあれば、マイクロソフトのＳＱＬやオラクルを使っていらっしゃると
ころもある。それから、このラインをほかの上位系、昨日、生産管理のセッションを杉浦さんにやっていた
19
計装制御技術会議 S3
だきましたが、そういうところではつながらなければ話にならない。すなわち、自分のところの世代が違う
ものもつながらなければいけないのは当たり前ですが、多分、他社製品がつながらないと、10 万点という規
模は動かないと思うのですが、そういう認識でユーザさん、よろしいですか。
言いたいのは、だから、ある生産設備を一つ取り替えたときに、他の設備と連携が取れないと、仕事がで
きない。他の設備は横河さんのものを入れたのだけれども、山武さんかもしれないし、東芝・三菱さんかも
しれないという状況で、継承性を考えなければいけないということで、よろしいでしょうか。
だから、ＤＣＳが１社の中で世代交代したから、その中で継承できると言われても十分でない。杉浦さん、
それでよろしいですか。
（杉浦）梶原さんのほうで、システム全部入れ替えるときに、コンペをしてどこかのシステムに替えるか
という一つお話があったわけです。その時マイクロソフトのワードが、一太郎から乗り換えるためのツール
を用意したみたいな形で、他社システムの乗り換えというのがまず一つあるだろうというのが、問題点の一
つです。
二つめが、先ほど新先生がＰＩという名前を出したわけですが、システムは多分 10 年前を導入したのであ
れば、プラントを動かして製品を作るのが精一杯だった。そこから分析したり何なりしたいというシステム
は、後からつけて増えてきているのではないか。そのようなシステムとリプレースの時期が来ているＤＣＳ
の入れ替えの連携が取れなければ、要するに自分のところで自己完結して、きれいにバージョンアップでき
ますよと言っても、他社のシステム、あとは最近では上位システムですね。ＥＲＰだとかサプライチェーン
などと、つながっているケースも多い。そういった、ほかのシステムとの連携まで含めた形での、本当に継
承性を保証してくださっているのかという意味での質問になります。
（新）それでは、その質問ですが、一つは上位系として接続性が確保されているかがポイントだと思いま
す。それから、ユーザ要求仕様書の中には、通信ネットワークがイーサネット対応で国際標準ということを
要求に入れていらっしゃいます。それで各社一応、国際標準だと言っているわけですが、どうもＩＥＣ
（International Electrotechnical Commission）のリアルタイムイーサネットの標準化などを見ていると、
提案したものはみんな標準にしてしまって、本当に相互に接続できるのか。こういう疑問が私にはあります。
シーメンスさんのところは PROFINET ですし、横河さんはＶネットでしたか。東芝さんはＴネットとおっし
ゃいましたか。みんなＩＥＣ化がされていらっしゃる。そういう形になっているのですが、ユーザさんのご
関心は、それが直接、または何かアダプタみたいなものを入れて、ちゃんとデータが交換できるかどうかと
いうことが、10 万点の規模になると、継承性として浮かび上がってくるということですね。
そこが聞きたいそうなので、すみませんが、ＣＣリンクも、たしかＩＥＣ一派にもくみしていると思いま
すので、では今度は廣田さんから行ってみましょうか。
20
計装制御技術会議 S3
（廣田）
当社としては、例えばＭＥＳ（Manufacturing Execution System）だとかＥＲＰ（Enterprise
Resource Planning）との接続に直接にかかわるケースは少ないのです。しかし基本的にＰＬＣを見た場合、
例えば、フィールドネットワーク、最下位のセンサーなどの情報も、すべてシームレスで、例えば当社であ
ればＣＣリンク、メルセックネット、あとイーサでネットを含め上位とのシームレスな通信を行うことがで
きます。当然パソコン上のアプリケーションは、組んでいただかなければいけませんが、ドライバーを提供
しています。そういう意味ではＰＬＣであっても、いちばん最下位までのデータを取ることができます。あ
とはＳＩさんやユーザさんが、それをうまく活用していただくのが、実際的な当社としての回答になるかと
思います。
（新）
ありがとうございます。では、国際標準にも熱心なオムロンさん。
（浪江）まず上位系との接続については、今、三菱電機さんがおっしゃったのと近いのですが、やはり私
どもはドライバーをご用意しているというところです。このドライバーを使ってお客様のほうで接続をして
いただくのが、基本的なスタンスになっています。
それから、ネットワークの件ですが、私どもはフィールドネットワークに関しては、ＯＤＶＡに参画をし
ていますので、デバイスネットを推進させてもらっています。
その関係というか、同じプロトコルが走るコントローラ間のネットワークとしては、イーサネットＩＰに、
第１プライオリティを置いて取り組んでいくということでやっています。
その他の工業用イーサネットも幾つかありますが、これは日本とヨーロッパとで事情も違いますので、各
エリアにおいて需要の多いものがありましたら、それはエリアごとに考えていくという立場を取っています。
（新）
（中原）
ありがとうございます。それでは、横河さん、お願いします。
（新）
質問の範囲が多岐にわたっているので、ちょっと。
では、Ｖネット中心で（笑）
。
（中原）一応、二つととらえました。まず一つは、上位とのインタフェースという話が出たのですが、横
河としては、単なるインタフェースではなくて、いわゆるＭＥＳ情報系で行われている生産計画ですとか、
操業の解析・分析は、これからどんどん運転のレベルと密着してくるだろうと思っています。
そういう意味では、単につながるということではなくて、オペレータ・ステーションそのものが、もっと
21
計装制御技術会議 S3
シングル・ウィンドウ化して、さまざまな情報を、当然役割を持ったかたに応じて違うデータが見えなけれ
ばいけないのです。仕組みとしては、ＳＣＡＤＡという言葉がもうちょっと古めかしくなっているので、あ
まり使いたくないのですが、いろいろなデータを統合した形で、一つのウィンドウの中に情報として集約で
きるという方向の一つのコンポーネントとして、ＤＣＳのＨＭＩも入っていくという方向になっていくので
はないか。そういうところが、逆にいうとＤＣＳベンダとしての差別化部分なのかと思って、いろいろと開
発投資をかけています。
そういう中に、Ｖnet／ＩＰで我々は今のところ主に海外を中心に販売していますが、フルイーサネットの
ギガベースのプロトコル、あるいは情報系のプロトコルとの共存も含めたネットワークを出して標準規格に
今、プレの段階で承認いただいて、2007 年には標準化する方向です。
確かに各社が出しているのは、ＴＣＰ／ＩＰベース、もしくはＵＤＰ／ＩＰベースのプロトコルまではイ
ーサネットなのですが、ではその上のアプリケーションレイヤーはどうかというと、当然それぞれ各社ごと
に独自色を出しつつ、他社と差別化していかなければいけない部分もあります。そこが統合できるというの
は、もう少し先かなと。その前に最初にお話ししたＨＭＩの中に、どういうふうに情報統合できるかが、む
しろプロトコル以前に非常に重要なポイントになるかと考えています。
（新）センサー端子台レベルも、イーサネットにしたらどうかというご意見がありましたね。そういう方
向はＩＥＣの中にはありますよね。
（中原）今、横河電機としては、Foundation Fieldbus で、やっとデジタルネットワーク化にある意味、
片足を引っかけられたという状況で、まだなかなか日本国内ではインストールベースというか新規システム
が少ないこともあって、導入例は少ないのです。海外を見るとかなり特に大規模システムを中心に、中近東
や中国でもほとんど国家標準になりつつあるという中で、需要が増えているという段階です。
ただ、ご存じのとおり、ＦＦも過去に非常に長い標準化の歴史の中で、今の最新の技術から見ると、テク
ノロジー的に本当に今のままでいいのかという議論も当然あって、そういう中でイーサネットという話も出
てくるだろうとは考えています。やはり制御バス以上に、Ｉ／Ｏバスは実時間性がもっとシビアに問われる
部分ですので、そういう意味では将来的に当然、ＩＰｖ６も含めて、センサー側もそういう方向になるのは
間違いないと思います。では近未来的にどうかというと、もう少し時間が必要かと考えています。
（新）ありがとうございます。それから、今年から横河さんはＡＲＣフォーラムで、ＳＡＰとＤＣＳをＸ
ＭＬベースでつなげるというご発表をされていらっしゃいますね。大体それは一つの横河の方針だと思って
よろしいのですか。
22
計装制御技術会議 S3
（中原）そうですね。別にＳＡＰと仲良くしようというわけではなくて、ある意味、ＳＡＰが従来は割と
囲い込みで、非常にクローズした戦略だったのが、去年あたりからＳＰ95 に目を向けるようになったのもあ
って、我々としてはそうであるならば、我々はもともと、ＳＰ95 を含めた標準化の取り組みを進めておりま
した。そういう意味で、一つの手を握る相手の１人かなとは考えています。ＳＡＰの導入事例はかなり増え
てきているとは聞いていますが、まだまだ特に国内ですと、かなりカスタマイズ部分が海外の導入に比べる
と非常に大きく、なかなか制御までの一貫したシステム構築という話が本当に広がるのは、もう少し時間が
かかるのではないかと考えています。
（新）
ありがとうございました。
それでは、山武さんは、イーサネット対応は早かったですよね。
（岩崎）今日はちょっと趣を変えて、今、実はプラント向けではないのですが、山武として、ビルのシス
テムもかなり多く実績を持っていて、そちらのほうの動きを含めて、どういうことをやっているかをご紹介
しようと思います。
ご存じのように、ビルのシステムは、バックネットという、基本的にビルのオートメーションに対する標
準的なネットワークが、すでに定義されているという時代です。そこがないと、なかなかマルチベンダの対
応では、できないということがあり、当然ビルのオートメーションのシステムは、そこに準拠した形で
や
られているという状態があります。
ではプロセス向けはどうかというと、まだそういう状態にはなっていないというのが我々のとらえ方です。
では、今後どういうふうになるのだろうかというと、プラントの建屋のないところは少し別ですが、工場
（ファクトリー）を見ると、建屋の中にプラントがあるというケースも多々あるわけです。そういったとこ
ろで、一体どうなっていくかは今後少し注目すべき内容ではないかとは思っています。そこの中には、すで
にＩＰｖ６は標準的にサポートするような仕掛けになっています。もちろん、山武もＩＰｖ６対応というシ
ステムは、すでに販売をしていて、インストールの実績もあります。
そういう意味では、そういったベーステクノロジーの上に成り立っているネットワークシステムを、今後
はそういったベース技術としてやっていくのが、今のところ我々が考えている内容です。
コネクティビティそのものは、プロセス向けでどういうふうにやるかというところは当然ありまして、現
状はＯＰＣを使って、少しデータのマネジメントをやるぐらいのものが実績ベースとしては多いのかなと。
昨今、聞くところによると、我々にとっていいことかどうかは別ですが、かなりお客様の中でもアプリケ
ーションを特化して、アプリケーションのひな形をお客様自体がもう作られている。その下につながるデー
タは、マルチのベンダのＤＣＳをカバーできるような形、もちろんＰＬＣはそういう形ですが、そういうこ
とでされているお客様も何例かいらっしゃいますというのが、最近の傾向かなと思います。我々はそことは
23
計装制御技術会議 S3
少しやらせていただいていて、そういったアプリケーションのソフトウェアの価値を高めて、そこにはある
程度マルチベンダのデータをつなげていくという仕掛けは、標準的に持っていくというのが今まさにやって
いる内容ということです。
（新）ありがとうございます。山武さんはビルを中心に、ほかのベンダとマルチベンダ化はとっくにやっ
ているという、その実績をプラントにも持っていきたいのと、プラントも、制御系ネットワークだけではな
くて、建屋のコントロール、バックネットを含むようなものと連携を取らなければいけないと。これはちょ
っと新しい視点だと思います。ありがとうございました。
それでは、多比良さんの日立が、自律分散というネットワークを開発されて、それはＩＳＯ15745 という
形で国際標準にはなっているのですが、ＩＥＣはつきあっていないのですね。その辺も含めて、ご意見をお
願いします。
（多比良）まず制御ＬＡＮなのですが、当社もイーサネットを使っていまして、ＴＣＰ／ＩＰとＵＤＰの
技術を使ってやっているわけですが、二重化や診断のアプリケーションは独自開発のものです。
この部分が標準化されるかというと、今のところ困っていないし、特にコスト的にメリットがあるとか、
これからイーサネットがなくなってしまって、長期保守ができないというときに、各社団結してということ
がない限り、ちょっと採用は難しいのかなという気がします。
それから、当社製品のリプレースに限って言えば、先ほど工事配線もなしに頭だけすげ替えてやるという
お話もありましたが、ＰＩ／Ｏの部分を、できるだけ長く作るということをやっています。例えば、85 年に
開発したものをまだ頑張って作っているのですが、これは正直言って大変です。一月に幾つも部品の改廃が
ありまして、それに対応していくことをやらなければいけないのですが、そういうものに対応していくとい
うのが一つです。
それから、10 万点のプラントを継承するということがありますが、ここで 10 万点のタグを同じままつぎ
足す、あるいは他社が制御ＬＡＮに共存して、必ずしもやる必要はないのではないかと私は考えています。
先ほど横河さんがおっしゃっておられましたように、上位系、Ｓ95 などの標準技術を利用した上位系で、Ｍ
ＥＳ、あるいは経営レベルで統合して、その中から 10 万点というタグを監視すると、あるいは解析すると。
その中ではＤＣＳというのは、どのメーカーのというのではなくていわばブラックボックス化、カプセル
化して簡単にすげ替えられる。その辺のつなぎをいかにうまく行うかが、これからの課題ではないかと思っ
ていて、上位系の開発はそういう方針で進めていければいいかなと考えています。
（新）ありがとうございます。ユーザの皆さん、そんなものでよろしいですか。上位系との接続性をやっ
ていただければ、上位系でデータベースやほかのツールと連携できる形というのが、多比良さんのご提案だ
24
計装制御技術会議 S3
ったと思います。
（多比良）簡単につなげるというふうには多分、今はなっておりません。それなりの苦労をしてインタフ
ェースをそろえてということが現状です。
（新）
そのカスタマイズが要るということですね。
（多比良）
（新）
そのとおりです。
ありがとうございます。
それでは、次は大庭さんにお話しいただきたいのですが、大庭さん、今日もお話でエミュレーションとい
うことが出てきたのですが、前回、昨年のこの会議で端子台を残して、上でエミュレーションするというお
話をいただいて、随分議論させていただきました。そこのところは多分、また過去の議事録に載っています
から見ていただくということで、今回はＴＣネットとＩＥＣの話を中心にお願いしたいと思うのですが。
（大庭）当社の場合、イーサネットを制御ＬＡＮに使うという取り組みを比較的早くから製品化して、95
年あたりから小規模システムで、イーサネットベースの制御ＬＡＮを始めました。
最初は小規模からやって、
当時 10 メガのイーサですから、それからだんだん 100 メガになってきて、だんだん規模を大きくして対応で
きるようになってきたという歴史があります。今、国際標準に取り組んでいるのはタイムクリティカルＬＡ
Ｎといって、要は時間確定、データの衝突もないし、ちゃんと指定された時間内に相手にデータが届くとい
う技術を、イーサネットの上にかぶせて、それをＴＣネットという名前で、横河さんと同じようにＩＥＣ化
活動を行っています。
これは、ただ自社で使われるだけではＩＥＣ化しても意味がないので、今としてはいろいろな場で広報活
動をして、こういう技術です、こういうふうにして使えば、こんなメリットがありますというのを、いろい
ろな会議、いろいろな場所で広報していまして、仲間作りをやっている状況です。ですから真のマルチベン
ダになるためには、いろいろなところで、いろいろな製品にこの技術を搭載してもらって、各社で使ってい
ただくというのが最終的な姿だと思って、今は広報活動中という状況です。
それから、先ほど新先生から言われたように、これを制御ＬＡＮのところだけではなくて、下のほう、Ｉ
／Ｏのネットワークにも応用していきたいという気持ちはありまして、その辺も今後、検討していきたいと
考えています。
（新）ＩＥＣの中ではイーサ何て言いましたか、規格がありましたね。一緒に使う規格が。ご存じないで
25
計装制御技術会議 S3
すか。すみません。
では、ネットワークのことは中川さんに聞かないといけないので（笑）
。
（中川）
シーメンスの場合は、上位系もシーメンスでとなっている場合は、非常にスムーズに Total
Integration Automation（ＴＩＡ）をコンセプトにやっていますので、問題はないのですが、実際の仕事の
うえでは、既設がＵＮＩＸ系の少し古いものでやられたり、イーサネットといっても、そう簡単につながる
わけはないのです。そこで現実には、ＰＣＳ７が新しい技術もあるから、シーメンスのドイツのほうでゲー
トウェイをたくさん開発しています。例えばＧＥのシステムとは随分実績もあってすんなりいくのですが、
それは今、開発中で全部が全部用意しているわけではありません。
日本のメーカーのように独自のネットワークでやられているところについては、ゲートはゲートウェイで
やるのですが、これもなかなか開発は進んでいません。どうするかというといちばん確実な方法はモドバス
（Modbus）でつなぐのですが、これは遅いので、それは承知のうえでつなげているのが現状です。もう一つ、
ＯＰＣサーバを利用する手はあるのですが、このＯＰＣサーバは、各社の名前がついたＯＰＣサーバができ
るわけで、ＯＰＣだからといって、どこからでもすぐ読めるわけでもない現状があるのです。ＯＰＣの協会
のほうでは、ＯＰＣ−ＵＳとかＸＭＬでまとめて、やり取りしようかとなってきているので、それができれ
ばもっとスムーズにいくかなという現状です。
（新）
ありがとうございます。それでは、奥住さん。
（奥住）Ｉ／Ｏのほうは、他社さんのＩ／Ｏを残して欲しいというお話は現実的にあるのですが、これは
余程切り替え時間があれば別ですが、往々にして非常に短時間の切り替えになりますので、これはお断りせ
ざるをえない状況です。
というのは、そういうお話が来るものは、大体が 10 年以上も前のマシンですから、Ｉ／Ｏとコントローラ
がオープンでないメーカの固有のＬＡＮでつながっているので、そこは幾らやってもつなぐことはできませ
ん。
現在の技術でいえば、当社のはＩ／Ｏとコントローラは、Profibus-DP でつながっていますので、これは
そのＤＰの規約に則ったＩ／Ｏやコントローラであれば、相互に接続することができます。
あと上位のほうは今、中川さんがおっしゃられたことだと思うのですが、PROFINET に切り替わっていくと
いうのが、実際のタイムテーブルに載ってきています。どちらかというと、ＰＡのほうは比較的保守的なの
で後になると思いますが、ＦＡのほうが先行して変わっていくと思います。そのときにＩ／Ｏのところのバ
スも、PROFINET になっていくと考えています。
26
計装制御技術会議 S3
（新）
ありがとうございます。
今、ベンダの皆さんにお話しいただきましたが、ユーザさんから何か、この辺の継承性ネットワークにつ
いてご意見はありませんか。
（高野）継承性という意味では、やはりネットワークですね。上位というより、やはりプラントシステム
間でいかにつなげるかが、我々としては非常に大事になってきています。
けれども、実際問題として、ではそれをどうやっているかというと、特に海外の場合だと、プラントシス
テムの複数種のネットワーク間をどうつないでいるかというと、結局パラレルＩ／Ｏでつなぐことになって
しまっている。プロトコルでつなぐのはまだまだ大変というのが現状です。
ここを何とかネットワークとネットワーク間で、我々もそこをリアルタイムの制御のものをつなごうとは
思っていなくて、ある情報をもうちょっと遅い時間、例えば１時間とかそういう周期でつなげればいいとい
うことを考えています。例えば、ＴＣＰ／ＩＰのようなプロトコルで、バッチでＸＭＬファイルを交換する
とか、そういったものを持ってこないと、ここの部分は解決していかないのではないかと思っています。こ
れはコメントです。
（新）高野さんについでにお聞きしたいのですが、ＯＰＣはどう評価されていますか。各社ＯＰＣがある
というお話があって、一応、標準で接続性で、今みたいなものをみんなまとめて扱えるという形が、ＯＰＣ
だと思うのです。現状のＯＰＣと、それからＯＣＰさんはＸＭＬという形のものを出して、さらにＵＡとい
う形のものを出される。後で Windows の話が出てきますので、
ちょっと先も見据えてどうなのかというのを、
一回ユーザに聞いてみたいところなのですが。
（高野）二つ論点があると思うのですが、まず１点は、ＯＰＣ自体は、データをつなぐ手段を提供してく
れているということなので、そのツールは使えばいいのでしょうけれども、やはり苦労するのはツールのデ
ータの中身なわけです。例えばＤＣＳベンダさんであれば、ＤＣＳベンダさんのタグ間をどうつなぐかが、
いちばん課題になるところです。そこをやはり解決していかないといけないということで、まだそこまでは
踏み込めていないだろうと思います。
もう一つは、本当に今のＯＰＣがこの先ＸＭＬドリブンになれば、使っていけばいいのではないかと思っ
ています。
（新）では、ネームスペースの問題が現状のＯＰＣにはあるというのと、ＸＭＬ化に対しては非常に期待
していると取ってよろしいでしょうか。はい、ありがとうございます。
それでは、
ここで休憩を 10 分取って、
休憩のあとは情報セキュリティの話、
皆さんが標準化に向っていて、
27
計装制御技術会議 S3
みんなイーサネットで通信するといったら、浮上してくる問題はセキュリティの問題ですので、次はその問
題から入っていきたいと思います。
−休憩−
（新）続いて、セキュリティに移りたいのですが、休み時間にご質問が来まして、「ＯＰＣサーバはいいの
だけれども Windows は嫌だ」というご意見で、
「ＵＮＩＸベースのＯＰＣ接続は日本ベンダでは提供されてい
ない。ＤＣＳ、ＰＬＣ、ＯＰＣ、Windows 以外での接続環境実現を行う方向はあるのでしょうか。ヨーロッ
パでは行っていると聞いていますが」というご質問です。先ほど、ＯＰＣの話題をしましたが、どなたかお
答えいただけるかたはいらっしゃいませんか。ＯＰＣ Linux というのもあるというのを聞きましたし。
それから、ＯＭＧ（Object Managing Group）が、ＤＡＩＳ（Data Acquisition from Industrial Systems）
というのを標準化しています。このＤＡＩＳは、どちらかというとヨーロッパやアメリカの電力系で使われ
ているもので、ＵＮＩＸベースでデータを収集するシステムですが、中身はＯＰＣの人が作りましたので、
ＯＰＣとの接続性がいい。現実にＯＰＣとアダプタを介して、データ交換をすることは、おやりになってい
ると私は聞いていますが、何かそれ以上の情報をお持ちのかたはいらっしゃいませんか。
ということで、すみません。その程度しか答えられませんけれども、一応ＯＰＣ Linux という話があるの
と、それから、ＯＭＧのＤＡＩＳという国際規格、ミドルウェアの規格があります。それは特に、電力の監
視系のデータ収集でＯＰＣとの接続性は出ています。
これは標準化には日立さんが加わっています。多比良さんはご存じないかもしれませんけれども、システ
ム開発研究所というところが知っていますので、もしとっても興味があるのでしたら私に聞いてください。
よろしいでしょうか。
それでは、今のイーサネットみたいなものを標準にする、または継承性を上げていくトレンドは、ある意
味でセキュリティ面では危険で、独自のプロトコル、独自のバスであれば大丈夫なのに、攻撃されるという
ことです。割と各社ベンダさんの出してきたものは、ゲートウェイを設けるという例が多くて、これは多分、
全部やられると思いますし、山武さんはセキュリティフライデーという会社まで起こされてなかなか活発に
活動されていらっしゃると聞いています。
一つ議論したいのは、これも休み時間の間に討議票を頂いて、質問として、
「各ユーザはちゃんとセキュリ
ティ・ポリシーをベンダに示しているのか」。
「自分たちのセキュリティ・ポリシーはこうだから、こういう
ふうに作れ」とちゃんと言っているのかというご質問で、ベンダだけ責めてもしょうがないですね。ユーザ
さんもセキュリティって何かよく分からないところがあります。
時間の制約もありますので少し問題を整理させていただくと、大体上にゲートウェイを設けて、ファイア
ウォールを設けて、外からはＩＰフィルタリングなどして、入れないようにするというのが常識で、それは
28
計装制御技術会議 S3
おやりになっていらっしゃると思います。問題は中側でありまして、特にご承知のとおり、メンテナンスな
りエンジニアリングをする人が、ノートパソコンを持ってきて内部の接続をしないと、ちゃんと動いている
かどうか確認できないという問題があって、そのパソコンが感染していると、そこを通して広がってしまう
という問題があります。ですから、上のゲートだけを守っていればいいという問題ではなくて、裏側でエン
ジニアリングをやらなければいけませんから、そこに対するセキュリティを考えなければいけない。
それを考えると各機器に対して、アンチウイルスのソフトを入れなければいけませんが、それをいつも更
新しなければいけないという問題が生じます。この中でも WindowsＮＴのエンベデッド版がありましたが、
ご承知のとおり WindowsＮＴはバグというか、セキュリティホールがあり、そうするとエンベデッドのやつ
を全部、パッチを当てなければいけないというと、ものすごいエンジニアリングが生じることになります。
ハードディスクではありませんから、それで大変苦労されたかたもいらっしゃるわけです。
マイクロソフトは、月に１回必ずアップデートをしていますので、これはどうするのだ。特にまず一つは
アンチウイルスのソフトを入れると、では制御系なりＨＭＩと干渉が起きるか起きないかという問題があり
ます。
もう一つは、そういうマイクロソフトのパッチを入れたときに、それぞれの機能がちゃんと動くかどうか
という保証もされていなくて入れていいのか。入れないとそのままセキュリティホールが残るという、非常
に大きいジレンマがある。
これはユーザさん各社も、皆さんご指摘の問題だと思うのですが、ちょっとそこら辺を議論したいのです
が、最初にちょっとユーザさんをいじめることにして、ちゃんとセキュリティ・ポリシーがあるかないかだ
けちょっとお答えというと、それは答えられないですか。では、セキュリティ・ポリシーに対して、各社ど
うお考えかみたいな、これから設定するとか、すでに設定しているとか、考えなければいけませんねとか、
そういうレベルでけっこうですので、現状はどうでしょうか。
高野さんは、この問題は関心が高いですから（笑）
。
（高野）
セキュリティ・ポリシーは我々は二つです。あまり難しいことを考えないようにしています。
まず一つは、分かっているウイルスであるとか、クラッキングの脅威ですね。これに対してはかからない
ということです。これをまず一つ最重点に考えています。
もう一つは、先ほどちょっとおっしゃいましたが、バージョンアップだとかいろいろなエンジニアリング
を、特に設備制御のそういったシステムについては極力やらないようにしたいということで、よくあるのは
例えば Windows をデフォルト・インストールしてしまうとか、いろいろなポートが開きっぱなしになってい
る。そういうことを徹底的に排除し、制御に必要なものしか入れないことを、我々としてはやっています。
これは実績としては、今年はエンジニアリングを一回もしていないです。チェックだけして、ここのポート
が閉じているから大丈夫と、そんなことをやっています。
29
計装制御技術会議 S3
ポリシーとしては、大きくその二つだけなのです。それに基づいてこうやってくださいという仕様を、参
加していただいたかたは分かっていると思うのですが、３ページぐらいの仕様書を書いていますので、それ
に従ってやっていただく。そんなことをやっています。
（新）それは例えばセキュリティホールがあっても、こちら側がポートを開けていないものに関しては更
新しない？
（高野）
（新）
そうですね。パッチも当てないというようなことです。
制御に必要なポートに関するセキュリティの更新はいつもする。そうでもない？
（高野）そうですね。これはベンダさんが、タイムラグがありますので、バージョンアップに対して保証
するという、タイムラグの時間があるので、我々はその時間を稼ぐという意味もあるのです。そういったポ
ートを閉じていて、ベンダさんは必ず大丈夫だよというところまでできて、ちょっと枯れてからバージョン
アップすることを考えています。
（新）
なかなか賢いですね（笑）
。では、梶原さん。
（梶原）セキュリティ・ポリシーがあるかないかというご質問ですが、情報システム系に関しては、セキ
ュリティ・ポリシーというか、情報管理規定や電子情報管理手続があります。今、話題に出ましたが、パソ
コンを家に持って帰って使ってはいけないとか、全社ネットワークに繋ぐ場合は、きちんと情報システムが
管理したパソコンでないと繋いではいけないとか、そういった管理規定はあります。
一方、制御システム系に関しては、最近、ＭＥＳ化というテーマがありますので、ガイドラインを作った
段階です。それは、基本的には山武さんのお話にもありましたように、制御システムと外部や情報システム
系とはゲートウェイを介してやらなければいけない、その時にはこうしなさいというガイドラインを２年前
に作りました。
今、気になっていますのは、従来クローズされ、聖域になっていた制御システムの中のセキュリティを一
体どうしたら良いのかということです。今日のご説明の中で、日立さんがオペレータコンソールのサーバ側
にセキュリティ対策をするというお話がありましたが、今後、入れた場合に、パッチ当てとか、性能保証と
か、
スピードとかいろいろな問題があるかと思うのですが、どういう姿が良いのか分からないのが実情です。
（服部）東京ガスの場合ですと、セキュリティ・ポリシー自体はありまして、情報システム系のものと専
30
計装制御技術会議 S3
用システムものと、若干異なった位置づけで運用しています。
工場の制御・監視に使用するＤＣＳのような専用システム系のものについては、基本的には上位とつなぐ
ということはなくて、完全にクローズした世界で運用することにしていて、かつ、人のアクセスに関しては、
関係者以外は触れないようにするというのが基本になっています。
ほかのシステムと、どうしてもつながなければいけないものも幾つかあるわけですが、先ほどの説明があ
りますように、ゲートウェイで分離する等の対策を講ずるという考え方で運用しています。
（今任）三菱化学の場合は、事業所、社内のＬＡＮに接続するケースがありますが、これはプラントワイ
ドにデータベースを構築したり品質データを共有したりという場合で、基本的には社内ＬＡＮのみです。社
外のＬＡＮに直接接続しないというルールがありまして、社内ＬＡＮであれば皆様と同様にファイアウォー
ルがあるというのが一つです。
それから、システム間という意味では、基本的にはルータをシステムごとに置いて、そこで一応、歯止め
という形のみしかありません。
あと人の面ですが、随分昔から、ＩＳＯを取得したときにシステムごとに記憶媒体リストを作って、管理
すべき媒体とその履歴の管理をやっているのですが、それ以外のものには全く今のところノーチェックの状
態です。例えばＵＳＢメモリをだれか持ってきて入れて、何かやり取りするとか、サービス員のかたが接続
するパソコンがどうだとか、そういうところは、現状は性善説で運営しているのが現実です。ビジネスネッ
トの個人端末では、やっと今年に入り、世間では最近いろいろと問題がありましたが、そういうものに対し
てのセキュリティや管理がやっと決められたところですので、制御系についてはまだこれからどうするかと
いう状態です。
あと、私どもは三菱化学以外のお客様のシステムを構築する場合は、運用面はお客様の中の話になるので
すが、ハード的には先ほど申し上げたように、ファイアウォールと、あとルータを置くという形で設計・施
工をやらせていただいています。
（杉浦）森永乳業の場合も、基本的には制御システムはクローズシステムで、社外のものとはつながらな
いと。社内のＬＡＮとはつながることもありますが、これも比較的ケースとしては少ないという形でのデザ
インを取っています。
Windows のソフト、過去のＮＴレベルのところまでは、どちらかというとメーカーデフォルトでそのまま
動いています。ＸＰになってから、先ほど高野さんも言われたように、やはり余計なポートは開けない。も
ともとの設計がデフォルトで、開けない方向に変わりましたので、必要なものしか開けない方向に変更して
います。
あとアンチウイルスソフトに関しては、なかなかいろいろなソフトがあるので「これを使え」と言えない
31
計装制御技術会議 S3
状態ですので、ある意味ではユーザ責任で入れていただいている形になっています。
それと Windows のパッチソフトに関しては、パッチを当てると、動きが変わる危険性が非常に高いので、
基本的には導入後、ユーザが勝手にパッチを当ててはいけないという形で運営しているのです。新しくパソ
コンを買うと、新しいパッチが当たったマシンが嫌でも来てしまうということで、そのつど対応を取る。で
すから、６か月置きに新しいマシンが出るたびに、大体適合性の確認をして、社内で使えるような状態にし
て出しているという状態での運営になっています。
ですから、今の質問のセキュリティ・ポリシーがあるかといったら、つながないというのがポリシーだと
いう状況です。
（千田）新日本石油の場合は、あるかと言われると、なかなか答えづらいところがあるのですが、同じよ
うに外部とは接続しないというのが、基本的にやってきたことだと思います。
情報系はどこの会社も同じようにやっていると思いますが、ウェブサーバにファイアウォールを設けるの
が原則だと思います。コントローラというか、制御系のアクセスについては、基本的には制御系にはアクセ
スはできない感じで、吸い上げはできるけれども、アクセスはできないということで、そういう仕組みを作
っています。情報を上げる場合にも、先ほど言ったルータなどを通してやっているということです。
では、制御系というか、コントローラを改造しなくてはいけない場合があるのですが、基本的には、当社
の場合はベンダにお願いしているのですが、まずは勝手にパソコンをつなげることはさせない。基本的には
エンジニアリング・コンソールがありますので、そこでしか作業を認めないようにしています。
その作業をする場合も、これはＤＣＳだけではないのですが、計装品も含めて、工事する場合には、そう
いう要領書がありまして、この作業をやりますよという書類を設計というか設備管理から発行して、それを
持ってベンダが現場に行って、オペレーターというか、当直のＯＫをもらってから、作業をしなくてはいけ
ないということで、人の出入りの辺は十分管理しているということです。
そういうところで対応していますが、今後、外部からアクセスできるような状態になることが考えられる。
先ほど言ったように、無線ＬＡＮなどが使えるような状態になってくると、また新たな制御系のほうのウイ
ルス対策も必要になってくるのではないか。若干そういうところを感じています。
（西條）ライオンの場合、情報系に関してはセキュリティ関連は非常に厳しくて、個人情報とか外部メデ
ィア、フロッピーディスク、あとＵＳＢメモリをさしていいとか、そういうことが非常に厳しくなっていま
す。あとｅメールやホームページは、どういうものを見ていいよとかいうところまで、非常に厳しくなって
いまして、うちでいうと今月中に e-learning を使って、必ず各自勉強しなさいといったことで、個人情報を
含めて情報系に関しては非常に厳しくなっている状況があります。
ではＦＡ系はどうなのかと言われますと、若干甘いところがあります。ではどういうことをやっているか
32
計装制御技術会議 S3
というと、ＦＡに関しては基本的に Windows のパッチのみを当てるようなことだけを今対応しています。パ
ッチを当てる場合も、各社さんで一応確認が取れたという段階でだけ、要はメーカーのほうから大丈夫です
よというＯＫがあったときだけ、Windows のパッチを当てることをしています。
ウイルスチェック・ソフトを入れていないのかという場合があると思うのですが、基本的にいろいろなソ
フト間で相性があったりしますので、ウイルスソフトに対しては入れていません。
また、今年あったと思うのですが、ウイルスバスターのＣＰＵ100％を食ってしまうという場合、そういう
ことがありますと、ＦＡ系は非常に困ってしまうので、基本的にはウイルスソフトは入れていないです。
では、ベンダのかたに対して、そういうセキュリティ・ポリシーを提示しているのかということに対して
は、トヨタさんはたしか「このソフトを入れてくれ」とかいうのがあると思うのですが、うちの場合は特に
セキュリティ・ポリシーを、ベンダさんに投げているといったことは今しておりません。
（新）ありがとうございます。これはユーザ側の事情で、今度はベンダ側の事情はどうなっているのかを
聞きたいと思います。
例えばベンダさんの場合、それぞれお客さんの要求にこたえて、たくさんのアプリケーションをお作りに
なっていて、それを全部チェックしないといけないと、大変ですね。だから今、西條さんがベンダがＯＫと
言ったものだけ更新すると言ったわけですが、ＯＳは違うは、アプリケーションは違うはといって、その中
で全部組み合わせを調べなければいけないというのは、なかなか大変な負担だと思うのです。そこら辺の事
情も含めてご意見を伺いたいと思いますが、奥住さん、いかがでしょうか。
（奥住）大変難しい問題で、そういうことも含めて、当社の場合、パソコンについてはインダストリＰＣ
と、それがバンドルされた形で、組み合わせと機能が保証されたＯＳとシステムのバージョンということで
お出しする形を標準としています。ですから、Windows のパッチ等も含めて、ＭＩＣＲＥＸ-ＮＸのバージョ
ンの中に、サービスパックという形で提供するようになっています。
それから、できていないこともたくさんあるのですが、できていることとしては、ＯＳクライアントには、
やはりウイルス対策ソフトが入るという可能性がありますので、入れられるソフトとそのバージョンと、こ
ちら側の製品のバージョンの組み合わせを確認したものを情報提供しています。
あと、先ほど山武さんのセキュリティゲートウェイと同じようなものかと思うのですが、インダストリ・
イーサの中に介在させるような、セキュリティモジュールが用意されています。そこで、プラントバスのと
ころにおいても、ある意味でのセキュリティが確保されるのかと。そういうあるものをうまく使っていくと
いうことですが、今後はそれを全体としてどういうふうにセキュリティを確保するのかを、きちんと我々の
ほうも研究して、ガイドラインのような形をまとめて、きちんとしたデザインができるようにしていきたい
と思います。
33
計装制御技術会議 S3
（新）それで、次の WindowsＨＭＩも絡んでくるので、一つご質問をご紹介したいのですが、東京ガスの
木村さんから、ＨＭＩはほとんど Windows になっていますが、Linux の製品は無いのでしょうか。あれば購
入費用にどのぐらい差があるのでしょうかというご質問があるので、すみませんが、一緒にお答えいただけ
るとありがたいのですが。
（奥住）
（新）
Linux 製品は、ありません。
ありがとうございます。では、中川さん、お願いいたします。
（中川）私たちのところでは制御系内の制御システム構築をやっていくときに、それの作業用のパソコン
については、ウイルス対策ソフトをしょっちゅう更新して、そのぐらいしかやっていないのです。あとは、
お客さんのところにシステムが入ったときに、お客さんが上のシステムとつなげるとき、いろいろとどうす
るのですかという相談をする程度ですよね。やはりお客さん次第かなと思います。
（大庭）マンマシンのところのソフトですか、ＯＳと標準のソフトという形で、ＯＳにパッチが当たった
時はマイクロソフトの回数には全然合わなくて、ある期間まとめて検証して、あるタイミングでバージョン
アップという形でリリースするような形態を取っています。
マンマシンのところなので、ウイルス対策ソフトは入れていないのが現状です。性能に影響が出るという
ことで、外部から入らないように、ゲートウェイのところで何とかシャットアウトする。そういう形で、制
御ＬＡＮにつながるマンマシンのところには、ウイルスソフトは入れていないというのと、バージョンアッ
プはそのつどではなくて、
ある期間まとめて検証を十分したあとで、
リリースするという形を取っています。
それから、Linux のマンマシンはありません。
（多比良）私どもは、まず、セキュリティパッチはある期間、例えば半年とかそういう単位で、その時の
ものを入れまして、確認してだんだん積み上がってくる形になっています。
すでに製品をお納めしたお客様に対して、出張的に対策をするようなことはやっておりません。ただし、
問い合わせのあったお客様に対しては、そのセキュリティパッチを適用していいかどうかということは、お
答えするようにしていて、あとはお客様のリスクでやっていただいているのが現状です。
あと内部のウイルス等に対する対策ですが、オペレーターズ・コンソールですと、リアルタイムに動いて
いるものですので、アンチウイルス的なものは動作に影響しますので、現在のところは入れておりません。
こういうものは定期点検の場合にチェックをするということで、現在はやっています。
34
計装制御技術会議 S3
それから、先ほどシンクライアントの場合、セキュリティはどうなのかというお話がありましたが、シン
クライアントシステムの場合にもやはりセキュリティの問題は残っていて、ターミナルサーバ側で、やはり
同じようにウイルスのチェックもやらなければいけませんし対策もしなければならない。シンクライアント
の場合も、同様の対策はやはり必要な状況になっています。
それから、Linux のマンマシンはありません。ただし、別製品系統で、サーバに使っている例はあります。
ウェブサーバ、それから、ユビコンポという製品で使ってはいます。
（吉田）山武ですが、今日も回答書の中で一つお入れしました。ゲートウェイを、まずユーザから何もな
い場合は、これをまずご推奨して、採用の是非をはかるのが第１になっています。
これは先ほどもお見せしましたとおり、制御ＬＡＮと、それから上位の情報系につながるＰＣとの間に入
るもので、ある意味ルータの機能、それからセキュリティ・ファイアウォールの機能、それからウイルスチ
ェックの機能を全部兼ねたものになっています。今これが実務上、最も効果的、実用的なのかということで
採用しています。
実際に今まで、私の個人的な経験というか観測でしかないのですが、どうも休み明けにウイルスが混入す
るという事象が多くて、なぜか休み中にウイルスが発生することもあるのですが、休み明けに感染する。当
社でもそうなのです。多分、多くは情報系のどこかに皆さん、ユーザさん、私どものメーカーも含めて、だ
れかがつなぎ込んだところから感染するというのが、いちばん多いのではないかと観測しています。そうい
う観点でいうと、このゲートウェイは一つ有効なものとして認められるかなと思います。
それからもう一つ、これならず、イーサネットスイッチか、ハブルータのたぐいが、まだまだ技術的にか
なり向上しているように見受けられ、むしろこういったものを最大限活用していく方向を取るのが、一つの
道ではないかと考えています。
先ほどのコンペでも、20 年間というのがありましたが、恐らく 20 年後このゲートウェイはないのではな
いかと思いますが、こういうものを順次最適なものを採用しながら、ユーザさんに運用を図っていくという
のが、今の方向性だと申し上げられると思います。
それから、もう一つは先ほどのセキュリティパッチ、HotFix ですが、これは先ほどユーザさんからもあり
ましたとおり、当社のほうで専門部隊が稼働をチェックして、ちゃんと稼働するものなのかどうかを確認し
たうえで、ユーザにそれをお勧めする形になります。その形は定期的なサービスの一端としてやる場合もあ
りますし、スポット的にやらせていただく場合もあります。現状はごく一部のユーザで、生産系のところの
アプリである程度定期的に、例えば３か月に１回とか、そういう運用をされているところもいらっしゃいま
す。しかし、むしろほとんどは、あまり触らずに、とにかくできるだけ今のまま動かすというほうが、どう
も現状の動向かと見受けています。
もう一つ、今度は制御系内部という話になって、制御系内部は幸か不幸か、今はまだマルチベンダの環境
35
計装制御技術会議 S3
で、外に直接つながるような形で運用をされているところは、そんなに多くはない。むしろ少ないといえま
すので、そこに対する運用は、まずエンジニアリング・ツールみたいなものは、とにかくお納めしたオペレ
ータ・ステーションの中で、何台か、１台なり数台を、エンジニアリング機能を持たせて、そこで一元的に
やることを基本にさせていただいています。それができないシステムの場合は、実際の運用上で、弊社のエ
ンジニアなどが持ち込むものに対するチェックを、組織的にそういうものを持ち込まないように防ぐという
方法で、今は運用しています。
この辺は実を申しますと、いろいろと現場で痛い目にあったこともあり、そういった経験的なものも踏ま
えて、今はそういう製品と、それから運用の採用になっています。
（中原）セキュリティに関しては、午前中にお話ししましたとおり、横河がお納めする制御システムのセ
キュリティ・ポリシーはかくあるべきではないかという、基本的な横河サイドの考え方をまずお示しして、
それをお客様のセキュリティ・ポリシーと合わせ込んでいくというプロセスを経て、最終的にお客様に納め
るという形を取っています。
やはり、ポリシーと同時に、運用されるのはお客様なので、お客様がどういう形で運用されるのか。我々
の横河の情報系でも、最近、パソコンの外部持ち出し禁止、ＵＳＢ持ち出し禁止とか、非常に厳しいルール
がだんだん始まっています。そういう意味では、情報系だけではなくて、制御系にも同じようなオペレーシ
ョンが、いずれ必要になってくるのではないかと考えています。
先日、海外の石油会社さんとお話ししたときに、どうも話がかみ合わないなと思って、よくよく聞いたら、
我々は当然、制御システムを外部から守るというスタンスで考えていたのですが、どうもお客様が考えてい
るのは、やはり経営システムを守ると。経営の情報インフラを守るために、制御系とはこういうふうにプロ
テクトしたいと。ですから、向きが全然違うことが分かったのです。
それも我々にとっては勉強だったのですが、やはり立場が変わると考え方も変わる。当然、我々は制御の
担当のかたともお話しするのですが、お客様の情報系のかたともお話しすると、必ずしもお客様の情報シス
テム担当者と、制御担当者の考え方が一致していないケースもあります。結果的に、ベンダが間に入って苦
労するというケースもあって、この部分の話は、まだまだお互いに経験を重ねていかなければいけない部分
なのかと今思っています。
あと、先ほどパッチのアナウンスが遅いという苦言を頂きましたので、ここら辺は社内に帰ってフィード
バックしたいと思います。我々もあるリソースの中でやっていますので、それは当然重要なので、やるので
すが、あまりにもマイクロソフトのパッチの頻度が、最近落ち着いているように思いますが、かなり高頻度
で来ると、ある程度のバッチ的に処理せざるをえないのも実情です。
そういう意味で、本当にこのパッチは当てるべきか、当てるべきではないかという判断も踏まえて、情報
は出すように努力しているところです。
36
計装制御技術会議 S3
（新）
まだ発展途上という意味では、やはり議論が大事ですね。
それでは、浪江さん、お願いできますか。
（浪江）ウイルス対策を含むセキュリティに関しては、基本的にはシステムインテグレータさんとユーザ
さんとの話し合いの中で、決めていただくということで、当社として直接的にタッチすることは、ほとんど
ありませんので、コメントを控えさせていただきます。
ＯＳのバージョンが上がるということについては、サービスパックレベルでバージョンが上がった場合、
当社のエンジニアリング・ツールとか、一部ＨＭＩソフトもありますので、そちらのほうの動作確認はやっ
ています。
（廣田）例えばＰＬＣであれば、今回のセキュリティと関係ないかもしれませんが、いわゆるパスワード
をかけておけば例えばプログラムの変更ができません。表示器の場合、例えば画面データに関しても、パス
ワードをかけておけば、例えば外部の人が簡単に変えられないということです。
あと、Windows に関しては、当然、我々は表示器としてグラフィック・オペレーション・ターミナルを持
っているのですが、それは Windows のＯＳで動いているわけではないので、ウイルスに関しては、あまり基
本的に関係ないかと思っています。ですから、例えばプログラムをエンジニアでない人に勝手に変更されな
いように、パスワードをかけて、不特定多数の人が変えられないといった対策になるかと思います。
もう一つは、例えばリモートメンテナンスで、特に最近、海外進出する日本企業が多くなっていて、例え
ば１次診断を、国内からリモートメンテナンスしたいといったとき、当社、三菱電機としては、例えばＭＩ
ＳＴＹなどの暗号化技術がありますので、それらを、そうしたリモートメンテナンスに使えないかと検討は
している状況です。
（新）ちょっと廣田さんにお聞きしたいことがあるのですが、マイクロソフトのホームページを見ている
と、三菱電機さんが Visio を活用した事例というのが出ていますね。
（廣田）
ありますね。
（新）ラダーを Visio で書いて、ＰＬＣを動かすというので、それは割と三菱電機としては、そういう方
向に行くのでしょうか。
（廣田）今、言われたのは多分、検査装置、MELQIC というラインの製品を検査する製品があり、我々は名
37
計装制御技術会議 S3
古屋でやっているのですが、この製品は姫路でやっていて、その辺の技術的な交流は具体的にはあまり多く
ないと思います。Visio のほうに行くかどうかは、何とも答えようがない状況です。
ただ、Visio でプログラムを作ることに関しては、非常にユーザさんから評判がいいというのは聞いてい
ますので、その辺は何らかの技術的な連携はしていく必要があると思っています。
（新）それでは、ユーザさんにお聞きしたいと思います。大体今こういうアプリケーション作成や管理は、
グラフィカル・ユーザ・インタフェースでやるというトレンドになってきていると思います。そうすると、
各社みんなエンジニアリング・ツールが違うわけですね。そうすると、操作性も違ってきますから、今ご紹
介した三菱電機さんの取り組みのように、マイクロソフトのオフィスの製品を使って、グラフィカルに横河
さんでも山武さんでも日立さんでも東芝さんでも、同じように扱えるとうれしいのではないかと思うのです。
そういう、いわゆるマイクロソフト製品利用という流れと、それから、ご質問にもあった Windows は危な
いから嫌だ、Linux がいいという、または専用のツールのほうがいいという流れとあると思うのです。その
辺、例えば聞きたいのは、マイクロソフト対応をもっと深めていく方向に、ベンダは開発したほうがいいの
か。それとも、そうではない方向を模索したほうがいいのかが、けっこう悩みだと思うのです。
何かご意見があればお伺いしたいと思うのですが、高野さん、いかがでしょうか。どちらに走ったらいい
のでしょうか。
（高野）
非常に難しいご質問なのですが（笑）。
まず一つ、我々として考えているのは、とにかくテクニックとしてはベンダフリー・テクニックの方向に
行きたいということです。あともう一つ、つなぐ標準というものについても、ベンダフリーな標準でやって
いきたいということが、まず大前提としてあります。
そういった意味では、方向性としては、マイクロソフトさんの何かの新しいバージョンのこのツールとか
着目するのではなくて、そういう業界が進んでいる、例えばＸＭＬのこういうフォーマットであると。そう
いう方向に我々は進みたいとは考えています。
（新）そういう意味では、日立のシンクライアント的なやり方ですね。多分ウェブブラウザで観測して操
作するという方向なのですね。多比良さん、シンクライアントと言っているのは。
（多比良）実は、シンクライアントの基礎技術としては、マイクロソフトの技術を使っているので、その
辺は変わらない（笑）
。
（新）なかなか難しい議論ですが、分かりました。だから、基本的にはウェブ技術みたいなものだったら、
38
計装制御技術会議 S3
ベンダフリーみたいに使えるということですね。
梶原さん、何かご意見はありますか。
（梶原）マイクロソフトの方法でいいかどうかというのは、私はちょっと分かりません。ただ弊社の場合、
ＤＣＳやＰＬＣは、いろいろなメーカーのものが入っていまして、実はメンテナンスという面で考えたとき
に、要員というか教育に非常に困っています。だから、ベンダフリーなエンジニアリング・ツールがあるこ
とは、ユーザにとっては非常にありがたいので、もしそういうものができたら、非常に歓迎なのです。それ
がマイクロソフトベースがいいのかどうかというコメントは、私はちょっと分かりません。ユーザとしてみ
れば、そういうものがあればいいなと。
（新）チョイスの一つとして、マイクロソフトがあるのはかまわないわけですね。ベンダフリーというこ
とね。
（梶原）はい。ただ、いろいろな性能保証がありますので、各ベンダさんに、性能保証されたものを提供
していただきたいというのはあります。
（新）
ありがとうございます。服部さんはどうですか。
（服部）マイクロソフトを使うかどうかという話ですが、当社の場合ですとプラントの制御監視を行う制
御系のシステムと、統括管理を行う情報系のシステムとは、位置づけが全く違いますが、少なくとも制御系
のシステムについては、マイクロソフトを積極的に使うことが歓迎されているとは限りません。古い考え方
かもしれませんが、プラントを動かしていくのに必要な機能は、何だろうかと考えてみますと、ソフトウェ
アがちゃんと動いて、かつオペレーターがミス無く安全に、しかも省コストで操業できればいい。こう考え
ていきますと、20 年前、30 年前と比べて一体どういう点で進歩があったのか考えてみると、その背景として
マイクロソフトを使うことが決定的に大きく寄与しているとは考えられないという、ややおかしな話になる
のかなと思っています。
30 年前は、計算機を使った制御システムと、１ループコントローラとの混在型のような時代だったと思う
のですが、ＤＣＳと呼ばれるような計算機になって、だいぶ省力化してきた。現在までの導入実績からを考
えてみますと、オペレーターあるいはメンテナンスサーにとってありがたい、ありがたくなった機能という
のは何だろうかというと、決定的なものはなく、本質は何も変わっていないのではないかと思えます。
その大きな理由は莫大な労力を要するソフトウェアのソースレベルの構築というワーク自体が、マシンや
構築環境が改善されたにせよ、
どんなに頑張っても変わらないからだと思います。
何が変わったかというと、
39
計装制御技術会議 S3
コーディングする際の容易さの辺がだいぶ作りやすくなったという点と、それから、オペレーターが操作性
がよくなった。あるいは警報がたくさん出てくる中で、そういうものを分析できるようになった、使い勝手
が良くなった、等の点だと思います。この辺がだいぶ違ってきているとは思いますが、これらは何もマイク
ロソフトがあったからできたかというと、必ずしもそうではないような気がしてなりません。ユーザから見
ますと、それがマルチベンダというのか、何も別にマイクロソフトにこだわらずに、そういった機能が担保
でき、昔の機能と同じように今風の便利なツールを生かした形で今後 10 年、20 年使えるといったものであ
れば、何もマイクロソフトのものを使う必要は、必ずしもないのではないかと考えています。
（新）
ありがとうございます。今任さん、いかがですか。
（今任）どう答えていいのか、何も考えていないと言ったほうがいいのかもしれません。使わざるをえな
いからマイクロソフト、Windows 系ですね。各ベンダさんは、新しいものはその流れですし、いざ更新しよ
うとしても、選択肢は基本的に我々にはない。かといって、それに対抗するものを独自に開発していく余力
もないというのが、Windows 問題です。もし何かやろうとしても、ではそれを会社として自分たちで保守し
ていくのかと言われたとき、それも非常に重たい課題ですから、とりあえず流れに乗っているというのが正
直なところかと思います。
幸いにして、いろいろな情報系のものは最近、ビジネスネットもそうですが、マイクロソフト系、Windows
でやっていますので、問題があるときは、みんな同じ問題を抱えるわけです。そのときにどうするかを考え
ようというのが、安易かもしれませんが、実態かと思います。
ただ、やはりマイクロソフトの恩恵を、いろいろとあずかっているのは、いろいろなパッケージ類を私ど
もは作って、いろいろなお客様にも提供しているわけです。いろいろなお客様は、日常のデータの管理はＥ
ＸＣＥＬシートを使われているというのがあり、そういう恩恵にあずかって飯を食っているというところも
あります。一概にマイクロソフトは悪いとも言いづらいし、何とも言えないのですが、今のところは問題な
く何とか行っているので、このまま引き続き問題がないことを期待しているというわけです。
（新）ちょっと角度を変えて質問します。今日も日立さんからご提案、ほかの会社もあったのですが、Ｐ
ＤＡや携帯電話を、データ・ロガーみたいに使ったりするのが、ちょっとトレンドになっています。そうい
うことは興味がおありになるのですか。というのは、例えば携帯電話にしてしまうとそこはマイクロソフト
は、今ちょっと弱いですから（笑）
。
（今任）そうですね。ＰＤＡ端末はやはり事業所、各場所ありますけれども、一部やはり広域パトロール
ですとか、ループ・チェック作業などで当時、山武さんなどといろいろ共同でやったという事例もあって、
40
計装制御技術会議 S3
使っています。ニーズもけっこう出てきています。
携帯電話のほうは、マイクロソフトは基本的には関係ないのですが、制御システムとは違う使い方で、や
はり、すぐ手元に持っていて、画像を取得できて、それを不特定多数、あるいは選択した特定の人に配信で
きるという利便性を使った運用方法として、いろいろな事故災害が起こったときの防災情報の伝達に、事業
所、製造部によっては運用しているところがあります。だから、製造部として運転員に全員カメラ付き携帯
を配布し、事故が起こったり災害が起こったり、何か漏れたりとかいう状況を、いち早くテレビ付きカメラ、
携帯のカメラで撮って、メール添付で送るという使い方をしている。制御システムはちょっと違いますけれ
ども。そういう面で、便利なものはとことん使おうというところは、傾向としてあります。
（新）
なるほどね。ありがとうございます。杉浦さん、お願いします。
（杉浦）昨日のセッション２の話から入らせていただきたいのですが、キーノート・スピーチをしていた
だいた元トヨタで今、名古屋工大の客員教授の黒岩さんのお話の中で、80 年代の自動車産業はアメリカが日
本に押しまくられた時代で、アメリカはダイナミックにイノベーションを起こし、そこで新しい仕組みを作
った。それをすべてコンピュータに入れて、いわゆるＣＩＭ（Computer-Integrated Manufacturing）という
形での生産システムを作って、日本を追い落とすのだと。トヨタはそれをかたくなに、人の教育という形で
進めていった。それで何年かたって結局、今の状況が来ているわけです。人の知恵を出さないと、結局コン
ピュータに任せてしまうと、そこで技術レベルが固定されてしまう。そこにおいて、人間の知恵で一生懸命
やっていったトヨタが、今の非常にいい会社に変わってきたという流れがあるわけです。
それと同じようなことが、マイクロソフトのソフトと Linux の間にあるのではないか。ですから、Linux
は知恵を出すベースがあるのか。というのは、マイクロソフトは、家でもそれなりにみんなもう使い方に慣
れていて、分かって、見える。ですから、人間は見えないものに対して知恵を出せるかというと、見えない
ものに知恵を出せるのは、見えている人だけしか知恵を出せないと。だから、Linux がいいと言っているの
は、見える本当の一部の少ない人だけしか、知恵が出せないシステムで、本当にいいシステムが作れますか
と。
逆に Windows はいろいろなところにバグがあったりいろいろな問題があります。でも現場のオペレーター
を含めて慣れているわけです。
みんな普段からパソコンとして Windows ベースで動かしている。そうすると、
どっちがより知恵を出しやすいシステムが作れるのかといったら、そういう意味では今はやはり Windows し
か選択肢がないのではないか。だから、マイクロソフトがいい・悪いというレベルの話より、私どもがその
システムを使って知恵を出せるか、出せないか。そこにむしろ観点を置いて考えたほうがいいのではないだ
ろうかと、お話を聞いて感じたのです。
実際、私どもはマイクロソフトのＯＳを使ってシステムを作って、今任さんのところと同じように、やは
41
計装制御技術会議 S3
り外販ということをやっているわけです。システム開発で、いろいろなバグがあるのですが、ある意味では
癖があって、その癖に慣れてしまえば大体、同じような形で直していける。ＯＳや何かが変わるというのは、
そんなに大きく変わっているのかというと、それほど大きく変わっていないではないかと。対応できないほ
どの大きい変更があるわけでもないし、ＮＴからＸＰに変わったからと、そんなに大きな変わりがあるわけ
でもない。ドットネットが来たからといって、対応できないほど難しい対策が要るわけでもない。それぐら
いの形で、割と漸進的な変更をしてくれていますし、有償になってはしまいますが、データ開示という意味
では、かなり開発者のための開示はよくやってくれている会社ではあるだろうと思っています。
今までの、例えばではこれが Linux に一気に戻ったときに、開発が楽にできますかというと、かなり大変
だろう。よほど自分でコードが読めて、ＯＳの中まで分からないと、結局は動かせない。そういう意味での
レベルでの落差が、Windows のメリットであるだろうと思います。
あとＧＵＩということに限っていうと、これがレガシーシステムか新しいシステムかによって、多分違う
と思うのです。既存のシステムを、何か画面として出したい。そういう共通のプラットフォーム、共通のル
ールで動いたほうがいいのですが、新しいものをそこで縛ってしまうと、新しいものができてこない。
ですから、例えばＭＩＣＲＥＸ-ＮＸの例ですと、あるタンクモジュールを登録すると、グラフィックまで
ダイレクトに生成するような機能を持っている。そういった便利さは、ＯＰＣの１点１点の、単にＩ／Ｏレ
ベルでハンドリングする仕組みを作って、各社共通のルールで使える仕組みを作ったからといって、決して
ユーザにとってメリットがないのではないか。ですから、ある意味では新しいものと古いものを救済するシ
ステムは、分けて考えなければいけないのではないかと思います。
（新）
ありがとうございます。千田さん、いかがでしょうか。
（千田）私はちょっと逆に、何でベンダが Windows を志向していくのかを聞きたいと思うのです。石油精
製というかプロセスという、主要のプロセスは大体うちの会社は１社でクローズしてしまっていて、マルチ
ベンダ化というメリットも感じていないですし、私の個人的な意見かもしれませんが、できれば今のままに
しておいてほしいと思っています。
では、なぜ Windows を採用するかという、採用した場合に、我々のシステムに対して、どういうメリット
があるのか。Windows を採用することで、開発コストが安くなって、そういう意味で Windows を志向して、
実際に物が安く提供していただけるのかどうかなのですが、そういう面もちょっと感じられないところもあ
ります。
そういう面で、いろいろなシステムを使っているところは、Windows を志向していくかもしれないのです。
我々、石油会社は、特に堅い会社で古い体質もあるのですが、そこで基本的に我々の立場としては安ければ
何を使ってもらってもいいけれども、基本的には変えてほしくないなというのが実情です。
42
計装制御技術会議 S3
（新）
ありがとうございます。では西條さん、お願いします。
（西條）エンジニアリング・ツールなのですが、多分マルチベンダっぽいようなＰＣ／ＰＬＣのほうは、
やはりユーザが慣れているというか、情報系で慣れている Windows にしていただくのが、一般の計装制御と
いうか、現場の人は楽かなと思います。
ただし、ＤＣＳとかそういう世界で、このシステムではないと保証できませんという言い方をされるので
あれば、それはその世界だけのものであっても、かまわないかなと。ただし、それはすべてを保証しますと
いうことになると思います。先ほど富士電機さんから言われたように、ＰＬＣは単体機器として保証してい
るという形で、そういう単体機器で保証しているのであればマルチベンダになってしまうので、それはある
程度 Windows で、みんなが慣れているシステムの中でやっていただくのがいいかなと。ＤＣＳはシステム全
体を保証しているということだったので、これであれば保証しますというのであれば固有かなと。
そういう意味からすると、先ほど私が言ったような例えば Windows が本当にＤＣＳの中に入っていいのか。
例えばデルのサーバでいいますと、Windows2003 のパッチを当てる前にハードウェアパッチを当てないと、
サーバがおかしくなってしまうよとかいう問題もはらんでいます。そういう意味からすると、システム全体
の保証をＤＣＳとして取りづらくなっているのかなというのがあって、そういう意味で Windows が入ってい
いのかどうかというのも、ちょっと挙げたのです。
（新）ありがとうございます。これがユーザの視点ということで、ちょっとご参考にしてこれからの製品
を開発していただけると、こういう会議をやる意味があるのではないかと思います。
だんだん時間が押してきましたので、このリプレースも含めて、残っているご質問を消化していきたいの
ですが、「ワールドワイドに事業をされるユーザにとって、システムに求めるものは？」という質問が来てい
るのです。これはやはり、高野さんに聞くのがいちばん適切ではないかと思いますので、世界展開も含めて、
システムにどういうのを求めているかということをお願いします。
（高野）近年そうなのですが、やはりシステムだとかソフトウェアが、非常に複雑に難しくなってきて
いる。あとはトータルシステムとして、いろいろな意味で提供して作っていることもあり、いちばん課題に
なっていることの一つが現地への保全の移行という問題です。そういったことが考慮に入ったシステムはち
ょっと考えなければいけないだろうなと。
一つ、我々の中で、解とまではいかないのですが、やっているのはグローバルなネットワークを引くとい
うことで、日本からも情報共有・支援できないかということを志向することを検討しています。ということ
は、先ほどの話とつながってきますが、各システムがネットワークで情報が確認できるとか、そういった方
43
計装制御技術会議 S3
向が一つ、我々としては注意してやっているところです。
（新）
よろしいでしょうか。
それでは、今度はベンダさんにお話をお伺いしたいと思うのですが、質問が三つぐらいあります。トヨタ
の高野様の意見とかぶるのですが、リプレースを行った場合の、生産停止期間を定量的な数字で教えていた
だきたい。実際、発注から検収まで期間、デバッグや試運転期間もというのですが、多分個別に違うと思う
ので、お答えできる範囲でよろしいかと思います。
それから、ソフトウェア制作において、設計コーディング、テストの各フェーズで、作業時間短縮につな
がる取り組みがあればお教えくださいということで、各社何かここら辺で、エンジニアリング・ツールで特
徴があれば教えていただきたいということです。
それから、ネットワークやインタフェースなどがみんな標準化が進んだ場合、ユーザとしてはベンダの乗
り換えコスト・リスクが低くなる。みんな同じになりますから、低くなる。みんな Windows なら簡単に乗り
換えられることになると思いますが、その場合ベンダ各位はどのようにされていくのかという質問がありま
す。
多分、みんな共通にしたところで、各社が特色を出していかなければいけない。今日のご意見の中でも、
横河の中原さんから、例えば国内ではこれから保守を強化していくと同時に、海外の新しい市場を見付けて
いくのだという方向性が出てきたと思うのです。これは各社の戦略になると思いますから、言えることは宣
伝していただいて、言えないことはちょっと内緒にしておくのもありかもしれませんが、こういうご意見が
あります。これは質問として、頭に入れておいていただきたいと思います。
それで、ベンダの各社さんについて、最後になってしまいますが、これから一言ずついただきたいのです。
私からのご質問は、中原さんがいちばん象徴的におっしゃったのですが、ここでユーザ仕様書と出てきたけ
れども、これはコストの一部だよというご指摘がありました。スタートアップ費だとか、いろいろと別にた
くさんお金がかかるというご指摘があり、そういう意味ではユーザ仕様書は、あまり完璧でなかったという
のがあると思います。最初なので、まとめるだけでも大変でした。
そういったことも含めてのトータルコストという形で、ベンダはユーザに商品を提案・提供されていくと
考えていますので、それも踏まえて何か最後に一言ずついただければと思います。
それでは、今度は廣田さんからお願いできますか。全体の感想でもけっこうですので、よろしくお願いし
ます。
（廣田）先ほどの現地での保守というか、ダウンタイムの短縮という意味では、例えばプログラムに関し
てはパソコン上でシミュレーションできます。例えば、ＰＬＣがなくても、表示器とかシーケンスも含めて、
パソコン上でシミュレーションでき、現地での調整をなるべく少なくするような取り組みは行っています。
44
計装制御技術会議 S3
ＰＬＣに関して、例えばユニットのオンライン交換があります。例えば１個のユニットが壊れたときの交
換に、ＰＬＣの電源を切らなくてはいけないかというと、そうではなくて、オンライン交換ができるような
取り組みを行っています。
あとプログラムの継承という意味では、基本的にＰＬＣに関しては、例えば 20 年前のＰＬＣでも、変換す
るだけで使えますし、プログラムの継承は、最優先に考えています。そういったことで、トータル的にユー
ザのシステムのダウンタイムをなるべく短くする取り組みを行っています。
（新）
ありがとうございます。では浪江さん、お願いできますでしょうか。
（浪江）すべての質問に答えることはできないのですが、標準化が進んだ場合、何で差別化するか、特徴
を出すのかということに関して、私どもはやりコントローラのメーカーということで、コントローラ部分の
コストパフォーマンスに、最大の注力を置いて特徴を出していきたいと思っています。
それから、今日のお話の中で、システムインテグレータという言葉を何度も出して、メーカーとしては少
し無責任と受け取られかねない回答もあったかと思います。しかし、実はシステムインテグレータについて
も、私どもはソリューションパートナー会という、これは計装のソリューションを提供できるインテグレー
タさんを大体 30 社ほど組織していまして、
こちらのパートナーと協力して、ユーザのサポートもしています。
そういう形で、これからも一緒にソリューションを提供していきたいと考えています。
（新）
ありがとうございます。では中原さん、お願いします。
（中原）まず、リプレースに関しては、いろいろな取り組みをやっています。実績としては、自社のＤＣ
Ｓのリプレースは当然ながら、他社のＤＣＳのリプレースも含めて、今、ダウンタイムという言葉が出まし
たが、最小で２日、最低でも１週間の中で解決する。要は、全体の工期も重要ですが、いかにプラントのシ
ャットダウン時間を短くするかに関していえば、それだけの実績を今までこの数年の中で作ってきました。
これができる背景には、やはり実際にプラントにつなぎ込みする前に、いかに品質を高めていくかという
ことで、これはエンジニアリングの取り組みもあるのですが、やはりシミュレータ技術などを使って、でき
るだけ実ハードウェアに依存しない形で、テストができるという環境をご用意することが、一つ効いている
と思います。
次に、ではエンジニアリングの作業工数を短くしたいというお話がありましたが、ちょっと国内にフィッ
トする話かどうか分からないのですが、我々は制御システムをハードコンポーネントとして納めるというだ
けではなくて、ライフサイクルにわたって、そのお客様のコストを下げていく活動に協力できないか。
そういうことで、上位系の話になりますが、設計ツールですね。特に今、海外ではインターグラフ社の Smart
45
計装制御技術会議 S3
Plant のような計装ツールが、半分以上のシェアで使われているわけです。そういうツールとコラボレーシ
ョンした形で、上位ツールで作ったデータをＤＣＳのエンジニアリング・ツールに、インポートさせていく。
そういう形で、データの双方向の一貫性を保つように、トータルのエンジニアリングコストを下げていく。
これは当然、設計時だけの話ではなくて、増改造時を含めて、当然ＤＣＳが絡む部分は、工場全体のある部
分です。お客様から見ると、全体の設計情報の中で当然イコライズされていることで、保全を含めた活動に
つながると我々は思っていますので、そういう活動を今やっています。
最後に、汎用的なインタフェースが普及すると、ベンダとして特徴をどこに出していくのかというのは非
常に耳の痛いご指摘です。特にＰＬＣベンダと違って、ＤＣＳベンダは、出る物量が２けたも３けたも違う
わけですから、少ないボリュームの中で、どれだけビジネスを拡大させていくかが、ＰＬＣベンダと違う悩
みです。
そういう意味では、我々は今、ＭＩＶとかＭＡＣとか、要はメイン・インストルメント・ベンダ、あるい
はメイン・オートメーション・コントラクタという形で、ハードウェアを納めるだけではなくて、設計から
オペレーションの支援、あるいは保全活動に関して、ライフサイクルにわたって、お客様を支援できるよう
な体制にビジネス体を持っていく。そこしか、我々としては生き延びる道はないのではないかと、方向とし
ては考えています。
（新）
ありがとうございます。それでは、岩崎さん、お願いします。
（岩崎）三つの質問ですが、revamp（増改造）の期間短縮は、通常、我々に対してはコミットメントせよ
と、お客様が来るような時代です。先ほど、横河さんにもあったように、１週間以内で全面切り替えをやる
という例は、ほぼ普通になってきたという印象が最近あります。そのためには、デバッグを先んじてやって
おかなければいけないというのはあるので、コミッショニングを含めて、どういう形の試運転をやっていく
かという体制です。
それから、我々のところはある程度、自社のリプレースという例にはなるのですが、実際、現場をどこま
できちっとした形で、入れ替え前に整理しておくかというのが、いちばん重要なことです。そこには、かな
り我々のフィールドサービスにかかわる人間が、1000 人規模で我々の会社の中には同居していますので、そ
ういう者がかなりお客様の中に入って、支援しながらやっていくというのが現状かと思います。
それから、ソフトウェア作成短縮の手法自体は非常に難しいのですが、最近、特にお客様から言われてい
る内容は、お客様の中で、エンジニアリングを、手法として標準化されているお客様がけっこう増えてきま
した。これは特に、自社でエンジニアリングをされるかたがたになるのですが、そういったところに、うま
く我々のツールセットとのつなぎ込みをかなり積極的にやって、お客様の中のエンジニアリング標準、エン
ジニアリングの環境の中にフィットするような、我々のところのツールの改造は、かなり積極的にやってい
46
計装制御技術会議 S3
るつもりです。
それから、
「すべてのプラットフォームが標準化すると」というのは、ベンダとしてつらいのですが、我々
インテグレータとしての顔も持っていますので、ソリューションをどのような形でお客様と一緒にやらせて
いただけるかも、少しキーになっていくのではないかと思っています。
そこでは、先ほど少し触れましたが、我々の山武という会社には、プロセス産業以外にビルシステムとい
う、もう一つの大きな柱がありますので、そちらのほうのシナジーで、どういった形で特色あるベンダ・ア
ンド・インテグレータになれるかどうかは、今後志向していこうかなとは考えています。
（新）
ありがとうございます。それでは、多比良さん、お願いいたします。
（多比良）リプレースのときのプラント停止期間なのですが、これはプラントの規模によって全然違いま
すので、一概には言えないのですが、やはり１週間前後が最近いちばん多いのではないかと思います。
それから、当社の例ですと食品さんなのですが、コントローラ６∼７本を、一夜にして切り替えたという
極端な例もあります。
それから、作業短縮につながる取り組みですが、一つはリプレース時にＰＩＯ、それから工事配線をその
まま生かすのがいちばんですが、そのほかにも制御プログラム、旧機種から新しい機種、今回でしたらＥＸ
8000 シリーズにコンバージョンできるソフトも用意して、旧機種からの移行の際の、エンジニアリングの労
力を大幅に節減することもやっています。
それから、実機でなくても、パソコンの中に仮想コントローラを持っていて、そちらのほうで機能確認を
やってしまう。それから、改造内容は改造部分だけを出力するといったエンジニアリング・ツールをそろえ
ています。そういった面で、作業短縮を図っていただくことができるかと思います。
それから、これから当社が進めていきますＤＣＳの方向性ですが、まず長期保守というご要求と信頼性が
ありますので、そちらのほうを進めていくのがまず第１です。ほかにも、オペレーションの操作性の向上も、
まだまだ残っていると感じていて、ただ単にオペレーターのかたが画面の前にいて操作するだけではなくて、
逆にＤＣＳの側から知らせる機能も充実していきたいというのがあります。
それから、保全関係の機能を充実させていきたいと思います。さらに、ＤＣＳだけではなくて、ＭＥＳや
ＥＲＰを統合したような垂直統合ができるのも当社の特長ですので、そちらのほうでも、お客様に提案して
いきたいと考えています。
最後に感想ですが、今回ユーザさんからのご要求のあったシステムが、ハードウェア中心だったので、な
かなかアプリケーションレベルでの特長が言えなくて、次回こういう機会があったら、そういった面、例え
ば連続系はこうですとか、バッチ系はこういうものを持っていますというものを、ご提案できたらなと考え
ています。
47
計装制御技術会議 S3
（新）
ありがとうございます。では大庭さん、お願いします。
（大庭）リプレース期間の短縮の件に関しては、午前中の発表にありましたように、当社製のものをリプ
レースする場合は、Ｉ／Ｏはそのまま、コントローラだけ新しくして、そのままエミュレーションの技術で、
ソフトはそのままということで、実際にあるシステムは、１日でリプレースは終わるということも可能にな
っています。
それから、エンジニアリング期間を短縮するというのは、ひとえにエンジニアリング・ツールがどういう
ところまでカバーしているかにかかると思います。そこで今、方向性としては、上位仕様書からどういう段
階を経て、コントローラのプログラムに落ちるかというところを短縮するという開発をしています。過去に
も、いろいろと製品はあるのですけれども、また新たにＩＥＣで今、プログラムを作ろうというところにや
っていますので、そこに落ちるような形の開発を現在進めています。
それから、標準化ですが、どこで差別化するか。コントローラから上のところは、ネットワークは標準化
され、マンマシンが標準化されというなかで、コントローラにはまだいろいろと独自性を出せるところかな
と思っています。例えばＰＩＤにしても、まだ独自のものがあると考えています。そういったところで、お
客様にこういった機能は、このコントローラでしかできませんよというところで、差別化になるのではない
かと考えています。
それを言うと、先ほど将来的にはコントローラを換えるときに、ＰＬＣオープンで言っていた話と、ちょ
っと逆行するような意味合いもあるのですが、例えばファンクションブロックを作って、これは当社独自の
機能なので、ここはブラックボックスにしていますというふうにしますと、他社のところには、なかなかそ
れがつながらないという自己矛盾を起こしているのです。けれども、それはそういうレベルのところではな
い部分では、簡単な制御と言うと何ですが、それは他社でも使えます。でも、守るべきところはやはりある
のではないかと考えていまして、そこは他社にはできないところだという方針で行く。それは多分、東芝だ
けではなくてほかの会社もそうだと思いますので、
そういう部分と、
そうではなくてオープンに行く部分と、
二つあるのではないかと考えています。
（新）
（中川）
ありがとうございました。では中川さん、お願いします。
五つぐらいのことをお話ししたいと思います。手短に言います。
リプレース後の立ち上げについては、ノーケンは Foundation Fieldbus もやっていまして、全世界では 9000
システム、55 万台が入っているのですが、ＦＦにしていただくと、非常に早い立ち上げができますと。これ
は Profibus-ＰＡでも同じですが、ぜひその辺はご検討くださいと。
48
計装制御技術会議 S3
二つめは、ソフトの制作を短くするのをどうしたらいいかというので、これは私どものＰＣＳ７というの
は、例えばＤＣＳのように計器ブロックをつなげてプログラムすると、計器を八つ並べるフェイスプレート
の画面が自動的にできるという自動生成の部分が随分多いので、非常に早くプログラムができ上がるという
ものも、ぜひご検討くださいと。
３番目は朝、服部さんから課題の提起があったのですが、ＦＤＴについては報告がなかったのですが、現
状はどうかというと、
これは計器で持っている診断情報、
ＨＡＲＴのものと Foundation Fieldbus と Profibus
のもののデータの扱いが、今はそれぞれのツールで読まないといけないのですが、データの取り扱いを統合
しよう、あるいは標準化しようという動きがあります。この三つの協会と大手のユーザとシステムベンダが
いろいろと話し合って、それを今持っておられる、例えばシーメンスだとＰＤＭというソフトにどうやって
統合するかということで、もうすぐいろいろと製品が出てくると思います。
日本では昨年、計測自動制御学会のほうで、今出ているＦＤＴのツールを使って検証テストをされたと思
うのです。これは早急に各メーカーが今開発されていると思うのですが、ＦＤＴ／ＤＴＭに対応する計器、
あるいはソフトが出てくると思います。
四つめ、これは１日目にＬＣＭのところであったのですが、今プロセス産業の計装システムについては、
特に安全計装システムが言われまして、ＩＥＣ61508 というのが３年ほど前に制定され、これはＪＩＳのＣ
0508 になっているのです。その上に、さらに 61511 というのが 2003 年に制定され、これは特にプロセス産
業の安全計装システムにかかわる要求仕様がかなりきっちり書かれています。今、私はＪＩＳ化委員をして
いるのですが、年度内にＪＩＳ化をする。これがＪＩＳ化になると、経済産業省も一昨年、産業事故が続い
たこともあって、かなり力を入れています。例えば Emergency Shut-Down System は、もちろんほかのプラン
トを動かすシステムと分けたシステムで、ですから、それは安全リレー回路ではちょっとだめかなとなって
くる。それで各社、安全ＰＬＣを出してきているわけですが、ＩＥＣ61511 に非常に注目していただきたい
と思います。これは１日めに、ＪＩＳ化委員会の副委員長の佐藤先生にお話ししてもらって、１日目のテキ
ストにありますし、
『計装』の１月号でさらに解説が出ると思います。
それから、最後にベンダの特徴をどう出していくかということで、シーメンスについては、先ほど出まし
たＰＲＯＦＮＥＴという、リアルタイムイーサネットに直接つなげるデバイスを今どんどん開発しています。
具体的には、プラントの現場にＰＤＡを持っていって、画面は小さいですが、計器室を見るような画面の操
作ができる。それがＰＲＯＦＮＥＴで直接つながるというのが、製品化されました。今、機器のほうも例え
ばインバータなどがつながるものを開発して、もう出ていると思います。
それから、もう一つは、先ほど言いましたＩＥＣ61511 が規格になっているので、ＰＬＣのＳＩＬ３認証
はもとより、今やっているのはいろいろな計器です。ＳＩＬの認証は各工程毎なので、計装ループも計算し
て、ＳＩＬ３になるとか確認をしないといけないのです。計器がＳＩＬ３認定していると、その計算は要ら
ないということになりまして、それに力を入れて特色を出そうとしています。
49
計装制御技術会議 S3
これはＩＥＣ61511 がＪＩＳになったら日本全体にかかってきますので、ぜひ皆さん、勉強をしてもらい
たいと思います。何かありましたら、お問い合わせください。
（新）
はい。では奥住さん、お願いします。
（奥住）私ども、ＭＩＣＲＥＸ-ＮＸという新しい機種を使って、やはりエンジニアリングの作り込みのソ
フトウェアのところもそうなのですが、現地の試験などにあたってかなり工数が削減できるという手ごたえ
を得ています。
目標としては、そのあたりを 30％ぐらい削減したいと思っているのですが、やはりツールがばらばらでな
く、
一つで一貫性を持ってデータベースやインタフェースも含めてできるところは非常によくなっています。
ぜひ使っていただきたいと思います。
それから、もう一つは、今日はあまりお話が出なかったのですが、このＤＣＳは非常に広範囲な技術と製
品が使われており、非常にお金がかかる製品です。私どもがシーメンス製品をプラットフォームに採用した
理由の一つでもあるのですが、逆に言えば我々はシーメンスとのコラボレーションの中で、ソフトウェアに
きちんと投資をして、お客様に必要なソリューションを提供していきたいと思っています。
（新）
ありがとうございました。
それでは、時間が押してきましたので、最後にユーザのかたに一言ずついただきたいと思いますが、その
前に最後のご質問が残っています。ちょっとこれは生臭いのでお答えできないかもしれないのですが、逆に
いえばバーチャルコンペの仕様書を作成するときの限界みたいなものもありますので、ご質問だけご紹介し
ます。
「購入するＤＣＳのメーカーを決めるときに、技術面での仕様、提示価格が同じであった場合、何を決定
判断材料としているか。また、その優先順位は」ということで、「例えば近くにメーカーのサービスステーシ
ョンがあること、納入実績、国産 or 外国製、リプレースの場合、既設メーカーにするなど」と書いてあり、
ここまで含めて仕様書を作るのはなかなか難しいので、すごく答えにくいのだろうと思いますが、「特に東京
ガス様、新日本石油様にお答えいただきたい」というご質問を紹介させていただきました。
では、すみませんが、最後に言い残したことを西條さんからお願いできますでしょうか。
（西條）今日はベンダのかたに、いろいろな質問をさせていただいて、ありがとうございます。僕たちだ
けではなくて、フロアにいるかたも、今まで見えなかったところが、ちょっとずつ見えてきたのかなという
ところがあります。来年以降も多分、こういった形でやっていただくのがいいかなと思います。結構私も、
見えなかったところとか、ＰＬＣオープンのような話が出てきて大変参考になりました。ありがとうござい
50
計装制御技術会議 S3
ます。
（千田）私は、計装からしばらく離れていて、最近ここ１年でまた戻ってきて、ＤＣＳの状況が見えなか
ったので、ちょっとつたないところがあったと思いますが、今日は勉強も兼ねて参加させてもらいました。
いろいろと情報を得られたことは非常に参考になったと思いますので、今後活用させていただきたいと思い
ます。
何か質問があったのでしたっけ。
（新）
お答えいただいても、いただかなくてもけっこうですが、国産か、外国製か、納入実績か（笑）
。
（千田）難しいのですが、ベンダを替えるかどうかという話がちょっとあったかもしれないのですが、基
本的には安ければ替えていきたいなとは思うのですが、なかなかそういうところが見えていないのが現状で
す。できれば、更新時期を当社も迎えているのですが、各社さんいい提案があったら、ぜひ聞かせていただ
きたいと思いますので、よろしくお願いします。
（杉浦）今回３回めで、初めて和やかで前進的なお話をできる機会が持たれたということで、非常に私個
人としては面白いセッションになったのではないかと思っています。
生臭いほうのお話にちょっと答えさせていただくと、今日の話の中から漏れたライフサイクルのエンジニ
アリングコスト、ないしは維持コストの部分が、やはり判定の基準にきっとなってくるのではないか。です
から、同じ値段、同じ条件でライフサイクルを見たときに、将来どちらのほうが安いかをある程度判断して、
同じ値段でもあるメーカーに決めることに多分なるだろうと思います。
（今任）今日で終了ですが、セッション１がライフサイクルマネージメントで、セッション２が、生産管
理に関するいろいろな実績や提案、そして、本日のＤＣＳとＰＬＣですが、これはそれぞれがぶつぶつと切
れているわけではなくて、何らかの形で関係があるテーマでした。
今、杉浦さんがおっしゃったように、ＤＣＳの機種メーカーの選定ですね。やはり、ライフサイクルをど
う考えるかが重要だという意味を含めて、セッション１で初めてそういうテーマを取り上げたというのも一
つの理由です。やはり、担当されている人が主体となって決めるわけですから、ポリシーをまず持つことか
なと思います。その他には、例えば、とあるベンダーのかたと親しいというのが理由かもしれませんし、自
分の経験から実績を積まれたベンダーのシステムというのも理由となるかもしれません。理由はさまざまあ
ると思いますが、ポリシーを持って、それをいかに周りに納得させることだと思いますので、ぜひ思い切っ
てどこかのものを選択して、成功させていただきたいと思います。その成功事例を、またこういう場でぜひ
51
計装制御技術会議 S3
紹介いただけたらと思います。
（服部）今年はこういった形のバーチャルコンペがいいかどうかは、結果的によく分かりませんけれども、
一つの具体的な形として提示できたのは、本会議の一つの成果ではなかったかと思っています。
前からいろいろとご指摘いただいていますとおり、仕様の詳細が甘いというのは確かにごもっともですが、
この会議に参加されている業種によって事情はさまざまですので、仕様を細かく規定しますと、逆にこのケ
ースだけしかやらないのかという話も出てきます。このようなジレンマから、仕様設定の際にはかなり苦労
しました。最終的には、ニュートラルな仕様を提示するという方法になりましたが、結果として、多様性に
富んだ“ファジー”なご回答を各ベンダさんから得ることができて、ユーザ側がこれを自由に比較評価する
ことができるという場を提供できたのではないかと思っています。
先ほどのソフトウェアなり、ベンダを決めるときにどうするのだという話ですが、企業姿勢としては、各
社さんと公平なおつきあいをしていくという回答になるかと思います。新規のベンダと比べると、おつきあ
いが長いベンダは、単なるシステム構築の技術や、お金以外のものを持っているかと思っています。具体的
には、あうんの呼吸というか、弊社のプラントであればこのような考え方で物を造っているといった、プラ
ントに関する知識はもとより、こういうふうにしてはいけないという運用上の話や、あるいはトラブルが起
きた場合にどういう形で対応すればいいか等々、仕事を進めていく上で重要な事項です。このようなことか
ら長くつきあっておられるベンダは、弊社の考えをよく理解できているので、相互で少人数でスムーズに仕
事をできる関係が得られているのかなと思っています。
新しいベンダを開拓することも非常に重要だと思いますが、長年の付き合いで構築されるものについては、
１か月、２か月のおつきあいですぐに分かるものではありません。組んでしばらくたってみると、ああ、や
はりおつきあいしなければよかったという結果になるというリスクもあります。今までは、たまたまおつき
あいさせていただいたベンダが非常に協力的だったので、このような失敗はほとんどないのですが、ベンダ
を決める際の一つとして、そのようなものがあるのかなと思っています。
（梶原）では一言ということで、３年後のシステムということで、今回バーチャルコンペをさせてもらっ
たのですが、やはりこれからはますますネットワークも標準化し、マルチベンダ化するのは確かだなという
のは、意を強くしました。そのためにセキュリティの問題も出てくるなと。やはり、グローバルスタンダー
ドというか、世の中はどのように動いているのかを、やはりユーザとして見ておかなければいけないと今日
は思いました。
山武さんからのコメントでいちばん強く感じたのは、今回は高信頼性システムとしたのですが、やはり一
体ユーザとしてどこまで信頼性を求めるのかという点です。機械安全のほうでは、絶対安全というのはあり
えない。そのことは今の世の中の常識ですので、プラントも不安全ならば、安全に止めるというリスク・ア
52
計装制御技術会議 S3
セスメント、リスク・マネジメントをする。それに対して、ユーザはどこまで考えているのかという指摘を
受けたのが、いちばんずしっと印象に残っています。
（新）
ありがとうございます。
それでは、最後にチェアマンの高野さんに一言と、チェアマンとしての全体の締めと両方を、お時間が押
していますので、よろしくお願いします。
（高野）今回は、より定量的なベンチマークをするためのスペックを作ろうということで、いろいろなご
意見がありましたが、何を考えなければいけないかという議論の種になったのではないかという意味では、
お役に立てたのではないかと思っています。
２点大事なことがあり、一つはやはり変化できるシステムであることと、もう一つ、これがいちばん大事
だと思いますが、この計装制御技術会議の人のネットワークでしょうか。ユーザ懇談会とベンダさんとお話
をしながら、あとフロアにいる皆さんとお話をしながらやっていく、この人のネットワークが非常に大事だ
ろうということで、これはぜひ今後も継続していきたいと思っています。
最後になりましたが、多くの討議票を頂きました皆様と、パネラーの皆さん、そして司会いただきました
新先生、本当にどうもありがとうございました。
以上で、このセッションを終わりたいと思います（拍手）
。
53
計装制御技術会議 S3

Download Report