神戸製鋼のデータ改ざん問題と安全率

神戸製鋼の製品データ改ざんがアルミ製品、鉄粉だけでなく鉄鋼線材にまで及んできました。

当然、それぞれの製品は別の部署で作っているのでしょうから、一部担当者や課長、部長の独断ではなく、会社全体で計画的にインチキをやっていたのだと思います。 重役が粉飾を指示していた東芝同様、こんな会社に救済の必要などなく、さっさと潰れるべきです。

私は昔、田舎大学の機械科を卒業しましたが、今回のニュースに触れて”安全率”について習ったことを思い出しました。 機械設計の講義で、旋盤の歯車の図面を書く授業でしたが、そのときに「計算上必要な強度に、安全率5倍を掛けて設計するように」と教わりました。

安全率についてはこちらのページに詳しい解説がありましたが、鋼の場合では静的な荷重の場合は安全率の目安は3、動的な荷重で引張りまたは圧縮のどちらかのみの場合は5、両方の場合は6、激しい繰り返し荷重や衝撃の場合は12となっています。

たとえば、総重量10トンのトラックが一度に10台並ぶ長さの橋をかけるとしたら、100トンまで耐えられるように設計すれば理論的には橋は落ちませんが、実際の設計では安全率3または5が掛けられているので、300トンないし500トンの重量が乗っかっても落ちないのです。

今回のニュースにおいては実際の改ざんデータの内容が出てこないのでわからないのですが、もしそれがメーカーから要求された強度に対して1割程度強度が低いものをインチキデータとともに納品していた、というレベルであれば、メーカー側の設計で十分な安全率をとっていれば最終製品の安全性に問題はないという結論になるでしょう。

このあたりのことを実際のデータにもとづいて冷静に考慮すべきだと思いますが、インチキを指示した重役達は絶対に許されるべきではありません。

出来上がったアルミや鉄鋼製品が顧客の要求スペックを下回ったのであれば、かつその強度でも最終製品の安全性が確保されるのであれば、メーカーは顧客にスペック緩和のお願いと値引きで交渉すべきです。 顧客が応じてくれなければ別の製品用に回せばいいのではないでしょうか。

インチキは絶対に駄目だけど、安全には問題ないかもしれない、という話でした。

 


ラジオサーバー、ホームラジオでNHKが受信できない件

9月9日追記

ラジオサーバーv3.2.5のSDカードイメージファイルを公開しました。 シェアウエア試用中の方、オンラインアップデートで現象が改善されなかった方はこちらをご利用ください。

https://drive.google.com/file/d/0B7T7P5pEy2D9Rk9ic1l5eWtRMTg/view?usp=sharing

9月8日追記

ラジオサーバーをご利用の方、大変申し訳ありません。 昨日公開のv3.2.4に、特定の環境(システム設定ページ内でストリーミングサーバーポートをデフォルトの8090から変更している場合)において、NHKのライブ聴取が出来ないバグがありました。 現在の最新版はv3.2.5ですので、もし上記に該当する場合は再度オンラインアップデートを行ってください。 v3.2.4からのオンラインアップデートは1分ほどで完了します。 シェアウエア版SDカードイメージ全体は明日9日に更新予定です。この問題はホームラジオには影響がありません。

9月7日追記

ホームラジオ、ラジオサーバーともにオンラインアップデートで改善されますので、ご自身のホームラジオ、ラジオサーバーの”システム設定”ページ最下部からアップデートを行ってください。 アップデートには高性能版(Raspberry pi 3)で2時間程、通常版(Raspberry pi B+)では半日位かかりますので、アップデートを開始したらそのまま放置してください。 完了後、自動的に再起動します。 この間、ブラウザを閉じてしまってもアップデートは継続されますので電源を切らずにお待ち下さい。

シェアウエア版でご試用中の方はオンラインアップデートが出来ませんので、再度SDカードイメージをダウンロードして書き込みを行ってください。 現在、最新版のSDカードイメージは各製品のページのGoogleドライブのリンクからダウンロードしていただけます。(Vectorは数日後)

----------ここまで追記

 

本日9月5日から、ラジオサーバー、ホームラジオでNHKのらじる★らじるが受信できなくなりました。

調査の結果、配信プロトコルが変更されたものとわかり、現在対策版を製作中です。

明日6日には完成する予定ですので、ご利用の方にはご迷惑をおかけいたしますがもう少々お待ち下さい。

完成後、既存ユーザーの方はオンラインバージョンアップにて更新版を配布させていただきますが、今回のバージョンアップでは一部プログラムの再コンパイルが必要であり、アップデートに数時間かかるものと思われます。

