KLab若手エンジニアの これなぁに?

KLab株式会社の若手エンジニアによる技術ブログです。phpやRubyなどの汎用LLやJavaScript/actionScript等のクライアントサイドの内容、MySQL等のデータベース、その他フレームワークまで幅広く面白い情報を発信します。

2011年06月

温度測定システム[3] 1-Wireのデータ転送

uchikawa-yです。 前回、前々回に引き続き温度測定システムまわりの話をします。 今回はまあ、ハード屋さんです。 個人的にはオシロスコープはテクトロニクス製のアナログオシロが好きなのですが、たとえ買えたとしても普通の家庭では置き場所に困りますよねぇ。今回使ったオシロスコープはUSBでPCに接続して使うタイプのものでした。 DS18B20, DS2480Bを実際使うにあたってはMAXIM社の提供しているデータシート、アプリケーションノート、サンプルプログラムを見るのが最も確実でしょう。特にデータシートなどに記載の実例、サンプルプログラムを真似するだけでもかなりのことができるはずです。 MAXIM社の製品ページDS18B20 MAXIM社の製品ページDS2480B さて、今回の温度測定システムを作り、使うためにはどういう知識が必要だったのでしょうか?
  • ICのデータシートを読む能力
  • 配線材、コネクタ、配線方法、加工方法などの知識(いわゆる工作についての知識)
あたりは置いておくとして課題と解決方法をまとめると以下のようになります。 意図的にネットワーク階層と対応つきやすいように下位のレイヤから書いてみました。完全にきれいに対応するわけではありませんが、DS2480Bはレイヤ1~レイヤ2あたりを担当してくれるデバイスです。これを使用すれば下回りのかなりの部分は知らなくてもある程度はなんとかなります。
1-Wireの電気的特性 DS2480Bが概ね適切に対応してくれる。DS2480Bを使わないならひたすらデータシートを読む
1-Wireのデータ転送条件(タイミングなど) DS2480Bが概ね適切に対応してくれる。DS2480Bを使わないならひたすらデータシートを読む
1-WireのROM Search(スレーブアドレス検出) DS2480Bが半分ぐらい処理。データシートとサンプルプログラムを熟読する
1-Wireシリアル変換器 DS2480Bの制御方法 DS2480Bのデータシート、実例、サンプルプログラムを読む(コピペも可)
温度センサDS18B20の制御方法 DS18B20のデータシート、実例、サンプルプログラムを読む(コピペも可)
シリアルポートの制御方法 perlのモジュール使って逃げた


ただし、数10mの配線を使ったり、センサを20個以上1つの1-Wireに接続するような物理的に厳しい使い方をする場合は結局ドキュメントを熟読する必要が出てくるように思います。

1-Wireのデータ転送

DS2480Bを使うなら「あまり」気にしなくてもいい部分ですが、1-Wireの話をするのにこれがまったく無いのも片手落ちなので書いておきます。なので今回は以降の部分は興味のない人は読まなくてもかまわない内容です。また、網羅した内容ではないので詳細についてはMAXIM社の資料を参照してください。
  • 信号線が1本の双方向非同期シリアルバス
  • 信号線(DQ)はlowレベル:0V, highレベル:ハイ・インピーダンス。外部1箇所で5kΩ程度のプルアップ抵抗を介して3V~5.5Vに接続する(オープンドレイン出力)。
    • マスタ・スレーブすべてのデバイスの出力がAND接続されたものが最終的な出力DQになるとみなせる
    • DS2480Bを使用する場合、DS2480B内でプログラマブルなアクティブ・プルアップ回路が内蔵されているため外部でプルアップは行わない
  • 半二重通信
  • 転送レート 16kbps(標準モード)
  • 100m程度のバス総延長で使用可能
  • スレーブデバイスは実質56bitのアドレス空間を持つ
  • 各デバイスのアドレスは出荷時に決定され変更不可能
通常、バス接続の場合は各デバイスは3-stateの入出力回路を持ち、バスから切り離す(high='1',low='0',ハイインピーダンス状態)ことができるようにしています。1-Wireの場合はハイ・インピーダンス状態と'0'のみを使い、外部でプルアップしています。この回路は、
  • すべての端子がハイ・インピーダンス状態→出力は'1'
  • 一つでも'0'状態の端子があった場合→出力は'0'
