評価技術」タグアーカイブ

ソニー製パソコンに異常発熱の恐れ 44万台無償修理

 ソニーは4日、ノートパソコン「バイオ TZ」シリーズの一部機種で異常発熱の恐れがあるとして、発売済みの44万台のうち顧客から申し出があった分を無償で点検、修理すると発表した。不具合が確認されたのは全世界で209件(うち国内が83件)。全体で軽度のやけどが7件報告されているという。

 ソニーは2007年8月には顧客から指摘を受けて、問題を把握していた。ただ、経済産業省への報告は今年8月だった。公表まで1年かかった理由について、同社は「不具合の調査に時間がかかったため」としている。

(NIKKEI。NETより)

 ネット上の情報から推測すると、ノートPCの液晶ディスプレイへの配線(フレキシブルPWB)がヒンジの開閉により徐々に絶縁層が磨耗し線間がショート、発熱するという故障のようだ。

当然稼動部分なので、そのような故障モードは当初から予測できるはずであり設計配慮はしてあったはずである。又耐久試験なども実施して問題がない事を確認してあるはずである。
それでも事故が発生した。なんらかの問題があったと考えるべきだ。

  • 製造的な問題
    設計的な弱点と製造的なばらつきが重なって事故が発生。
    事故品が設計仕様どおり作られていたのかどうかはわからないが、設計余裕がないところに製造上のばらつきが加算され、事故が発生。または製造の工程能力を超えた設計仕様が指定されていた可能性もある。

    当然設計的に製造余裕度を確保することは重要だが、高機能かつ小型という時代の要請は十分な設計マージンを確保できない場合もある。

    特に今回のように工程内検査で見つからない故障モードに関しては、きちんと工程FMEAを実施して事前に対策を打っておかなければならない。
    稼動部分の磨耗が与える故障モードの影響をきちんと評価をすれば、何らかの対策を打たなければならないという結論がでたはずである。

  • 設計妥当性評価の問題
    当然設計妥当性評価の項目には、寿命評価も入っていたはずである。
    その評価基準が妥当であったかどうか検証をしなくてはならない。これは外部からは知る由もないが、自社製品に水平展開をするために考察をしておく必要がある。

    寿命試験の基準を、製品の使われ方できちんと決定しなければならない。
    ノートPCの寿命を100年と想定して評価基準を作成するのは妥当ではない。
    長持ちをする製品を出荷するのも企業の責任であるが、消費者が受け入れられる価格で製品を販売するのも企業の責任である。

    例えばノートPCの使い方を、職場とオフィスで同一のノートPCで仕事をすると考える。
    そうすると始業時に一度PCを開き、昼休みの前後に開閉、就業時に閉じる。自宅に戻ってもう一度開閉。という使い方を想定、3年間のPCが毎日使われるとすると、3×365×3回=約3000回の開閉が行われるわけである。それに安全係数をかけて評価基準が決定される。

    しかし事故モデルのような小型ノートPCの場合、客先に持ち込んでプレゼン、移動中での使用等があるはずであり、一日3回の開閉ではすまないはずである。

    又寿命評価は材料の耐久性仕様から机上検討すべきではない。今回のようなアプリケーションでは本体との干渉が影響を与えるはずであるから実機で開閉寿命テストをしなければ、妥当性の評価をしたことにはならない。
    フレキシブルPWBの屈曲モードが、ヒンジ部分の磨耗により単純な屈曲ではなくなる可能性もある。

いずれにせよ、安全事故に関連する故障モードに関しては事前に評価をし対策を打っておくべきである。


このコラムは、2008年9月8日に配信したメールマガジン【中国生産現場から品質改善・経営革新】第50号に掲載した記事です。

【中国生産現場から品質改善・経営革新】は毎週月曜日に配信している無料メールマガジンです。ご興味がおありの方はこちら↓から配信登録出来ます。
【中国生産現場から品質改善・経営革新】

購入部品の評価

 購入部品の評価が難易度を増している。
昔ながらの部品であれば、部品サンプルで機能や品質を技術的に評価する。
そしてその品質、納期、コストを保証出来る事をベンダー監査により確認する。
この手順で購入部品の評価が出来る。

しかしモジュール部品の場合、機能の大部分は組み込みソフトで実現している。従って、伝統的な購入部品の評価手法だけでは十分とは言えない。
製品の高機能化、小型化が進み、この様なモジュール部品を外部調達する比率が増加しているのが現実であろう。言って見れば自社にないソフトウェア技術を部品として購入している訳だ。

では、自社にないソフトウェア技術をどのように評価したら良いのだろうか?
「バグはもう一つある」というのがソフトウェア業界の常識の様だ(笑)
ベンダーが設計したソフトウェアの信頼性を評価する事は、ほとんど不可能だ。しかもベンダーが組み込みソフトのソースコードを公開するとは思えない。組み込みソフトのコーディング検証が出来るのならば、自社で作ることが出来るだろう。

モジュール部品の検証は「入力」と「出力」を漏れなく洗い出し、全ての入力の組み合わせに対して正しい出力が得られる事を検証することになる。組み合わせだけではなく、タイミングや状態の遷移も検証対象となる。

この様な設計検証がベンダーで正しく行われている事を確認する。
自社製品に組み込んだ場合の検証をユーザの立場で行う。これを妥当性評価という。妥当性評価は自社で実施しなければならない。

妥当性評価を実施する場合、評価計画を事前に作成する事が重要だ。
モジュール部品が完成品に与える影響の致命度により順位付けをし、評価項目、評価順序の計画をあらかじめ作成して評価する。計画を作っておかないと、評価漏れや、重要ではない項目の評価に時間が取られ、評価作業が泥沼状態となる。


このコラムは、2016年9月26日に配信したメールマガジン【中国生産現場から品質改善・経営革新】第495号に掲載した記事に加筆修正しました。

【中国生産現場から品質改善・経営革新】は毎週月・水・金曜日に配信している無料メールマガジンです。ご興味がおありの方はこちら↓から配信登録出来ます。
【中国生産現場から品質改善・経営革新】