「IoT」の記事 - Crieit

OpenBlocks IoTをWEBサーバにする

2022-08-14T17:08:59+09:00

OpenBlocks IoT をWEBサーバにする方法です。
OpenBlocks IoT をセンサー類のゲートウェイとして使用し、さらにWEBサーバとすることができれば、OpenBlocks IoT 1台でセンサーからのデータを入力しモニターする等のシステムを稼働させることも可能となります。

FW4搭載の OpenBlocks IoT を対象とした解説です。FW4非搭載の OpenBlocks IoT については、汎用OSが裸で搭載されているため、それぞれのOSに応じた手段でWEBページの実装と配信が可能であり、それは難しいことではないためわざわざ解説する必要はないでしょう。

FW4とは？という方はこのサイトを参照してください。
IoTゲートウェイソフトウェア FW4

一方、FW4搭載の OpenBlocks IoT の場合は、FW4 が HTTP/HTTPS を使用しており、ユーザがWEBページを実装しようとする場合に「さて、どうしたものか」と悩むかもしれません。

FW4 にはNode-REDが付随しており、Node-REDを用いたWEBシステム実装が可能です。ただし、以下の解説では、Node-REDを使用せずにWEBシステムを実装する方法を述べています。

ConMas Gateway スクリプトのデバッグ (2)

2022-08-11T09:30:57+09:00

ConMas Gateway スクリプトのテスト、デバッグをどうする、というテーマの続編です。

前編 ConMas Gateway スクリプトのデバッグ (1)

結論は「スクリプト単体でテストをしましょう」です。
端末（i-Reporter）や ConMas Gateway を使うと何かと不便なので、テスト、デバッグの9割をスクリプト単体でテストをし、最後に端末と ConMas Gateway を使ったテストをしましょう、ということです。

このような、スクリプトを例として解説を進めます。

準備

テストに必要となるデータの雛形を取得します。

Gateway が稼働するサーバ上のディレクトリ action 下のファイルを以下のようにしておきます。

Gateway は端末からのリクエストを受けると最初にこのファイルを探し出し参照します。次に Gateway は、"script"に記述されたスクリプトを起動します。

ConMas/gateway/action/hogehoge.json

{
 "datasource": "script",
 "script": "scripts/requestlog.py"
}

"script"に記述するスクリプトは以下のようなスクリプトにしておきます。

ConMas/gateway/scripts/requestlog.py

import sys
import json
import traceback

jsonData = json.loads(sys.stdin.readline())
# querydata = jsonData['query']
# postdata = jsonData['post']['clusters']

f = open('./logs/request.log', 'w')
dp = json.dumps(jsonData)
f.write(dp + '\n')
f.close()

mappings_data = []
mappings = dict(error="", mappings=mappings_data)
print(json.dumps(mappings))

この状態で、端末からGateway連携を起動させます。当然ですが、このスクリプトが実行されます。
このスクリプトは、端末からのリクエストをファイルに書き込む以外に何の仕事もしません。端末は期待するデータを受け取ることができませんが、準備作業としては問題はありません。

前述のスクリプトが出力したファイルは、サーバ上のディレクトリ ConMas/gateway/logs にあります。
テスト対象となる（前述の、リクエストをファイルに書く以外に何もしないスクリプトを偽物とした場合の）本物のスクリプトの入力には、端末からのリクエストの代わりに、このファイルを使用します。
これでスクリプト単体でのテストが可能となります。ここからのテストには、Gateway も端末も不要です。つまり、スクリプト・エンジンがPythonであれば、Pythonスクリプトの通常のテストとまったく同様のテストが可能です。当然ですが、便利なテスト・ツールを使うことが出来ます。

trace-Python文の実行をトレースまたは追跡する。
Pythonのデバッグを完全理解
 Pythonプログラムを追跡する
 pythonの例外でstack traceを表示する

忘れないうちにディレクトリ action 下のファイルを書き変えて本物にしておきましょう。
ConMas/gateway/action/hogehoge.json

{
 "datasource": "script",
 "script": "scripts/hogehoge.py"
}

テスト用に取得した入力ファイルにはJSONが書かれています。ただし、見にくいのでツール等を使ってキレイにしてから使用することをおすすめします。

JSONきれい～JSON整形ツール～

例えば、こうやってスクリプトを実行させます。

c:\ConMas\gateway\scripts>type ..\logs\request.log | python hogehoge.py

参考までに、本物のスクリプトの姿はこんな感じです。
ConMas/gateway/script/hogehoge.py

import sys
import json
import traceback

try:
    #-----------------------------------------------------
    #   帳票から送信されたデータ
    #-----------------------------------------------------
    jsonData = json.loads(sys.stdin.readline())

    mappings_data = []

    #-----------------------------------------------------
    #   帳票にレスポンスするデータを作成する処理がこの辺に書かれているはず
    #-----------------------------------------------------

    mappings = dict(error="", mappings=mappings_data)
    print(json.dumps(mappings))

except Exception as e:
    logging.debug(traceback.format_exc())
    mappings = {"error": "Error: " + str(e)}
    print(json.dumps(mappings))

テストにおいて入力データを変更したければ、入力ファイルの内容を書き換えれば良いのです。

ここで紹介したテストでは、端末（帳票）とのコンビネーションをテストすることは出来ませんが、それは後ですれば良い、という考え方に基づいています。それじゃダメ、という考えの場合は始めからコンビネーションでテストしてください。

ConMas Gateway スクリプトのデバッグ (1)

時系列データからデータの変化点を得る

2022-08-07T13:17:07+09:00

仮想の課題と解決策を考えてみます。

課題

PLCあるいはセンサーから取得されるデータの変化点（変化が発生した時刻）と、変化した際のデータの差（前のデータとの差）を取得する

取得するデータ

データに変化が生じた時刻
前のデータとの差（対象のデータは数値で数は1つ）

条件

データは1秒間隔でソースから取得され、テーブルAに記録される
対象のデータは数値、1回に取得される数は1つ
1回に取得されるデータは、テーブルAにレコードとして追加される

解説

さて、データ・ソースから取得されたデータが無秩序にデータベース中のテーブルに書き込まれます。これはありがちなケースです。PLCやセンサーからデータを取得するゲートウェイの設計担当者が、出来る努力をしなかったケースですね。（もちろん、全てのデータがほしい、というオーダーがあった可能性は否定できませんが）
このようなお粗末を許すプロジェクトですから、他の失敗も考えられます。
簡単に想像できる失敗は、目的とするデータを計算するバッチ・プログラムを作り出すことです。このプログラムはスケジューラで定期的に実行されます。良さそうな設計ですが、はたしてこのプログラムの処理はデータの発生に追いつくのでしょうか。もし追いつかない場合には、対症療法的な対策が取られるでしょう。それは、チューニングと称して行われる、データベースに対する様々な工夫です。それでも解決できない場合には、ハードウェアの設計担当者のミスが指摘されるかもしれません。こうしてプロジェクトは「計画になかった役に立たない不要な作業」のために大きく複雑になっていきます。
想像したくもない状況ですが、情報システム開発のプロジェクトでは、今でもこれに類する失敗が繰り返されています。

