湿度に弱い部品はベーキングしないとだめ!

電子部品というのは金属だとかプラスチックなので、湿度がどうこうなんて普通の人は考えないと思います。

しかし、じつは湿度を吸収してしまうのです。

湿度を吸収した状態でなにが問題になるかというと、加熱した時に水分が膨らんで部品を壊してしまうのです。

加熱とはどういうときか?

 

部品を実装するときです。

 

ということで、部品には「MSL(Moisture Sensitive Level)」が記載されています。

レベル1のものはほとんど気にしなくていいのですが、レベルが上がるごとにどんどん厳しくなっていきます。

レベル1以外のものは実装する前に「ベーキング」といって軽く加熱して湿度を飛ばす作業が必要になります。

 

例えば、抵抗だとか積層セラミックコンデンサだとか、こういうものはMSL1なので気にしなくて大丈夫です。

それから、ロジックICのような小さなICもだいたい大丈夫です。

違ってくるのは、

・CPUやメモリのような大きな部品

・LED

などです。

 

部品が大きくなると湿度を沢山吸湿するので、MSLのレベルが上がってきます。

そして不用意に実装ラインに入れると割れて壊れます。

 

ということで、MSLレベルはきちんとチェックしないと面倒なのですが、幸い一目で分かる点があります。

部品の包装です。

 

抵抗や小さなICなどは紙テープやプラスチックテープにぞんざいに貼り付けてあるだけです。

しかし、MSLレベルが高い部品になると、CPUでもメモリでもLEDでも、必ずアルミコーティングされた容器に入っています。

この容器から出してすぐに実装すれば問題ありませんが、容器から出してしばらく放置すると「ベーキング」が必要になります。

 

ということで、アルミ包装の部品があったら「MSL」について確認してベーキングを確実に実施するようにしましょう。

 

以上、小田切でした。

組込みソフトウェアではオブジェクト指向は使えない?

自分はもともとソフトウェア専攻だったこともあり、

 

「C++やJavaなどのオブジェクト指向最高! 複雑な構造のプログラムでも抽象化してうまく設計できる! Cとかごちゃごちゃになりやすい言語なんてくそだ!!」

 

と思っていました。

だって、オブジェクト指向では綺麗につくれるプログラムも、非オブジェクト指向で作るとデータと関数がごちゃごちゃになってわかりにくいんです。

 

ところが、組み込みの方の世界に入ってみると皆C言語で書いていました。

 

「なんて遅れているんだ!」

 

とその時は思いましたが、それなりに理由があるのです。

 

1,開発者がC言語に慣れている

組み込みでは長い間Cが使われているので、皆慣れています。

逆にC++は使い慣れていない人が多いです。

 

2,過去の資産がC言語

C言語の資産があると、C言語で開発するのが楽です

メーカが提供しているのもC言語のライブラリだったりします。

 

3,メモリが限られている

これがある意味一番の制限です。

オブジェクト指向など、昨今のプログラミング言語はメモリを大量に使います。

開発しやすさなどを優先して、メモリを多少無駄に使っても気にしないというスタイルです。

PCやスマホ、あるいは数百MBのメモリが載っているLinuxボードならそれでもいいのですが、

プアな組み込み環境だとメモリが数kBしかありません。

こうなると、インスタンスを作る度にメモリを確保するようなオブジェクト指向言語を動かすことは非現実的です。

 

とまぁ、このように、今でもC言語で開発をするのが現実的なのです。

昔の自分のように「オブジェクト指向じゃないなんて!」と怒らないようにしてください(笑)

 

以上、小田切でした。

データシートとアプリケーションノートの違い(初心者向け)

CPUなどの資料を取りにメーカーのサイトに行くと、文書がたくさん並んでいます。

・データシート

・エラッタ

・アプリケーションノート

・ユーザーガイド

etc

 

一体何が違うんだ、どれを見ればいいんだ、となると思うので、ざっくり説明したいと思います。

 

データシート

対象:ハードウェア開発者

データシートは基本となる文書ですが、そのデバイスの全容を網羅的に書いています。

・電気的特性

・中身の構成

・ピンの並び順

etc

一部ソフトウェア開発者が見る部分がないこともないですが、ほとんどハードウェア的なことを書いてあります。

これを読むことで、ハードウェアの概要がわかります。

 

 

エラッタ

対象:ハードウェア開発者&ソフトウェア開発者

半導体製品にもソフトウェアと同じようにバグが有ります。

