「生活の支援としての自動車自動運転」を聞いてきた！

10月２６日、KKE Vision 2016に行ってきた！
そのうち、はじめの基調講演は、本家に書いた
つぎの「生活の支援としての自動車自動運転」をメモメモ

---

■司会者挨拶
・伊藤先生と構造計画
　MASで意見交換
　自動走行に構造計画参画

■生活の支援としての自動車自動運転
・高齢化社会が進んでいる。そういう視点で考えないと
　→中身は生活支援に到達できてないですよね～
　解決すべき課題の提示

・主にヒューマンファクターの問題
　自動運転が導入：ドライバー不要になるわけではない
　　どんなふうに人間が関わり？どんなことを知っていないといけないか
　　１１月５・６日　筑波大の学園祭：ドライビングシミュレーター

・講演の内容
　一過性のブーム？本当に役に立つシステム→どんなことを考える？

・話題
　自動走行の必要性
　自動走行システムの開発動向
　自動走行実現のための課題と今後の展望
　質疑応答

・なぜ自動走行システムが必要か
　　安全の向上
　　　２０２０年までに交通事故死者数を２５００人以下に
　　渋滞の解消
　　モビリティ向上（高齢者、障がい者）
　　　今日の話題
　　時間の有効活用（エンタメ、仕事）
　　　ヨーロッパの人たち
　　コスト削減（トラック、バス、タクシー）
　　技術者の夢
　　　自動で動くモチベーション

・安全の向上
　日本の道路交通安全の動向
　　平成に入ってからの減少→衝突安全の開発・普及／救急医療の発達
　　　衝突した後については、頭打ち：４０００人くらい亡くなっている
　　　　→あと１５００人減らさないと！
　　事故が減った社会的インパクト

　全世界では、年１２０万から１３０万人の交通事故死者がある
　　→１００万人を超えるオーダー：事故が減る社会的インパクトは計り知れない

・免許保有率
　　６０歳から：保有しない人が多くなってくる
　　　→運転し続けたいが、危なくて運転できない：加齢とともに増える
　　→自由に移動できるようになるのはすばらしい！

・高齢者・障害者のモビリティ向上
　　動画　Google：ブラインドの人が自動運転で

・時間を有効に活用

・自動運転の開発動向

・動画：日産自動車　セレナ
・現在の実用化レベルの例
　テスラ　モデルS
　　自動運転便利機能
　　　アダプティブクルーズコントロール
　　　オートレールセンタリングとレーンチェンジ
　　　パーキングスペースディテクション
　　センサー
　　　カメラ
　　　レーダー
　　　超音波センサー
　　→地図情報と連動していない

　　テスラ　モデルS　：家より高い？
　　　カーナビのお化けがある
　　　青い線：システムが車線を認識
　　動画：走っているとき
　　　首都高速走ると・・・いろんなこと起こる
　　　　地図と連動していない：下り坂で加速、出口に向かって加速
　　　　今は、そこが現状

・自動運転と呼ぶんですか？
　本当の意味の自動運転

・自動運転実現に向けた課題
　　法律的な課題
　　　責任の所在
　　技術的な課題
　　　システムが対応できない場面の存在
　　　その場合のドライバとのインタラクション
　　社会的な課題
　　　リスクを負うのは誰か

・事故の責任は誰が負う
　　国際法：ウィーン交通条約（日本はジュネーブ条約に加盟）
　　　第8条　運転者
　　　第13条　車両の間の速度と距離
　　国内法
　　　道路交通法
　　　自動車損害賠償保障法　免責３要件
　　→刑事だけでなく、民事も

・自動運転を支える技術の例：Lidar
　　精密な地図がいる
　　自分が今どこにいるかを正確に認識
　　　→カーナビX：５ｍのずれ、どっちの車線にいる？
　　３次元レーザースキャナー
　　　→道の端まで分かる
　　　→すすんでるけど・・・
　　　　雨降っている状況で　とまってしまったり、
　　　　照り返しがすごいと・・：パイロン蹴飛ばす
　　　　問題ある：お金をどこまでつぎ込むか
　　どうやってつくる？

