人感センサログをRaspberry PiからPostgreSQLへ ― PLCレス最小構成 × 二次使用フリー納品

※本記事は2023〜2024年に実施した案件の振り返り紹介です。Raspberry Pi Compute Module 4の産業利用の情報がまだ少なかった頃の取り組みとしてお読みください。

案件概要

お客様:住宅設備機器メーカー様
プロジェクト:人感センサの検出ログを、お客様サーバの既存PostgreSQLへ直接書き込むロギングシステムの開発
構成:Raspberry Pi Compute Module 4+焦電型赤外線センサHC-SR501(GPIO直結)、Python製ロギングプログラム(systemdサービス化)、既存の生産データ基盤(PostgreSQL)へLAN経由で直接INSERT
担当範囲:要件定義、プログラム開発、現地試運転確認。ソースコード・立上げ手順書は二次使用フリーで納品

背景と課題

設備の稼働データは、すでに集まっていました。記録されていなかったのは「人や物が、いつそこで動いたか」。工場のデータ基盤にこの1点を書き足したい——それが今回のご相談です。ただし、センサ1点のロギングのために、PLCと通信ユニットを並べるのは大げさすぎます。

検出したいのは赤外線センサ1点の動き情報。構成は小さく、費用も小さくしたい
新しいデータベースは立てない。既存の生産データ基盤(PostgreSQL)のテーブルに合流させたい
誰かがプログラムを起動しに行く運用は論外。電源が入れば勝手に動き続けること
お客様側で改良・展開できるよう、成果物は囲い込まないこと

対応内容

PLCではなく、Raspberry Piを選ぶ

センサ1点+DB書込という要件に対して、当社が選んだのはPLCではなくRaspberry Pi Compute Module 4でした。焦電型赤外線センサHC-SR501をGPIOに直結し、Pythonで検出を監視、psycopg2でPostgreSQLへ直接INSERT——部品代数千円のセンサと小さなボードで、要件のすべてが満たせます。ラダーもPythonも書けるから、案件の大きさに合わせて道具を選べる。PLCを選ばないという判断も、制御屋の仕事のうちです。

新しく建てず、既存の基盤に合流させる

書込先は、お客様サーバで既に稼働している生産データ収集用のPostgreSQL。既存のテーブル定義に合わせてデータを整形し、センサ特有のチャタリング(短時間の連続検出)は書込間隔の制御で抑えました。プログラムはsystemdのサービスとして登録し、電源が入れば自動で走り出し、異常終了しても自動で再起動——当社の通信案件で貫いている「挿せば動く」の作法を、Linuxの流儀で実装しています。

RTCがない。だから時刻同期は「実装すべき機能」

ロギングシステムの命は時刻です。そしてRaspberry Piは、電池バックアップの時計(RTC)を標準では持ちません。電源を落とせば時刻を忘れ、復帰後はネットワークの時刻同期だけが頼り——つまりロガーとして使うなら、**時刻同期は「あると良い機能」ではなく「実装すべき機能」**です。稼働後にはこの観点から時刻同期を強化する改造をご依頼いただき、あわせて別のセンサロギングシステムにも同じ対策を展開しました。

渡して終われる納品

納品したのは動くシステムだけではありません。ソースコード・実行環境・立上げ手順書を揃え、二次使用フリーの条件でお渡ししました。お客様のエンジニアが自分たちで改良し、次のセンサへ展開できる形です。囲い込まない納品は、結果として次のご相談につながっています。

結果

人感センサの検出ログが既存の生産データ基盤に合流し、設備データと「人の動き」を同じ土俵で分析できる素地ができた
systemd常駐化により、運用開始後の起動操作・監視の手間はゼロ
稼働後に時刻同期強化の改造を追加受注、別のロギングシステムへも展開——小さく始めて、育てる関係に

センサ1点から工場のデータ化は始められます。「PLCを買うほどではないけれど」——その規模感のご相談こそ、ラズパイもPythonも書ける当社の出番です。