ハイ・インピーダンス状態を'1'とみなせば等価的にAND接続されたとみなせます(ワイヤードAND)。このような回路は電気的に高速なスイッチングに不向きですが1-Wireは低速用途に特化して積極的に利用しています。 各デバイスが'1'を出力している場合、他のデバイスから見たり、出力端子を見ている限りはバスから切り離されている状態と区別がつきません。 1-Wireではデバイスの検出(ROM Searchコマンド)など特殊な場合以外は複数のデバイスが同時に出力を行いません。出力をしないデバイスはすべてDQ端子を'1'にします。 ここでは便宜上、マスタからスレーブへデータを送る場合をWrite, スレーブからマスタへデータを送る場合をReadとして1ビットのデータ転送動作を示します。データ転送スロットは必ずマスタから開始されます。マスタがDQを1→0として1μs以上0を続けるとスロットが開始されます。
Fig.1 Writeタイミング


Writeでは全てのスレーブが出力をおこないませんので各スレーブのDQ端子は'1'の状態のままです。従って1-Wire上の最終的な出力結果はマスタの出力状態を反映したものになります。スロット開始から15μs以内にマスタの出力が確定する必要があり、その後45μs以内のどこかの時点でスレーブデバイスがデータを読み込みます。
Fig.2 Readタイミング


Readでは事情が異なります。スロットの開始はマスタ側から行いますが、マスタは1μs以上'0'を出力した後'1'を出力してバスを明け渡します。スロットの後半では出力デバイスが入れ替わり、出力を行うことになっているスレーブデバイスの出力が1-Wireの出力結果になります。マスタはスロット開始15μs以内にデータを読み込むのでこの間はスレーブはデータを保持する必要があります。 以下は実際の8bitのWrite, Read動作を行ったときの1-Wireの波形です。WriteとReadでは動作の違いから波形が異なることがわかります。
Fig.3 8bit Write動作


Fig.3 8bit Read動作


続く!

次はDS2480Bの主要な機能の一つであるROM Searchアクセラレータ(スレーブデバイスの認識、アドレス取得の支援機能)の説明をしようと思います。これは1-Wireデバイスを使う場合に避けられない話題なので今回書くつもりでしたが、続けて書くとかなり長くなりそうなので分けることにします。ではまた次回で。

温度測定システム[2] 測定ソフト, DS18B20, DS2480B

uchikawa-yです。前回に引き続いて温度測定システムの話をします。 忘れていたのですが温度センサDS18B20のスペック等とDS2480Bの機能について何も書いていなかったですね。構成/回路図には名前だけ出ていました。 今回はMAXIM社のデバイスを使用しています。このMAXIM社はアナログ/アナログ・デジダル混在のICに比較的強いメーカーです。他の会社の互換品をオリジナルより高性能にして出したり、他ではなかなか見られないようなユニークなオリジナル製品を作るメーカーです。 まず簡単に動かす方法を紹介して、後は下のレイヤから書いていきましょうかね。

温度測定システムの利用方法

今回作成した測定システムはホストからはUSBシリアルとして見えます。USBシリアル変換チップにはFDTI社のFT232RLを使用しています。FT232用のUSBシリアルドライバが使える環境であれば他にドライバは必要ありません。Perlで測定プログラムを作成してみました。こちらはgithubで公開しています。 https://github.com/uchikawa-y/temper_1w このプログラムではシリアルポートの操作を簡単に行うためにDevice::SerialPortというPerlモジュールを使用しています。 使い方やインストールの方法は上記のURLに置いてあるドキュメントを参考にしてください。 基本的にはperl 5.xとFT232のドライバがあれば動作するはずです。Debian Linux 5.0, FreeBSD 8.1R, NetBSD 5.1(玄箱HG PowerPC), Windows XP(Cygwin上のperl), Windows7(Cygwin上のperl)では動作実績があります。

温度センサDS18B20と1-Wireシリアル変換DS2480B

DS18B20