アップデートの途中で電源を切ってしまうと動作しなくなる可能性がありますが、その場合はご連絡いただければ最新版のSDカードイメージファイルをご提供いたします。

準備が整い次第、ホームページにてご案内いたします。


プリウスの事故

先日から日本に一時帰国していますが、昨日鈴鹿市のF1マート(安売りスーパー)に買い物に行った帰り、サーキット道路の脇で黒いプリウスが歩道側の壁にぶつかっているのを見ました。

多分まだぶつかったばかりで、30代くらいのスーツを着た運転手が車から降りて、となりのお店のほうに歩きはじめたところでした。

片側一車線ですが道幅は広く、直線の区間ですので普通ならハンドルから手を離していてもまっすぐ行けそうなものを、なんでこんな急な角度で歩道に上がって壁にぶつかったのかと、ちょっと考えたらあの福岡の病院へのタクシー突入事故を思い出しました。

福岡のタクシー事故は、先月でしたか続報があり、EDRの記録を根拠に、運転手のブレーキとアクセルの踏み間違いということで送検されたとのことでしたが、一貫してブレーキが効かなくなったことを主張していた運転手さん本人が真実を話していたのであれば断腸の思いであると想像します。

本当に車両に欠陥はなかったのか、それをきちんと丁寧に検証したのかが気にかかります。 私個人の意見は過去の記事”福岡の病院でのタクシー突入事故について” にありますのでご一読ください。

上記画像の昨日の事故は犠牲者がいないようで幸いでしたが、画像をみていると、”あれ?ブレーキ踏んでるのにスピードが落ちないよ。 うぁぁーだんだん加速してきた!追突するー!!” となって、仕方なく壁に向かって急ハンドルを切ったように見えてきませんか。

真相は知りませんし、物損事故なのでニュースにもならないでしょうから単なる想像ではありますが、福岡の事故と同じ型のプリウス、若い運転手、まっすぐな道ですので、踏み間違いはないでしょう。 単なる脇見や対向車を避けての事故かもしれません。 でも、もしそうでなければ警察はEDRを見て踏み間違いと判定し、壁の弁償と車の修理は運転手の責任とするのでしょうか。

※EDRはイベントデータレコーダのことで、事故発生時のアクセルやブレーキの操作状態を記録するそうです。コンピュータが正常に動作していることが前提ですが...


ドコモの海外送金とTransferWiseの比較

まにら新聞 のウェブサイトを見ていたら、上部に”ドコモの海外送金 ど~んだけ送金しても手数料は一律1,000円” というバナー広告が出ていて、気になってクリックしてみました。

私は昨年から日本→フィリピンの送金には TransferWise を使っていて、はじめて使ったときに記録した利用方法などはこちらに紹介していますが、”ドコモの海外送金”のページでは、フィリピンへの送金も直接ペソの為替レートが表示されていたので比較してみました。

ドコモの海外送金の場合は、手数料1000円、本日1月16日の為替レートは0.4252

docomo

TransferWiseは手数料990円、本日1月16日の為替レートは0.43569だった(図中右下部分)

tw

10万円送金した場合、フィリピンの銀行に振り込まれる金額は、ドコモの場合は

( 100,000 – 1,000 ) x 0.4252 = 42,094.8ペソ

TransferWiseは画像に表示されている通りで 43,137.44ペソなので、その差は1042.64ペソである。

ドコモの利用条件は、ドコモの携帯電話契約者本人であること、とあるのでドコモの携帯を持ってないといけないし、マイナンバーの確認も必要で、かつ手数料が高いとなるとやはりTransferWiseの勝利である。

昨年からすでに8回、TransferWiseで送金をしているが、全く問題なくすぐに届くし、随分節約できるようになったので満足しています。 おすすめです。


アクセルとブレーキの踏み間違い事故について考えたこと

特にここ数日は話題になっているようだが、AT車のアクセルとブレーキの踏み間違い事故について考えてみた。

よくあるパターンは、駐車場で止まろうとしたときにアクセル全開で店に突っ込んでしまったり人を轢いてしまったり、ということだと思う。

ならば、前後に障害物があるときにアクセルを踏んでもアイドリングを維持すれば、クリープでのろのろ進むだけなので被害はかなり軽減できるのではないだろうか。

自分の車(1999年のボルボ)が何度も電子スロットル故障で苦労したのでその構造についてはだいぶ勉強したのだが、最近は軽自動車でさえ電子スロットル装着の割合が多いようなので、折角だからそれを利用すれば既存の車両で事故軽減オプションがついていないものでも簡単に実現できるように思ったので、着想のみのアイディアとして書いてみようと思う。