経験からではなく歴史（学問）から学ぶ賢者はこう考えます「データへの処理は、そのデータが発生したときにしろ」。
データ・ドリブン型システムとは、本来はこのようなことを指し、大昔からソフトウェアの工学分野で有効性が唱えられていました。ただし、今回のケースでは、データが発生した時には何も手出しができません。条件から読み取ると、発生したデータはもれなくテーブルAに書き込まれ、テーブルAに書き込まれる前になにかの工夫はできなさそうです。
となると、可能で有効な細工は、データがテーブルAに追加される部分にすべきのようです。そして、もう一歩考えを進めると、データベースの基礎的な知識さえあれば、使うべきはトリガーだということに簡単に気づくことができます。
後述の解決策の一例でもトリガーを活用しています。

解決策の一例

テーブルA

解決策を具体的に説明するために、テーブルAを以下のように仮定します。これは、かつての僕の記事で何度か登場した"from_plc"ですね。

mysql> desc from_plc; 
+-------------+-----------+------+-----+-------------------+-------------------+ 
| Field       | Type      | Null | Key | Default           | Extra             |
+-------------+-----------+------+-----+-------------------+-------------------+
| body        | json      | YES  |     | NULL              |                   | 
| time_insert | timestamp | YES  |     | CURRENT_TIMESTAMP | DEFAULT_GENERATED |
+-------------+-----------+------+-----+-------------------+-------------------+
2 rows in set (0.02 sec)

mysql>

見てのとおり、モデルはMySQLで実装されています。

トリガー

計算と目的のデータをピックアップするために、トリガーを使います。トリガーは以下のとおりです。

DROP TRIGGER IF EXISTS from_plc_proc;

DELIMITER //
CREATE TRIGGER from_plc_proc AFTER INSERT ON from_plc FOR EACH ROW
BEGIN
    DECLARE count_new INTEGER;
    DECLARE count_old INTEGER;
    DECLARE count_rec INTEGER;

    --  from_plc_last の参照
    SELECT COUNT(*) INTO count_rec FROM from_plc_last;
    IF count_rec > 0 THEN
        SELECT JSON_EXTRACT(body, '$.value') INTO count_old FROM from_plc_last;
    ELSE
        INSERT INTO from_plc_last (time_insert) VALUES (NOW());
        SET count_old = 0;
    END IF;

    --  from_plc_last の更新
    UPDATE from_plc_last SET body = NEW.body, time_insert = NEW.time_insert;

    SET count_new = JSON_EXTRACT(NEW.body, '$.value');

    --  count_status の更新
    IF count_new <> count_old THEN
        INSERT INTO count_status (count_old, count_new, time_change) VALUES (count_old, count_new, NEW.time_insert);
    END IF;

END;
//
DELIMITER ;

3つのテーブルが登場します。

from_plc : 前述のテーブルAの実態
from_plc_last : from_plc中の最新のレコードのコピーが置かれる
count_status : 目的のデータの導出が可能なデータが記録される

各テーブルの属性は以下のとおりです。from_plcは既出なので、あらためて示すことはしません。

mysql> desc from_plc_last; 
+-------------+-----------+------+-----+---------+-------+ 
| Field       | Type      | Null | Key | Default | Extra |
+-------------+-----------+------+-----+---------+-------+
| body        | json      | YES  |     | NULL    |       | 
| time_insert | timestamp | YES  |     | NULL    |       |
+-------------+-----------+------+-----+---------+-------+
2 rows in set (0.01 sec)

mysql> desc count_status; 
+-------------+-----------+------+-----+---------+-------+ 
| Field       | Type      | Null | Key | Default | Extra | 
+-------------+-----------+------+-----+---------+-------+
| count_old   | int       | YES  |     | NULL    |       | 
| count_new   | int       | YES  |     | NULL    |       | 
| time_change | timestamp | YES  |     | NULL    |       |
+-------------+-----------+------+-----+---------+-------+
3 rows in set (0.01 sec)

mysql>

このシステムでは、from_plc_last はヒット率100%のキャッシュとして機能し、前後のデータの差を計算する処理の効率化に寄与します。

テスト

上記の解決策をテストしてみました。

データ

以前の僕の記事「サーバやPC上のプログラムでModbus機器からデータを取得 (2)」で登場したPerlスクリプトの劣化版とModbusシミュレーターでデータを発生させました。

サーバやPC上のプログラムでModbus機器からデータを取得 (2)

Perlスクリプトの46, 68行目をコメント・アウトしただけです。

結果

from_plc

mysql> select * from from_plc; 
+----------------------------------------------------+---------------------+ 
| body                                               | time_insert         |
+----------------------------------------------------+---------------------+
| {"ts": "2022-08-07T12:31:52.445466", "value": 0}   | 2022-08-07 12:31:52 | 
| {"ts": "2022-08-07T12:31:53.492522", "value": 0}   | 2022-08-07 12:31:53 |
| {"ts": "2022-08-07T12:31:54.547653", "value": 0}   | 2022-08-07 12:31:54 |
| {"ts": "2022-08-07T12:31:55.563391", "value": 0}   | 2022-08-07 12:31:55 | 
| {"ts": "2022-08-07T12:31:56.610040", "value": 0}   | 2022-08-07 12:31:56 |
| {"ts": "2022-08-07T12:31:57.672496", "value": 1}   | 2022-08-07 12:31:57 |
| {"ts": "2022-08-07T12:31:58.703830", "value": 1}   | 2022-08-07 12:31:58 | 
| {"ts": "2022-08-07T12:31:59.734885", "value": 1}   | 2022-08-07 12:31:59 |
| {"ts": "2022-08-07T12:32:00.766081", "value": 1}   | 2022-08-07 12:32:00 |
| {"ts": "2022-08-07T12:32:01.797569", "value": 1}   | 2022-08-07 12:32:01 | 
| {"ts": "2022-08-07T12:32:02.859724", "value": 2}   | 2022-08-07 12:32:02 |
| {"ts": "2022-08-07T12:32:03.891062", "value": 2}   | 2022-08-07 12:32:03 |
| {"ts": "2022-08-07T12:32:04.958819", "value": 2}   | 2022-08-07 12:32:04 | 
| {"ts": "2022-08-07T12:32:06.5521", "value": 2}     | 2022-08-07 12:32:06 |
+----------------------------------------------------+---------------------+
14 rows in set (0.01 sec)

mysql>

from_plc_last

mysql> select * from from_plc_last;
+------------------------------------------------+---------------------+
| body                                           | time_insert         |
+------------------------------------------------+---------------------+
| {"ts": "2022-08-07T12:32:06.5521", "value": 2} | 2022-08-07 12:32:06 |
+------------------------------------------------+---------------------+
1 row in set (0.00 sec)

mysql>

count_status

mysql> select * from count_status;
+-----------+-----------+---------------------+
| count_old | count_new | time_change         |
+-----------+-----------+---------------------+
|         0 |         1 | 2022-08-07 12:31:57 |
|         1 |         2 | 2022-08-07 12:32:02 |
+-----------+-----------+---------------------+
2 rows in set (0.00 sec)

mysql>

ConMas Gateway スクリプトのデバッグ (1)

2022-08-06T19:02:04+09:00