温度センサDS18B20の主な仕様は以下のようなものです。詳細についてはMAXIM社よりデータシートやアプリケーションノートなど豊富な資料が公開されています。 MAXIM社の製品ページDS18B20
電源電圧 3.0~5.5V
待機電流 750nA TYP(70℃)
動作電流 1 mA TYP(温度測定, EEPROM書き込み時)
温度測定範囲 -55~+125℃
温度測定誤差 ±0.5℃ MAX(-10~85℃)
±2℃ MAX(-55~+125℃)
分解能 9bit~12bit
入出力 双方向非同期シリアル(1-Wire)
パッケージ TO-92 3pin, SOP(1.27mmピッチ) 8pin, μSOP(0.65mmピッチ) 8pin
±0.5℃ MAX(-10~85℃)というのは一般的な半導体温度センサとしては高精度なほうです。サーバ信頼性のための温度測定目的なら無調整で使用できるでしょう。 温度測定時の消費電流が1mAというのは頭に入れておいたほうがいい値かもしれません。

DS2480B

DS2480Bは1-WireをRS-232Cへ変換するICです。ホスト側からはRS-232C経由で各種のコマンドを送り、1-Wireデバイスを制御することができます。1-Wireはバス内に1つのマスタ、複数のスレーブを持つマスタ・スレーブ型の非同期双方向バスですが、DS2480Bは1-Wireのマスタとして動作します。 MAXIM社の製品ページDS2480B データシートに"Serial to 1-Wire Line Driver"とあり、"Line Driver" と言っているところがDS2480Bの本質とメーカーのスタンスなのでしょう。
  • 通信速度:9600bps (default), 19200bps, 57600bps, 115200bps
  • Search ROM(スレーブデバイスのアドレスサーチ)を半自動で行う検索アクセラレータ機能
  • 1-W端子はドライブ能力の高いアクティブプルアップ
  • 2線接続用にstrong pullupに対応
  • 30m以上の長い1-Wireバスに対応するためのスルーレート制御, タイミング制御機能
  • 1-Wireのオーバードライブ(高速モード)に対応
1-Wireの配線総延長が100m程度となるような重い負荷状態への対応として電気的な部分を設定する項目が多数ありますが、今回は電気的な特性にかかわる部分はほとんどデフォルト設定値のままにしてあります。 ソフトウェア側から考えたDS2480Bを使うメリットのうち大きなものは以下の2点です。
  1. 直接1-Wireのバス制御を行う必要がなくなり、1-Wire上のデバイスをRS-232C上のデバイスとして扱うことができる
  2. 1-Wireデバイス(スレーブデバイス)のアドレスサーチ(ROM Search)の処理の一部を2480Bが半自動で行ってくれる
いずれもソフトウェアの負担を低減してくれます。

DS2480Bを使った本当の理由 (1-Wireを使う方法は他にもあるだろう)

前述1.のメリットがあまりに大きいというのがDS2480Bを使用した理由なのですが、少々説明する必要があります。

Linux の1-Wireドライバ

