いわさきICカードの停留所番号について(5回目) 最終手段

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

最終手段


いわさきICカードですが、これまで全9バイト(72ビット)のうち、途中や下位の部分比較をすることで、バス停番号を見いだす調査と研究をしてきました。

下位7バイト(56ビット)の比較で、おおむねバス停番号が確定できそうではありましたが、実際にはこれでもだめで、重複が生じます。

そこで今回、諦めて、できるだけ避けていた全桁比較を実施することとしました。
具体的には従来の実装下位7バイトに、さらにもう一つ情報を加え、上位2バイトをあわせて全9バイトを比較する形としたものです。

これまで下位7バイト用として登録された情報については、かなり大変でしたが全て再チェックし、DBに不足する2バイト分の情報を書き足す作業が完了しました。ですので公開中バージョンと同等以上のデータが再登録されています。
後にも書きますが乗車と後者は番号が違うので、これによっていわさきのDBデータ量は当社比2倍に増大しました。


重複するかどうかはまだ不明


同じ車体の同じ系統の同じ停留所なら常に同じ9バイト(72ビット)もの情報をカードに書くのかどうか、はまだ不明です。今後明らかになることでしょう。
そして、この9バイト(72ビット)もある番号が本当に一意なのかどうかも謎です。これも今後明らかになることでしょう。


乗車と後者は原則として番号が違う


理由は不明ですが、乗車と後者では上位2バイトの内容が異なります。
登録については報告があったものに限るので、同じバスの同じ系統の逆方向で同じバス停に乗ったとしても、乗車と後者は別の登録になるので表示はできなくなります。


今後起こること


どうやら上位2バイトから4バイト程度で車体あるいはカード端末を一意に表わし、その中で他の番号と全く調整を取っていない附番方式で系統、そして停留所番号を振っているのではないかと予想されます。

全情報比較となったことから、従来はたまたま一致して正常表示されていた停留所や営業所も、今後はたまたまでは表示されなくなります。完全一致が表示の条件となるためです。

このため特に営業所や、鴨池・垂水フェリーでは従来表示できていたものが表示できなくなる現象が頻発すると予想されます。
ただこれも、営業所の窓口番号、フェリーでも改札機の番号、といったものが番号で区別可能になる可能性があります。
こういった報告の際には、端末装置が一意に特定できる情報をお寄せいただければ幸いです。



←4回目 ◆ 6回目?→

2017/09/22(金)18:44 |Comments(0) |Trackback(0)

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

▲ページトップ

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

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

バス停番号


いわさきグループは、Rapicaと共通で、全部で9バイト(72ビット)の情報領域を持っているのですが、ここに書き込む内容が未だによく分かっていません。

全ての情報のうち先頭4ビットは事業者番号であり、いわさきグループは現在は4で固定です(かつてのいわさきバスネットワーク(林田バス系統)は5があった)。

乗降で一致するのは、バイト単位なら下位7バイト(56ビット)、ビット単位なら更に上7ビットが共通するので下位63ビットは一致しているとみなすことができ、うち下位4バイト程度は停留所番号であろうと考えられます。

これだけの長さがあれば、バス停はおろか、運行しているバスの車体をも一意に特定できるのではないかと、一応は考えています。


それでも生ずる番号重複


ところが、今年の5月9日に65-2番線として報告された番号と下位7バイトが完全に重複する番号が今日、13番線として報告されました。


0 1 2 3 4 5 6 7 8 9 A B C D E F
xx xx xx|45 12|06 A0 01 B0 DC 00 12|41|xx xx xx ◆ 65-2番線 降
xx xx xx|4B 92|06 A0 01 B0 DC 00 00|30|xx xx xx ◆ 65-2番線 乗



0 1 2 3 4 5 6 7 8 9 A B C D E F
xx xx xx|40 92|06 A0 01 B0 DC 00 12|41|xx xx xx ◆ 13番線 降
xx xx xx|4E 12|06 A0 01 B0 DC 00 00|30|xx xx xx ◆ 13番線 乗


これを見ると、+5〜+Bの7バイト(56ビット)の停留所番号は2件で完全に一致していますし、更に上に7ビット追加して下位63ビットにしてみても一致してしまいます。
+4の最上位ビットを含めた、下位64ビットにしてようやく不一致にすることができます。
乗車と降車で不一致となる上位バイト(+3〜+4)は謎が多いのですが、いわさきで、停留所を完全に特定することは本当に可能なのでしょうか。


全桁使えば一意になるのだろうか?


先頭4ビットを除いた全8.5バイト(68ビット)を使えば一意にできる可能性はあります。

