ICカードこれひとつ これまでの流れ

ICカードこれひとつ」がたどってきた波乱の歴史を、中の人の気持ちとともに忘れないうちにメモしておきます。

前史
H23頃まで
中の人がICカードに興味をもちはじめる
H23頃まで
パソリを入手する
わざわざビュー・スイカを取り寄せ、パソリでチャージできる利便性から未来を感じる
H25/06/08
福岡に出張し「SUGOCA」「nimoca」「はやかけん」を入手 (この当時はアプリを作ることになるとは予想もしていない)
H26
中の人が暇だったのでFeliCaのダンプツールで遊び始める
H26
手元の「らんでんカード」の中身が気になり始める
H26
嵐電に電話問い合わせをするも酷く扱われ凹む。民間鉄道会社は協力をしてくれないことを知る。仕方がないので、自力にて駅番号を揃えることとした
H26/03/04
Windows用「らんでんカード ビューアー」のテスト版が完成する (まだ対応駅は少ない)
H26/03/14
窓の杜に紹介してもらい、気をよくする
H26/03/15
Windows用「らんでんカード ビューアー」の正式版が完成する (ようやく嵐電全駅踏破)
H26/08/16
Windows用「CI-CA カードビューアー」が完成する
H26/08
さらに他のカードも気になり始める
H26/09/29
Windows用「hanica カードビューアー」と「itappy カードビューアー」が完成する
H26/10
ノートPCにパソリ付けて持ち歩くのはとても大変なので、そろそろAndroid用アプリも作りたくなる
C++で作りたいので、clang/LLVMのAndroid用を待っていたけど出てくる気配はゼロ
しかたなくJava
H26/10
Android用のFeliCaダンプツールを開発、無事にノートPCはお蔵入りになり調査旅行の荷物が軽量化された
H26/10/23
Android用「らんでんカード ビューアー」の初版が完成する
H26/10/23
Android用「CI-CA カードビューアー」の初版が完成する
H26/10/25
Android用「hanica カードビューアー」の初版が完成する
H26/10/29
Android用「itappy カードビューアー」の初版が完成する
H26/11/02
Android用「近江鉄道バスICカード ビューアー」の初版が完成する
H26/11/05
Android用「NicoPa カードビューアー」の初版が完成する
H26/11/20
Android用「ナイスパス カードビューアー」の初版が完成する
H26/11/23
Android用「えこまいか・パスカ カードビューアー」の初版が完成する
H26/11
この頃までに、全てのカードを一つのアプリで処理する構想を練り始める
H26/12/05
開発機としてNexus 7を入手
H26/12/20
Android用「IruCa カードビューアー」の初版が完成する
H26/12/22
Android用「ICい〜カード・ですか ビューアー」の初版が完成する
H26/12/22
Android用「NORUCA カードビューアー」の初版が完成する
H26/12/26
Android用「ayuca カードビューアー」の初版が完成する
ICカードこれひとつ
H27/01
全国対応するため、ICOCAほかSuica互換カードや改札の研究を本格化する。自動改札機にはそれぞれ固有番号があることに気づき情報収集を始める
H27/02/28
「うめぐるバス」調査乗車。この当時はコミュニティバスというものを知らなかった。中の人が初めて乗車したコミュニティバスとなる
H27/04/03
Android用「ICカードこれひとつ」の初版が遂に完成する
H27/04/06
バージョン0.05で「くまモンのIC CARD」に新対応
H27/04/30
バージョン0.25で「RapiCa」「いわさきICカード」「DoCARD」に新対応
H27/05/03
調査旅行にて関東で「Suica」「PASMO」を入手
H27/05/05
調査旅行にて名古屋で「TOICA」「manaca」を入手
H27/05/12
バージョン0.33で「ICa」「LuLuCa」「PASPY」に新対応
H27/05/19
バージョン0.38で「odeca」に新対応、また電子マネー提携カードへの対応も強化しはじめる
H27/05/21
バージョン0.39で「りゅーと」「KURURU」「長崎スマートカード」に新対応
H27/05/22
バージョン0.40で「hareca」の認識に対応、但し読み取ることができないカードがあるという問題が生じ始める
H27/06/10
バージョン0.59で「Kitaca」に正式対応開始 (全国対応カード網羅)
H27/06/23
伊丹市にitappyの停留所番号についてネットで情報開示請求をする
H27/06/24
伊丹市交通局の方から連絡を受ける。とても親切にしてもらうことができ、感激する (自治体バスに良いイメージを持つようになる)
H27/06/29
鹿児島市交通局にRapicaの停留所番号についてネットから情報開示請求をする
H27/07/06
鹿児島市交通局より連絡を戴き、翌日にバス停番号提供を受けられる
H27/07/08
バージョン0.79で「icsca」に新対応
H27/07/16
バージョン0.86で「OKICA」に新対応
H27/08/04
バージョン0.99リリース。次のバージョン番号に非常に困る
H27/08/07
バージョン0.100リリース。何とかなった
H27/08/19
バージョン0.107で、おサイフケータイ等複数機能が混在するものを読み取った時の動作への対応を始める
H27/08/22
バージョン0.109で、おサイフケータイ等複数機能が混在するものを読み取った時の動作に正式対応開始、以降改良を続ける
H27/09/23
バージョン0.135で「北見バスICバスカード」に新対応
H27/09/24
高槻市役所へ出張し、高槻市営バス停留所番号の資料請求をする。親切にしてもらうことができ、感激する
H27/09
この頃までに、調査旅行中にバス停名が読めないバス停で降りる必要が生じ困る (読み方が分からないので表示を食い入るように見て難を逃れる)
H27/09/28
バス停名と駅名のDBに「ふりがな」と、ついでにローマ字の情報を加え始める。必要は発明の母
H27/10/05
バージョン0.144で「ICOUSA」に暫定対応開始
H27/10/07
大阪狭山市循環バス」乗車のため出張。コミュニティバスは地味なものが多い中、日野ポンチョに市のゆるキャラ「さやりん」が描かれるポップな車体は印象深い。コミュニティバス存続のための参考になるのではないか
H27/10/10
高槻市より情報提供を受けられる
H27/10/11
箕面オレンジゆずるバス」存続危機と言われた日祝ダイヤに乗車するため出張。最初から最後まで中の人1人しか乗客がおらず、関係者2名と運転手で中には4人しか人間がいない。事態の深刻さを肌身で痛感した。コミュニティバスを一層支援していく決意
H27/10/14
バージョン0.148で、駅名の駅ナンバリング表示に対応開始
H27/10
この頃までに、様々なバス停が報告されてくるも、そもそもそのバス停はどこにあるのか、実在するのか、停留所名は正確なのか、疑問に思い始める
H27/10/15
ストリートビューで位置を正確に確認するようにし、判明した位置情報をバス停名と駅名のDBに加え始める
ICカードに書き込まれる番号、鉄道駅の番号以外は見事に全て重複することが確認された。バス停留所番号、車体番号もグループ内で重複しており、駅改札口番号も同駅内ですら重複を確認。仕方なく、DBの仕様を変更し対応を進め、アプリやDBの構造はどんどん複雑になっていく
H27/10/17
北九州市交通局より「ひまわりバスカード」のバス停番号提供を受けられる
H27/11/10
バージョン0.162で名大生協「Meica」に新対応 (熱望にお応えし、学生証や大学生協電子マネーへの対応を開始する)
H27/12頃
密かに物販表示に対応開始する
H28/01/04
EX-ICの調査旅行にて、東海道新幹線の全EX-IC駅番号が確定したことで「ある事実」が浮かび上がる(その内容についてはJR東海が公表していないのでこちらでは明言致しません)。JR東海はツンデレであることも判明
H28/01/07
バージョン0.188でFeliCaポケットの概略情報表示に対応
H28/01/19
バージョン0.193でかざすフォルダに対応
H28/01/27
EX-ICで、新大阪から博多までの全EX-IC駅番号が確定。全て連番で空き番号はなく、JR西日本は新駅を一切作る予定がないことが判明
H28/02
「読み込みが遅い」という理由で★1が付けられ、社内が悲しみに包まれる
H28/02/14
バージョン0.202で、交通系IC専用高速モードを搭載した。遅いというクレームはこれにて一掃されると期待
H28/03/11
サイバネ規格、唯一重複していないと思われた駅番号までついに重複してしまうことが発覚。これにて重複しない番号は遂に一つもなくなった
H28/03/16
この日、叡山電鉄がPiTaPaに対応したので、朝から全駅網羅の調査旅行を実施
バージョン0.212で「Asaca」「DoCARD」に正式対応、叡山電鉄も全駅対応
H28/05/16
バージョン0.232で、カード読み込み中にProgressDialog(クルクル回転)を表示するようにし、読み込みが遅くても画面が動いているように見せる改良
H28/05/23
「更新多すぎ」という理由で★1が付けられ、社内が悲しみに包まれる
H28/07/18
交通系IC専用高速モードでnanacoが読めないとのクレームが入り、社内が悲しみに包まれる。モード切り替え時にわざわざダイアログを表示しても読まれないことを知る
H28/07/20
バージョン0.250で、交通系IC専用高速モード時は、カード名の代わりにモード中であることを表示するようにしたり、切り替え時に表示される画面を改良したりした
H28/08/15
ICOCAに新タイプが登場したことが発覚する
H28/09/05
10カードの物販で、偶然番号が重複していた他店舗名が表示されたとしてユーザーが警察に相談するという事件が発生、通報を受けて社内に戦慄走る
H28/09/06
バージョン0.258緊急リリース、説明書を全く読まないライトユーザーが増えてきたことを重く受け止め、10カードの物販は標準で表示しないようにした。機能ONにする時も説明を全て読まないとONに出来ないようにした
H28/09/08
10カードの物販で、偶然番号が重複していた他店舗名が表示されたとしてユーザーがJR九州にクレームを入れるという事件が発生、通報を受けて社内に再び戦慄走る。ユーザーには最新版を使うよう案内をする
H28/09/11
EULA(ソフトウェア使用許諾書)は、最後まで読まないと「同意する」のボタンを押せないように処理を改良した上で、「事業者に問い合わないこと」を条文に追記した
H28/09/26
当初は座標からGoogleMapのAPIを引いて住所を取る予定だったものの、上手く行きそうにないため、DBに住所情報も追加し始める
H28/09/26
バージョン0.263で「なっち」に新対応
H28/10/10
「履歴機能がない」という理由で★1が付けられ、社内が悲しみに包まれる。可能な限り開発を急ぐ決意
H28/10/13
バージョン0.269で「せたまる」に新対応
H28/10/20
バージョン0.270で、メモリー使用量を削減する大規模な内部変更を開始した。苦戦したものの、しばらく後には無事に成功。
H28/10/23
バージョン0.272でモバイルSuica特急券の表示に対応するも、Google Playの不具合で配信されず困る
H28/10/30
「交通系ICカードで、履歴に時刻が表示されない、改善を求める」というクレームが入り悲しみを覚える。カードに記録されていないことをお知らせしつつ、最初に起動した時にはチュートリアル画面を表示する必要があるなと思うに至るも、開発工数を考えると気が遠くなる(今は諦める)
H28/10/31
「西鉄バス(nimoca圏)で利用区間が表示されない、改善を求める」というクレームが入り、更なる悲しみを覚える。nimoca圏でバス停が記録されないのは仕様であることをお知らせしつつ、アプリからマニュアルへのアクセスをより容易にするような改善を進めることにした
「くまモンのICカードを利用した際に未登録のバス停が多い、改善を求める」というクレームが入り、深い悲しみを覚える。ユーザーからの報告による登録制である旨お知らせをしつつ、画面にしつこくダイアログを表示しても読まない人は絶対に読まないのだということを理解する。今後はより一層しつこくダイアログを出す決意を固める
H28/11/15
バージョン0.278で「カード再表示機能」を遂に搭載。好評を博し、気をよくする
H28/11
この頃までに、店舗名から業種が全く想像できないものが多すぎることに頭を悩ませ、業種表示が必要と考える
H28/11/16
総務省が日本標準産業分類というものを作っていることをようやく発見する
H28/11/24
バージョン0.279で店舗の産業分類の表示に対応
↓拍手する