製造現場の紙帳票のデジタル化を担うi-Reporter。現段階ではまだベストなソリューションとは言えませんが、今後の機能アップが期待出来るとすればそのポテンシャルは大きく、紙帳票のデジタル化に留まらず、旧態依然な現場のパネルまでも、i-ReporterをのせたWindowsのタッチパネルに入れ替わるかもしれません。日本の製造業をチャンピオンに返り咲かせるDXの誘因として重要なソリューションのひとつであることに間違いはありません。。
このi-Reporterシステムに必須といってもよいのが"ConMas Gateway"です。まだ機能面での不足がある ConMas Gateway ですが、i-Reporter の jQuery.ajax とも言える ConMas Gateway を使わずして i-Reporter の存在意義は語れません。

この記事では、ConMas Gateway スクリプトの効率的なデバッグ手法について複数回に分けて解説します。

この記事の内容は、IT系開発に不慣れなFA系システム開発者向けです。WEBシステムのサーバ・サイド開発等に長けたITエンジニアにとっては、当たり前のことが書かれています。

この記事の内容を理解するために、i-Reporterに関する細かな知識を事前に得ている必要はありません。ただし、この知識がない方は、ある程度の想像力を働かせながら読み進める必要があります。

システム・モデル

ConMas Gateway から起動されたスクリプトは、i-Reporter からPOST（あるいはGET）されたデータを、標準入力を介して ConMas Gateway から受け取ります。
スクリプトは i-Reporter へのレスポンスを標準出力を介して ConMas Gateway へ渡し、ConMas Gateway はこれを i-Reporter にレスポンスします。

つまり、ConMas Gateway のスクリプトは、WEBシステムにおける CGIを使うスクリプトと何ら変わりがありません。

面白いのは、ConMas Gateway と ConMas Server の間にインタフェースが全く存在せず、両者は何のやりとりもしないことです。
もちろん、ConMas Server のデータベースは公開されているため、ConMas Gateway が直接あるいはスクリプトを介して、このデータベースをアクセスすることは可能です。

なお、ConMas Gateway はスクリプトがなくても、自らの機能でデータベースをアクセスし結果を i-Reporter にレスポンスすることが出来ます。ただし、このデータベースのアクセスはシンプルなものに限定され、複雑な処理、あるいはデータベース・アクセス以外の処理を行うにはスクリプトが必要となります。
この記事では、このスクリプトのデバッグについて述べており、ConMas Gateway 自身が持つデータベース・アクセスについては述べていません。

データ

i-Reporter とスクリプトの間でやりとりされるデータはJSONです。これは、データを処理する手続きをシンプルに記述できるという点で歓迎できます。

POSTされるデータは、クラスタ（i-Reporterで処理される帳票上のデータの最小単位）の属性と（当該クラスタに入力された）データが key: value のタプルとなったJSONです。複数のタプルが配列で並びます。どのクラスタをPOSTするかは、事前に ConMas Designer 上で選択します。
GETされるデータは任意です。ConMas Designer による設定でURLに続くデータを任意に記載することが出来ます。
レスポンスは、帳票上のクラスタのIDと当該クラスタに表示されるデータをタプルにしたJSONです。もちろん、このタプルは配列で複数にすることができます。

この記事では、データのフォーマットに関する細かな解説をしません。データのフォーマットに関する細かなルールや、ConMas Designer での設定については、シムトップス社から提供されるマニュアルを参照してください。これらの情報がなくても、この記事を読み進める上での支障にはなりません。
マニュアルにアクセスするには、シムトップス社のサイトにアクセスするためのIDが必要になります。

標準と思われるデバッグ手法

標準と思われるデバッグの手法は、i-Reporterで（必要であれば帳票にデータを入力し）帳票上のアクション・クラスタを発動させ、当該クラスタに設定されたスクリプトを動作させながらテストと不具合の解消を進めるという（何の工夫もない）いたって普通の方法です。
小さく単純でテストが簡単なスクリプトのデバッグでは、この方法でも良いかもしれません。ただし、大きく複雑で、複雑、高度なテストとデバッグを要するスクリプトの場合には問題が生じます。

問題

この方法ではスクリプトの動作を簡単にはトレースすることができない
この方法でのスクリプトのトレースは、デバッグのための古典的なプリント、あるいはカバレージをファイル等に出力するなどが必要となる。一方で、Python で提供される Pdb や Trace 等のコマンドラインで容易に使えるツールが使用できない。

次回

続きは次回とさせていただきます。
初心者の方々のために、ゆっくりとマッタリと進めさせていただきます。
次回は「ではどうすれば良いか」です。

ConMas Gateway スクリプトのデバッグ (2)

サーバやPC上のプログラムでModbus機器からデータを取得 (2)

2022-07-30T15:43:22+09:00

サーバやPC上のプログラムでModbus機器からデータを取得、その第二回です。
第一回では、Android上のModbusシミュレータからデータを取得するための、Perlスクリプトのサンプルを紹介しました。Perlでは問題があるという方は、他の言語で記述しても原理は変わらないはずなので、他の言語で実装してみてください。

サーバやPC上のプログラムでModbus機器からデータを取得 (1)

今回は、取得したデータをデータベースに保存します。

データベース

以前の記事で使用した、MySQLとテーブル"from_plc"
を使います。

PLCからゲートウェイでデータを取得しデータベースにJSONで保存 (4)

C:\Users\hoge\Downloads>mysql -u hoge -p
Enter password: *******
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 60
Server version: 8.0.29 MySQL Community Server - GPL

Copyright (c) 2000, 2022, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> use hoge
Database changed
mysql> desc from_plc;
+-------------+-----------+------+-----+-------------------+-------------------+
| Field       | Type      | Null | Key | Default           | Extra             |
+-------------+-----------+------+-----+-------------------+-------------------+
| body        | json      | YES  |     | NULL              |                   |
| time_insert | timestamp | YES  |     | CURRENT_TIMESTAMP | DEFAULT_GENERATED |
+-------------+-----------+------+-----+-------------------+-------------------+
2 rows in set (0.02 sec)

mysql>

Perlスクリプト

前回は、Perlスクリプトを僕のセルフォンTermux上で動作させましたが、今回はPCのWindows上で開発し動作させます。何故？

僕のセルフォンのTurmuxのcpanになんらかの問題があるらしく、DBIのビルドができないんです。いろいろトライしたけど僕には解決は無理と判断し、Turmax上のPerlスクリプトを放棄しました。
DBIは必須ではないですが、データベースをアクセスするPerlなら、DBIを使うのが一般的ですよね。
DBIのない環境で、これ以上Perlを書く気にはなれませんよね。まあ、僕のせいなんですけどね。

「サーバやPC上のプログラムでModbus機器からデータを取得 (1)」で作成したスクリプトに手を加えました。これで、Modbus機器からModbus/TCPにより取得したデータをデータベースに保存します。

#!/usr/bin/perl

use IO::Socket;
use DBI;
use Time::HiRes "gettimeofday";
use utf8;
use Encode;
use JSON;

