将来的には、完全自動運転でとかと思いましたが、免許証を認証するとかすぐ対処しないといけませんね

「免許自主返納後に運転して事故」とか、何年も先の話をしている場合ではないですね。2020年以降販売する車は免許証を差し込んで、運転を許可されている車かどうか認証して、確認できないとエンジンがかからないようにするとかすぐに対策しないとしないとけませんね。

 自動運転をすぐに実現するのは厳しいでしょうが、運転免許証を認証するのはすぐにできるはずです。

まず、ICチップを組み込んだ免許証ですが、一番遅い時期に導入された鳥取県でも2010年に導入されています。このため全国で導入されてから8年以上経過しています。運転免許証の有効期間は長い人でも5年ですので、すでにすべての人の免許証はICチップが入ったものに切り替わっています。

また、免許証のICチップには 「氏名」「生年月日」「免許証交付年月日」「有効期間」「免許の種類」「免許証番号」「顔写真」 の情報が入っています。ICチップを読み取る機器はすでにありこれをベースに開発すれば、有効期限内の運転免許があるか、この免許証で運転可能な車かどうか、をチェック可能です。ETC機器と同額程度で実現できるのではないでしょうか。 また、画面に氏名や顔写真を表示することも簡単にできそうで、免許のまた貸しにもある程度の抑止力があるでしょう。さらに、半年くらい開発期間は長くなるかもしれませんが今どきのディープラーニング技術を使って、「顔写真」と運転者が同一人物か顔認証でチェックすることもできるでしょう。

いろんな方面からの対策がありますが、役所関係が本気になれば免許ベースの対策はすぐに現実できそうな感じがします。

最近、多い自動車事故についての統計解析

最近、多い自動車事故について統計データを分析、解析してみようかとデータを探してみました。”交通事故総合分析センター”のサイトから入手できそうですが無料で入手できるのは統計解析後の情報だけでした。有料ならどこまで生データを入手できるのかよくわかりませんでした。無料で入手した統計データでは確認したい情報はありませんでした。以下に、何を確認したかったのかなどを書きます。

 事故件数は報道されている件数よりも遥に多いはず。ということは、報道は一部を報道しているだけなので、そこには報道関係者などのベクトルがかかっている。そのベクトルは妥当なのか、報道されている統計後の情報は、意図的に元データを操作するなどデータ自体にもベクトルがかかっていたりしないかを確認したかったのです。

まず、ぱっと思いつく疑問を挙げてみました。

・高齢者の事故が多いとされているが、何か傾向はあるのか?

・報道写真を見ていると、特定車種をよく見る。車依存の事故が多いのでは?

・今どきの分析での成果はなにかあるか?
とりあえずこの辺についてコメントします。

■”高齢者”に関する分析
・ 「運転者年齢層別の事故件数」や「 高齢者の事故 」の統計データがありました。 計数データはほかの年齢と比較しないと、あまり意味がないでしょう。事故を起こしたのが高齢者かどうか、資料での記述”第1当事者”の年齢別のデータについては、人口統計の補正はしているようですが、運転者人口とか運転時間(人・時)を母数とした情報にはなっていません。この辺の考慮や、運転時間別の比率つまり普段運転していない人のほうが多いとか、自動車を乗り換えてからの期間が短いつまり操作性が異なる車に慣れないうちに起こす事後が多いとか、組み合わせてみるとより顕著な結果が得られるように思います。

■”車種別”の分析
車の台数が多いから、よく報道に登場するのかどうかとか車種別のデータがありません。気が付いている人も多いので、統計データを公開しないのは何か意図的に隠ぺいしているように見えますよね。明らかに何かあるのなら情報を公開して、みんなで議論しつつ対策を進めるべきでしょう。逆に何もないなら公表しない理由は何のでしょうが、少なくとも何かる車種があるので公開できない状態なのでしょうか?よくあるパターンは、気にしているところは何もないが、思わぬ車種に特異なデータがあったりしますね。

■” 今どき”の分析
今どきの分析ならもっと面白い結果が出てきてもよさそうですが、その辺が何もない感じです。これだけ大量のデータがあるのだからちょっと何かすれば改善できるネタは出てくるはずなのですが。

↑感覚的にはそうかもしれないが、分析的なアプローチがない感じです。また、プリウスをじっくり乗りこなしたうえでも感じる違和感には到達していないと思われ、深堀りした内容にはなっていない感じがします。

↑ 最近のブレーキとアクセルの踏み間違いとみられている件に触れているが、その件についての原因周りの話はなく、 ギア周りの話に終始していて分析不足の感がある。

↑ギア周りの話は、同感です。 最近のブレーキとアクセルの踏み間違いとみられている件には触れていない。

↑全体的に同感ですが、身振り手振り付きの喋りながらの運転は危険運転とまではいかないが、いまいちです。さて、直近の事故は、事故ごとに特性は違うので、それぞれの事故ごとに分析が必要でしょう。

