交通系ICカードの物販について分かったこと

ICカードこれひとつへの数多くの情報提供により、交通系の物販も、かなり解読が進みました。

階層構造


詳細は不明ながら「イシュアー」→「アクワイアラー」→「種類」→「端末」という番号の階層構造が予想されます。

そしてカードには、うち端末番号が記録され、イシュアーやアクワイアラーは記録されません。


格納される情報


・イシュアー: カードを発行している会社(manacaとPASMOは複数ある)
・アクワイアラー: 実際にカード端末を発行する会社
・種類: 現在は、有人と自動販売機の区別がある
・端末: 上の3情報と組み合わせて一意になる番号が割り当てられている


情報量


ビット構成の全てを解読したわけではないので、以下は全て予想となりますが、今のところ、「端末」のIDは20ビット、「アクワイアラー」は4ビットあると予想しており、うちカードには端末IDの下位16ビットが記録されると見込んでいます。
ですので、この予想では、アクワイアラー1社しかないとしても最大16が重複してしまい、もしアクワイアラー最大16がひしめきあう状況になれば、最大256の重複がありうることが分かりました。
しかも、manacaとPASMOは一つのカードに複数のイシュアーが存在しますので、カード種類という括りであれば、PASMOでは1000を軽く超える規模の重複が将来的に予想されます。

このほか「種類」として、有人・無人の区別があります。カードには、有人は0xC7、無人(自動販売機)は0xC8として記録されますが、こちらも4ビット領域があるため、最大で16の区別が可能なようです。


下位情報の補足


アクワイアラー番号 → C7/C8の区別 → 端末ID の順に並ぶと予想しています。


上位情報の補足


イシュアーは、SPRWIDの頭2桁の英字で区別されているようです。A〜Zが26種類なので、26×26=676までのイシュアーが可能なようです。

また、各イシュアーごとに、アクワイアラー&種類&端末番号までの範囲を最大10倍に拡張できる余裕が持たれているようです(10進数で1桁分の余裕)。

ということは、PASMOは本気出せば1万以上の重複が生じうる可能性があります。


結論


以上より、交通系の物販については膨大な量の重複が今後想定され、いずれ全てを履歴画面に併記することは難しくなる日が来ると見込まれます。

交通系は無理と判断して諦める方法もありますが、それはそれで面白くありませんし、現に交通系物販の表示はかなり需要があり膨大な量の報告が届いていますから、今のところは重複があって対応を続ける予定です。
ただ、現在のアプリは1万件も重複表示できるような内部設計にはなっていないので、随時時間を見ながら内部の仕様変更を進めていきたいと考えています。

そして、あまりにも重複が多い場合は履歴画面に全部を表示するのではなく、必要に応じてタップして一覧のダイアログを表示する、のように構成を変更する必要が生じるものと想定をしています。

とはいえ、本当に1万件も重複してしまうと膨大なメモリー領域が必要となり、かなりの端末スペックを要求することになると思いますし、実際に1万件も表示したところで読み切れませんから表示する意味が殆どなくなるものと思われます。

1万は大げさとしても、数十件重複するだけで、見て確認できるレベルを超えますから、いずれは破綻を来す日が来るのだろうと予想をしています。

2017/05/25(木)23:38 |Comments(0) |Trackback(0)

製造開発 | ソフトウェア開発 | コンピュータ | [編集]

▲ページトップ

「なっち」通常と昼割は完全に分離可能かどうか

これはある種のパズルゲームの問題です。

求めるもの


履歴20件の残高を、「通常」と「昼割」に分けること。


与えられる条件


①残額の概念には、「通常」と「昼割」の二種類がある
②最終的な「通常」と「昼割」の残高は分かる
③各履歴に記録されるのは「通常」と「昼割」の合算
④各履歴で消費したものが「通常」か「昼割」かは分からない
⑤時刻は分かるので、昼割条件かどうかの判断は可能


弊社が考えたこと


まず新しい方から古い方へと順番に、それが昼割条件かどうかを判断する。
最終的な残高は分かるので、その条件ごとに、通常残高または昼割残高から引き算し、その結果をその履歴行の回答とする。
19件について同様に実施する(20件目のみは次がなく利用額が不明なため計算しない)

この方法で一見上手く動いているように見えたものの、昼割に一切チャージしない条件で、乗車が昼割条件に合致した場合、以降全ての計算が誤るという、とても残念な結果になりました。

判断する時点では、その一つ過去の昼割残高を得る術がないため、結論としては、この与えられる条件内では解を得ることができないものと判断しました。

皆様はこのパズルを解くことが出来るでしょうか。

2017/05/03(水)13:14 |Comments(0) |Trackback(0)

製造開発 | ソフトウェア開発 | コンピュータ | [編集]

▲ページトップ

福島交通NORUCAについて

はじめに


特定地域用の交通系ICカードの一つに、福島交通のNORUCAがあります。