{
    my $Server = 'localhost';
    my $Port = 502;

    my $TransactionID = 0x0200;
    my $ProtocolID = 0x0000;
    my $Length = 0x0006;

    my $UnitID = 0x01;
    my $FunctionCode = 0x03;
    my $StartAddress = 0x0000;
    my $CountRegister = 0x0001;

    my $req = pack("n3C2n2", 
        $TransactionID, $ProtocolID, $Length, 
        $UnitID, $FunctionCode, 
        $StartAddress, $CountRegister);

    my $old = -1;

    while (1) {
        my $socket = new IO::Socket::INET( 
            PeerAddr=>$Server,
            PeerPort=>$Port,
            Proto=>'tcp');
        die "IO::Socket : $!" unless $socket;

        my $size = $socket->send($req);
        shutdown($socket, 1);

        my $response = "";
        $socket->recv($response, 1024);

        my @data = unpack("n3C3n", $response);
        my $Register = $data[6];

        if ($old != $Register) {
            print "sent data:\n";
            BinaryDump($req);
            print "received response:\n";
            BinaryDump($response);

            my $now = getCurrentTimeStr();
            my $output_data = {
                'ts' => $now,
                'value' => $Register
            };
            my $json_text = decode('utf-8', encode_json( $output_data )); 
            print $json_text . "\n";
            my @values = ($json_text);

            $user = 'hoge';
            $passwd = 'hoge001';
            $db = DBI->connect('DBI:mysql:hoge:localhost', $user, $passwd);
            $sth = $db->prepare("INSERT INTO from_plc (body) values (?)");
            $sth->execute(@values);
            $sth->finish;
            $db->disconnect;
        }

        $old = $Register;

        $socket->close();
        sleep 1;
    }

}

# 利用させていただきました
# https://netlog.jpn.org/r271-635/2018/11/perl-bynary-dumper.html
sub BinaryDump {
    my ($buf) = @_;
    my $len;
    my $i;

    $len = length($buf);
    printf ("length = %d\n", $len);
    for ($i = 0; $i < $len; $i++) {
        printf("%02X ", ord(substr($buf, $i, 1)));
        # 16文字目で画面上の改行
        if (($i % 16) == 15) {
            print "\n";
        }
    }
    if (($i % 16) != 15) {
        print "\n";
    }
}

# 利用させていただきました
# https://akrad.hatenablog.com/entry/2018/10/20/234528
sub getCurrentTimeStr {
    my ($epochSec, $microSec) = gettimeofday();
    my ($sec, $min, $hour, $day, $mon, $year) = localtime($epochSec);
    $year += 1900;
    $mon++;
    return "$year" 
        . '-' . sprintf("%02d", $mon) 
        . '-' . sprintf("%02d", $day) 
        . 'T' . sprintf("%02d", $hour) 
        . ':' . sprintf("%02d", $min)
        . ':' . sprintf("%02d", $sec)
        . '.' . "$microSec";
}

Perlの自由さと気楽さが良いですね。

テスト

Windows上ということで、再び MOD-RSsim に登場いただきます。MOD-RSsimを起動しておきます。

Perlスクリプトを実行します。

C:\Users\hoge\Downloads>perl sample.pl
sent data:
length = 12
02 00 00 00 00 06 01 03 00 00 00 01
received response:
length = 11
02 00 00 00 00 05 01 03 02 00 00
{"ts":"2022-07-30T15:05:59.916895","value":0}

Holding Register 40001 の0を取得しデータベースに保存されます。

MOD-RSsim で 40001 に任意の数値を入力します。

40001 のデータが変わる都度、データベースに値が保存されます。

C:\Users\hoge\Downloads>perl sample.pl
sent data:
length = 12
02 00 00 00 00 06 01 03 00 00 00 01
received response:
length = 11
02 00 00 00 00 05 01 03 02 00 00
{"ts":"2022-07-30T15:05:59.916895","value":0}
sent data:
length = 12
02 00 00 00 00 06 01 03 00 00 00 01
received response:
length = 11
02 00 00 00 00 05 01 03 02 00 01
{"ts":"2022-07-30T15:06:04.10446","value":1}
sent data:
length = 12
02 00 00 00 00 06 01 03 00 00 00 01
received response:
length = 11
02 00 00 00 00 05 01 03 02 00 02
{"ts":"2022-07-30T15:06:07.41537","value":2}
sent data:
length = 12
02 00 00 00 00 06 01 03 00 00 00 01
received response:
length = 11
02 00 00 00 00 05 01 03 02 00 03
{"value":3,"ts":"2022-07-30T15:06:10.72655"}
sent data:
length = 12
02 00 00 00 00 06 01 03 00 00 00 01
received response:
length = 11
02 00 00 00 00 05 01 03 02 00 04
{"value":4,"ts":"2022-07-30T15:06:12.150828"}
sent data:
length = 12
02 00 00 00 00 06 01 03 00 00 00 01
received response:
length = 11
02 00 00 00 00 05 01 03 02 00 05
{"ts":"2022-07-30T15:06:14.213053","value":5}
Terminating on signal SIGINT(2)

C:\Users\hoge\Downloads>

データベースのテーブル"from_plc"を確認してみます。

C:\Users\hoge\Downloads>mysql -u hoge -p
Enter password: *******
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 75
Server version: 8.0.29 MySQL Community Server - GPL

Copyright (c) 2000, 2022, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> use hoge
Database changed
mysql> select * from from_plc;
+----------------------------------------------------+---------------------+
| body                                               | time_insert         |
+----------------------------------------------------+---------------------+
| {"ts": "2022-07-30T15:05:59.916895", "value": 0}   | 2022-07-30 15:05:59 |
| {"ts": "2022-07-30T15:06:04.10446", "value": 1}    | 2022-07-30 15:06:04 |
| {"ts": "2022-07-30T15:06:07.41537", "value": 2}    | 2022-07-30 15:06:07 |
| {"ts": "2022-07-30T15:06:10.72655", "value": 3}    | 2022-07-30 15:06:10 |
| {"ts": "2022-07-30T15:06:12.150828", "value": 4}   | 2022-07-30 15:06:12 |
| {"ts": "2022-07-30T15:06:14.213053", "value": 5}   | 2022-07-30 15:06:14 |
+----------------------------------------------------+---------------------+
6 rows in set (0.00 sec)

mysql>

まとめ

このように、Modbus機器からのデータ取得は、専用の機器や商用のソフトウェアがなくても可能です。今回はModbus/TCPでしたが、RTUでも原理は同じです。
データ取得だけではなく、Modbus機器にデータを書き込むことも難しくはありません。Modbusの仕様を理解すれば、データの取得も書き込みも簡単です。
Modbusに限らず、各メーカのPLCの仕様もほとんどがオープンになっているので、それぞれの仕様を理解しさえすれば、Modbusと同じように自分で書いたプログラムでの読み書きが可能です。
様々な種類のPLCやリモートIOなどをアクセスする場合には、ゲートウェイなどを利用したほうが良いかもしれません。一方で、限られた種類のPLCやリモートIOをアクセスする場合は、自分で書いたプログラムを使用するという選択もあると思います。

「作らない」のではなく「作れない」んです。なぜ「作れない」のか？「作らない」からです。

サーバやPC上のプログラムでModbus機器からデータを取得 (1)

