IoT・Modbus ゲートウェイの受託開発

Obeita は、お客様の用途に必要な機器、プロトコル、接続先システムに合わせてゲートウェイのハードウェアとソフトウェアを開発します。物理インターフェース、データの対応付け、ネットワーク経路、障害復旧を先に定め、実装内容を合意したうえで、選定した構成を実機で試験します。

用途からゲートウェイを選ぶ

RS485 と Modbus RTU・TCP 変換

通信速度、バス構成、機器アドレス、レジスタマップ、ポーリング周期を確認します。独立したバスとクライアントの役割を明確にし、変換時のタイムアウト、例外処理、再接続動作を合意します。2 系統 RS485 ゲートウェイとModbus リモート I/Oの事例では、それぞれ異なるバスと制御の要件を紹介しています。

シリアル・現場データの MQTT 接続

シリアルフレーム、解析規則、ペイロードの項目、ブローカー認証、接続先のデータモデルを定めます。必要に応じて、オフライン時のバッファリング、再接続動作、未送信データの扱いを明確にします。多インターフェース IoT ゲートウェイは、複数のインターフェースからのデータ収集とゲートウェイ統合の参考事例です。ESP32-S3 エッジ DTUの事例では、現場の信号を ESP32-S3 を用いた設計につないでいます。これらはデータ収集とゲートウェイ構成の事例です。新規案件では、MQTT のペイロードとブローカーに関する作業範囲を定める必要があります。

Linux エッジゲートウェイ

ローカル処理や複数種類のインターフェースが必要な場合は、プラットフォームのリソース、Ethernet・シリアルポート、イメージ保守、遠隔更新の要件を比較します。RK3506J Linux ゲートウェイの事例では、物理 I/O と Linux 上のデータ収集、プロトコルの適合、設定を結び付けています。RK3528 クラスのネットワークプラットフォームでは、ポート構成とソフトウェアの対象範囲が異なります。

無線 RS485 ブリッジ

ケーブルを置き換える場合は、マスター・ノードの役割、シリアル通信のタイミング、電力予算、再送、通信範囲の条件を定めます。SLE、Sub-GHz、Wi-Fi は、それぞれ現場条件とファームウェアに応じた検証が必要です。

開発の段階と成果物

1 つのデータ経路を端から端まで定める。機器資料、フレーム例、上位システムのインターフェース、必要な障害時動作を確認します。
設計と引渡し内容に合意する。基板やモジュールの作業、ファームウェア、プロトコルの対応付け、設定ツール、試験記録を定めます。ソースコード、筐体、製造支援は、合意した場合に範囲へ含めます。
開発し、実機で検証する。対応機器の拡大、量産の確約、オプションのインターフェース追加に進む前に、選定した経路を試験します。