LinuxではGPIO(汎用の入出力端子)を利用して1-Wireバスのマスタ動作をさせるドライバが存在します。これは一般のPC用ではなく組み込み機器用のドライバです。カーネルの構築をするとmenu configの項目に出てくるので知っている人もいるでしょう。しかし、このドライバを使う場合、動作可能なホスト機器(の入手性にやや問題があります。たとえばFonera+OpenWRTでは利用可能でしたが実質的に2100E以外では満足に動作しないようでした(要改造)。

パラレルポートの双方向データ線を使う

一般のPCでも、たとえばパラレルポートの双方向データ線があればそれを利用して直接1-Wireのマスタ動作をさせることは可能です。こちらも試してはみましたが、一般的なPCのハードウェア+Unix/Linux系のOSでは10数μsのレベルの正確なタイミングを発生させる確実な方法が見当たらなかったため、1-Wireのエラーがかなりの頻度で発生したり、使用するPCの機種、OSなどによりパラメータの調整を行う必要があったりしました。 1-Wireのプロトコルは「DQ線をhighレベルにしてから『○○μs以内に必ず』lowレベルにする」というようなハードリアルタイム処理が必要なものであるのでなかなか厳しいです。こういうのはむしろ「H8などの組み込み用CPUボードとITRON」なら楽勝なんですけどね。

結論

測定用のホスト機種や条件で調整する必要があるというのはなかなか使い勝手が悪いので、それならいっその事ハードウェアに任せてしまえ、というのがDS2480Bを採用するに至った理由です。おかげでUSB-シリアル変換器に使ったFT232RLのドライバさえあればハードウェア/OSを問わず動作する汎用性の高い温度測定器になりました。

続く!

今回は測定ソフトウェアと使ったデバイスの紹介をしました。 1-Wireの動作や制御ソフトを作る場合の留意点、そのほか諸々のことにはまだ触れていませんので次はそのあたりを書いてみたいと考えています。 次もやっぱり低レイヤな話が多めになると思います。

FlashLiteなコンテンツをHTML5に移植してスマートフォンでも見れるようにした (2)

ソーシャルゲームをスマートフォン向けに出している企業も増えてきました。見ているとWallabyによる自動変換+手作業派とFlashをタッチ対応してAndroidだけ出す派の2派が多いようですね。弊社のアプリでも、Wallabyは真・戦国バスター、Flashのタッチ対応はトイボットで使われています。 あとWallabyとは別のやり方で自動変換を試みたものもあります。 そんな中、愚直に移植を試みるのが、いま紹介している方法になります。 そんなわけで、移植担当のosuga-hです。 FlashLiteコンテンツをスマートフォンに移植する話の続きです。 今回はflaファイルから見た目の部分をHTMLに起こしていく作業にフォーカスして、どんな作業をしたのかをより具体的に説明したいと思います。

前回のあらすじ

  • FlashLiteコンテンツをスマートフォンにも!
  • flaファイルからHTML5にしてみた時の作業の流れを紹介
  • 他にもいろんな人がいろんな工夫してやっている
 

宣伝

諸事情で解説記事なのに画像がないのですが、紹介している方法で移植したものがリリースされました。 代わりに参考になればと思います。

真・戦国バスター

http://pf.mbga.jp/12004957 http://sp.pf.mbga.jp/12004957 (スマートフォン向け)

トイボットファイターズ

http://pf.mbga.jp/12001717 http://sp.pf.mbga.jp/12001717 (スマートフォン向け) ※iPhone版のみHTML5移植

Flashの画面を移植していく

このフェーズが一番職人芸になりがちなポイントで、後の工程の効率にも影響してきます。 Flash/CSS両方に詳しい人が有利です。 逆にFlash/CSSに詳しくない人はここが一番の山場で、ここさえ終わればあとは簡単な山場しかないです。 まずはロジックより先に、「画面」の移植をしていきます。 JSを書くフェーズでも修正が入る箇所なので、無理に完全再現する必要はありません。

今回の目次

概要

  1. 動いているものを見る(概要把握
  2. flaファイルを見る(実装計画
  3. 準備(心の準備
  4. 素材のエクスポートとコーディング(png出力とHTML+CSSの記述)
  5. 補足

付録(のクセに長い)

  1. png画像の出力方法
  2. HTMLとCSSの記述に関して

1. 動いている物を観察して、全体の流れをイメージする

漠然と「場面」と流れがつかめればOKです。

ex1) とあるゲームの場合

  • ヘッダとフッタがあってゲージが動くんだなぁ
  • イベントがあるとカットインが入るんだなぁ
  • 最後は読込中が出て終わるんだなぁ

ex2) また別のゲームの場合

  • キャラが出てきて一言いうんだなぁ
  • キャラの紹介ダイアログが出るんだなぁ
  • ゲーム始まる前の状態で待機だなぁ
  • ヒットの度合いで演出が出るんだなぁ
  • 星が飛ぶなぁ
  • タイマーがあるなぁ
  • 時間切れで終了状態になって待機だなぁ

2. Flashでflaファイルを開く

1. で掴んだ流れがどのように実装されているのか「具体的に」確認して認識とのズレを埋めていきます。 特にチェックするのは、重ね順(レイヤー)と入れ子(ムービークリップ)で、HTMLで再現が難しそうなところが無いかなどチェックしていきます。 再現が難しい点を思いつく限り上げると、、、
  • 複雑なマスク操作(マスク自体がアニメーションしてるなど)
  • ガイドレイヤーによるアニメーション
  • 1コマずつ手動で調整されているアニメ(パラパラ漫画系)
  • ムービークリップの入れ子が深い
この辺は思い切って省略していくことも考えます。 慣れてくるとこの辺で全体の作業や、コーディングの方針が見えます。

3. 作業用のディレクトリを切って、気合を入れる

この辺りから作業を開始します。 対象のflaファイルを、適当な作業用ディレクトリに放りこんで ターミナルから vim index.html を華麗に実行します。 華麗に実行してください。 ここからは vimとFlashとSafariを何度も往復します。 ※vim のところは適宜「エディタ」と読み替えてください

4. flaファイルから素材を切りだして配置

flaからpngに変換しつつ、HTMLにタグとCSSを追加していきます。 付録2の移植方法が基本ですが、往々にして職人芸です。現状では慣れるしか無いです。 この工程で第一段階は終了です。 個人的な好みですが、先に必要な画像を全部吐くのではなく、 画像を吐く → HTMLを書く → Safariを更新 → 画像を…。 と繰り返した方が良いです。 吐き出す画像の選択ですが、背景など重ね順的に下な物や、適当なUIのグループ(例えばヘッダーとか)から着手してます。 具体的なコードの書き方やpngの出力方法は後述します。

補足

アニメーションはこの時実装しませんが、どのように実装するのかは考え始めます。 逆に実装が楽になるようにHTML+CSSを組めると効率が上がります。 ex) 経験値ゲージは-webkit-transform:scale( 現在の経験値/MAX経験値 , 1 ); かな ex) 途中から出てくる要素は初めopacity:0で必要になったらopacity:1かな また明らかにJSからアクセスするHTML要素にはidをバシバシ振っていきます。