2016/11/25(金)22:24 |Comments(0) |Trackback(0)

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

▲ページトップ

ICカードこれひとつの履歴機能の計画と展望

履歴機能


ICカードこれひとつ」は、おかげさまで日本中の交通系ICカードで、読めるものは全て読めますし、駅だけでなくバス停まで表示できるようになっています。

このように、表示に限っては非常に高性能となっていますが、まだ実装されていない、どう考えても欲しい機能があります。
そう、履歴機能です。

いちいちカードを読ませるのも面倒ですので、読んだ分はスマホの中に保持しておいてくれても良いではないですか。そうですね。その通りです。
じゃあなぜそんな機能がいま無いのかというと簡単で、実装したい機能がまるで夢のように多機能なため、いまだ夢の機能になっているのです。

どんな夢か


Suica他10カードに限れば、履歴は20件、改札情報は3件あります。
改札情報は難しいですが、履歴については各履歴ごとにシリアル番号が付いているため、前回まで読んだ分と、今回新規に読んだ分と比較し、差分を求めてそれを新規に蓄積する、ということができます。
こうして情報を蓄積する「蓄積型履歴表示」はいつか実現したい機能の一つであります。


蓄積型履歴表示の難易度


蓄積型履歴表示は魅力ですが、とても難しい機能です。
久々にカードを読ませた等により間が開いた場合にどうするか、という問題ふくめ、技術的な課題があります。
また、「ICカードこれひとつ」は対応カードが多く、カードごとの仕様差も大きいという多機能ゆえの悩みもあります。
履歴に10カードのようにシリアル番号が付いていないカードも少なくなく、そういったカードでは前回との差分を正確に求めることが難しくなります。
蓄積型履歴表示に対応できるカードとできないカードが生じることになり、このため処理が煩雑になるだろうことは疑う余地がありません。