2022-07-26T17:14:42+09:00

サーバやPC上のプログラムでModbus機器からデータを取得、なんて場面があります。例えば、接点やセンサーがつながったリモートIOからデータを取得したい場合などです。

この記事では、Modbus/TCPでリモートIOなどからデータを取得するサンプル・プログラムを紹介します。

この記事で紹介するサンプルはModbus/TCPを前提としていますが、Modbus/RTUでも原理は同じです
。Socketがシリアル・インタフェースに変わり、やりとりするデータのフォーマットがTCPからRTUに変わるだけです。
※RTUの場合、送受するデータにCRCを組み込む必要があり、少々やっかいですけどね。

リモートIOのメーカーのサイトでは、PLCがリモートIOからデータを取得するように書かれていたりします。リモートIOからのデータを使って機械を制御する場合はそんな構成なのかもしれませんが、そのデータをサーバやPCで処理したい場合には、リモートIOのデータをサーバやPCが直接取得するのが合理的です。リモートIOとPLCは必ずしもセットではないのです。
「そんなことは、ここであらためて書かなくてもあたりまえだろ」と思われる方も多いでしょうが、固定観念と先入観が、迷わず（本来は不要であるはずの）PLCを登場させてしまいます。

Modbus/TCP

Modbusについては、エム・システム技研さまのこのドキュメントがおすすめです。

Modbus プロトコル概説書

サンプル・プログラム

今回はPerlを使いました。Perlである必要性はありませんが、Perlではだめだという理由もありません。なぜPerlを選択したか？僕のセルフォンでPerlが使えたからです。

サンプルでは、ファンクション0x03: Read Holding Register を使っています。

データをコンソールに16進表記で表示するために、公開されていたコレを遠慮なく拝借いたしました。
(Perl) バイナリ変数の１６進ダンプ表示

#!/usr/bin/perl

use IO::Socket;

{
    my $Server = 'localhost';
    my $Port = 5502;

    my $socket = new IO::Socket::INET( 
        PeerAddr=>$Server,
        PeerPort=>$Port,
        Proto=>'tcp');
    die "IO::Socket : $!" unless $socket;
    print "connected to the server\n";

    my $TransactionID = 0x0200;
    my $ProtocolID = 0x0000;
    my $Length = 0x0006;

    my $UnitID = 0x01;
    my $FunctionCode = 0x03;
    my $StartAddress = 0x0000;
    my $CountRegister = 0x0001;

    my $req = pack("n3C2n2", 
        $TransactionID, $ProtocolID, $Length, 
        $UnitID, $FunctionCode, 
        $StartAddress, $CountRegister);
    my $size = $socket->send($req);
    print "sent data:\n";
    BinaryDump($req);

    shutdown($socket, 1);

    my $response = "";
    $socket->recv($response, 1024);
    print "received response:\n";

    BinaryDump($response);

    $socket->close();
}

# 利用させていただきました
# https://netlog.jpn.org/r271-635/2018/11/perl-bynary-dumper.html
sub BinaryDump {
    my ($buf) = @_;
    my $len;
    my $i;

    $len = length($buf);
    printf ("length = %d\n", $len);
    for ($i = 0; $i < $len; $i++) {
        printf("%02X ", ord(substr($buf, $i, 1)));
        # 16文字目で画面上の改行
        if (($i % 16) == 15) {
            print "\n";
        }
    }
    if (($i % 16) != 15) {
        print "\n";
    }
}

テスト

テストにも僕のセルフォンを使いました。
Modbusスレーブとして、Androidアプリケーション"ModTCPSimX"に活躍いただきました。

ModTCPSimX のポート番号のデフォルトは5502です。僕のプログラム側も5502にしてあります。
※一般的なModbus/TCPは502です。
Holding Register 40001 に任意の数値を設定しておきます。
※ModTCPSimX では値の背景が黄色の場合は更新がコミットされていません。鉛筆アイコンでコミットするのを忘れずに

Termuxでプログラムを動かすと、最後のバイトに値が置かれたTXが返ります。

次回

せっかくなので、次回は取得したデータをデータベースに保存します。どうってことないんですけどね。

サーバやPC上のプログラムでModbus機器からデータを取得 (2)

PLCからゲートウェイでデータを取得しデータベースにJSONで保存 (6)

2022-07-23T23:14:58+09:00

PLCからゲートウェイでデータを取得し、データベースにJSONで保存します。複数回に分けて、サンプルを用いて解説します。
前回は、PLCから取得したデータをデータベースに保存しました。

PLCからゲートウェイでデータを取得しデータベースにJSONで保存 (5)

タイトルに書かれたテーマは前回で完了しています。完了していますが、これでは何か物足りないと感じ、今回はデータベースに次々と書かれるPLCからのデータをブラウザに表示してみます。

WEBアプリケーション

データベースのデータをWEBブラウザに表示するために、WEBアプリケーションをサーバ上に作成します。このサンプルでは、WEBアプリケーションはPHPスクリプトで実装します。

いよいよ図が窮屈になってきました。これ以上に窮屈な図は、もはや理解容易性の面で逆効果です。正確さと理解容易性は、ある時点以後、反比例します。

PHPである必要はありません。では、このサンプルを何故にPHPスクリプトで実装するのか？それは、そこ（私の開発環境）にPHPが稼働していたから。

PHPの準備についてはここでは解説しません。PHPの準備についての解説は、他の記事にお任せします。PHPスクリプトでのMySQLアクセスについても、他の記事にお任せします。

HTMLとPHPスクリプト、そしてJavaScript

結果的には、サーバ・サイドはPHPスクリプトのみではなく、以下の3つのファイルで構成してみました。

HTML
PHPスクリプト
JavaScript

3つめの JavaScript は jQuery です。jQuery は一般に配布されているとても便利なライブラリです。jQuery を利用することにより、とても高機能なWEBアプリケーションを短期間で実装することができます。jQuery の解説も他の記事にお任せします。

以下がサンプルです。

index.htm



  
  
  Sample
  
  


  count: count

index.php

getMessage() . "\n";
    exit();
  }

  $sql = "SELECT JSON_EXTRACT(body, '$.value') AS count FROM from_plc ORDER BY time_insert DESC";
  $res= $dbh->query($sql);
  foreach($res as $value) {
    echo $value['count'];
    break;
  }
?>

jQuery は、HTML中で参照されている、jquery-3.6.0.min.js です。
HTML中には、jQueryを呼び出すオリジナルのJavaScriptスクリプトを書いています。
いずれもコードの解説はいたしません。

WEBブラウザでアクセスしてみる

WEBブラウザで上記の index.htm を参照すると以下ようになります。

数字は、データベース上のテーブルが更新される都度変化してます。（正確には、JSONの要素"value"の値が変化してから1秒以内に、ブラウザの表示も変化します）

最後に

ここまでサンプルとして実装したシステムを応用すると、工場の機器により製造される製品の生産数を、ほぼリアルタイムに画面表示する、といったシステムを構築することができます。
勘違いしていただきたくないのは、この記事で示したサンプルはあくまでもサンプルであって、基盤となるミドルウェアやプロトコル、プログラム言語は、この記事のサンプルで使用したものである必要はありません。もし、この記事で取り上げたような、PLCからデータを取得し、これを処理するようなシステムを設計・構築する場合は、この記事の内容にとらわれず、それぞれの環境、条件、実現したい機能などに応じて、最適なハードウェア、ミドルウェア、プロトコル、プログラム言語、そしてアーキテクチャを想像し選択してください。