まとめ

JS移植最初のステップはHTML+CSSによる画面の再現をしました。 この段階でJSの動的な部分まで考えて置けるとより良いでしょう。 今回は以上です。

付録

付録1. pngの出力方法

大元の素材を使ってもいいのですが、flaに配置されているものはFlash内でエフェクトが加えられていたり、サイズの調整が行われていることが多いのでFlashからエクスポートしています。
  1. 画像にしたいオブジェクトをコピー
  2. 新規ドキュメント作成
  3. 1. でコピーしたものをペースト
  4. ペーストしたものを選択
  5. ALT+F ALT+E ENTER で画像出力ダイアログを出す
  6. 適切なファイル名を英数字で付ける
  7. 範囲をイメージサイズ、カラーを24ビット(必要に応じてアルファチャンネル付きで)
  8. (optional) 外部画像編集ツールで調整。(余分な余白を落としたり)

付録2. HTMLとCSSの書き方について

Flash上で移植する要素をクリックすると幅、高さ、座標などCSSに記述するための数値が確認できるのでそれを見ながらCSSを記述していきます。 基本的には対応するCSSプロパティに記述するだけです。
Flashのプロパティ CSSのプロパティ
x left
y top
width width (scaleが設定されている場合はscaleが1の状態でのwidth) ※1
height height (scaleが設定されている場合はscaleが1の状態でのheight)
scale -webkit-transformプロパティの値にscale(x,y)
rotate -webkit-transformプロパティの値にrotate( R deg ) degは単位
画像 background-image:url( PATH/TO/IMAGE.png )もしくはimgタグ
※1 width, height, scaleは対象にアニメーションが設定されていないか、scaleが変化しないアニメーションが設定されているとき、scale適用後の幅と高さをCSSに記述しても構いません。その時CSSにscaleを設定する必要はありません。 この作業をサポートするFlashHTML5Panelというものを作ったので利用してください。 大した機能はないですが、それでも役に立ちます。

iPhone4はtouchstartイベントのevent.targetにTextNodeもセットされる

どうもosuga-hです。 イベントハンドラの引数のtargetプロパティには必ずHTML要素が代入されるように実装されていることが多いですが、 iPhone4ではTextNodeも対象となるように実装されているようです。 おとなしくevent.currentTarget使ってればこんなことにはならないんですけど、予想外の挙動だったことは間違いないんで、紹介したいと思います。

問題となったコード断片

 1 <div id="menu1">menu1</div>
 2 <div id="menu2">menu2</div>
 3 <script type="text/javascript">
 4 var menu1 = document.getElementById( "menu1" ),
 5     menu2 = document.getElementById( "menu2" );
 6 
 7 menu1.addEventListener( "touchstart" , onTouchStart , false );
 8 menu2.addEventListener( "touchstart" , onTouchStart , false );
 9 