最近の車には、一昔前のフライトレコーダと同レベルの情報は残っているのでしょうからデータ解析すれば何かわかるでしょう。入力信号の混線や人為的なデータ破壊とかまで考えるとデータ矛盾のチェックなど大変な作業かも知れません。

できるだけ早く、完全自動運転で何とかしてほしいです。そのレベルに辿り着く途中の車のデザインは現状と変えないほうようにするとか、新しいデザインの車は一定基準を満たした人だけ運転できるとか、いろんな角度からの対策も必要そうですね。

バージョンアップ情報、脆弱性情報の自動チェックを正式運用開始

先に書いた「Webページの更新内容自体が、動的更新によるものかどうかを自動チェックして、通知するかどうかを切り分けるように強化」の完了し、うまく機能することが確認できたので、正式に運用を開始しました。また、「日本語でのメール送信」機能も組み込んだので見やすく、作業効率が改善しました。今後、新たなソフトウェアのチェックが必要になったときにチェックルールをメンテナンスしていきます。

雨が降りだしたら自動で排水 

ほとんど使っていないはずの電気代の月額が5500円とか、9500円に増えていることに気がついて、調べると排水ポンプが稼働しっぱなしになっており、常に「ジョロジョロ」と排水されていることが判明しました。普通は、「ドバー」っと一気に排水されて水がなくなると自動で止まります。これは排水ポンプのフロースイッチが効かなくなっていることが問題原因なので、本来は排水ポンプを修理もしくは交換するところです。しかし、費用も抑えたいし、コンセント側で電源をON/OFFしてやれば同じということで、余っていたスマートコンセントを付けてみました。そして指定した時刻に定期的に排水するように設定しました。この変更で、電気代は月額390円に激減しました。これは意図した通りなのですが、故障する前の電気代は月額1100円程度だったので、期待以上の削減です。ポンプの待機電力より、スマートコンセントの消費電力のほうが小さいとは思えないので、以前は現状のポンプの稼働頻度よりも高頻度でポンプが稼働していたと推測されます。

短時間に多量の雨が降った場合、自動では排水されず、水が溢れるかも知れないので、少し工夫してみます。
IFTTTのサービスを使って、雨が降り出したら排水ポンプを動かすAppletの設定をします。まずIFTTTで「New Applet」すると次が表示されます。

「+this」をクリックして実行する条件”トリガー”を設定します。ここでは「Weather Underground」を使っています。検索枠にサービスの名称” Weather Underground ”の頭から数文字を入れると選択肢が表示されます。
” Weather Underground ” をクリックします。

次に実行条件を選択します。雨が降ったら起動したいので、”Current condition change to ….”(現在の天候がxxxに変わったら)を選択します。

”Current condition” は「Rain」(雨)を、Locationをマップで指定します。「Create trigger」をクリックします。

「+that」をクリックして、何を実行するかを指定します。

”実行条件”と同様に、実行する処理をサービスの中から選択します。ここでは、利用するスマートコンセント”Meross”を指定します。

”Turn on”(電源オン)を選択します。

登録した”排水ポンプ”のスマートコンセントを選択し、「Create action」をクリックします。

設定した内容を任意の名前を指定します。 「Finish」をクリックしIFTTT設定を完了し保存します

以上で、「雨が降りだしたら自動で排水」することができます。排水ポンプを止めるほうはスマートコンセントのスケジュール設定で「1分後にオフ」を登録しているので、1分後に自動的に排水ポンプは停止します。

他のサービスやWebRequest、Webhook、独自実装を組み合わせて排水量制御とか、排水の代わりに灌水の制御をするようにして、雨の状況を予測して灌水するかどうかを制御するとかいろいろできますね。

Pythonで日本語メール送信

定期実行タスクの機能を使ってメール送信していましたが、content-typeを次のようにcharsetを指定したいのに、

Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US

つぎのように指定されています。
Content-Type: text/plain; charset=ANSI_X3.4-1968

このcharset指定のメールでは、日本語の文面が文字化けしてしまいます。受信したメーラーで明示的に文字コードを指定することで文字化けは解消しますが、いちいち指定する手間が大変です。そこで定期実行タスクのメール送信機能は使わずに、Pythonから直接送信するように変更します。

Python2.6で使用するので、 Uchida さんのコードを参考にさせていただきました。

参考のための補足情報:

・デバック方法
smtp = smtplib.SMTP(c[‘host’], c[‘port’])
の次の行に 「 smtp.set_debuglevel(True) 」を追加することで、メールサーバとの通信内容を確認できます。

・ユーザー名、パスワードの指定にはダブルクオーテーションでくくるのはNGです。ダブルクオーテーションもユーザー名、パスワードとして送信されます。

user = <アカウント名>
password = <パスワード>

このPython実装でのメールでは、charsetは次のように設定されます。

Content-Type: text/plain; charset="iso-2022-jp"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

以上の設定により 、メールの日本語文面を文字化けせずに参照することができます。 これをベースに、脆弱性情報の通知メールに送信機能を組み込みます。