NORUCAに限らず交通系ICカードは「情報」「残額」「履歴」という大きく3つの領域で構成されるのが一般的で、うち「情報」領域にはカードの種類を表わすため事業者番号が書き込まれていることが多いのです。

しかしNORUCAの場合、どうも「情報」領域の様子がおかしい。
そこで、全国のICカードこれひとつユーザーの皆様に情報提供を求めたところ、多数の情報が寄せられ比較をすることができました。

比較した結果


比較した結果として、以下の共通情報を得ることができました。
# Service code = 804B : Random Access Read only
804B:0000 0F C9 00 01 E0 00 00 10 00 00 10 00 14 80 40 00
804B:0001 xx xx 19 00 00 00 00 00 00 00 00 00 xx xx xx xx

情報領域となるサービス804Bは、2ブロック計32バイト構成です。
後のブロックの先頭2バイトはカードの作成日、最後の4バイトはカード固有のIDが記録されていますので伏せました。

最初のブロックの先頭2バイトは、本来サイバネ規格の事業者番号が書き込まれるはずなのですが、弊社が知る限り、0F C9 は福島交通株式会社に割り当てられた事業者番号ではありません
これは、広島に本社を置きフェリーなどを運航している、瀬戸内海汽船株式会社に割り当てられた番号であり、この会社はPASPYに参入しています。

結論


事業者番号が重複することは考えにくく、また 0FC* となるこの近隣の番号は、概ね広島周辺の会社が割り当てられていることから、以下が予測されます。

NORUCAに書かれている事業者番号らしきものは、間違っている

結果として、NORUCAには福島交通株式会社の正確な事業者番号が書かれていないと予測され、もって現時点では、福島交通株式会社の正確な事業者番号を知る手段がなく、これは未知ということになります。

2017/04/30(日)09:14 |Comments(0) |Trackback(0)

地域振興 | ソフトウェア開発 | コンピュータ | [編集]

▲ページトップ

いわさきICカードの停留所番号について(3回目)

詳細は1回目である「いわさきICカードの停留所番号について」をご覧下さい。

データフォーマットについて


いわさきグループは、他社と異なりデータフォーマットが異なっておりましたが、ほぼ特定に至りましたので報告を致します。

RapicaといわさきICカードの基本的なデータフォーマットは、1回目を読んで頂いての通りですが、重要な要素は次の項目となります。

+3〜+6 (4バイト): 事業者、駅・停留所番号
+7〜+8 (2バイト): 系統番号?
+9〜+B (3バイト): 装置番号?

Rapicaの事業者である、鹿児島市交通局・南国交通・JR九州バスは、同じフォーマットで+3〜+6の4バイトの中に停留所番号を保存していました。
また最近、装置番号(≒車体番号)が記録されていることも確認致しましたので、ここから系統番号も記録されていることはほぼ確実とみております。

しかし、いわさきICカードはフォーマットが全く異なっており、長く情報収集を続けてきました。
停留所番号は他社と同様に最初の4バイトにあると仮定して情報収集してきましたが、このたび、系統番号や装置番号を保存する領域で、停留所番号を保存している可能性を見いだしました。
具体的には次の通りです。

+3〜+6 (4バイト): 事業者、不明な情報
+7〜+8 (3バイト): 系統番号
+9〜+B (2バイト): 停留所番号

系統+連番というフォーマットは、他に北陸鉄道の「ICa」に類例が見られます。
1報告あたりに必要な調査時間が膨大なため、大量に報告が届くと大変なことになってしまう形式ですが、どうやらそのような形式で保存されているように考えられます。

きっかけ


いわさきグループは自社公式サイトで時刻表も系統ごとの停留所も一切公開しておりませんため、調査がかなり難航していました。

そんな中で、たまたま検索でヒットした「32-1番線」の時刻表で全ての停留所の一覧が確認でき、停留所番号を最後の2バイトとした時に、金生町を0番とすると報告された情報と一致することが確認できました。

同じ系統で表示されていても、カードに記録される系統番号が異なることがあり、これは出発する停留所や経由地、方向(上下線の差違)などの違いによって変化するものと予想されます。

また過去の報告では、系統番号は一致しながら停留所番号が異なる例がいくつか検出されております。しかしこれにより、報告のミスなどの検出可能性も含め、順次研究を進めていける段階へと移行したという手応えを感じました。


今後の対応について


まだ上記の解析結果で確定したわけではありませんが、確度は高いと予想されるため、今後この方式に順次変更をしていきます。
また、これまで報告され登録された分については、見るべき情報が変わってきますので一旦データベースから抹消することになり、新しい報告と過去の報告を順次データベースに追加することとなります。

再調査と登録はかなり時間を要する作業となりますので、今後しばらくは従来表示されていた停留所名が表示できないことになると思います。
しかし今後は、従来よりも正確に表示することが出来るようになると予想をしております。