・死亡事故を起こしたドライバーの投稿
　１台くらいの前方の左右が死角
　そこからはいってくると、なすすべがない

・今年の春の死亡事故
　白い荷台が空と区別がつかない？本当のところは分からないけど・・
　止まっている車の認識は難しい

・センサーの能力に限界

　そこは道じゃない！
　　ろかたにクルマがいる
　法律を部分的に破ってもやらざるを得ないことをデザインとして入れるか？
　　→恣意的な判断になりかねない

・どうぞ、いやどうぞ
　鉢合わせ：相手に先行って貰う→お互いに待って、動かない
　ある種のリスクをとって行動しないと・・→どうやってリスクをとる

・あの赤い棒はなに→社会的な文脈依存

・自動走行とシンギュラリティ
　現在の乗用車と全く同じように使える自動車が
　完全にドライバーレスで自動走行できるようになるためには
　システムは人間と同等か、それ以上の知性を持つことが不可欠
　　　シンギュラリティ
　現実問題としては、もうちょっとトーンダウンした自動運転が必要

　本当に頼りたいところで、頼れないシステム
　　→はしごをはずされる
　むずかしいとことでこそ、システムに頼りたいのに・・

・自動運転にレベルというコトバを聞いたことがありますか？
　　アンケート：ほとんどの人が手を挙げる
　　いばらぎできくと：半分くらい
　１：運転支援
　２：部分的自動　　　　　人間が監視
　　-----------------------------------
　３：条件付自動　　　　　システムが監視
　４：高度自動
　５：完全自動
・SAE　J3016
・レベル5：ちょっときびしい？ある限られた領域なら→それはレベル４？

・高齢・障害者と自動運転
　少なくともレベル３までは必要なときは人間が自分で運転をしなければならない
　→すなわち、運転席に「運転免許証を保有している人」が座っている必要がある
　→免許証を返納した高齢者や障害者は自動運転のサービスを受けられない

・レベル３は実現できる？
　通常時、ドライバには監視は要求されない
　　しかし、システムが制御を継続できない場合は、ドライバが運転を引き継ぐ必要がある
　　ドライバはわき見をしてもいいが、お酒を飲んだり寝てはX

・システムが対処できない場面ではドライバが対処する
　　でも、運転の文脈がわからなくなる（ここどこだっけ？）
　　ドライバに制御引継ぎを出すことが要請される
　　気づいたらいつの間にか危険な状態になっていたということは許されない
　　　　３００メートル、４００メートル、前方大丈夫という

　ありうる外乱を完璧に押さえ込まないと、レベル３を自称できない
　機械の知能でそれが出来るなら、レベル４でいいのでは？

・状況を押さえ込めばレベル３を作れるかも？

　　逆走で１０秒間？

・鉄道が自動化できているのは、外乱の押さえ込み画上手くいっているから
　　無人
　　　ゆりかもめ、にっぽりとねりライナー
　　有人
　　　福岡市地下鉄七隈線、つくばエクスプレス
　列車の知能がそれほど高いわけではない
　外乱が入り込まない工夫をしている
　　　高架、ホームドア等（地下鉄には踏切がない）

・レベル２なら問題ない？
　　いつでも介入できるように準備する
　　　→罰ゲーム？それなら運転する！
　メリットは？　
社会？ユーザー？

・人間中心の自動化
　　大規模装置産業：作業員の作業を減らし、自動化：技術中心の自動化
　　結局人間に頼る→やりにくいところだけのこる
　航空：人間中心の自動化が、９０年代にまとまる
　日本の自動車業界：やってきた　アドバンスドセーフティービークル
　　　８つの項目にまとめる

・たとえば
　レベル２；無理なく監視を続けることの出来る工夫
　　たとえば、運転操作に関する意思決定に関与する
　　　戦略的な「スムーズに移動する」判断への関与
　今後の展開
　　　ホースメタファ；
　　　　免許能力おちた・・・陰で支える

