ModbusやSDI-12対応センサー

市販のセンサーモジュールを検討しているんですけども、
共通プロトコルとして業界的にはModbusやSDI-12があるようです。
どちらもオープンな規格なのでメーカー間で互換性がありそうな雰囲気ですけども、
メーカーが混在した運用とかってできるもんでしょうかね?

  • Wikipedia(modbus)にもこんな記載があります。

    >ほとんど全ての実装において、公式の規格からの逸脱が見られる。

    同一メーカーならまだしも、他メーカー同士のセンサなら要注意ですね。

  • In reply to Kon Nozomu(すと):

    すとさん
     
    やっぱり、混在はリスク高そうですね。
    同じメーカーのロガーとセンサーを組み合わせて設置するのがふつう?みたいなので、
    センサーだけ流用してくるのは難しそうですね。
     
    となると、センサー毎に1点1点ソフトも作り込みをしないといけないので
    トータルで考えると何気にアナログ出力(電流or電圧)のセンサーの方が扱いが楽そうですね。
    センサーを自作すると、センサーの評価が大変なので、なるべく市販品を流用したいんですよねー。

  • In reply to Kirin:

    センサモジュールをどのように組み合わせて利用されるのか分かりませんので、参考になるかどうか・・・

    産業用通信ではデータリンク層までは規格で統一されますが、アプリケーション層レベルの話になると各社・各製品データと制御内容の割り当てが異なってくることが多くあります。なのでセンサモジュールをつないで通信状態にするまでは規格通りの手順で初期化ができると思いますが、制御データのどのバイトが何の意味になるのかや制御パラメータの意味が製品ごと変わってくると思います。

    オープンネットワーク(規格が公開された産業用ネットワーク)ではアプリケーション層を規定しようとする動きもあって製品群ごとに動作を規定する規格というのが出されています。CANopenを例に出しますが、CANopenではプロファイルと呼ばれる製品群の括りにより同じプロファイルサポート製品なら置き換えが出来るようになっています。CANopenをアプリケーション層に利用したEtherCATでも同じようにプロファイルの括りを設けています。ただ、細かい部分はプロファイルで規定されていなかったり、規格上でもOptionalという扱いのものが各社実装がバラバラだったりで完全に置き換え可能かというとYESとは言えないです。日本の話しですが、もともと産業界は大きな会社による囲い込み戦略(三菱のCC-Linkや安川のMechatrolink)で成り立っていて、オープン規格というはここ数年の話です。半導体製造装置メーカを中心にEtherCATを利用していこうという動きがあり、相互接続性に関してはこれから段々と改善されていくと思いますが、現状はまだ厳しいです。

  • In reply to Shoji Yamamoto:

    Yamamotoさん
     
    コメントありがとうございます。
    なるほどオープン規格でも各社それぞれ思惑がありそうですね。
    規格に拡張性があるとメーカー毎の色を出しやすい(囲い込みしやすい)ようですし。
    現時点ではオープンといっても発展途上という認識でいれば良さそうですね。
     
    ちなみに今考えているのは、例えばお天気システムなど
    気温、湿度、風速、雨量を管理する場合に
    精度や価格などお手頃なセンサーを集めてシステムを組むようなケースですね。
    ほんとセンサーの価格帯はピンキリあって、センサーメーカーの枠を超えていいところどりしたいなと思っています。

  • In reply to Kirin:

    測定対象とデータを集計して何らかの気象情報のアウトプットを出す部分が離れていてセンサネットワークを組むこと前提でしたら、センサの性能の他にセンサからデータを取り出すための通信速度も考慮する必要があるかと思います。独自にネットワークを構築することは結構大変です。恐らく、RS485に独自プロトコルみたいなものとなり、それだったらオープン規格のどれかを採用した方が良いということになりかねないです。

    あと、気象情報システムの中核が何になるかよって選択肢は変わってくるかもしれません。もし、PCベースのシステムならEtherCATという選択肢も有りかもしれません(内臓のNICが利用できます。ただし、通信マスタのプロトコル・スタックのソフトウェアが必要ですが)。組込みマイコンシステムの場合なら通信はRS485などのUARTペリフェラルを利用したものになるかと思います(CANもありかも)。あとはTCP/IPベースで構築しても良いかもしれません。ただ、データ取得の同期性能まで気にする必要があるのなら注意が必要ですね。

    調べられててご存知かと思いますが、16ビットより上になってくるとAD変換の製品が極端に減ってしまいます。既成品で済ませるとなると一部の製品しかないのでそこで制約ができるかもしれません。AD変換部分を設計するとなると16ビット以上で極端に難しくなりますし。。。予算に余裕があるならNI(頭脳がlabVIEW、ADはNIの製品)で固めてシステムを構築して、その後、量産品でコスト低減策を講じるとかありかもですが、お高いんですよね。NIが利用できてもAD変換の外にセンサを付けるところはやらなあかんのですが。

  • In reply to Shoji Yamamoto:

    Yamamotoさん
     
    色々と情報ありがとうございます。
    そうですね、制御系ネットワークいろいろあるので迷いますけども、
    今回は、出口(基幹インフラ)は決まっているので、そことのゲートウェイのために、
    マイコンベースでセンサー情報を集めてきて、サーバーに送るイメージですね。
     
    ラスト1メートル問題ということで、
    センサーのインターフェースはRS485でもRS232でもアナログでも何でもありです。これから作るので^^
    アナログだとセンサーの数だけチャンネルが必要なので、RS485みたいなバス接続なら拡張が簡単ですよねー。
     
    センサーの自作はめんどくさくて、例えば気温センサーひとつとっても、
    精度保証のため出荷検査時に一台一台アスマン式通風乾湿計とか持ち出してシビアに校正掛けないといけないので、
    もっとお手軽に、自前のシステムにセンサーだけ買ってきてポンっと乗っけたいんですよね。