←2回目 ◆ 4回目?→

2017/04/11(火)14:31 |Comments(0) |Trackback(0)

地域振興 | ソフトウェア開発 | コンピュータ | [編集]

▲ページトップ

交通系ICカードによる物販についての説明

はじめに


ICカードこれひとつ」による物販対応ですが、交通系ICカードによる物販は店舗名の表示に対応しています。
しかしこれは技術的難易度が高く、かなり実験的な色合い濃く、そのため特に告知することなくひっそりと開始した経緯があります。
番号はかなり重複しているため、表示も重複せざるを得ませんし、このため自分が見たことも聞いたこともない店舗名が画面に表示されてしまうという難点もあります。
当該の店が未登録であれば、見たこともない店「しか」表示されないという状況となります。


これまでの対策


まだユーザーが少ない頃は、よく分かっておられる方々が特に利用されていたこともあり、多少のトラブルはありましたが重複前提でご利用戴き、報告もいただけました。
しかし現状のようにユーザーが増えてきますと、理解しないまま利用されトラブルを起こされる方が少なからず現われるようになりました。

これまでも、番号が重複していることを告知したり、標準で表示OFFとしてONするためには説明文を読ませるようにしたりしました。この目的のため、全てスクロールしないとボタンを押せないようにする処理を作成したりもしました。ただ結論としては、殆ど効果がありませんでした。

ユーザー個人が勘違いするだけであれば、それは使い方が悪いのですから仕方なしで済ませることができます。しかし残念ながらこの機能の場合、第三者に迷惑が及ぶため、弊社としては対応に苦慮をしています。

これまでも、未知の店が表示されたということでカードの盗用などを疑い警察に通報した方がおられ警察沙汰になったり、鉄道会社や店舗にクレームを入れる方がおられたりしています。

このような状況が続きますと、「ICカードこれひとつ」というアプリそのものが「公害」となってしまうため、「交通系ICカードの物販店舗表示機能」そのものを廃止することも検討せざるを得なくなります。


最近の暫定的な対策


説明を全部読まなければONできないダイアログを、全く読まないままスクロールだけしてONする方がおられる以上は、技術だけでは対処不能となります。ですので、これまで重複している場合のみ表示していた注意文を、重複していない場合にも表示するようにしました。

これまでは、全てに表示しなくても済むよう、事前説明という手段で何とかしようと試みてきたのですが、残念ながらそれは無理だったのです。

今のところ、ユーザーに確実に説明を読ませる方法は発明されておりません。毎回ダイアログを表示するという方法も提案されていましたが、毎回表示したとしても読まない人は読まないという実績が既にありますので、結論としては最終手段という事になりました。現時点で、「画面に常時表示する」以外に効果が期待できる方法はありません。

表示が邪魔、としてGoogle Playにもレビューが寄せられておりますが、機能廃止よりはマシであると思って我慢していただければ幸いです。
どうしても許容できないというのであれば、第三者に迷惑を及ぼさないためには、今すぐできる方法としては機能廃止以外に選択肢がないのです。


今後の方針?


機能を廃止しても喜ぶ人は誰もおりませんし、弊社としてもそれだけは避けたいと考えています。
そこで当面は、全ての物販に説明を表示する方針で行きたいと考えています。
今後どうするかはまだ決まっておりませんが、機能を安全に維持し続ける方法として、弊社内では次のような案が出されていることをお伝えをして締めくくりとさせて戴きます。

・交通系ICカードの物販は将来的に有料機能とし利用者を限定するという案
・利用者は限定しない代わり、過剰な説明文(今回不評なもの)は将来的に有償オプションでOFFできるようにする案

2017/03/13(月)15:00 |Comments(0) |Trackback(0)

製造開発 | ソフトウェア開発 | コンピュータ | [編集]

▲ページトップ

カレンダー

04 | 2017/05 | 06
- 1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31 - - -

プロフィール

miraicorp

Author:miraicorp
未来情報産業(株) 社長

主として「ICカードこれひとつ」や「文字、文字コード」処理、時々C++などについて記述しています。

twitterツイッター

管理用

検索フォーム

お知らせ

コメント等お気軽にどうぞ。

気に入ったら拍手して頂けると、今後の記事を書く際の参考や励みになります。

■お仕事を募集しております
ソフトウェア製造の仕事や、原稿執筆の仕事などを随時受け付けております。
お気軽にご相談下さい

■初めての方へ
こまごまと更新しているため、他にも関連する記事があるかもしれません。
「月別アーカイブ」「検索フォーム」「カテゴリ」などをお試し下さい。
トップページはこちら

最新記事

最新コメント

最新トラックバック

月別アーカイブ

カテゴリ

広告枠

メール

メールはこちら

リンク

このブログをリンクに追加する

RSSリンクの表示

QRコード

QR