たとえば、http://www.ebay.com/bhp/waterproof-ultrasonic-sensor で$7.28で販売されている防水の超音波式測距センサーを車の前後にとりつけて、マイコン基板(たとえばRaspberry Pi)で車両前後の距離を監視する。

ultrasonic
最大4.5mまで測れるセンサー 7.28ドル

あとは、アクセルペダルのセンサーの信号線を制御する仕組みを追加し、車両前後の障害物までの距離が設定値以内であれば、アクセルを踏んでも全閉時の抵抗値(または電圧)を維持するようにし、さらにブザーでも取り付けて”ブーー!”と音がすれば、クリープでのろのろ走りながら自分が間違ってアクセルを踏んでいることに気づけるのではないだろうか。

アクセルペダルのセンサーに制御を割り込ませる製品はすでに数多くの会社が”スロットルコントローラー”のような名称で出しており、車種別の専用ハーネスなんかも出ているので、それを流用すれば自作でもそう難しくなさそうである。

スロットルコントローラは、アクセルペダルを踏む量と電子スロットルが実際に開く量のカーブを少し変化させ、少し踏んだだけで電子スロットルをガバっとあけて車が早くなったように錯覚させる機能を持つものと理解しているが、その錯覚のために何万円も出すより、自分の足でアクセルペダルを多めに踏めば結局同じだと思われ、それだけの機能ではもったいない気がする。 数多くの車両のアクセルペダルセンサーの配線に関する情報をもっている会社であれば、障害物センサーとの組み合わせもいとも簡単に実現できると思うのだがどうだろうか。

試しに自分の車で試作品を作ってみたいと思うのだが、なにしろフィリピンの郵便事業会社が駄目すぎて、海外からパーツを購入しても届かないか法外な関税をかけられるかでえらい面倒くさいのがネックである。

 


アメリカンなプロバイダcox

先日、アメリカ在住の方からお問い合わせのメールをいただいたので、当日の朝に返信を差し上げておいた。

しかしその5日後、メールが不達になった旨の通知が自分が利用している日本のプロバイダ(ASAHIネット)のメールサーバーから届いた。

<*****@cox.net>: host mx.west.cox.net[68.6.19.3] refused to talk to me: 554
fed1rmimpi110.cox.net cox 202.224.39.197 blocked.  Error Code: CXBL – Refer
to Error Codes section at
http://postmaster.cox.net/confluence/display/postmaster/Error+Codes for
more information.

相手先プロバイダのメールサーバー mx.west.cox.net が送信元のASAHIネットのメールサーバー 202.224.39.197からの通信を拒絶している、というもので、エラーコードはCXBLとのこと。 上記リンク先でCXBLを調べてみると

The sending IP address has been blocked by Cox due to exhibiting spam-like behavior (送信元IPアドレスはスパム的挙動のためにブロックされている)

とのこと、どうすればよいかの説明がその横にあって

Submit a request using the contact form here. The request will be reviewed by Cox. Cox has sole discretion whether to unblock the sending IP address. (このコンタクトフォームを使ってリクエストを送信せよ。 リクエストはCoxによって検討される。 Coxはブロック解除するかどうかの独占的な決定権がある。)

だそうで、そのリンクを開いてこちらのメールアドレス、氏名、ブロック解除してほしいIPアドレス、理由などを書き込んで送信してみた。 そうしたら、

Delivery has failed to these recipients or groups:

B*******am@cox.com
The recipient’s mailbox is full and can’t accept messages now. Please try resending this message later, or contact the recipient directly.

だそうだ。 B某さんのメールボックスが一杯で受信できない。 再送信するか、受信者に直接コンタクトしてください、だって。 わざわざ時間をかけて入力して送信したのに。

随分前にもアメリカのプロバイダをお使いの方とのメールのやり取りで、同じようにブラックリストで受信拒否しているメールサーバーがあって苦労したことがあったが、大勢が利用しているプロバイダのメールサーバーのIPアドレスをブロックしてしまうと、そのプロバイダの利用者(今回はASAHIネット)は相手(今回はcox.com)にメールを送信できず、送信に失敗したことがわかるのも5日後になるという理不尽な状態になってしまう。

しかもブロック解除のリクエストを受け付けるフォームからの送信も届かないとなると、解決方法はこちら側で別のメールアドレスを使うしかないのだ。

世の中にいろいろなスパム防止の方法があるが、必要なメールを受け取れなくなってしまう可能性が少しでもあるなら、いくらスパムを削除する効果が高くても全く駄目なシステムだと思う。 そんな方法は、なにかアメリカンな印象である。