そのバグを説明する資料です。

 

 

アプリケーションノート

対象:ハードウェア開発者&ソフトウェア開発者

データシートは淡々と特性や中身の説明している文書ですが、

「私はこのCPUを使ってUSB通信をしたいのですが実際にどうやればいいんでしょう」

みたいなことには答えてくれません。

そこで「こういう機能はこうやって使ってね」「こういう設計するといいよ」みたいな手引書がアプリケーションノートです。

自分が実現したい構成に近いアプリケーションノートがあればラッキーです。

アプリケーションノートは、ソフトウェアとハードウェアの両方について書いて有ることが多いです。

役に立つアプリケーションノートがない場合、手引無しで作ることになるので苦労します。

 

ユーザーガイド

対象:ソフトウェア開発者

アプリケーションノートは機能別に手引をしてくれますが、ユーザーガイドはさらに噛み砕いた文書です。

「開発環境のインストール方法」「デモボードの使い方」みたいなことを説明しています。

極端な話、ユーザーガイドで書かれていることは専門家でもなくてもできます。

(手順通りにやればいいだけで、ほとんど知識がいらないので)

 

 

と、こんな位置づけになっています。

 

デバイスを選定するときには、データシートで判断して選んで、

実際に回路設計するときはアプリケーションノートとデータシートを交互に見て、

基板ができてソフトウェア開発するときには、ソフトウェア開発者がユーザーガイドを見ながら開発環境をセットアップする……というような流れです。

 

以上、小田切でした。

適当に製品作っても売れませんよ

回路設計とはちょっと違うけど閑話休題的に。

 

自分が勤めていた会社でも自社商品というのを作っていました。

ボチボチ売れたものもありますが、ほとんど売れないものもありました。

というか全体的に見て、開発にかけたコストを回収できてないと思います。

 

なんでそんな風になってしまったのでしょうか。

どうも、「こういう製品を作ろう」と営業だとか役員が考えて作ってしまうのが原因のようです。

逆にある程度顧客になりそうなところにヒアリングして作ったものは、まぁまぁ使われました。

 

つまり、潜在顧客の意見を聞いて作ったものはよくても、こちらが思い込んで作ったものは駄目だったようです。

考えてみれば当たり前ですが、世間で流布している俗説などが悪い気がしています。

名経営者の伝記などで「世の中の人に調査しても新しいものは生まれない。新しい需要を作り出すつもりで新しいものを作れ」的な事が書いてあります。

これを信じれば、思いついた製品を作るのは悪くないように思えてしまいます。

 

なにが間違っているんでしょうね。

 

第一に、企画の本気度が違うんだと思います。

ホンダの創業者の伝記でも「俺はこれを作るんだ!俺はこれを信じているんだ!」みたい熱いパッションで作っています。

ですが、世の中の企画というのは「まぁ、こんなもん作れば売れるんじゃないかなぁ。別に自分はそんなに思い入れ無いけど」みたいなのが多いわけです。

これだけ本気度が違えば失敗するでしょう。

 

第二に、実際の開発ではほとんど新しい物を作ってないということです。

高度成長期に全く新しいジャンルの製品(ウォークマンとか)を作っていればたしかに新しいです。

これはリサーチしても作れない製品だったと思います。

しかし、世の中の殆どの企画というのは類似品があるわけです。

すでにある商品とちょこっとだけ違うものを作っているだけなんです。

だったらリサーチできるので、リサーチを活用したほうがいいですよねって話。

 

とまぁ、こんな感じで、伝説になっているような製品の開発の話というのは特例だと思うんです。

すべての製品の開発でそんな考え方をしていてもうまくいかないと思うんですよね。

なので、「人生をかけていない製品」「類似品がある製品」だったら素直に潜在顧客の意見を聞いてニーズに合わせて開発したほうが上手く行くと思います。

 

まぁ、人生をかけているような熱い製品が見つかれば、そのパッションで貫いちゃってもいいかもしれません。

 

以上、小田切でした。

ハードウェア開発者にプログラミングの知識は必要?

たまにハードウェア開発もその上のソフトウェア開発も全部やるという人が居ますが、普通は別々の人が行います。

そんな立場のハードウェア開発者がプログラミングの知識が必要か?という話題です。

 

いきなり、結論。

ある程度は必要

ある一定以上があると便利。

 

◯必要な部分

ハードウェア開発者というのは特に組込系になると、ソフトウェア開発者と密なやり取りをします。