ただ、同じ車両の同じ系統に乗車したとして、上位ビットは常に定まった値を書くのかは、現時点では情報がなく不明です。
これについては報告に期待をするしかありません。

そして、同じ車両の同じ系統なら常に同じ番号を書く=停留所が完全に特定できる、のだとしても、実際には次ような問題が生じます

①乗降で上位バイトが違うため、ソートしたときに乗車と降車で番号が離れてしまう
②乗車と降車で番号が変わってしまう
③系統のバス停一覧をみても番号全体の予測が不可のため、事前登録ができない
④Javaのlongは63ビット長なので、整数の変数に番号が収まらない。複数に分ける必要がある
⑤SQLiteの整数も63ビット長なので、DBに数値を収められない。複数に分ける必要がある


今後の方針


内部的な仕様変更が必要になるため、すぐの対応ができないことから、当分の間は画面には停留所が重複するように表示させるしかないようです。
現在はRapicaといわさきはDBを共通化させており、今後もその方針ですが、影響範囲が大きくなるため慎重に仕様変更をしていかなければなりません。

そしていずれ全桁を使うようにするかもしれません。
その場合、いまは予測対応で乗降の途中の停留所も表示するような対応ができることもありましたが、それは今後一切不可になるのかもしれません。


いわさきの報告で今後して欲しいこと


当分は、下位7バイトの一致で判定します。
そこで表示が正常であった場合も、その旨を報告いただきたいのです。比較していない上位バイトを確認し、全体として一致するのかどうかを判断できます。
またお時間に余裕があれば、車体を特定するため、車のナンバープレートの番号を合わせて報告願います。

完全に予測ではありますが、この長大な番号は、車体→系統→停留所という構成で番号を振っているのではないかと予想をしており、系統だけでなく車体をも特定できる可能性が秘められています。



←3回目 ◆ 5回目→

2017/09/19(火)23:03 |Comments(0) |Trackback(0)

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

▲ページトップ

新幹線の駅番号について

新幹線の駅番号


駅には番号が付いています。新幹線も同様です。
新幹線にICカードで乗ることができるようになった現在、新幹線の駅番号も確認することが可能な時代となりました。
(スマートフォンなどのように本体内蔵のFeliCaチップも、ここではICカードと呼ぶことにしておきます)
現在、ICカードやスマホなど何らかの形でFeliCaで乗車できる新幹線は次の通り。

JR北海道 北海道新幹線
JR東日本 東北新幹線
JR東日本 上越新幹線
JR東日本 北陸新幹線
JR東海 東海道新幹線
JR西日本 北陸新幹線
JR西日本 山陽新幹線


番号は複数ある


新幹線と在来線の乗り換え駅の場合、新幹線改札機は新幹線としての駅番号と、在来線としての駅番号をカードに書こうとします。

弊社では「モバイルSuica特急券」は未確認でどのように動作しているのか全く分かりませんが、EX-ICは調査しておりますので、その前提で説明を致します。

新幹線のりかえ改札に、ICOCA等とEX-ICを重ねてタッチすると、新幹線に乗る場合は、ICOCA等には「在来線の駅番号で出場」が書かれ、EX-ICには「新幹線の駅番号で入場」が書かれます。
新幹線から降り在来線への乗り換え改札を通る場合は、この逆になります。
新幹線から直接外に出る改札で出場すれば、EX-ICのみに「新幹線の駅番号で出場」が書かれるわけです。このように新幹線駅には、とりあえず常用される駅番号が二つあると考えて良いでしょう。


北陸新幹線は何やら独特な雰囲気


北陸新幹線の駅番号の振り方は独特で、こちらも駅番号が二つ存在します。新幹線としての駅番号のほかに、在来線としての駅番号があります。

モバイルSuicaで新幹線に乗る場合、モバイルSuica内の「モバイルSuica特急券」情報欄に特急券情報が書き込まれます。モバイルSuica特急券で使用される駅番号は、新幹線としての駅番号です。

ところが、モバイルSuicaの「履歴」情報と「改札」情報に記録される番号は、どうやら乗る時も降りる時も、新幹線としての駅番号は使われておらず(弊社では未確認、報告から推定)、「在来線」として用意されたと思われる特異な番号が使われています。
特異な番号が作られたのは、北陸新幹線によって旧来の路線がJRとしては廃止され第三セクターになってしまったことも関係していると思われます。


モバイルSuica特急券の動き