実はこのアーキテクチャを想像する、というのが設計者にとって最も楽しく重要な工程なのです。実装のテクニックなどは、アーキテクチャの上に成立する技術であって、アーキテクチャがイマイチなシステムは、おそらく実装もへんてこりんになってしまったり、どこかアンバランスなものになってしまうものです。

PLCからゲートウェイでデータを取得しデータベースにJSONで保存 (1)
PLCからゲートウェイでデータを取得しデータベースにJSONで保存 (2)
PLCからゲートウェイでデータを取得しデータベースにJSONで保存 (3)
PLCからゲートウェイでデータを取得しデータベースにJSONで保存 (4)
PLCからゲートウェイでデータを取得しデータベースにJSONで保存 (5)

Raspberry Pi に Ubuntu を入れて SSH でログインするまでの A to B

2020-09-01T00:07:27+09:00

何番煎じかわからないが、 Raspberry Pi (以下、 RasPi) に Ubuntu を入れる手順についてまとめてみようと思う。

Ubuntu 公式の How to install Ubuntu on your Raspberry Pi チュートリアルは充実しているし、単にインストールして動かすだけなら、既にある記事でも十分だろうとは思う。
しかし、初回セットアップ時の細かいカスタマイズについて書かれているものがあまり見当たらなかったので、この記事ではそれについて補足しながらまとめていく。

先に断っておくが、 cloud-init による IaC の話が中心になる。

TL;DR

焼いた SD を RasPi に挿す前にブートプロセスの設定を書き換える
cloud-init の挙動を理解しろ
モニター無し＆無線LAN Only だと、工夫がいる
ARP リクエストのブロードキャストが届かないと苦労する

きっかけ

完全に私事だが、おしごとで Linux 使うことが増えてきて、 WSL (or WSL2) や仮想マシン上の知識だけではなかなか難しい、ネットワーク回りの知識が不足してきた。
そこで、勉強がてら何らかの物理的な Linux マシンが欲しかった。

中古の x86 ラップトップに Linux を入れるのでも良かったのだが、それだと Linux 向けの無線やネットワーク回りのドライバーが揃っているか確認するのが難しい。
そこで、様々な Linux ディストリビューションが公式でサポートされ、 I/O も充実していて、コスパの高い Raspberry Pi 4 B+ をチョイス。

これまで、 RasPi 自体は所持していたのだが、電子工作目的であったことから Raspberry Pi OS (旧 Raspbian) しか入れていなかった。
より Linux サーバーらしい使い方も試してみたいと言うことから、今回は Ubuntu をいれることした。

いざ、セットアップはじめようとして、致命的な問題に気づく。
micro-HDMI のケーブルを持っていないと言うことに…

ということで、なんとかセットアップを工夫して、 モニターが無くても一通り設定して ssh できる ところまで持って行くことを目標にする。

準備

用意するものは以下の通り。

Raspberry Pi 2 または 3 または 4
8GB 以上の microSD カード
misroSD を書き込める PC (Win, Linux, mac)
インターネットに繋がる Wi-Fi またはイーサネットケーブル

RasPi 無印や Zero など、 SoC (CPU) が ARMv6 のものは、 Ubuntu ではサポートされていない。

microSD カードは、 IOPS が速いものの方が、後々うれしいだろう。
SD カードの規格で言えば、アプリケーションパフォーマンスクラス A1 や A2 に対応しているものが良いというコトなのだろうが、正直モデル差やロット差が激しすぎるので、実際買ってみて IPOS が早いかどうか試してみるしかないと思う。

以下のものも有れば望ましいが、今回の手順ではなくても大丈夫。

HDMI (RasPi 4 の場合は micro-HDMI) で繋がるモニター
RasPi 繋げる USB キーボード

ブータブル SD の作成

まず、使用する Ubuntu の OS イメージを準備しよう。

2020年8月時点では、 20.04 LTS と 18.04 LTS に対して、それぞれ 32bit版と 64bit版が存在する。

特に理由が無ければ、 20.04 LTS の 64bit 版で良いだろう。
但し、 512MiB しか RAM がない RasPi 3A+ では、 64bit OS だと ssh でアクセスするだけで Out of Memory してしまうので、 32bit にすることをオススメする。
また、 RasPi 2 の CPU は 32bit 版なので、 32bit OS しか選べない。

microSD への書き込みは、主に以下の 2種類の方法がある。
どちらか好きな方でどうぞ。

メモ:

以前は NOOBS という、 RasPi を起動後に OS 選択させてインストールさせるツールも存在したが、今回は触れない。  
詳しくはググってほしい。

1. イメージファイルをダウンロードして任意のツールで焼き込む

Install Ubuntu Server on a Raspberry Pi 2, 3 or 4 のページからダウンロードしたイメージファイルを、任意のツールで microSD に焼く方法。

個人的には、 balenaEtcher を使って焼くのが、以下の理由でオススメ。

.gz, .xz, zip などで圧縮された状態のイメージをそのまま焼ける
- オンザフライで解凍しながら焼かれるので、あらかじめ展開しておく必要が無い
- ... と思っていたけど、最近のバージョンでは一旦一時ファイルに展開されてから焼かれるっぽい。それでも早いけど。
Portable 版がある (インストール不要)

2. Raspberry Pi Imager を使う

Raspberry Pi 財団公式サイトの Raspberry Pi Downloadsi ページからダウンロードできる、 Raspberry Pi Imager を使って、 OS のイメージをダウンロードしながら microSD に焼く方法。

Raspberry Pi Imager をインストールして起動すると、インストールしたい OS を尋ねられるので、ここで Ubuntu の任意のバージョンを選択する。

ダウンロードしながらそのまま焼き込むため、本来なら (1) よりも早くてオススメのハズ…
…なのだが、少なくとも私が試した限り、 (1) のほうがずっと早いんだよねぇ。。。

OS イメージを DL元が違って、ダウンロード速度がネックになって遅くなっているのかな…
あまり深く調べてないけど。

system-boot パーティション内の cloud-init 等の設定を書き換える

作成した micorSD を早速 RasPi に挿す …前に 、初回セットアップ設定の書き換えを行う。

一度書き込んだ microSD を再び PC に挿すと、 "system-boot" という 250MB 位の FAT32 パーティションが開けるはずだ。

このパーティション直下にある README というファイルを開くと、このパーティションに存在するファイルの概要が簡単に書いてある。

An overview of the files on the /boot/firmware partition (the 1st partition
on the SD card) used by the Ubuntu boot process (roughly in order) is as
follows:

* bootcode.bin   - this is the second stage bootloader loaded by all pis with
                   the exception of the pi4 (where this is replaced by flash
                   memory)
* config.txt     - the first configuration file read by the boot process
* syscfg.txt     - the file in which system modified configuration will be
                   placed, included by config.txt
* usercfg.txt    - the file in which user modified configuration should be
                   placed, included by config.txt