その時に「え、なにそれ?」状態では話が進みません。

プログラミングの基本的な知識は絶対に必要です。

変数や関数、割り込み、スタック、等の知識は必須です。

なので、教科書的な用語の意味を知った上で、チュートリアル程度でもいいのでC言語でプログラムを書いて動かすという経験があるべきです。

 

◯便利な部分

ハードウェア開発では部品表だとか、アートワークで提出されるデータだとか、結構大量のリストを扱います。

基本はテキストファイルです。

ハードウェア開発では、時に大量のリストを照合したりコピペしたりといった作業が発生します。

しかも、同じような作業が何度も発生します。

そういったときに、テキストファイルをちょちょっと処理できるプログラムが書けると効率が劇的によくなります。

ということで、rubyやperlなど、テキストを簡単に使えるスクリプト言語を扱えると非常に楽になります。

あとはEXCELのVBAも扱えると更に便利です。

 

ということで、ハードウェア開発者だからといってプログラミングを避けずに勉強しましょう!

 

以上、小田切でした。

信頼性試験の基準ってどうやって決めるのか?

またもや信頼性試験ネタ。

温度をかけたり、落としてみたり、静電気かけてみたりと、いろんなことをやるのが信頼性試験ですが、自分で決める立場になると難しいものです。

いったい、信頼性試験の中身やレベルってどうやって決めるんでしょうか。

 

開発を受ける立場で「こういう試験をやってくれ」と言われて実施するなら困りませんが、決める方になると途方に暮れます。

 

そもそも、信頼性試験の立場は法律でもなんでもありません。

電波法やPSEなど法律と関係する試験もありますが、ほとんどの信頼性試験は法律と全く関係ありません。

また、信頼性試験の様々なことがJISで定められていますが、JISは規格であって法律ではありません。

だから、「これをやればOK」みたいな絶対的なものがありません。

 

つまり、信頼性試験というのは「業界慣例」だとか「会社のリスク回避」でしかないのです。

極端な話、電波法などが関係する部分以外はやらなくても法的な問題はないのです。

実際の所、信頼性試験なんてほとんどやらないで出荷してしまうとこもあります・・・

 

さすがに全くやらないのは危険ですので、やるべきです。

全く確認ができてないわけですから、出荷した途端にトラブルが多発してしまいます。

もしその製品の業界で基準となっているものがあれば、そのレベルの試験をしたほうがよいです。

もしそういったものがないときは、実際に扱われる場面を想定して試験の基準を決めないといけません。

ここの話は大変なのでいつかそのうち・・・

 

以上、小田切でした。

静電気イミュニティ試験の基準

ESD試験の基準はだいたい他所からの要求で決めるものですが、自分で決める立場になると決めるのが結構難しいです。

そうしたら、なんかいい表を見つけてしまいました。

ネット上にあるものではないので、内容だけ紹介します。

 

これはあくまで目安なので、参考程度にお願いします。

これを基準にどこまで厳しくするか、という考えでよいように思います。

 

試験対象
機器
接触放電 気中放電 間接放電 判定基準
家電
照明
商業・軽工業
工業
4kV
10回
8kV
10回
4kV
10回
B
情報機器 4kV
25回
8kV
10回
4kV
25回
B
医療用 2,4,6kV
10回
2,4,8kV
10回
6kV
10回
B

 

以上、小田切でした。

静電気対策の方法

信頼性試験で実施する静電気試験ですが、試験のためだけでなく実際の現場でも静電気は飛ぶので、この対策は非常に重要です。

ということで、代表的な静電気対策を簡単に列挙したいと思います。

 

◯電源

まずは電源です。

電源は静電気だけでなく雷サージなどもあるので、高電圧の対策は必須です。

そして、この部分は逆刺しの可能性も考慮して、双方向の高電圧保護部品である「バリスタ」を使用することが多いです。

普通のツェナーダイオードですと電源逆刺しの際に、ツェナーダイオードに大電流が流れて破損してしまいます。

 

◯インターフェース部

コネクタ類です。

コネクタに人が触れる場合などに静電気が飛んできます。

なので、インターフェースの各線にはツェナーダイオードかクランプダイオードを入れます。

普通のデジタル信号線には負電圧が入ることがありませんので、双方向の保護素子であるバリスタは必要とされません。(使ってもわるくないけど)

ツェナーダイオードはGNDと信号線の間に入れ、ツェナーダイオードの降伏電圧以上の電圧をGNDに逃がすようにします。