モバイルSuica特急券を、TOICA/ICOCAとEX-ICに対応付けるとするならば、モバイルSuica部分(履歴、改札など)はTOICA/ICOCAに対応し、モバイルSuica特急券部分はEX-ICに対応するのでしょう。

EX-ICの場合でもTOICA/ICOCA等は在来線としての駅番号を書かないと他の駅の自動改札機で処理できなくなりますので、在来線としての駅番号が使われています。
そこから考えると、モバイルSuica特急券の場合も同様であり、新幹線とそれ以外での区別用として、新幹線としての駅番号と別に、在来線としての新幹線駅番号(よく分からない表現)が必要だったのかもしれません。


なお、駅番号は路線ごとに附番されますから、複数の路線との乗り換え駅ではその路線数ぶんの駅番号が存在しています。
つまり北陸新幹線の在来線等との乗り換え駅の場合は、この在来線としての新幹線駅番号のほかに、在来線の各路線ごとの駅番号がありこちらも使われているものと思います。

例えば長野駅などは在来線がIC未対応なため不明ですが、富山駅の場合は、あいの風とやま鉄道の富山駅としての番号が併用されていることを確認しています。あいの風とやま鉄道の駅番号は旧国鉄と同じ番号帯に新たに作られていますが、元の北陸本線としての番号とは異なっているようです。

2017/08/09(水)19:17 |Comments(0) |Trackback(0)

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

▲ページトップ

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

(これは古い解析結果です。調査により新しい結果が出ていますので、そちらは追って書きたいと思います)

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

本稿は、現時点で分かっていること、分かりかけていることをメモしています。
後から誤りと分かったものは訂正したり、新しく記事を書いたり致します。
このように、根本的な誤りを含む可能性をお含み置きいただきお読みください。

階層構造


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

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


格納される情報


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


情報量


ビット構成の全てを解読したわけではないので、以下は全て予想となりますが、今のところ、「端末」のIDは20ビット、「アクワイアラー」は4ビットあると予想しており、うちカードには端末IDの下位16ビットが記録されると見込んでいます。

(H29/7/3追記)
更なる研究で、端末に与えられるIDは各イシュアーごとに36ビット程度があると分かってきましたが、カードに書き込む「端末」のIDは、20ビット中下位16ビットではなく、実際に16ビットで間違いはなさそうと分かってきました。
当初は端末20ビット+アクワイアラー4ビットと予想しましたが、端末20ビットと予想したうちの上位4ビットが、どうやらアクワイアラー4ビットだったようです。
以前アクワイアラーと予想したビット情報(上位情報)については後述します。
(H29/7/3追記おわり)

ですので、この予想では、アクワイアラー1社しかないとしても最大16が重複してしまい、もしアクワイアラー最大16がひしめきあう状況になれば、最大256の重複がありうることが分かりました。
しかも、manacaとPASMOは一つのカードに複数のイシュアーが存在しますので、カード種類という括りであれば、PASMOでは数千件規模の重複が将来的に予想されます。

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


下位情報の補足


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


上位情報の補足


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

また、各イシュアーごとに、アクワイアラー&種類&端末番号までの範囲を最大10倍に拡張できる余裕が持たれているようです(10進数で1桁分の余裕)
ということは、PASMOは本気出せば1万以上の重複が生じうる可能性があります

(H29/7/3追記)
更なる研究で、上位ビットの使途はかなり未知であることが分かってきました。
可能性は二通りで、
①情報は16ビット
②情報は10進数1桁と、さらに12ビット
のいずれかです。
当初は②を予想しましたが、①の可能性も高そうです。

上位情報も何らかの未知の情報を含むのですが、今のところ詳細は分かっていません。
これまで収集した情報では、上位情報のうち2ビット程度は変動しており、何らかの情報を表わしているものと予想しています。
最大16ビットの上位情報がありますので、PASMOは本気出せば1億件以上の重複を生じうる可能性があることになるのですが、使途が未知ですので、これはあくまでも可能性となります。
(H29/7/3追記おわり)


結論


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

交通系は無理と判断して諦める方法もありますが、それはそれで面白くありませんし、現に交通系物販の表示はかなり需要があり膨大な量の報告が届いていますから、今のところは重複があって対応を続ける予定です。
ただ、現在のアプリは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)

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

▲ページトップ

カレンダー

08 | 2017/09 | 10
- - - - - 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

プロフィール

miraicorp

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

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

twitterツイッター

管理用

検索フォーム

お知らせ

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

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

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

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

最新記事

最新コメント

最新トラックバック

月別アーカイブ

カテゴリ

広告枠

メール

メールはこちら

リンク

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

RSSリンクの表示

QRコード

QR