* start*.elf     - the third stage bootloader, which handles device-tree
                   modification and which loads...
* uboot*.bin     - various u-boot binaries for different pi platforms; these
                   are launched as the "kernel" by config.txt
* boot.scr       - the boot script executed by uboot*.bin which in turn
                   loads...
* vmlinuz        - the Linux kernel, executed by boot.scr
* initrd.img     - the initramfs, executed by boot.scr
* meta-data      - meta-data for cloud-init; usually just contains the
                   instance id
* network-config - network configuration for cloud-init; edit this to set up
                   wifi access points and other networking settings
* user-data      - user-data for cloud-init; edit this to configure initial
                   users, SSH keys, packages, etc.

このパーティションには、 Raspberry Pi の BIOS の変わりとなる config.txt, bootcode.bin, start.elf と言った構成ファイルや、ブートコード、そして cloud-init の構成ファイルが入っている。

このうち cloud-init というのは、 Infrastructure as Code (IaC) の一種だ。その名の通り、 AWS 等のクラウド上の仮想マシンの初期設定を得意としている。
校正用の設定ファイル (YAML) を使って設定内容を記述することで、クラウドやディストリビューションの違いをある程度吸収して初期設定を記述することができる。
OS のイメージ内に予め cloud-init のサービス(デーモン) が組み込まれており、 OS の起動時に各クラウドのサービスの UI 経由で設定ファイルを読み取って、主に初回起動時に初期設定処理が走る… というのが主な仕組みとなっている。

RaspPi 用の Ubuntu Server イメージでは、この cloud-init 用の設定ファイルの取得元が上記の system-boot パーティションとなっている。
イメージ組み込みの定義と system-boot パーティション内の定義を組み合わせて、初期設定が実行される。

例えば、このイメージを使ってそのまま Ubuntu を起動すると、 "ubuntu" というログイン ID に "ubuntu" というパスワードが設定され、 SSH のパスワード認証が有効になった状態で起動している。
このうち、 "ubuntu" というユーザー名と SSH サーバーの起動は、 OS 組み込みの /etc/cloud/cloud.cfg の定義によるもの。
そして、 "ubuntu" というパスワードの設定と、 SSH のパスワード認証の有効化は、 system-boot パーティションの user-data ファイル内の以下の定義によるものだ。

#cloud-config
chpasswd:
  expire: true
  list:
  - ubuntu:ubuntu

ssh_pwauth: true

とうことで、遠隔から SSH ログインできるように、こららのファイルを順に書き換えていこう。

cloud-init の network-config

network-config ファイルには、以下の 2つの大きな役割がある。

cloud-init 初期設定実行前にデバイスをネットワークにつなぐ
netplan の /etc/netplan/50-cloud-init.yaml にファイルの内容を転記する

『何だ、同じことじゃないか』と思われるかも知れないが、この二つはシステムに適用されるタイミングと言う点で大きく異なる。

前者は、 cloud-init サービスの起動直後に、 cloud-init の通信を行うためにシステムに適用される。
一方後者は、後者は内容をファイルにコピーするだけである。

cloud-init サービスによって netplan の 50-cloud-init.yaml が書き換わるのは、ネットワークサービスの起動より後になる (systemd の /usr/lib/systemd/system/cloud-init.service の設定を参照)。
このため、システムやサービスが再起動されるか、能動的に netplan apply しないと、 50-cloud-init.yaml の内容は適用されない。

そしてもう一つ重要なのが、以下の一文。

Networking Config Version 2 — cloud-init 20.3 documentation

Cloud-init does not current support wifis type that is present in native netplan.

そう。
前者では、 Wi-Fi の設定が無視されるのだ。

すなわちこれは、有線LAN が繋がっていない場合、ファイルの更新や apt パッケージの取得などのインターネットに繋ぐような処理は、初回ブート時の cloud-init では全くできないことを意味する。
幸いにも、 Ubuntu イメージ組み込みの cloud-init の初期設定の内容は、ネットワークに繋がっていなくても処理が完走できる。

cloud-init の元々の用途を考えれば、 Wi-Fi が設定できる必要性はないだろうし、仕方が無いことなのかも知れないが……

このファイルに Wi-Fi の設定を記載しただけでは、初回起動時には Wi-Fi が有効にならないことは覚えておこう。
後の手順に関係してくる。

とりあえず、 netplan の設定に Wi-Fi アクセスポイントの情報は書いておきたいので、 network-config は以下のように書き換える。
SSID やパスワードは自分の環境のものに置き換えて書いてくれ。

--- network-config.org
+++ network-config
@@ -11,15 +11,15 @@
 ethernets:
   eth0:
     dhcp4: true
     optional: true
-#wifis:
-#  wlan0:
-#    dhcp4: true
-#    optional: true
-#    access-points:
-#      myhomewifi:
-#        password: "S3kr1t"
+wifis:
+  wlan0:
+    dhcp4: true
+    optional: true
+    access-points:
+      "SSID-of-myhomewifi":
+        password: "password-of-myhomewifi"
 #      myworkwifi:
 #        password: "correct battery horse staple"
 #      workssid:
 #        auth:

cloud-init の user-data

cloud-init 書き換えのメインとなる user-data。
これは、 Cloud Config Data の内容を記述する YAML 形式のファイルだ。
基本的には、 OS 組み込みの /etc/cloud/cloud.cfg の値を上書きしたり、 cloud.cfg で読み込まれた Modules の設定を記述していく。

書き換え部分が長いので、3カ所に分けて説明していく。

--- user-data.org
+++ user-data
@@ -14,12 +14,22 @@
 # expire user passwords
 chpasswd:
   expire: true
   list:
-  - ubuntu:ubuntu
+  - newusername:ubuntu
+
+# Override the default user name defined in cloud.cfg
+system_info:
+  default_user:
+    name: newusername

 # Enable password authentication with the SSH daemon
-ssh_pwauth: true
+ssh_pwauth: false
+ssh_authorized_keys:
+- ssh-rsa AAAA<中略>== rsa-key-of-user1
+
+# locale and timezone
+timezone: Asia/Tokyo

 ## On first boot, use ssh-import-id to give the specific users SSH access to
 ## the default user
 #ssh_import_id:

既に上でも触れたが、 OS 組み込みの cloud.cfg の定義によって、 "ubuntu" というユーザーが作成されている。
しかし、既知のユーザー名をそのまま使うのはセキュリティ的にも若干不安があるし、作成後のユーザー名を書き換えるのは若干面倒なので、作成されるデフォルトのユーザー名自体を、他の名前に書き換えてしまおう。
system_info.default_user で、作成されるユーザ名を変更できる。
また、 chpasswd によるパスワード書き換えの対象となるユーザ名も変更しておこう。

ssh_pwauth で、 ssh のパスワード認証が有効になっているので、コレは切ってしまいつつ、
代わりに、 ssh_authorized_keys[*] リストに公開鍵を登録する。
これで安全に ssh できるようになった。恵dc

ついでにタイムゾーンも JST (Asia/Tokyo) に書き換えておこう。

--- user-data.org
+++ user-data
@@ -53,19 +63,20 @@
 #- pastebinit
 #- [libpython2.7, 2.7.3-0ubuntu3.1]

 ## Write arbitrary files to the file-system (including binaries!)