クランプダイオードは、「信号線とGND」と「信号線とVCC」に入れ、VCC以上またはGND以下の電圧をGNDやVCCに逃します。

 

◯人が触れる部分

スイッチなどです。

ここもツェナーダイオードかクランプダイオードを入れます。

 

◯基板外周

基板はたいてい筐体に入りますが、筐体の隙間から静電気が入ってくることが有ります。

なので、基板の最外周に部品があるとそこに静電気が飛んだ時に部品が壊れてしまいます。

最外周をGNDにしておくことで、筐体の隙間から飛んできた静電気がGNDに逃げるようにします。

 

◯ネジ穴周辺

ネジ穴も静電気が飛んでくる場所です。

なので、基板に開いているネジ穴の近くにGNDではなく部品があると、部品を壊します。

ネジ穴はまずGNDを置いて、そのまわりに部品を配置します。

 

◯金属部は部品から離す=GNDに接続する

金属がある製品だと、静電気はまず金属に飛びやすいです。

なので、金属の近くに部品があるとそこを静電気が通ったときに部品を壊します。

金属はGNDに接続するなどして、静電気が部品を通らないように配慮します。

 

代表的なところではこんなところでしょうか。

 

以上、小田切でした。

静電気イミュニティ試験について

信頼性試験の一つである静電気イミュニティ試験について簡単に解説します。

 

イミュニティは「電気的ストレスに耐えること」なので、「静電気ストレスに耐える試験」ということになります。

つまり、静電気で壊れないかを調べるための試験になります。

 

まず、静電気を発生させるための装置と、その静電気を製品にかける「ガン」がセットになった機材を使用します。

試験者はそのガンを製品に当てて静電気をかけることになります。

 

製品を稼動状態にした状態で静電気をかけていき、都度正常動作するか確認をしながらすすめていきます。

 

◯接触放電

金属部に人の手が触れたときを想定する試験です。

ガンに尖った電極をとりつけ、電極を金属部にあてて直接静電気を打ち込みます。

 

◯気中放電

非金属部に人の手が触れたときを想定する試験です。

この試験では、先が丸くなっている電極をガンに取り付けて試験を行います。

まず製品からガンを離した状態でガンの引き金を引いて、電極に帯電させ、その状態ですばやく試験部に近づけます。

こんな方法の試験なので、「どの程度離して引き金を引くか」「試験部に近づける速度が早いか遅いか」で結果が大きく変わってしまいます。

つまり、この試験は、試験する人の癖で結果が結構変わります。

 

◯間接放電

製品の横に10cm離して大きな金属板(470kΩでグランド接続)を置き、そこに静電気を印加する試験です。

変な試験ですが、直接静電気をかけても正常なのに、近くで静電気が流れると動作不良を起こす機器があるそうです。

そういった場合を想定した試験です。

 

さらっと説明しましたが、細かいことを知りたい方は「IEC61000-4-2」で調べてみましょう。

 

以上、小田切でした。

落下試験は結構きついよ!

信頼性試験の中で「落下試験」というものがあります。

その名の通り、製品をコンクリートの上に落下させて、破損・機能異常がないかを確認する試験です。

 

詳しくは「JIS C 60068-2-31」を参照するといいです。

JISの公式HPに行って、上記型番で検索すれば無料で閲覧できます。

(印刷はできない)

 

さて、落下試験なのですがぶっちゃけかなりのものです。

1kg以下のものですと、(JIS推奨では)1mの高さからコンクリートに落とすことになります。

 

まず筐体が頑丈な必要があります。

簡単なツメで止めてある程度ではまず開いてしまいます。

ツメで引っ掛けるなら相当頑丈にしないといけません。

 

次に基板です。

普通の部品はそれほどダメージをうけませんが、重い部品がついていると根本にダメージが来てしまいます。

背の高い部品・重い部品がある場合は、ネジ止めやシール材の塗布など固定を強化する必要があるかもしれません。

 

今回、私のケースでは、基板間コネクタで取り付けてある小基板が吹き飛びました。

まぁ、そんな衝撃想定していない基板だったので壊れて当たり前なのですが……

さらに両面テープで止めても取れてしまうという状況でした。

基板間コネクタの両端でネジ止めしておくぐらいの想定をしないと1mの落下は耐えられないようです。

(筐体にゴムなどついていればマシなのかもしれませんが・・・)

 

ということで、落下試験を考えて事前に設計ができるといいですねぇ……

 

以上、小田切でした。