Hadoopを中心とした分散環境での開発方法論・モデリング・設計手法等についての座談会(第5回）のメモ。
■システムの耐用年数10年（開発4～5年、規模10Mステップ、10K人月）
進路制御のシステムはガチガチなつくりで、耐用年数も20年を超える
→システムの寿命が長いので、新しく採用する技術の見極めも重要に
■国鉄三大システム
・マルス 1960～
・コムトラック 1972～
→鉄道会社別に派生したシステム有
・ヤックス ～1984
■鉄道システムに求められるもの
・作業の効率化
・連続稼働（社会インフラとしての責務）
→分散処理
①可用性のためのしくみ
②バッチ処理の高速化
・高度な判断支援（ベテランの引退に伴うノウハウの継承）
→最適化
■連続稼働のためのシステム構成
・Fault Tolerant：1系のみ
・Active-Standby（FT）：1系、2系
・Active-Active：1系、2系 ◎現在、これが主流
→系切り替えは10秒以内、データのリトライからの投入はない。
・専用ハードウェアが高価
・作りこみが複雑
・系を切り替えるタイミングは無限大（試験不可能：不具合の温床）
→汎用的なハードを使用したい
→なるべく作りこみを減らしたい
・1系、2系、3系（3系は予備でStandby）
・1系、2系、3系、全部Active
→多数決をとらせる（magiシステムやね）
■輸送計画のシステムではバッチ処理がほとんど。
・作業のオーダーは数分～数時間
→この時間を短縮したら、作業の効率化になるかな？
→Asakusaつかえるかな？
■鉄道における計画問題
・作業が俗人的
・効率化したい
☆研究が盛んだが、実用化はまだ...
ただ、ハードウェアの性能向上、低下価格化進んでるので..
■システムに求める要望も変化している
・プロフェッショナル向けの機能から、誰でもそれなりの結果を出せる機能へ
■最適化技術
・ある条件のもとで最適解または許容解を見つける技術
・線形計画法、整数計画法
・ネットワークフロー
・？
☆とにかく数式化・モデリングしないと始まらない
■制約条件もいろいろ
・走行距離とか、検査とかも含める
それを踏まえて、車両運用案を決めるのが大変。
■乗務員運用のモデリング
・車両運用のモデリングと同じ。
ただし、1車両に複数の乗務員が便乗できるので、数式が少し変わる。
■車両割当のモデリング
・組み合わせも膨大
・予備の割当も必要
・ネットワークフローを使って作業したことも
■1970年代頃から盛んに研究されてきた
コンピュータの高性能化により、机上研究から実証研究に移りつつある。
ただし、実用化はまだまだ...
大手鉄道会社では、実用化を始めているところも...
ただ、まだまだ
■まとめ
鉄道システム
・まだまだシステムの介在する領域アリ（未踏領域が多く残っている）
・開発サイクル長く、開発も保守的になりがち
→35年前のコムトラの仕様と大きくは変わっていなかったりする。
→新しい手法を導入するには、事前の緻密な調査が必要。結構コストかかる。
・業務の用件や、システム利用者の意識は常に変化
→システムは追従の必要アリ
・これからの鉄道システムの開発には、多様な技術力が必要
コアな部分とそうでない部分を分けて考えようという流れもある。
・コアな部分：保守的でも仕方ないかな
・そうでない部分：分散処理とか使ってみようよ
東京メトロは最適化技術を導入しはじめている
京急まだ、基本人力w
→システムと人間の使い分けをある意味しっかりしている。
市販の参考文献アリ
質問：分散系は、鉄道の周りのサービスで使ってんじゃない？
Suicaの使用履歴（電子マネーの購買履歴）とか、乗車データとかはある。
→データ売ってもお金になる（駅構内のテナントの販売計画とか）
→東急エージェンシーとか、鉄道系広告会社が研究してそう。
→ストーカーみたいなマーケってテーマのひとつだし...
質問：新技術の採用のネック
・保守体制、コストがキーに
→耐用年数長いしね
→採用技術（製品）のライフサイクルは結構気にする
→スピーカーさん自身、途中で終わっちゃったシステムは今のところない
→エクセルで帳票作ってほしいっていうニーズも
→10年後のエクセルってw 互換性はー？
→企業買収とかで、製品の取扱い元が変わって、保守費用UPってことも
0 件のコメント:
コメントを投稿