こんにちは、無人機担当エンジニアの筑紫です。
今回は、私が無人機の開発に携わるようになって、初めて本格的に取り扱う事になったデータ連携の部分を少しお話させていただこうかと思います。
予約データの連携
無人機での車両の貸出し手続きをおこなうには、基本的には予約が必要です。
各加盟店様の方で基幹となるwebシステムがございますので、そちらから予約いただく形になります。
そして、一定間隔で基幹システムと無人機の間でデータ連携をおこない、予約情報が取得できれば無人機側で手続きが可能となる寸法です。
そのデータ連携はMXL形式のデータでやり取りをおこなっています。
例としては、下記のような形になります。
この受け取ったXMLデータを解析し、無人機内のデータベースにある項目にそれぞれ取り込んでいくわけですが、中には基幹システム側との仕様の兼ね合いで、そのままでは支障が発生する場合があります。
例えば上記の＜クラス＞の場合、基幹システム側から受け取ったデータには「軽自動車」と名称が格納されていますが、無人機側では番号で管理しているのでエラーになっちゃう！などなど。
そういった場合には、データを取り込む際にマスタを参照してクラス名称からクラスコードに変換するロジックを通すことで、番号に変換して取り込みをおこないます。
もちろん逆も然り、無人機側から基幹システムにデータを送る場合には、逆にクラスコードからクラス名称に変換してからXMLを送信する、という形になっています。
こういった単純な変換であれば特に難しいことはないのですが、ちょっと手こずったのが車両番号、いわゆるナンバープレートの部分でした。
無人機では鍵の番号をナンバープレートのひらがな以降の数字（最大4桁）で管理して、予約された車と一致しているかどうかの判定をしています。
そのため、当初は平仮名の「わ、れ」以降の文字を単純に切り出して取り込むようにしていたのですが、ある日突然取り込み結果に不具合が発生しました。
調査したところ、地域名に平仮名の「わ」が含まれており、その影響で文字の切り出し範囲にズレが生じていたことが判明。
その地域名が「いわき」「なにわ」の２つでした。
あろうことか、地元である「なにわ」を失念するという大失態。
あわててこの二つの地名を除外した上で数字を取り込むように修正したのも、今となっては良き思い出です。いや良くはないか。うん。
事前によく調べておけという話ですよね。反省。。
ちなみに、なぜ「わ、れ」以降の文字を切り出すようにしていたかと言うと
ナンバープレートの豆知識
いきなりなんやねんという感じですが
前述の不具合が発生した際に、ナンバープレートについて色々と調べましたので、そのお話をここで強引にねじ込んでみました。
ナンバープレートと言えば一番大きな4桁の番号や地域名の部分がわかりやすくて目立つ部分かと思いますが、他の部分にもちゃんとした意味があります。
まずは地域名の横の3桁の数字。
こちらは分類番号になっていて、一番左の1桁が「３」だと普通乗用車、「５」や「７」は小型乗用車、という風に、車の種類を表しています。
そして、平仮名一文字の部分。
これはその車の用途を表しており、下記のように分けられています。
・あ行～か行 ⇒事業用
・さ行～ま行、や、ゆ、ら行 ⇒自家用
・わ、れ ⇒レンタカー
・A、B、E、H、K、M、T、Y、よ ⇒米軍関係
ちなみに、「お」「し」「へ」「ん」の4文字は、ナンバープレートには使われていません。
その理由としては
・お ⇒「あ」と誤認しやすいから「を」で代用
・し ⇒「死」を連想するから
・へ ⇒「屁」を連想するから
・ん ⇒ 発音しにくいから
だそうです。
いや、「屁」て。他のはまあわかるけど、「屁」て。
そんな理由！？ と、当時は率直にそう思いました。
改めて見ると、今でも同じ思いです。「屁」て。
というわけで、おそらくレンタカーのシステム開発に関わっていなかったら、ここまでわざわざ調べることはなかったと思いますが・・・
これもまた、エンジニアの面白さという事で。