まずはシンプルな実装から


機能が全くないよりは、シンプルでもあった方が良いのではないか。

まずは需要を満たすことが必要であるということから出来るところから始め、シンプルな実装から実現して、徐々に多機能化していく方針へと軌道修正をすることとしました。
機能公開後も、開発の都合によりそれまでの履歴をご破算とするような仕様変更が発生することもありえますが、その辺は許容してもらいつつ、徐々に開発を進めていきたいと考えています。

考えているシンプルな実装の基本的なコンセプトは次の通り。

①カードを読み取り、エラーがなく、高速モードでもない場合はDBに保存する
②その時、IDmごとに分類し、同じカードは同じカードでまとめる
③保持する履歴件数の上限は、IDmごとにxx件、古いものから自動的に消える、のような仕様が適当と思われる
④また、保持するIDm件数も、xx件、古いものから自動的に消える、のような仕様が適当と思われる
⑤画面遷移は「IDmベースのカード一覧画面」→「選んだカードの履歴一覧画面」→「選んだ履歴を再表示」というスタイル
⑥IDmごとに、カードに名前を付けられるようにする
⑦次回以降、表示したときに履歴画面以外でも「Suica」等でなく付けた名前を表示するかどうかは要検討


ここからどう蓄積型に拡張するか


蓄積型を実現するためには、それ相応のデータベースを用意する必要があるため、単純な履歴機能とは別に新規作成ということになると思われます。
蓄積型表示ができないカードがあるので、蓄積型表示に対応して以降も従来型の単純な履歴機能は保持されることになるでしょう。