・社会的な課題：トロッコ問題
　　個人の利便性か、社会の効果か？
　　　自動運転で、新しい事故が起こる：社会として耐えることが出来るか？
　　　自動運転を導入していかないと、毎年４０００人の死者が出るとしたら？


Q&A
・日本：悪いケースも考える　あれもできる、これもできるといわない
・欧米：これもできる、あれもできるという(悪いケース言わない）

KafkaやFlink等の話を聞いてきた！

10月25日ビッグデータのリアルタイム処理技術勉強会に行ってきた！
ので内容をメモメモ


■ご挨拶など
・ホートンワークスの人、テコラスの人の会場説明
・Hadoop Summit　国際イベント

■ストリーム処理を支えるキューイングシステムの選び方
・自己紹介
・ストリーム処理
　バッチ処理じゃない
　ソーシャルネットワーク、センサー、メディア、
　　→終わりがないことを前提に、着たら処理する
　　　性格が変わる
・キューイングシステム
　ＦＩＦＯ
　ブローカー
・なぜキューイングシステムを使うのか
　システムの疎結合化→スケールアウト可能
　　　受けきる
　耐障害性
・比較対照キューイングシステム
　
・Kafka
　Linkedinが作った
　キューイングシステムの枠組みを超えた
　Zookeeper：分散前提
　ＨＡ：クラスタリング（フェイルオーバーでなく）

・ＡｃｔｉｖｅＭＱ
　メッセージエンタープライズバス
　ストレージ
　プロトコル豊富
　ＨＡ：フェイルオーバー

・ＲａｂｂｉｔＭＱ
　あーらんで書かれている
　ＡｃｔｉｖｅＭＱよりはやかったりする
　ＨＡ；フェイルオーバー
　はやいＡｃｔｉｖｅＭＱというかんじ
　ＰＩＶＯＴＡＬ

・ＮＡＴＳ
　ＧＯで書かれている
　ストリーム処理：ＮＡＴＳ　Ｓｔｒｅａming

・ＮＳＱ
　ＧＯで書かれている
　完結した環境

・Ｒｅｄｉｓ
　ＰｕｂＳｕｂを提供
　インメモリーキュー
　ｈａ：せんちねる

・ＺｅｒｏＭＱ
　ただのライブラリです
　内部通信で使われる
　ＨＡ：自分で何とかする

・Ｎａｎｏｍｓｇ
　ライブラリ
　こっちのほうが導入しやすい？
　ＡＰＩ：安定してきた

・アーキテクチャ
　ブローカー必須・永続化可
　　Ｋａｆｋａなど
　ブローカー不要・インメモリのみ
　　ＺｅｒｏＭＱ，ＮａｎｏＭＱ

　永続化のメリット
　Ｌａｍｂｄａ　アーキテクチャ
　バッチレイヤ

　メッセージのレプリケーション
　　レプリケーション可
　　　耐障害性、負荷分散

　　シャーディング
　　　スケールアウト
　　　シャーディングキーに注意

キューイングクライアント
　対応プロトコル
　標準
　　ＡｃｔｉｖｅＭｑ，ＲａｂｂｉｔＭＱ
　独自バイナリ

　独自テキスト

Ｇｏｏｇｌｅ（ＧＣＰ）
　kafkaに対応している　

メッセージの再取得
　可能
　　Ｋａｆｋａ
　　ＡｃｔｉｖｅＭＱ
　　ＮＡＴＳ

複数コンシューマーによる分散取得
　スケールアウト
　注意：集約関数の結果

・Apache FrinkとApache SparkについてはBahir

・Ｋａｆｋａ一強

・処理時間
　　ＡｃｔｉｖｅＭＱががんとあがる
　　Ｋａｆｋａはそれよりゆるやか。
　　あまり変化ないのは、ＮＳＱ

・キューイングシステム
kafka：ストリーム処理するらナ
ＡｃｔｉｖｅＭＱ：多様なプロトコルをサポートするなら
ＲａｂｂｉｔＭＱ：ＡｃｔｉｖｅＭＱより速い（小レイテンシー）
ＮＡＴＳ：レイテンシーくるか？
ＮＳＱ；
Ｒａｄｉｓ：インメモリＫＶＳ
ＺｅｒｏＭＱ：アーキテクチャを１から
Ｎａｎｏｍｓｇ：実績少ない

■ＩｏＴ時代におけるストリームデータ処理と急成長のＡｐａｃｈｅ　Ｆｒｉｎｋ
・自己紹介
・ビッグデータＸリアルタイム
　ＩｏＴでのデータの扱いの変化
　　新しいニーズへの対応：セキュリティ
　　データの即時活用：データレイク
　　全量分析によるＡＩの活用

２．ビッグデータ処理プラットフォームのパラダイム
　オープンソース
　　Ｈａｄｏｏｐ，Ｈｂａｓｅ
　　Ｓｔｏｒｍ　２０１１年公開
　　Ｓｐａｒｋ
　よりリアルタイム性

３．ビッグデータ処理の３つのたいぷ
　　バッチ
　　クエリ
　　ストリーム
・バッチ
　　実行時間：分～時間
　　Ｈａｄｏｏｐ，Ｓｐａｒｋ
　クエリー
　　えらすてぃっくさーち
　　いんぱら
　　どりる
　ストリーム
　　連続した処理

４．あらためてストリーム処理
　　・リアルタイムに
　求められる要素
　　低レイテンシー、高スループット
　　スケーラブル
　　フォルトトレラント
　ストリーム処理エンジン
　　メッセージ到達せいの保証
　　フロー制御
　　ウィンドウ処理
２つの方式
　イベントアットあタイム
　　イベント受けたら処理
　マイクロバッチ：ＣＥＰ的処理可能
　　　タイムベース
　　　　発生時間
　　　　処理時間
　　　カウントベース

メッセージ到達性保証
　Ａｔ　Ｍｏｓｔ　Ｏｎce
　ＡｔＬｅａｓｔ　Ｏｎｃｅ
いくざくとりー　わんす

バックプレッシャー
　受信側の処理能力を超える送信データ
　→ペースを制御：送信側に要求
　　リアクティブストリーミング

ウィンドウ処理
　たんぶリングウインドウ
　すらいでぃんぐういんどう

ストリーム処理データエンジン
・２０１４年以降　競争激化：Ａｐａｃｈｅプロジェクト
　現時点では３つ
　　ＳＴＯＲＭ，ＳｐａｒｋＳｔｒｅａｍｉｎｇ，Ｆｌｉｎｋ

・ＳＴＯＲＭ
　Ｔｗｉｔｔｅｒが公開
　耐障害性、分散型
　エコシステムを構築しやすい
　spout bolt

・ＳｐａｒｋＳｔｒｅａｍｉｎｇ
　インメモリ

・Ｆｌｉｎｋ
　バッチ、すとりーむ、機械学習も
　シンプル

・アーキテクチャ
検討ポイント
・大量データの収集方法
・ピークの対応、じかんのずれ
・集計方法
・データの欠損
・計算途中の一時データ
・運用
ストリームデータ処理
　キャッシュ
運用
　ストリーム処理エンジンの管理コンソールを活用
　ボトルネックを見るのにあんばり

本日のまとめ

■Ａｐａｃｈｅ　ＮｉＦｉ
・インキュベーターからトップレベルへ
・データのフローを管理するツール
・１．０からＵＩ変わった
・Ｋａｆｋａでバージョン違いのときとか
・Ｓ３におくとか
・ＮｉＦＩ：ないあがらふぁいるず
・マルチテナント
　ユーザー：クライアント証明書を使っている

※ＥＴＬ（タレントとか）
　躓くポイント：ＥＴＬツール　実行したら終わり
　ＮｉＦｉ常に起動して中から通る
　メッセージを流すといまくいく

※ラムダアーキテクチャ
　みにふぁい：ＩｏＴゲートウェイになる