  |
http://b.hatena.ne.jp/entry/p.twipple.jp/JfSVb
とかバカにしてるコメントが多くて組込屋さんとしては少しもやもやしました。
30－40億かかるかは中のシステムわかんないので何とも言えませんが
乗車駅～降車駅の運賃＊消費税とかいう式で毎度計算をやるなんて計算コストが大きすぎて
論外なんじゃないかなぁ。
ブコメにもあったけど運賃テーブルを参照でもしないとやってられんはずと思って
ソースを探したところ
http://blogs.itmedia.co.jp/morisaki/2011/12/1040-be7c.html
以下引用
首都圏の鉄道では運賃計算のための経路が10の40乗を超えるそうです。その内訳は、単純に乗り降りの駅の間の運賃を計算するだけでなく、定期券の併用を考慮し、定期券の前後で通常の運賃を支払う場合や、乗り継ぎでいったん改札を出た後で時間をおかずに別の改札を通った場合に割引がある場合（首都圏では同一駅で東京メトロから都営に乗換えるような場合、関西では東梅田、梅田、西梅田へ乗換えるような場合）のように、かなり複雑なパターンを考慮する必要があるそうです。
運賃計算が正しく実装されているかどうかを確認するために、実機用と検証用のプログラムを別のチームで作成し、2つの結果を突き合わせるそうです。実機では、計算機リソースの制約から運賃テーブルを使ったり計算時間を50ミリ秒以下にする必要があったりします。場合によっては、それらの制約が原因となって運賃計算を誤って実装される場合があるそうです。一方検証用はそのような制約がほとんどないので、運賃計算のルールに近い形での実装が可能になります。2つの結果が異なる部分があれば、いずれかが間違っていることになります。
やっぱりこんな感じになってるようです。
これを改修して誤徴収0を担保する為の評価ってものすごいコストだと思います。
たぶんバカにしてる人達に任せたら要求されてる応答速度返せないシステム作りそうだなぁと。
というわけでPC上で動くプログラムの常識があてはめられない組込み世界のリソース制約と止まってはいけないクリティカルなシステムにかかるコストについて
もうちょっと知ってもらえたらなぁと書いてみました。
WEB系の人はCをおわコン扱いするけど お前らが使ってるデバイスのファームやドライバはほとんどCで そのおかげで高スペックな環境実現してんだろって言いたくなるわ
11