計画


データの登録作業で時間が吸い取られており、新機能のプログラミングができない残念な状況が続いていますが、年内にはある程度のメドをつけ、今年度中には一応の機能実装を終えたうえで、βバージョンである現在のバージョン0から「バージョン1」へと進化させたい考えでいます。
なお、履歴については有料機能のうちの一つとすることを予定しており、有料オプションの価格は未定ですが、あまり高くない価格を予定しています。
このためにはアプリ内課金の機能も搭載する必要があるため、その分の工数が必要になるのですが、これについては未知な点が多く、まだ何とも言えません。
いずれにせよ、この機能の実装がバージョン1になる前提として計画されておりますので、ご期待下さい。

2016/10/10(月)08:30 |Comments(0) |Trackback(0)

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

▲ページトップ

ICカードこれひとつ 物販対応の現状とお願い

「ICカードこれひとつ」の物販対応は、受けた報告から店名や所在地、GPS座標、またレジの台数などを全て確認し、実在性や正確性を確認した上で初めて登録をしております。

しかし交通の報告と比して、物販は調査が必要な項目が桁違いに多いのに対して、いただける情報量が当初の想定よりも圧倒的に少なく(※1)、このため登録に必要な情報を集めるために膨大な時間を要しています。
元々少ない開発の人的リソースが物販調査に割かれることから、アプリ開発に大きな圧迫となっております。