-#write_files:
-#- path: /etc/default/keyboard
-#  content: |
-#    # KEYBOARD configuration file
-#    # Consult the keyboard(5) manual page.
-#    XKBMODEL="pc105"
-#    XKBLAYOUT="gb"
-#    XKBVARIANT=""
-#    XKBOPTIONS="ctrl: nocaps"
-#  permissions: '0644'
-#  owner: root:root
+write_files:
+- path: /etc/default/keyboard
+  content: |
+    # KEYBOARD configuration file
+    # Consult the keyboard(5) manual page.
+    XKBMODEL="pc105"
+    XKBLAYOUT="jp"
+    XKBVARIANT=""
+    XKBOPTIONS=""
+  permissions: '0644'
+  owner: root:root
+- path: /etc/cloud/cloud-init.disabled
 #- encoding: gzip
 #  path: /usr/bin/hello
 #  content: !!binary |
 #    H4sIAIDb/U8C/1NW1E/KzNMvzuBKTc7IV8hIzcnJVyjPL8pJ4QIA6N+MVxsAAAA=

お次は、ファイルの作成。

日本語キーボードを認識しないと面倒なので、 /etc/default/keyboard を書き換えて日本語キーレイアウトを認識させる。
但し、 Ubuntu Server では、このファイルを書き換えただけだとキーボードレイアウトの変更が有効にならないので、後述の runcmd で dpkg-reconfigure コマンドを対話無しのオプションをつけて実行しておく。

cloud-init の設定の大半は、初回ブート時にただ一度だけ実行されるのだが、 cloud-init サービス自体は基本的に毎回常に起動して、サービスとして常駐しっぱなしになっている。
Modules で、 Module frequency: per always となっているモジュールの実行などは、ブートする度に毎回実行される。
そうすると、場合によっては cloud-init の実行ログがログイン画面を覆ってしまうことが毎回の起動毎に発生して鬱陶しい。
このため、 /etc/cloud/cloud-init.disabled という空ファイルを作成しておくことで、次回以降の起動時に cloud-init を無効にしておく。

--- user-data.org
+++ user-data
@@ -72,8 +83,19 @@
 #  owner: root:root
 #  permissions: '0755'

 ## Run arbitrary commands at rc.local like time
-#runcmd:
+runcmd:
+# apply keyboard configration
+- [ dpkg-reconfigure, -f, noninteractive, keyboard-configuration ]
+# apply netplan config defined on 'network-config'
+- [ netplan, apply ]
+# after wlan0 is connected, write the arp entry to target machine on background job
+- [ nohup, sh, -c, 'sleep 30; ping 192.168.0.2 &' ]
 #- [ ls, -l, / ]
 #- [ sh, -xc, "echo $(date) ': hello world!'" ]
 #- [ wget, "http://ubuntu.com", -O, /run/mydir/index.html ]
+
+# Restart 2 minutes after running all config modules (for apply keyboard configration)
+power_state:
+  delay: '+2'
+  mode: reboot

最後に、任意のコマンドの実行。

最初の dpkg-reconfigure は、 keyboard の書き換えを反映させるため。

[ netplan, apply ] のコマンドで初めて、 network-config で設定した Wi-Fi 設定が有効になる。

最後の [ nohup, sh, -c, 'sleep 30; ping 192.168.0.2 &' ] は説明が難しいのだが、これは仮に ssh でゲストの IP アドレスが 192.168.0.2 であると仮定して、そこへ向かって Ping を打っている。
何故そのようなことをしているかというと、ゲストPC から RaspPi の IP アドレスを ARP コマンドで確実に調べられるようにするためだ。

RasPi に繋げるモニターがないことを前提とすると、 SSH するために DHCP によって RasPi に割り当てられた IP アドレスをどうやって調べるのか、と言う問題に直面する。

How to install Ubuntu on your Raspberry Pi #4 に書かれているように、 RasPi の MAC アドレスの先頭 24bit は b8-27-eb (Pi 2~3) もしくは dc-a6-32 (Pi 4) と決まっている。
通常、 RasPi がオンラインになったときに、 ARPリクエストがブロードキャストされるため、同一ネットワーク内の PC の ARP テーブルに RasPi のレコードが追加され、以下のような arp コマンドで対象の IP アドレスを調べることができるようになる。。。 多くの場合は。

while(1) { arp -a | ?{ $_ -match 'dc-a6-32' }; Start-Sleep -Seconds 1}

ところが、 RasPi が Wi-Fi で繋いでいるのがルーターだったりすると、ルーターが気を利かせて、同じサブネット内であっても ARPリクエストを代替して投げてしまい、同じサブネットの端末全員の ARP テーブルには、 RasPi の MAC アドレスのレコードが記録されないことがある。

そこで、 RasPi 側から SSH のアクセス元となる PC を指定して ping を投げることで、その PC の ARP テーブルに確実に RasPi が載るようにしている。

ちなみに、 30秒 sleep しているのは、 netplan apply した直後はまだ Wi-Fi に繋がっていないことが多いためだ。

そして最後に、 cloud-init の停止やタイムゾーンの変更を確実に反映するため、 power_state で再起動させている。

RasPi の config.txt

cloud-init とは関係ないが、必要があれば config.txt の構成ファイル書き換えてしまおう。

例えば、 HDMI の解像度が一般的でなかった場合や、端末とのネゴシエーションがヘタクソで適切な解像度で表示できない場合などは、このファイルで HDMI の解像度を指定してやる必要がある。

参考:
* Raspberry Pi 4B 画面解像度設定（TV出力版） - Qiita
* Video options in config.txt - Raspberry Pi Documentation

但し、 config.txt には、

# Please DO NOT modify this file; if you need to modify the boot config, the
# "usercfg.txt" file is the place to include user changes.

って書いてあるので、書き換えるなら config.txt ではなく usercfg.txt にしておくと良い。

--- usercfg.txt.org
+++ usercfg.txt
@@ -1,3 +1,9 @@
 # Place "config.txt" changes (dtparam, dtoverlay, disable_overscan, etc.) in
 # this file. Please refer to the README file for a description of the various
 # configuration files on the boot partition.
+
+framebuffer_width=1024
+framebuffer_height=600
+hdmi_group=2
+hdmi_mode=87
+hdmi_cvt=1024 600 60 1 0 0 0

起動する

こんな感じで一通りファイルを書き換えたと、 RasPi に microSD をさして起動すると、初回ブート時の設定を適用しながら起動してくれる。

cloud-init の処理が終わらなくても、ログイン画面には進み、その後も cloud-init のサービスは稼働し続ける。
このため、最初の起動でログイン可能になったとしてもログインせず、全ての処理が終わって一度再起動されるのをおとなしく待つ方が良い。

RasPi 3A+ の場合、全ての処理が終わるのに5分以上ったので、気長に待つようにしよう。

前述の arp で RasPi の IPアドレスを調べて、そこに対して SSH できるようになっていれば、とりあえずは完成だ。

cloud-init についてもう少し掘り下げて説明しようと思ったのだが、記事が長くなってしまったので、次回の更新に回す。