令和 2年 9月
１．概要
イーサネット機能の追加は随分と前から考えていたのですが、幾つかの理由から後回しにしてきました。
理由の大半は私が想定しているユーザーから見てそのメリットを認めてはもらえないだろうあなという点にあります。
組み込み装置の大半は工場や(規模の差でしかないのですが)プラントの機械装置が対象です。
ある程度の規模のプラントになれば、プラント内の個々の装置はプラント内の通信ネットワークに接続されて、より上位側の
制御システムからの指示を受け動作するようになります。
また、このようなシステムでは、それぞれの装置の動作履歴はネットワーク経由で制御システムに報告するような構成を要求されます。
これは全ての装置をネットワーク経由で管理し易いからです。
しかし、小規模の工場では「そんな面倒なものはいらん」の一言で却下される可能性が高い気がします。
イーサネット接続を追加することで得られるメリットとデメリットは以下の通りです。
メリット
・ 圧倒的な拡張性を手に入れられる。
イーサネットの通信性能は他の通信とは比較にならないほど圧倒的な拡張性と通信速度を得られます。
単一のイーサネットで複数の機器と通信でき、プログラムの変更とハブによる配線の増設のみで通信機能を拡張できます。
・ 装置毎に異なる装置の管理機能をネットワーク経由とすることである程度統一した操作にまとめることが出来る。
装置の維持管理は工場でも負担の大きな作業です。個々の装置毎に異なる維持管理方法を覚える必要がある
従来方式の管理では担当者の負担は増えるばかりです。しかし、ネットワーク経由で装置の状態を報告する形式に変更する
ことで、装置状態の情報収集部分だけでもＰＣによる統一的な操作に置き換えできます。
デメリット
・ 通信の即時性が保障されていないため、組み込み装置の全ての通信をイーサネットに置き換えることは出来ない。
従来方式であるRS-232Cとは異なり、送信を開始してプログラムによる送信処理の終了を迎えても、実際の送信処理が終わった訳ではない。
これは実時間処理が必要な用途では使い難く、全ての通信をイーサネットに置き換えることは出来ない。
結果として、実時間処理が必要な用途の通信ポートは残して、イーサネットポートを追加することになる。
・ マイコンに要求されるリソースや性能の要求が厳しい
組み込み用のマイコンにとってイーサネットコントローラを介した通信処理の追加は、多くのメモリとCPU性能を必要とします。
特にRAMについては最低でも数kB以上,の追加が必要で可能であれば数十kBを見込んでおく必要がある。
この数字は組み込み用途のマイコンにとっては、それ程楽な要求ではない。
・ プログラムの規模が大きく内部的にも複雑な機能を実装しているため、プログラムの保守に不安が残る。
イーサネットによるTCP/IP通信のプログラムサイズはGCCコンパイラの最適化オプション1の条件でコンパイルしても30kBを超える規模になります。
これだけの規模のプログラムを組み込んだ後で、何らかの不具合が起きた場合、その原因を正しく見つけ出すことは簡単には出来ません。
ここで一番厄介なのは、TCP/IPプログラムが原因ではない可能性を含めて考える必要があります。
いずれにしてもTCP/IP通信のプログラムがブラックボックスでは保守は困難です。
このため、使用するTCP/IPプログラムの信頼性やサポートの質は非常に重要になります。自分でメンテナンス出来ないなら、メンテナンスの保障
がある製品を採用するか十二分な実績のある枯れた製品を採用ことが条件になります。
２．TCP/IPの実装方法の検討
当初はイーサネットコントローラーを内蔵するPICマイコンにMPLAB HarmonyによるTCI/IPプロトコルスタックを組み込むことを考えていました。
しかし、この構成では以下のような不安を払拭し切れなかったため、製品に実装できずにいました。
・ MPLAB HarmonyによるTCI/IPプロトコルスタックはソースコードを参照できるメリットはあるが、この規模のプログラムを読み込んで内容を理解する
のは簡単ではない。ましてやバグが残っていた場合にその原因にまで到達するのは非常に多くの時間をかける必要がある。
結局、この方法での実装は諦めました。たとえその時点で動作したとしても、客先に販売した後で問題が起きたときに十分な対応を行うだけの見込みが
たたないと判断しました。MPLAB Harmonyは無保証・サポート無しです。何か問題が起きても自力で解決することが要求されています。
が、これは現実的ではありません。小さな組織が客の信用を失うと後から取り返すのは非常に困難でしょう。やはり、信用第一でいくべきと判断します。
無駄話
今の時代に他人の成果物を含めて商品化しない方針で臨むのは時代遅れです。時代の流れはフリーソフトウェアをおおいに活用する方向に動いています。
従って、私の考え方には批判的な考えの方も多いと思います。私も全てのプログラムを自前で用意すべきだとは考えていません。
コンパイラの出力にも多くの内部コードがあります。それらまでを否定することは不可能です。
どのようなケースでは他人のコードを許容し、どのようなケースでは許容しないかの線引きが重要です。
一つの目安として、自分で対処する方法を考案できるかどうかが判断の基準になります。
例えば、コンパイラの場合、ある程度バグが収束していることが前提条件にはなりますが、コンパイラに与えるソースコードの書き方を変更することで
バグを回避できるケースはよくあります。つまり、コンパイラにバグが残ったままでも他の対処方法が残されています。
この方法は全てのケースで上手くいく訳ではないでしょうが、多くの場面で適用できます。
今回のケースではMPLAB HarmonyのTCP/IP機能の一部を抜き出して使用する事になります。どうしてもインプリメントの問題が起こり得ます。
逆にMPLAB Harmony全体を丸ごと使用するなら、インプリメントの問題は無くなりますが、そうすると今度はプログラム全体がブラックボックスとなります。
何か起きたときに膨大なソースコードを追跡し、問題を修正するのは現実的ではありません。フリーソフトウェアの使用は常にこの問題と隣り合わせです。
市販のTCI/IPプロトコルスタックも何社か調べてみましたが、価格に見合うだけのサポートが得られるかどうか。
また、その価格を商品に転嫁して購入してもらえるかどうか。
現時点では販売の当てがない状態ですので、この方法は採用できません。
数年間、この状態で立ち往生していたのですが、W5500というICの存在を知ることになりました。
W5500は韓国のWiznet社の製品でHardwired TCP/IP embedded Ethernet controllerと紹介されています。
マイコンとの接続はSPI IFによる通信で、コマンドと通信データを送ることでTCP/IPの送受信を代行してくれます。
実は、この会社の製品は数年前にも見つけてはいたのですが、当時はこれらの製品について何処まで信頼できるのかについて
自信が持てなかったので結果として、そのまま放置していました。
今回、HPからデータシートなどの資料を詳しく見てみるとTCP/IPのコントローラーとしては2005年から製品を発表しています。
製品も数世代にわたってモデルチェンジが行われており、基本機能については十分に「枯れた技術」と考えて良いでしょう。
３．W5500を検証する
TCI/IPプロトコルスタック機能の大半をハードウェアで実装しているW5500ですが、このICを採用して信頼性のある通信が出来るかどうかの検証は
必要です。ICである以上何らかのバグは残っているでしょうし、SPI IFを介してマイコンと通信する仕様から時間当たりの通信データ量は自ずと上限が
あることが予想されます。
しかし、このICを採用することはTCI/IPプロトコルスタックをソフトウェアで実装した場合と比較して、多くのメリットがあります。
・ マイコン側のTCI/IPプロトコルスタックプログラムの大半を削除することが出来る
マイコンの本来の目的は機械制御です。通信は機械制御を実現するための一部機能として必要ですが、その通信部分が巨大化していくと、
リソースの競合や割り込み処理への応答時間の悪化・機械制御の間隔の長時間化など悪い影響が出てきます。
本来の主業務に集中するためにマイコン自身を出来るだけ軽い負荷状態とし、プログラムを単純な状態に維持することは非常に重要です。
・ デバイスの使用実績から信頼度を予測しやすい。
メーカーはこのICを年間数十万個といった単位で販売しているでしょうから、それらの実績を信用して使うことが出来ます。
バグの大半は既に世界中の誰かの手によって見つけられていることが期待できます。
ソフトウェアによる実装では、使用するCPUによってコンパイラが、使用するイーサネットコントローラーによってドライバが個々に違ってきます。
ハードウェアを仮想化した上位部のソフトウェアについての実績は多くても、OSへのインプリメントを含めたシステム全体での
実績や信頼度は中々実体を知ることが出来ません。バグが残っているリスクは常に意識しておく必要があります。
反面、SPI IFはデータの通信量の上限を決定します。SPI IFは比較的高速な通信IFですが、それでもイーサネットとの比較では低速です。
通信データ量に関してはSPI IFの速度から大まかに計算できます。PIC32マイコンのSPI通信速度の上限は25MBPSです。マイコンが通信に割ける最大時間を
全体の10%と仮定すると、2.5Mbps(約315kbyte/sec)が上限です。実際には最終的な通信データには含まれないコマンドなどの送受信を含むので、
この値の80%が有効なデータとすると2Mbps(250kbyte/sec)が実データの通信量となります。この値は一般的な組み込み装置のデータ通信量としては十分です。
その他に注意すべきはW5500はハードウェア化されたTCP/IPドライバですので、仕様として固定されているものがあります。
用途によっては大きな制約になるものがある可能性があるので検証が必要です。
・ 同時に使用できるソケットの数は8個まで
ソケットとは電話における回線数のイメージです、同時に通信できる通信相手の数と考えて良い。
通信は送信と受信を1セットとして数えます。大いに越したことは無いのですが8個あればそれ程不自由はしないでしょう。
他にも細かな固定仕様はありますが、左程気になるものはありません。
実機を伴わない検討としては、デバイスのデータシートを詳しく読み込んだ後、ドライバソフトウェアの動作を理解する必要があります。
これらは次に書いていきます。
前へ 次へ