(※1)これまでの実績では、タクシーでの物販扱い精算での報告で一言「タクシー」だけというものがありました。


このアプリはあくまでも交通系アプリで、物販対応はご要望にお応えし、可能性に挑戦している研究的サービスの扱いとなっておりますが、このままの状況が続く場合、物販店名表示サービスは提供継続が難しくなります。
末永くサービスを提供していけるよう、可能な限り必要な情報をご記載いただき、弊社内作業の軽量化にご協力をいただけますようお願いを致します。


参考までに、次の点は調査に難航しているため、お時間に余裕があれば調査しての報告にご協力いただければ幸いです。

①駅構内、空港内、ショッピングモール内等にある店の位置の確認
GoogleMapにリンクするために緯度経度の調査を実施していますが、この調査にかなり膨大な時間が掛かっています。
GoogleMapに店名を入れてすぐに出てくるような店なら良いのですが、駅構内、空港内、ショッピングモール内などのテナントは出てこないことが多いため、報告の際に調査しておいていただけますと、かなり対応が楽になります。
なお、物販情報に限っては、曖昧な座標情報はかえって作業に支障を来すため、詳細位置不明の場合は無理に座標を記載いただかなくても構いません。

②店名・支店名
報告いただいた店名・支店名で検索をして実在性や正確性を確認しますが、時々店名が実在しないことがあります。
また、店の英名も、調査に難航する項目ですので、分かる範囲で記載いただければ幸いです。(既に英名登録済みの店は記載不要です)

③レジの台数
店によってはレジの台数を数えるのが大変なこともあるかと思いますが、これが記載されていると、その後の報告でもかなり作業が軽量化されることがあります。
アプリにも記載がありますように、x/y のように分数形式で記載いただけると、作業はコピペだけとなるのでかなり楽になります。

④契約カード種類は正確に
分からない場合と、セブンイレブンの場合は、原則として「不明」をお選び下さい。
SuicaとPASMO、TOICAとmanaca、KitacaとSAPICAといったJR系と私鉄系は、特に疑問に思うような報告が多い代表例となっております。


注文の多い料理店よろしく注文が多くなっておりますが、フリーソフトとして提供していくためには人件費を削る必要があります。
その分は利用者の皆様にご協力をいただくしかありません。
どうかご理解のほど、よろしくお願い申し上げます。