10 function onTouchStart ( event ){
11     menu1.removeEventListener( "touchstart" , onTouchStart , false );
12     menu2.removeEventListener( "touchstart" , onTouchStart , false );
13 
14     var target = event.target ;
15     if( target == menu1 ){
16         //menu1の処理
17     }else{
18         //menu2の処理
19     }
20     //画面が遷移する
21 }
22 </script>
#menu1も#menu2も中にテキスト以外の要素を持っていないから、event.targetはいつも同じになるだろうという予想の元にこのようなコードを書いていました。 ところがiPhone4でmenu1をクリックしたにもかかわらずmenu2の処理が走るという問題に遭遇したのです。

原因

原因は冒頭でも述べましたがiPhone4の場合テキストを"タッチ"するとtargetにTextNodeが渡されてきます。 このため#menu1をクリックしたとしても target != menu1 となり、menu2の処理が走っていました。 以下は検証用途のコードです。
 1 <div id="elem1"> |←壁の向こうと、こっち側でevent.targetの内容がちがう→|</div>
 2 
 3 <style type="text/css">
 4 #elem1 {
 5     padding:20px;
 6     text-align:center;
 7     border:1px solid #000;
 8 }
 9 </style>
10 
11 <script type="text/javascript">
12     document.getElementById( "elem1" ).addEventListener( "touchstart" , function ( event ){
13        alert( event.target );
14     } , false );
15 </script>
テキストの上をタッチすると 余白をタッチすると touchstart , touchmove , touchend全てでTextNodeが渡ってきました。 んーclickイベントでは渡ってこないから、たぶんバグだけどW3C的には問題ないと言えば言えないこともない実装・・・。

解決

このケースでは問題を回避するのは簡単です、EventオブジェクトのcurrentTargetプロパティを使います。 currentTargetにはaddEventListnerした要素が渡ってきます。
 1 <div id="menu1">menu1</div>
 2 <div id="menu2">menu2</div>
 3 <script type="text/javascript">
 4 var menu1 = document.getElementById( "menu1" ),
 5     menu2 = document.getElementById( "menu2" );
 6 
 7 menu1.addEventListener( "touchstart" , onTouchStart , false );
 8 menu2.addEventListener( "touchstart" , onTouchStart , false );
 9 
10 function onTouchStart ( event ){
11     menu1.removeEventListener( "touchstart" , onTouchStart , false );
12     menu2.removeEventListener( "touchstart" , onTouchStart , false );
13 
14     var target = event.currentTarget;
15     if( target == menu1 ){
16         //menu1の処理
17     }else if( target == menu2 ){
18         //menu2の処理
19     }else{
20         //例外処理
21     }
22     //画面が遷移する
23 }
24 </script>
ついでにもう少し安全なコードに書き換えました。

まとめ

iPhoneではevent.targetにTextNodeも渡される。 イベントハンドラでaddEventListenerした対象かどうか調べたいときはevent.currentTargetを使ったほうが安全。 event.targetやevent.currentTargetについてはこちらの説明も合わせて御覧ください。 Document Object Model Events | Event interface

温度測定システム[1] ラック内温度を測定する

別に若手でもなんでもないuchikawa-yです 「DSAS開発者の部屋」の方ではおそらく読んでいただける人の期待するものと違うだろう、ということで比較的フリーダムなこっちの方を占拠することにします。『抵抗は無意味だ!』あ、違うか。次何か大物を出す場合には独立したTopをもらえるといいなぁ。 要するにサーバラックなどの環境を把握するための温度測定システムを作ってやろうという話です。Hardwareのカテゴリを作りました。ここは(当面)私の領域です!

1. なぜサーバラック内の温度を測定するか

サーバの信頼性の観点からサーバラック内の環境を正確に把握するのは案外大事なことです。 DSASブログでも以前ラック内温度が低すぎるためにHDDの動作に問題が発生した件がありました。 データセンタではラック内の温度管理を何らかの方法で行っています。あらかじめ決められた基準でユーザに対してラックを提供しています。しかし実使用においてはサーバの設置状況、冷却の方法などによりラック内の温度分布は変化します。たとえばラックの上部と下部では温度差がある場合があります。 またエアフローを考慮した設置方法と、あまり適切ではない設置方法をとった場合に全体の温度分布に違いが発生する場合もあるようです。 ユーザがラック内の温度分布を必要に応じて測定し、サーバ設置や利用方法などの運用に反映させることができればラックの利用効率を高め、かつ信頼性を確保する指針の一つになるでしょう。