2016/10/06(木)08:30 |Comments(0) |Trackback(0)

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

▲ページトップ

改札口の仕様を表現する

はじめに


鉄道の改札口というのは予想以上に多種多様で、当初の設計では表現しきれいない繊細な特徴を有するものも発見されています。
ただ種類も概ね出そろってきていると判断されるため、この辺りを再設計することにしました。

とりあえず現状より機械処理しやすく、そこそこ入力しやすいようにASCIIの範囲内で綺麗に表現する方法、を考えています。

たたき台と備忘録をかねて、検討中の内容をメモ代わりに記載したものを公開します。


方針


情報としては、入場方向・出場方向・どちらの方向にも共通したもの、の3つに分けることが可能です。
また予期せぬ画期的な改札が登場することを考慮し拡張性や余裕を持たせることも必要ですが、必要以上に拡張性を持っていても使われることはないし、DBのサイズが増えて良いことがないので、必要最小限としておきましょう。

共通事項


入場にも出場にも共通するのは、次の事項
・幅広
・簡易改札
・有人改札

有人改札でかつ簡易改札というのは存在しないので、この二つは排他とします。
また簡易改札も、1本だけで建っている(時に入場と出場で背中合わせになっている)簡易改札と、扉こそないもののあたかも普通の自動改札であるかのように装うものとがあることが分かってきました。
これらの区別需要があるため、これは今後はきちんと区別して記録することにしましょう。

必要な情報容量は3桁

w-- 幅広
-k- 簡易 (詳細不明なもの)
-kk 簡易 (1本独立タイプ) 地方によくみられる
-k1 簡易 (2本連結一体化タイプ) JR九州などに見られるニコイチ型
-k2 簡易 (2本連結自動改札機風タイプ) JR西日本などに見られる
-u- 有人改札

未使用は - で埋めることとしましょう。


入場と出場


入場と出場で仕様が異なるという微妙な自動改札機があるため、入場と出場は同じ仕様で、かつ別々に持つこととしましょう。
表現すべきは次の事項
・入場専用
・出場専用
・IC専用
・磁気券専用

入場専用/出場専用は、ハードウェア的に片方のみのものと、双方向可能ながら片方向しか進めないようソフトウェア的に設定しているるものとがあります。
また、時間帯によって変化するものもあり、その表示について需要があります。

以上をきちんと記録するためには、各方向ごとに情報容量3桁必要です。

まず方向性については2桁

o- 通行可 (HWかSWか不明な場合)
x- 通行不可 (HWかSWか不明な場合) (入専または出専の時に使う)

oo 通行可 (HW的に)
xx 通行不可 (HW的に)

of 通行可 (両方向可能改札を、SW的に通行制限) f=fix
xf 通行不可 両方向可能改札を、SW的に通行制限)

ot 通行可 (両方向可能だが、時間帯で方向性が変化)
xt 通行不可 (両方向可能だが、時間帯で方向性が変化)

時間帯で変化するものでも、開始・終了時刻などは今後も記録する予定がないので、最初から考慮しません。
oo xx は良いと思う一方、of xf は視覚的に今ひとつ感があるため、再考する必要があるように思っています。


その他の属性


今のところは次の属性が表現できれば充分です。
・IC専用
・磁気券専用

従って1桁で表現できます

i IC専用
m 磁気券専用
- いずれでもないもの


表現例


以上より、共通3桁、入場と出場各3桁で表わせそうということが分かりました。
念のため入場・出場は拡張性を考慮し1桁増やし、3+4+4桁で表現し、各部を/で区切ることとしましょう。
/を含め、1改札あたり13文字あれば余裕を持って仕様を表現できるようです。

表現例は次の通りです。

---/o---/x--- ↑入専 (不確定なもの)
---/x---/o--- ↓出専 (不確定なもの)
---/oo--/xx-- ↑入専 (ハードウェア的に固定)
---/xx--/oo-- ↓出専 (ハードウェア的に固定)
---/of--/xf-- ↑入専* (両方向可能改札を、SW的に通行制限)
---/xf--/of-- ↓出専* (両方向可能改札を、SW的に通行制限)
---/ot--/xt-- ↑入専* (両方向可能だが、時間帯で変化)
---/xt--/ot-- ↓出専* (両方向可能だが、時間帯で変化)
---/ot--/ot-- ↑↓(時限)

-k1/o---/---- ↑簡易(1本独立タイプ) 入専
-k2/o---/---- ↑簡易(2本連結自動改札機風タイプ) 入専

-u-/oo--/oo-- ↑↓有人

w--/oo--/oo-- 幅広
---/ooi-/ooi- IC専
---/oom-/oom- 磁気

---/ooi-/oo-- 入IC専
---/oo--/ooi- 出IC専


今後


今後この表現方法を導入したとして、どのように画面に表示するか(現状通り入場と出場を混合して表示するのか、入場と出場を分けて表示するのか)を考慮する必要があります。
また報告画面も、この仕様に合わせて変更していく必要があると思われます。

2016/10/01(土)11:08 |Comments(0) |Trackback(0)

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

▲ページトップ

ナイスパス 乗降におけるデータの変化

ナイスパスは20件の履歴のほかに、最新1件の乗降情報を保持しているようです。

鉄道とバスとでは動きは異なるようですが、鉄道でもバスでも、乗車中ということは分かり、また降車した段階で、乗降の情報が全て揃います。
では乗車中に、乗車している情報がどれだけカードから得られるのでしょうか。

実際のカード内情報の動きを見ながら検証したいと思います。

データは提供いただいたものそのままで、日時・金額・乗降した場所、乗車したバスの車輌などが完全に特定できますが、個人を特定できるものではないので、特に隠さずそのまま掲示してあります。問題あればお知らせ下さい。



鉄道


鉄道乗車 新浜松(01)駅


(残高情報)
020B:0000 25 58 AA 8C 00 00 00 00 00 00 00 00 00 00 00 00
YYYYYYYYYYY
020B:0001 21 30 5F 61 81 A0 11 08 00 0C 30 5C 00 00 00 00
FF
020B:0002 10 0C 3B B1 44 39 01 24 01 CA A3 A3 F9 B2 00 27
KKKKK SS SS #######%%%%%%%
(履歴)
030F:0000 21 2E 61 01 2F 3F 9B 20 00 0A 5E 0F F4 2F E4 00
#######%%%%%%% FF

※乗車段階では残額情報部は更新されますが、履歴部は前回のままで更新されていません。
従って10ニブル(5オクテット)が一致するかどうかで、乗車中かどうかを判断することは可能そうです。

残額情報部の凡例
Yは残額(ポケット1)
Fは処理内容 0x11 = 鉄道乗車改札機(1)/乗車(1)
Kはバスでは系統NO欄、鉄道では無効の可能性あり
Sは駅または整理券番号、鉄道では駅番号 01=新浜松 前回分は無効
#は今回の駅 0xCAA3A = 830010 = 新浜松
%は前回分、ただし降車ではなく乗車した場所が残る

鉄道降車 上島(07)駅


(残高情報)
020B:0000 24 B8 AA 8C 00 00 00 00 00 00 00 00 00 00 00 00
YYYYYYYYYYY
020B:0001 21 30 5F 61 61 41 23 08 00 10 2F E4 00 00 00 00
FF
020B:0002 00 0C 61 01 44 39 01 07 01 CA A3 AC AA 76 00 28
KKKKK SS SS #######%%%%%%%
(履歴)
030F:0000 21 30 49 C6 10 CA A3 AC AA 76 23 1F F0 2F 44 00
#######%%%%%%% FF

※降車段階では残額情報部の降車情報も書き込まれ、また履歴部も1件挿入されます。
降車段階では10ニブル(5オクテット)が一致しています。