2. サーバラック内温度測定の概要

サーバラック内の温度測定を行うにあたり、測定の大まかな用件を示しておきます。
測定温度範囲 10℃~100℃(サーバ排気温を含む)
センサの設置範囲 ラック(80cm×1m×2m程度)が最大10台程度
湿度範囲 30%~60%程度(結露しない)
測定点数 数点~数10点
一般のオフィスルーム内の温度測定とそれほど変わりませんが、センサの設置範囲は最低2m程度、複数のラックの測定を行う場合は20~40m程度の総延長となることが想定できます。測定装置を複数置いてネットワーク接続をする方法も考えられますが、ここでは測定用の機器を最低限の数でまかなえるようセンサ側の制約を少なくする方向で考えます。 温度分布を知りたいため測定点は最低ラック内数点は必要です。配線が少なくてすむような構成が可能なセンサが望ましいです。

3. センサのインターフェース (1-Wire)

温度センサは温度に対応した電圧や電流のアナログ値で出力するものと、内部的にA/D変換を行いデジタル値で出力するものがあります。
  • アナログ出力
    • 電圧出力
    • 電流出力
  • デジタル出力
    • 1-Wire
    • I2C
    • その他
IC化された温度センサにおいては温度に対応する電圧を出力するタイプが従来一般的でした。しかし電圧出力ではセンサと測定器の間が数m以上となる場合、ノイズの影響や、センサケーブルの電圧降下の影響を受けやすく、高精度の測定は行いにくくなります。電流出力形式のものやデジタル出力のものが適しています。 デジタル出力のタイプではバス型のインターフェースを持ち、複数のセンサを1本のバスインターフェース上で扱うことができるものが販売されています。今回の目的ではこのようなインターフェースを持った温度センサがよいでしょう。

1-Wireバス

MAXIM社の温度センサは1-Wireという名前のリモート測定に適した非同期型シリアルバスインターフェースを採用しています(1-WireはMAXIM社の登録商標です) "1-Wire"という名前のいわれは電源・GNDを除く信号線が1本のみであることから来ています。実使用では2線(Vcc+電源と信号線を時分割で共有)または3線で配線します。1本のバス上に複数のデバイスを接続することが可能で、条件次第でバス長は100m程度、デバイス数最大100程度まで使用可能とされています。電気的な条件の制限を受けるので額面通りには受け取れないのですが、広い範囲に多数のセンサを配置することが可能で、今回の目的には適したインターフェースです。 類似のインターフェースとしてはPC内の温度センサ、ファンの回転数センサなどのインターフェースとして使われているI2Cバスがあります。こちらは1-Wireよりも高速のデータ転送が可能ですが、数m以上の配線長での使用には適していません。たとえば電気的特性として負荷容量は400pF以下となっていますが、平行2線の配線ケーブル自体の容量が50pF/m程度はありますのでこの条件だけで10m程度の配線は難しいということになります。

4. 温度測定システムの試作

実際に作成した測定装置は以下のようになります。センサを並列に接続していくことで測定点を増やすことができます。 実験的にはセンサ8個、ケーブル10mまで動作確認をしています。 これをUSBインターフェース経由でPCなどに接続し、データの収集を行います。
Fig.1 温度測定システム


図2に作成した装置の回路図を示します. 最近のPC(サーバ機を含む)ではシリアルインターフェースは省略されることも多いですがUSBは標準装備です。電源供給も同時に行うことができるため使いやすい形になります。 ここでは秋月電子製のUSB-シリアル変換モジュールを使用し、これ経由でPCに接続しています。
Fig.2 温度測定回路図


測定装置基板


PC接続


l実際の測定結果が図3です。これはオフィスに置いた社内システムのサーバラックで温度測定を行ったものです。5分間隔で温度測定を行った結果をrrdtoolを使ってグラフ化しました。
Fig.3 サーバラック温度測定結果


日によって温度変化の様子に大きな違いがあることがわかりました。たとえば休日にオフィスの空調が止まっていると温度の上昇が大きいことがわかりました。 これによって休日に必要のない機器の電源を止めたり、サーバのあるスペースのエアフローを改善するなどの対策が必要であることがわかりました。 次回は測定に使用したプログラムや1-Wireの簡単な話をしたいと思います。
 KLab若手エンジニアブログのフッター