残額情報部の凡例
Yは残額(ポケット1)
Fは処理内容 0x23 = 鉄道降車改札機(2)/降車(3)
Kはバスでは系統NO欄、鉄道では無効の可能性あり
Sは駅または整理券番号、鉄道では駅番号 01=新浜松、07=上島
#は乗車駅 0xCAA3A = 830010 = 新浜松 (※乗車時に書かれ降車時も変化しない)
%は降車駅 0xCAA76 = 830070 = 上島

鉄道の場合について


乗車中にも、どこで乗車したかがカード内から把握できます。
また履歴情報では乗車時刻は記録されず、降車時刻も精度が10分単位と悪いものの、最新1件については乗降ともに時刻が記録され、かつ精度も1分単位となっています。

うまく履歴情報と混合できれば、最新1件については、それなりに正確な情報を補うことが可能と思われます。


バス


バス乗車


(残高情報)
020B:0000 23 DC AA 8C 00 00 00 00 00 00 00 00 00 00 00 00
YYYYYYYYYYY
020B:0001 21 30 6D E0 6D 80 51 08 00 0A 2E CC 00 00 00 00
FF
020B:0003 04 4C 1C 68 03 FE 94 A2 00 00 00 00 00 00 00 00
KKKKK SS SS #######%%%%%%%
(履歴)
030F:0000 21 30 52 13 D6 00 00 02 99 50 5E 0F F6 2E 68 00
#######%%%%%%% FF

※乗車段階では残額情報部には乗車位置などは記録されません(今回停留所番号欄には0が書かれるもよう)。また履歴部も前回のままで更新されていません。
残額部と履歴部の10ニブル(5オクテット)は一致しないので、バスでも乗車中かどうかを判断することは可能そうです。

残額情報部の凡例
Yは残額(ポケット1)
Fは処理内容 0x51 = バス(5)/乗車(1)
Kはバスでは系統NO欄 乗車時は書かれない(無効)
Sは整理券番号 乗車時は書かれない(無効)
#は乗車停留所 乗車時は書かれない(無効)
%は降車停留所の代わりに前回分(前回の乗車停留所番号=0が書かれている可能性) 

バス降車


(残高情報)
020B:0000 23 28 AA 8C 00 00 00 00 00 00 00 00 00 00 00 00
YYYYYYYYYYY
020B:0001 21 30 6D E0 6E E0 5E 08 00 12 2E 68 00 00 00 00
FF
020B:0002 00 00 37 40 42 CC 12 16 04 29 95 02 99 96 00 2B
KKKKK SS SS #######%%%%%%%
(履歴)
030F:0000 21 30 53 03 74 29 95 02 99 96 5E 0F EE 2D B4 00
#######%%%%%%% FF

※降車段階では残額情報部の乗降の情報が書き込まれ、また履歴部も1件挿入されます。
降車段階では10ニブル(5オクテット)が一致しています。

残額情報部の凡例
Yは残額(ポケット1)
Fは処理内容 0x5E = バス(5)/精算(E)
Kは系統NO欄 0x42CC = 17100
Sは整理券番号 乗車0x12=18 降車0x16=22
#は乗車停留所 0x29950 = 170320 = 紺屋町
%は降車停留所 0x29996 = 170390 = 博物館

バスの場合について


バスの場合、鉄道とは違って、乗車した時点では、停留所番号ないし整理券番号などはカードに書かれないようです。
ただ、処理内容としてバスに乗車したという情報は書いているように思われます。
実際には暗号化された領域に乗車位置が書かれている可能性はありますが、可読範囲内には少なくとも書かれないようです。

乗車したという処理情報が書かれているため、整理券番号なども乗車時に書かれていることが期待されましたが、残念ながら期待は裏切られたもようです。

2016/09/27(火)13:48 |Comments(0) |Trackback(0)

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

▲ページトップ

カレンダー

11 | 2016/12 | 01
- - - - 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