マイコンを利用した3層 IT アーキテクチャ設計の提案 Three - 阪南大学

２００８年度
修士論文
指導教員
花川
典子
教授
マイコンを利用した３層 IT アーキテクチャ設計の提案
Three layer IT architecture design using micro computers
阪南大学大学院
企業情報研究科
企業情報選専攻
8107002
尾花
A
将輝
目次
１章
はじめに
P1
２章
ユビキタス社会と組込み技術
P3
３章
２．１
ユビキタス社会とは
P3
２．２
ユビキタス社会を実現する技術要素
P5
２．３
Web アプリケーションとは
P6
２．４
Web アプリケーションを実現する技術要素
P8
２．５
組込みシステムとは
P9
２．６
組込みシステムを実現する技術要素
P10
２．７
Web サーバと組込み機器
P12
組込み機器 Web システムの問題点
３．１
Web サーバを組込み機器自身に搭載し制御を行う場合における問題
P14
３．２
Web サーバ等を経由し，組込み機器の制御を行う場合における問題
P15
４章
５章
６章
P18
関連研究
４．１
組込みシステムにおけるアーキテクチャ
P18
４．２
Web アプリケーションシステムにおけるアーキテクチャ
P19
４．３
cogma システム
P21
組込み機器を用いた３層 IT アーキテクチャの提案
P23
５．１
３層 IT アーキテクチャのシステム例
P23
５．２
ハードウェアアーキテクチャ
P24
５．３
ソフトウェアアーキテクチャ
P25
５．４
簡易汎用ファームウェアの提案
P27
３層 IT アーキテクチャの試験的実装と検証
P30
６．１
試験的実装したシステムの概要
P30
６．２
３層 IT アーキテクチャ試験的実装
P30
６．３
３層 IT アーキテクチャ試験的実装詳細説明
P32
６．３．１
サーバ層
P32
６．３．２
コントロールクライアント層
P33
６．３．３
マイクロクライアント層
P34
６．４
３層 IT アーキテクチャによる検証
B
P35
７章
３層 IT アーキテクチャを用いたシステム構築
７．１
P43
ニンテンドーDS からコーヒーメーカの電源を入れるシステムの構築
P43
７．２
８章
P47
水槽管理システムの構築
P52
おわりに
参考文献
P53
謝辞
P54
C
１章
はじめに
近年，様々な機器にネットワーク機能を搭載した携帯情報端末が登場し，無線 LAN 等を
用いる事で，どこでもインターネット検索を行える環境が実現しつつある．ここで言う携
帯情報端末とは，ニンテンドーDS や，PSP，または携帯電話等の機器を指す．このような機
器を用いると，インターネット検索のみならず様々な事が実現可能となっている．例えば，
外出先にて商品の購入を検討していた場合，その商品Ａの値段が 15000 円だったとする．
当然，他店ではどのぐらいの値段で販売されているかを考慮し商品を購入する判断をおこ
なう．しかし，他店に行って商品 A の値段を確認する時間がない場合にはこのような携帯
情報端末を用いた環境が非常に有効である．多くの商品の店舗ごとの販売価格が提示され
ている価格.com[1]の Web ページへ携帯電話でアクセスし，商品Ａが他店ではどのぐらいの
値段で販売されているかを確認することが可能であるからだ．そこで，他店での最安値が
16000 円という情報を取得できれば，この店舗の商品Ａの 15000 円が最も安いという事がわ
かり，商品購入の判断がスムーズにおこなえるという使い方である．このように手軽に且
つ高速に様々な情報を取得できる事が，現在の携帯情報端末と無線 LAN などの通信技術を
つかった環境の最大の利点であり，総務省が提唱するユビキタス社会の一端であると言え
る．
しかし，これでは不十分であるという思いがあった．確かに，直接店舗に行かなくても
販売価格がわかる価格.com サイトや，その商品を購入できるオンラインショッピング等，
10 年前には考えられないシステムが多く登場している．しかし，携帯情報端末等から取得
できるものは，サーバサイドに蓄積された情報というものに特化されている．つまり，サ
ーバに蓄積された様々な店舗の商品の販売価格を単に携帯情報端末上から参照できる等の
参照型のシステムである．本来のユビキタス社会を実現するためには，参照型のシステム
ではなく，例えば，個人の家の窓の開閉をする，エアコンなどの家電製品を外出先から操
作したい等，携帯情報端末からの特定の機器の操作を要求するような PUSH 型のシステムも
必要ということである．著者の生活での例を述べるなら，いつも朝起きてコーヒーとタバ
コを吸うのが日課であるが，ここでコーヒーを作るのが非常に面倒である．コーヒーメー
カにコーヒー豆をセットし，水を入れ，ボタンを押して 3～5 分程待たなければいけない．
この時間をベッドで過ごしたいというのが私の素直な気持ちでもあり，ベッドの中からコ
ーヒーメーカを携帯情報端末で操作できるような PUSH 型のシステムがあればと考えた．
そこで，著者はニンテンドーDS 等の携帯情報端末からコーヒーメーカを操作するシステ
ムを開発することを考えた．コーヒーの準備は，前もって水とコーヒー豆をセットしてお
くと，スイッチ部分をニンテンドーDS から ON に入れれば，ベッドから起きてキッチンに着
いたころにいい香りのコーヒーが出来上がっているということが実現できるというアイデ
1
ィアである．コーヒーメーカのシステムは，携帯電話で操作するための web アプリケーシ
ョンとコーヒーメーカの電源部分の ON,OFF を入れ替える組込み機器を作成してコーヒーメ
ーカにつなぐことで．ベッドからのコーヒーを入れることに成功した．さらに，このよう
なシステムは，汎用性を高めることで様々な家電製品やモータを操作することが可能であ
る．例えば，エアコンやカーテン（モータを設置してモータを制御する），窓の開閉，自動
ロックなどである．しかし，汎用性を高めるためには，コーヒーメーカに特化したプログ
ラムや機器の構成を排除して，どのような家電製品や機器でもプログラムから自由に操作
で切る仕組みを考える必要があった．
そこで，３層 IT アーキテクチャの提案をする．これはコーヒーメーカに特化した携帯情
報端末から操作するシステムを一般化し，様々な家電製品や機器に接続可能なソフトウェ
アとハードウェアのアーキテクチャである．特徴は，ソフトウェア，ハードウェアともに
完全に独立した３層の構造をもち，家電製品や機器に依存部分を特定の箇所に集約するこ
とで，システム全体としての大きな構造の変更なく新しい機器や電化製品を追加したり，
削除できるシステムアーキテクチャである．つまり，一度システムを構築した後に新製品
の家電製品が新たに加わったとしても，容易にその新製品を操作するシステムを組み入れ
ることができるシステムアーキテクチャである．
本稿では，2 章に総務省が推進するユビキタス社会とその要素技術である組込み技術や
Web アプリケーション技術について紹介し，３章では従来の組込み技術をユビキタス社会に
利用するときの問題点を述べる．また，４章では組込みシステムや Web システムの従来の
アーキテクチャを紹介し，５章では３層 IT アーキテクチャの提案をおこなう．6 章では提
案したアーキテクチャを試験的に実装したシステムを紹介するとともに提案アーキテクチ
ャを検証する．７章では実践的なシステム構築事例を紹介する．まとめと今後の課題を８
章で述べる．
2
2章ユビキタス社会と組込み技術
前章で記述したニンテンドーDS を使ってコーヒーメーカでコーヒーを沸かすことはユビ
キタス環境の一部である．そこで，本章では，ユビキタス社会とそれを実現する技術につ
いて説明する．まず，ユビキタス社会について説明し，要素技術の Web アプリケーション
や組込み機器，さらに Web サーバと組込み機器を統合した無見込みシステムなどについて
紹介する．
２．１ユビキタス社会とは
ユビキタス社会は，現在のユビキタス社会と一昔前のユビキタス社会とでは若干意味が
異なってきている．本稿では，一昔前のユビキタス社会を第一世代ユビキタスと呼び，現
在のユビキタス社会を第二世代のユビキタスとよぶ．第一世代のユビキタス社会はコンピ
ュータ同士を接続することにより，特定の場所に行かなければ取得できない情報を取得可
能な社会を指していた．つまり，データが蓄積されている特定の場所に行かなくてもコン
ピュータを経由して情報が取得できるという環境である．第二世代のユビキタス社会は使
用するコンピュータの小型化や無線通信技術の発展によって，固定設置されたコンピュー
タではなく，持ち運びできる携帯情報端末によってどこからでもインターネットに接続で
きる社会を指している．
まず，第一世代のユビキタス社会について詳しく述べる．第一世代のユビキタス社会は
e-Japan 戦略[2]によって基盤が整えられた．e-Japan とは，国の政策であり，2001 年～2005
年まで実施された．e-Japan 戦略で最も有名な功績としては一般家庭へのブロードバンド普
及率が挙げられる．我が国日本におけるブロードバンド普及率は総務省の公式ページによ
れば[3]DSL（ADSL 回線等）が 4600 万世帯に導入，FTTH（光回線）が 3500 万世帯に導入さ
れたという報告であり，数字で見るだけでもかなりの普及率である．更にブロードバンド
普及に伴い，料金の値段も格段に下がった．高速回線（ここでは DSL）の月額料金が 2001
年には 7800 円であったが，2004 年には 2500 円へと値下げが行われた．これは当初の 3 分
の１の料金価格で高速回線が使え，コンピュータ同士を繋げるユビキタス社会のインフラ
整備へ大きな貢献をしたと言える．このように e-Japan 政策ではブロードバンド普及を行
う事で，ユビキタス社会のインフラ環境を構築する事が第一の目的であった．ブロードバ
ンド環境のインフラ構築後，e-Japan 戦略は e-Japan 戦略Ⅱと呼ばれる新たな政策が打ち出
された．e-Japan 戦略Ⅱは言わば e-Japan 戦略を見直した政策である．特色とし、医療、食、
生活、中小企業金融、知、就労・労働、行政サービスというＩＴ活用の先導的取組み 7 分
野を定め、国家ＩＴ戦略を、インフラ整備から活用促進へと大きく変更したところにある．
つまり，インフラ環境をブロードバンド環境と絞り込まず様々なコンピュータの連結を実
現すると同時に，それを有効活用できるサービスの提供を行う事が e-Japan 戦略Ⅱの目的
である．例えば，中小企業金融の 24 時間取引が可能なオンラインシステム等である．我が
3
阪南大学もこれに先立ち，自慢のシステム HInT システム（旧バージョン）等が e-Japan 戦
略Ⅱにあたる．
その後 2005 年には e-Japan 戦略が終わり u-Japan 戦略（図１参照）[2]が始まった．こ
れが第二世代のユビキタス社会である．u-Japan 戦略とは正式にはユビキタスネット・ジャ
パンと呼ばれ，ブロードバンドネットからユビキタスネットへのインフラ環境提供を目指
す．ユビキタスネットとは「いつでも、どこでも、何でも、誰でも」というコンセプトを
元に実現するシステムである．「いつでも」は 24 時間の時間を指し，「どこでも」は移動中
（外出先）からでも，「何でも」は身の回りの物（例えば車や，家電等），そして「誰でも」
は老若男女問わず，ネットワークに容易に接続できる．これが u-Japan 戦略，つまりユビ
キタス社会である．例えば，高齢者が深夜 1 時に外出先から携帯電話で明日の病院の予約
をする．これが u-Japan 政策の一例である．u-Japan 戦略の政策終了予定は 2010 年度であ
り，現在，進行途中であり，身の回りに様々なユビキタス環境が提供されつつある．例え
ば，ホットスポット[4]が良い例である．ホットスポットとは，市役所やホテル，駅など公
共施設に無線 LAN のアクセスポイントを設置し，そこから無線 LAN 機能を搭載した携帯情
報端末（例えば iPod Touch 等）でインターネットに接続し，高速ネットワーク通信を可能
とするサービスである．ホットスポットは街中の様々な場所に設置されており，駅のホー
ム，飲食店等様々な場所にてサービスの提供が行われている．さらに，u-Japan 政策はイン
フラの整備だけでなく，外出先から自宅の家電操作の実現や， ICT(Information and
Communications Technology )を活用した住民への行政サービスの提供促進等，様々な実現
図１
e-Japan 戦略と u-Japan 戦略概要
4
出典：総務省 HP
すべきサービスを提唱している．
２．２
ユビキタス社会を実現する技術要素
u-Japan 戦略におけるユビキタス社会を実現するために必要な技術として大きく２つの
要素がある．ひとつはネットワークのインフラの整備である．e-Japan におけるインフラ整
備はブロードバンドにおけるネットワークの提供であった．しかしブロードバンドは住宅，
オフィス，教育機関等の建物への導入が基本である．つまり有線での接続が基本であった．
しかし，u-Japan 政策は外出先，つまりは公共の道路や駅等で接続可能な環境の推進である
（図２参照）
．そのため無線通信が基本となる．ネットワーク無線通信で最も有名なものは
無線 LAN（WiFi）接続である．家電量販店等でも販売されている無線 LAN ルータを使用する
ことで無線通信が可能となる．無線 LAN はある一定の範囲内に 2.4GHz 帯の電波を飛ばし，
コンピュータに設置された無専用機器でその電波をキャッチすることで接続可能となる．
無線 LAN にも様々な規格も存在し，1394.11b,1394.11a,1394.11g 等の様々な通信規格が存
在する．この技術を用いて前述したホットスポット等のサービスを実現している．しかし，
無線 LAN 技術だけではユビキタス社会の実現はできない．つまり，広域な公共エリアをす
べて無線ＬＡＮで網羅することは不可能であるからだ．そこでふたつめである携帯電話等
の携帯情報端末の性能の向上である．
近年の携帯情報端末は非常に高性能になりつつある．例えば携帯電話は，10 年程前まで
図２
u-Japan 戦略の将来像の例
5
引用：総務省 HP
は電話しか出来なかった．しかし，携帯電話の性能は向上しメールができるようになり，
写真等の機能が搭載され，さらに，パソコンでしか閲覧できなかった Flash 等がついた Web
ページも閲覧可能となった．これは携帯電話の機器性能向上もあるが，通信技術の向上の
役割も大きい．現在の携帯電話は第三世代（３Ｇ）とも呼ばれており，2.0GHz 帯の電波を
使用したデジタル回線である．速度も比較的高速であり，最大速度 2.0Mbps（アナログ回線
が 54Kbps）の速度であり，広範囲における無線通信では非常に高速通信である．携帯電話
という制約で通信技術上様々な制約が発生したものが無くなり，幅広いサービスを受ける
事が可能となった．また携帯電話を除く携帯情報端末の性能向上もユビキタス社会の貢献
となっている．例えば，ゲーム機であるニンテンドーＤＳやＰＳＰ等は無線ＬＡＮ（WiFi）
を搭載しており，ホットスポット等を用いる事でインターネット接続する事が可能となっ
ている．このように，電話機能だけであった携帯電話，遊具であったゲーム機等にも高性
能なネットワーク機能が搭載されており，何でも接続可能な環境の構築に貢献していると
言える．
以上のような無線環境や携帯情報端末の発展に必要不可欠な要素技術が組込み技術であ
る．つまり，組込み技術の発展がユビキタス社会の実現を左右する重要な役割を果たして
いる．
２．３
Web アプリケーションとは
Web アプリケーションの説明を行う前に Web システムの説明を行う．Web システムとは，
クライアントサーバシステムのひとつの種類である．クライアントにはブラウザと呼ばれ
る HTML(HyperText Markup Language)を解析する事ができるソフトが導入されており，ブラ
ウザからサーバにアクセスし，指定の HTML で記述されたファイルを参照する事によりブラ
ウザ上に文字や画像が表示される．この時サーバとクライアントの通信を行うために HTTP
（HyperText Transfer Protocol）にて通信するのだが，HTML ファイルがアップロードされ
ているサーバの事を Web サーバと呼ぶ．Web サーバとはパソコンを Web サーバと指すもので
は無く，基本的にはハードウェア，ソフトウェアの両方が兼ねそろうシステムを指す．そ
のため，パソコンを用いずサーバソフトウェアである Apache 等を組み込んだマイクロチッ
プ等も Web サーバと一般的には指す．
Web システムとはクライアントソフトのブラウザが Web サーバ上にある HTML ファイルを
参照する事により基本的には成り立つ．この動きを図３にまとめた． Web システムは特定
のユーザが HTML で記述したファイルをサーバにアップロードすることで，第三者がブラウ
ザにてその HTML ファイルを参照し情報を取得がしていたのが，従来の Web システムであっ
た．しかし，現在の Web システムは少し異なる．オンラインショッピング，宿泊施設の予
約等，ブラウザを経由し様々な処理が可能となった．このオンラインショッピングや宿泊
施設の予約処理をおこなうソフトウェアを Web アプリケーションと言う．
6
クライアント
サーバ
ブラウザ
Index.HTML
<html>
<head>
<title>修士論文</title>
</head>
<body>
修士論文
</body>
</html>
図３
アクセス
Index.HTML を解析
文字，画像の表示
表示
Web システム概要図
クライアント
サーバ
Index.cgi
Index.HTML
値を引渡し
フォーム等から値を引渡
し
ブラウザ
値の受取処理
HTML 文を解析
処理Ａ
文字，画像の表示
処理Ｂ
処理した HTML 文を
ブラウザに渡す
HTML 文
生成
図４
Web アプリケーションの仕組み
Web アプリケーションの特徴は，ブラウザから与えられた情報を元にサーバ内で処理を実
行し，その結果をブラウザに伝えるシステムが特徴である．つまり，ブラウザは昔と同じ
く基本的には HTML 等のタグ言語（XML 等）を解釈する機能しか搭載されていない．
（ただし，
JavaScript にて簡単な処理を行う事が可能であるが，ブラウザの種類によるのでここでは
省く）つまり，サーバにて CGI，JAVA 等の言語を用いて処理を行い，その結果をブラウザ
に伝える，これが Web アプリケーションである．（図４参照）
7
２．４
Web アプリケーションを実現する技術要素
Web アプリケーションを実現するための技術は数多く存在する．その中で，Web アプリケ
ーションを開発するひとつの方法として，Java Servlet と呼ばれる開発手段がある．Java
Servlet（ジャバサーブレット）とは，Java を用いる事でブラウザが解釈可能な HTML 文な
どを動的に生成するサーバ上で動くプログラム、もしくはその仕様である．この方法を用
いる事で，様々な Amazon[5]などのショッピングサイトやオンラインバンキングなど多種多
様な動的な Web サイトが構築されている．
同じく，技術として Perl などを用いた CGI プログラム等が存在するが，CGI のプロセス
を Apache 等のサーバソフトウェア上で動作可能なのに対して，JavaServlet は Java にて
一度コンパイルした.class ファイルを生成し，サーバにアップロードしておく必要がある
ため少し煩雑さが増す．しかし，この２つの技術の差として，CGI は CGI クライアント（ブ
ラウザ）からのリクエスト毎に新しいプロセスを起動する．これに対して，サーブレット
は一度呼び出されるとメモリに常駐し，リクエスト毎に軽量なスレッドを起動する．これ
により，高速処理が可能となる他に，データ共有を扱う事ができ，複数のユーザ間の情報
を共有する事も可能である．また，サーブレットの技術の延長として JSP が存在する．JSP
はサーブレットを自動生成して動作する．つまり，事前にコンパイルが必要であったサー
ブレットであるが，クライアントからリクエストがあるとその都度コンパイルを実行する．
この技術に似た Microsoft 版が ASP と呼ばれるプログラム開発環境が存在するが，ASP は完
全な Windows の OS 上のみで動作する環境依存の Web システムである．
次にセッション管理について述べる．Web システムを利用するに辺り絶対避けて通れない
ものである．
Web ブラウザと Web サーバ間では前述したように HTTP プロトコルが採用おり，
HTTP プロトコルには状態を保持する機能がなく，ユーザ（ブラウザ）が連続的に複数回の
アクセス（Web ページの表示等）をしても，サーバ側はそれを特定のユーザの連続したアク
セスと認識する事ができないのである．つまり，複数人のユーザが複数回サーバにアクセ
スしたものとして認識してしまうのである．そこで，Web アプリケーション内に特定のユー
ザからの状態（アクセス履歴や，入力したデータなどの情報）を保持した上で，次にその
ユーザがアクセスしたときに特定のユーザからのアクセスであることをサーバ側が認識で
きるような機能をセッション管理である．セッション管理にも様々存在するが，一番有名
なのが Cookie（以下クッキー）を用いたセッション管理方法である．クッキーとは，サー
バからクライアントに一時的に情報を保存しておく事が可能なデータである．クッキーに
様々なデータ（ユーザの状態等）と共にセッションＩＤと呼ばれるＩＤをサーバが発行す
る．そのセッションＩＤを元にどのユーザであるかを判別するものである．（図５参照）こ
の技術を用いる事で，例えば多くの入力項目がある入力フォーム（例えばオンラインショ
ッピングの購入画面等）の入力途中で，何らかのトラブルにて通信が途絶えても，再ログ
8
事前に Cookie を渡す
クライアントＡ
(Cookie 101)
クライアントＡ
サーバ
サーバ
クライアントＢ
Cookie101 だからクライ
どれが，誰から
の通信かわか
クライアントＢ
クライアントＣ
アントＡさんだ
クライアントＣ
らない・・・
図５
Cookie を用いたセッション管理図
インする必要ない等，入力が完了した項目までのデータをサーバが保持する等，ユーザに
とって恩恵の多い技術となっている．
２．５
組込みシステムとは
組込みシステムとは，汎用コンピュータ（ここではパソコン）とは全く反対のコンピュ
ータシステムの事を指し，特定の目的（特定の機能）のための専用コンピュータシステム
を一般的に指す．組込みシステムには様々な呼び方が存在する．組込みシステムは，別名
で組込み機器と呼ばれる事が多いが，実際には組込みシステムと組込み機器とは正確には
意味が違う．また，近年はユビキタス社会の実現に大きな役割を担う事が多く別名ユビキ
タスコンピュータと呼ばれる事もある．このように組込みシステムには複数の呼び方が存
在するが，世間一般的によく使われているのは組込み機器が多い．
続いて組込みシステムについて述べる．組込みシステムとは，ソフトウェア，ハードウ
ェアの２つの要素を特定の目的のために最小限で構築されたコンピュータシステムを指し，
組込みシステムを制御するソフトウェアを組込みソフトウェアと呼ぶ．この特定の目的の
ために開発されると言う点に組込みシステムの最大の特徴があるのだが，この特定の目的
という定義について述べる．組込みシステムとは対象的である汎用コンピュータは，デバ
イスや CPU 等をある程度定められている物である．これにより，様々な処理をプログラム
によって実行するのがコンピュータである．つまり，特定のデバイスや CPU 等に合わせた
OS を搭載することにより，様々なアプリケーション等が実行できるコンピュータを汎用コ
9
ンピュータと呼ぶ．これに対して組込みシステムとは，特定の処理だけを行えるハードウ
ェア構成で成り立っており，特定のプログラムしか処理できないシステム構成となってい
るシステムを指す．そのため，デバイスや CPU 等を自由に選択する事ができ，専用ハード
ウェアを作成する事が可能である．このハードウェア自由に選択できる事が組込みシステ
ムの最大の特徴であり，最小限のコンピュータシステムを構築できる事から，最小限コン
ピュータシステムと呼ばれる事もある．例えば，処理に浮動小数点計算等が不必要な場合
において，浮動小数点が計算できない CPU を搭載し，システムを構築する等である．これ
による恩恵として，安価で且つ，特定の処理を高速で行うシステム構築が可能となる．
組込みシステムは様々な場所で利用されており，一般家庭では冷蔵庫，電子レンジ，テ
レビ，DVD レコーダ等の数え切れない組込みシステムが存在しており，我々はそれらを意識
せず使用している．つまり世の中から組込み機器が無くなれば，生活ができないほど組込
みシステムは非常に我々と密接な関係にある．また近年のユビキタス社会にも貢献してい
る携帯情報端末等も組込み機器と定義されている．しかし，近年の組込み機器の定義が徐々
に変わってきている．組込みシステムとは特定の目的のため，つまり一切の汎用性がない
機器を定義していたのだが，ITron[6]等を用いた組込み OS（リアルタイム OS）の普及によ
り，定義が変化しつつある．OS を搭載すると様々なプログラムを実行する事が可能となり，
特定の目的のためと呼ばれていた組込みシステムだが，近年は少しだが汎用性があがって
きている．そのために組込みシステムと汎用コンピュータのシステムとの区別が不明確に
なってきている．そのため特定の目的のためでなく，組込み CPU を搭載すれば組込みシス
テム，汎用 CPU(Intel 等)を搭載すれば，汎用コンピュータと分けている事も多い．
２．６組込みシステムを実現する技術要素
組込みシステムを実現する技術要素は多く存在する．その一部を紹介する．まず簡単
にマイコンの説明をする．マイコンとは Micro Computer の略であり，コンピュータが成
立する中枢部を LSI（集積回路）に集積したものを一般的に指す．用途により，メモリ等
を取り付けるが，多くの組込みシステムにはメモリを搭載している事が多く，ROM，RAM，
CPU 等をひとつにまとめた LSI をワンチップ・マイコン（マイコンボード）と呼んだりす
る．今回これらもまとめてマイコンと総称する（図６の赤四角点線部分，図７参照）．こ
のマイコンにファームウェアと呼ばれるソフトウェアを転送することにより，電子機器
の制御等を行う．ファームウェア（Firmware）とは電子機器（携帯電話等）に組み込ま
れたハードウェアを制御するためのソフトウェアを指す．つまり，コンピュータシステ
ムの最も基礎的なソフトウェアである．汎用コンピュータであるパーソナルコンピュー
タのマザーボード上に取り付けられている BIOS（Basic Input/Output System）もファー
ムウェアの一種と言える．ファームウェアは基本的にはアセンブリ言語が記述するが，
CPU 等の高性能化もあり，高級言語である C 言語等で記述する事が近年一般的になりつつ
10
分解
物理的ハードウェア
無線 LAN ルータ
マイクロコンピュータ
z 制御プログラム
z DHCP サーバ
図６
無線 LAN 機器の分解写真と内容
ある．今回著者が使用した EZ-USB[7]もマイコンとファームウェアを使用している．この
EZ-USB を用いて簡単にシステムの流れを説明する（図７参照）
．
ファームウェアをマイコン上の ROM（電源を切ってもプログラムを保持できるメモリ）
に書込み（図７の①），電源導入時に ROM 上のプログラムが RAM（電源を切ると内容が消
えるメモリ）に移動する（図７の②）ことにより，システムが稼動する．尚今回使用す
る EZ-USB は学習用マイコンであるため，USBPort から直接 RAM へ Firmware を転送する事
が可能なっており，ROM を経由し動作する必要がない特殊なマイコンボードである．
続いて，組込みソフトウェアの説明をする．組込みソフトウェアとは組込みシステム
に搭載されているソフトウェア全般を指す．例えば，携帯電話のソフトウェアを例に挙
げると図８のようになる．ハードウェアの管理等を行う OS が搭載され，ミドルウェアが
CPU & RAM
CPU
USB
Port
Firm
ware
Program
RAM
②
①
ROM
マイコンボード
マイコンボード
EEPROM(ROM)
図７
実際のマイコンボードとマイコン動作例
11
アプリケーション
ミドルウェア
ソフトウェア
OS
アプリケーション
ソフトウェア
マイコン
ハードウェア
ハードウェア
マイコン
今回作成した
組込みソフトウェア
携帯電話等の
組込みソフトウェア例
図８
組込みソフトウェア例
導入され，そしてアプリケーションが動作するというものである．もう少しわかりやす
く言うならば，携帯電話用の OS（リアルタイム性 OS）が搭載された上に携帯用の JAVA
（ミドルウェア）が搭載され，その上で携帯用アプリが動くというものである．このよ
うに，組込みソフトウェアとは，この組込みシステム専用ソフトウェア全てを指す．た
だし，重要な点として，組込みシステムはこの全ての要素は必要としない．図８の右側
を見ればわかるが，マイコンとアプリケーションだけで動作する組込みシステムも数多
く存在する．本論文で開発したマイコンもこれに相当する．
また組込みシステムにはリアルタイム組込みシステムと呼ばれるシステムも存在する．
リアルタイム組込みシステムは主に機器を制御する際に使われるシステムであり，特定
のプロセスを制約時間内に処理をするシステムの事を指す．例えば，ある組込み機器の
ボタンを押せばその動作を最優先で実行するというものである．つまり，外部イベント
に対して，タイムリーに応答するシステムの事を指す．これらのシステムはソフトウェ
ア内のスケジューリング機能が特定の処理を行う事に優先的に設計されている事がひと
つの理由である．この技術を応用した OS がリアルタイム OS であり，前述した携帯電話
等に組み込まれている ITROM OS がリアルタイム OS である．
２．７
Web サーバと組込み機器
近年新しい組込み機器の考えかたとして，Web サーバシステムを導入した組込みシステム
が提案されつつある．これは u-Japan 戦略のひとつであり，ユビキタス社会において，家
電等の物もどこからでも操作できるユビキタス社会の構築を目指しているからである．そ
こで，従来の Web サーバシステムと組込みシステムの両方を連結し，Web アプリケーション
から組込み機器を操作するシステムが世の中に広まりつつある．
現在組込み機器を Web アプリケーションから操作するシステムには大きくふたつの方法
が存在する．
ひとつは組込み機器内部に Web サーバ機能を搭載するシステムである（図９）．
組込み機器のカメラの内部にネットワーク機能と，Web サーバシステムを搭載する．これに
12
より，Web ブラウザでもカメラの映像を見ることができるネットワークカメラができるとい
うものである．つまり，図６の無線 LAN ルータのように，無線 LAN 機能に DHCP サーバを搭
載することでネットワークルーティング機能を搭載する事とほぼ同様の事を行い，組込み
機器を Web アプリケーション化するのである．ふたつめの方法として，汎用コンピュータ
上の Web サーバシステムに組込み機器管理機能を搭載する方法である（図１０）
．これは組
込み機器にネットワーク機能を搭載し，従来の Web サーバシステムに組込み機器を操作す
る専用 Web アプリケーションを構築することによって実現する手法である．例えば，最近
の HDD レコーダの場合，メーカが提供する Web サーバにアクセスし，そこで会員登録をす
る．その後 DVD レコーダにその会員登録をした情報を入力，その後携帯電話等でメーカの
Web アプリケーションにアクセスすることにより，携帯電話等から HDD レコーダを操作する
事ができるというものである．つまり，従来のクライアントサーバシステムのクライアン
ト部分が組込み機器になったというイメージである．ふたつの方法は Web アプリケーショ
ンから組込み機器を操作という共通の目的であるが，実現方法は全く異なる方法で実現し
ている．
レコーダ専用サーバ
（メーカ）
カメラ
Web サーバ機能
機器通信，制御機能
カメラ機能
Web サーバ機能
ネットワーク通信
DVD/HDD レコーダ
機器内部に組み込む
図９
図１０
組込み機器と Web サーバ１
13
組込み機器と Web サーバ２
3章
組込み機器 Web システムの問題点
ユビキタス社会における組込み機器と Web サーバの連携は，携帯情報端末等から家電製
品（以下組込み機器）を操作するためには非常に重要な要素義中である．主に２つの方法
がある．ひとつめは Web サーバを組込み機器自身に搭載し制御を行う方法である，ふたつ
めは別のコンピュータに搭載された Web サーバ等を経由して組込み機器の制御を行う方法
である．しかし，両者ともに様々な問題点が存在する．それらの問題点を本章にて述べる．
３．１
Web サーバを組込み機器自身に搭載し制御を行う場合における問題
組込み機器とはマイコン（Micro Computer）を搭載したデジタル機器を指す．まず，Web
サーバを組込み機器自身に搭載する方法について説明する．Web カメラはコンピュータでは
なくあくまでもカメラであるのだが，分解するとマイクロコンピュータとメモリを載せた
小さな基盤がある．これ Web カメラに内蔵されたマイクロコンピュータとメモリ上で Web
サーバが動作する．つまり，Web カメラのみあれば，サーバ用の PC がなくても，携帯電話
から Web カメラの画像が参照できるシステムを構築することができる．この場合，Web カメ
ラだけでなく，センサのマイコンに Web サーバを搭載すると，カメラだけでなくセンサの
反応状況を携帯情報端末で確認する Web アプリケーションが容易にできる．現在の組込み
機器の Web アプリケーションの多くは，このように組込み機器のマイコンに Web サーバを
搭載する手段を使っている（図 10 参照）．
しかし，組込み機器自身へ Web サーバを搭載するにあたり２つの問題点がある．ひとつ
めの問題点は，他の機器との連結が困難な点である．他の組込み機器との連携するために
は，追加したい機器を追加する機器に物理的に組込み機器自身に搭載する必要がある．例
えば，図 11 のような携帯電話で操作できる換気扇（Web サーバを搭載したマイコン内蔵）
が稼働しているとする．そこに煙センサを組込んで，煙を検知すると自動的に換気扇が回
IP アドレス
Web カメラ
Web サーバ内臓
IP アドレス
照明スイッチ
映像の確認
Web サーバ内臓
図 10 Web サーバを搭載した組込み機器のシステム例
14
Web サーバ機能を搭載した換気扇
追加したい！
煙センサ
換気扇
追加するには以下の 2 点があるた
めほぼ不可能！
z 電子機器の回路の変更
z 電子機器を制御するソフトの
変更
Web サーバ
マイコン
既に１つの組込み機器
図 11 換気扇と Web サーバが搭載されている組込み機器における問題
る仕組みへ拡張したいと希望したケースを考える．すでに換気扇のマイコンには換気扇の
回り方を制御するプログラムと携帯電話から指示をうける Web アプリケーションのプログ
ラムが工場出荷時に ROM に書き込まれている．したがって，容易にプログラムを変更する
ことができない．つまり，マイコン上の Web アプリケーションのプログラムやマイコン上
のプログラムに，煙センサの情報を保持することも，制御する処理を追加することができ
ない．したがって，煙センサを換気扇にカスタマイズ機能として拡張させることができな
い．つまり，開発が終了した組込み機器（この場合は換気扇）はその機器の機能以外の機
能を追加する事は不可能である．ふたつめの問題点は IP の問題である．Web サーバを組込
み機器へ搭載する場合，機器自身にグローバル IP を付加する必要がある．例えば赤外線セ
ンサ等のセンサを複数個自宅に設置した場合，その個数だけグローバル IP が必要となる．
グローバルＩＰを付加しすぎると様々な問題が発生する．例えば，グローバル IP 枯渇問題
がある．これは現在主流の IPv4 ではグローバル IP アドレスが足りなくなるという問題点
である．現在 IPv4 では最大２の 32 乗（= 4,294,967,296 ）個であった IP アドレスを利
用できる．しかし，センサのひとつひとつに IP アドレスを付与すると，すぐに IP アドレ
スが足りなくなる．そのために IPv6 という仕様が提案されている．これは２の 128 乗（340
兆の 1 兆倍の 1 兆倍）の個数の IP アドレスが識別でき，ほぼ無限のグローバル IP を利用
することができる．しかし，現在の主流の IPv4 仕様と互換性はなく，IPv6 が数十年前から
提案されているにもかかわらず，未だに普及しない状況にある．したがって，センサのよ
うな組込み機器のひとつひとつに IP アドレスを付与することは現在の状況においては現実
的ではない．
３．２
Web サーバ等を経由し，組込み機器の制御を行う場合における問題
次に別のコンピュータの Web サーバを経由して組込み機器の制御をおこなう方法につい
て説明する（図 12 参照）．この方法は Web サーバ専用の別のコンピュータを設置し，その
コンピュータ上に Web サーバが動作する方法である．つまり，組込み機器をサーバコンピ
15
Web サーバ用コンピュータ
Web カメラ
Web カメラ用
デバイスドライバ
Web サーバ
スイッチ用
デバイスドライバ
照明スイッチ
映像の確認
図 12 別コンピュータの Web サーバを経由した組込み機器のシステム例
ュータへ直接接続し，サーバ機が直接組込み機器からの情報取得や操作を実行する仕組み
のシステムである．サーバ用コンピュータには各組込み機器のデバイスドライバの導入が
必要となる．
別コンピュータの Web サーバ等を経由し，組込み機器の制御を行う場合も問題点が存在
する．ひとつめとしては，Web サーバ自身，つまり Web アプリケーション内に組込み機器を
管理，制御する専用のプログラムを導入する点にある．図 13 のように DVD/HDD レコーダが
操作できる Web アプリケーションが存在したとする．そこへカメラも操作可能にしたい場
合，カメラ専用プログラムを導入するために，Web アプリケーションの変更が必要となる．
また後から換気扇を操作したいとなると，更に換気扇専用プログラムの導入が必要となる．
このように，新しい組込み機器をシステムに追加するたびに Web アプリーションを変更が
発生する．つまり，新しい組込み機器を追加するたびに Web アプリケーションの本体の変
更が発生し，サーバを停止してサーバプログラムのメンテナンス時間を設ける必要がある．
24 時間稼働を要求される高信頼性を要求されるシステムでは度々のメンテナンス時間は社
会に与える影響が大きく好ましくない．
ふたつめの問題として，システム全体のトラブルについてである．システム全体のトラ
プログラムの追加以外に
従来のシステムの変更も必要
組込み機器
Web アプリケーション
DVD/HDD レコーダ専用
プログラム
Web カメラ専用
プログラム
換気扇専用
プログラム
サーバ
図 13 Web サーバへ組込み機器専用プログラム導入問題１
16
ブルとは，例えば，図 14 のような場合，ひとつの組込み機器にトラブルが発生した場合，
それに影響されてサーバシステム全体がストップすることである．具体的には，サーバプ
ログラム上にある DVD/HDD レコーダの組込み機器のデバイスに特定の処理を実行させるプ
ログラムが実行された時，何らかの理由で DVD/HDD レコーダの組込み機器が故障しており，
デバイス呼び出しに失敗し返答が無いケースである．本来はタイムアウト等でその処理を
スキップし，他のシステムに影響を与えないようにすべきである．しかし，未熟なプログ
ラマによる開発やプログラムミスがある場合，スキップ処理を忘れたことによって，故障
を起こした機器だけが制御不能になるだけではなく，システム全体がダウンしてしまう可
能性がある．
以上のように従来の組込み機器を使用した Web アプリケーションのアーキテクチャは，
拡張性の問題や IP アドレス問題，さらに保守性や信頼性の問題が内在するアーキテクチャ
である．
トラブル発生
組込み機器
Web アプリケーション
DVD/HDD レコーダ専用
プログラム
サーバ
処理がストップ
機器から返事が
ないから次の処
理いけない！
あれ？
動かない
Web カメラ専用
プログラム
換気扇専用
プログラム
動かない！
図 14 Web サーバへ組込み機器専用プログラム導入問題２
17
4章
関連研究
本章では，ハードウェアやソフトウェアをつかってシステムを作る場合のシステムアー
キテクチャの現在の動向について説明する．本稿で提案する３層 IT アーキテクチャとの比
較の上で，従来のシステムアーキテクチャの内容とその問題点は重要である．そこで，本
稿の提案でも利用する組込みシステムのアーキテクチャと Web アプリケーションのアーキ
テクチャについて紹介する．
４．１
組込みシステムにおけるアーキテクチャ
組込みシステムのアーキテクチャは数多く存在する．東芝システム・ソフトウェア技術
研究所の井上氏が提唱するマイコンにおけるソフトウェアアーキテクチャ[8]がある．これ
はマイコン等の組込み機器システムの主な役割はリアルタイム制御にあり，リアルタイム
システムには，並列化（並列処理）が一般的に用いられている．そこで，効率よく並列化
を行うためのソフトウェアアーキテクチャモデルの提唱を行っている．並列化を行うには
マルチタスクの概念が必要となる．このマルチタスクであるが，どの処理をひとつのタス
クにし，どのタスクをスケジューラに登録するかが重要な要素となる．そこで，リアルタ
イム組込みシステムの概念を利用したソフトウェアアーキテクチャを提唱している．リア
ルタイム組込みは入力装置からの入力を処理し，出力装置に出力する概念を分け，入力装
置，出力装置等の周辺機器（デバイス）を並列化するものである．また周辺機器の制御は
低レベル（小さな処理）に分ける事が可能であり，これらを抽象化する事でひとつのタス
クとして処理することが可能となる．このひとつのタスクを DIT(Device Interface Task)
と呼び，組込み機器の機能部の処理を FT(Functional Task)と呼ぶことで，図 15 のような
アーキテクチャを提唱している．
また近年，携帯電話等の組込みシステム（組込みソフトウェア）が肥大化しつつあり，
そのため高性能な CPU が必要となる．しかし，CPU の性能を向上（動作周波数向上）させる
と必然的に消費電力が上がってしまう．そこで，近年は消費電力に着目したアーキテクチ
ャが多い[9]．高速処理を実現し，且つ消費電力の低減を実現するためには動作周波数を抑
入力デバイス１
DIT
入力デバイス２
DIT
タスク
並列実行可能
FT
DIT
出力デバイス１
DIT
出力デバイス２
DIT
出力デバイス３
スケジューラ
図 15 マイコン組込みシステム
18
アーキテクチャモデル図
CPU1
アクセス禁止
CPU2
タスク状況
Linux Kernel
CPU1
CPU2
CPU3
CPU4
OS
OS
OS
OS
Sysfs(System Filesystem)
システム
制御
タスク
タスク状況により
CPU を復帰，遮断
CPU Hotplug
タスク 4
タスク 3
スケジューラ
によりタスク
を割振る
タスク 4
CPU Add
CPU Remove
CPU 復帰命令
CPU 遮断命令
メイン処理を行う
OS と CPU
図 16 消費電力設計
図 17 マルチタスクとセキュリティ
えた複数の CPU をひとつのチップにまとめたマルチコアプロセッサを用いたシステムが現
在最も有効とされている．複数の CPU を搭載した組込みシステムが低負荷時はシステムを
稼動させる最低限の CPU だけを起動しシステムを維持し，逆にシステムに複数のタスク（プ
ログラム）が実行される環境になればソフトウェア的に CPU を稼動させ，それぞれの CPU
にタスクを割り振り，円滑に処理を実行するアーキテクチャが現在主流となっている．（図
16）更にマルチコア技術を応用し，セキュリティ性の向上を考慮したシステムアーキテク
チャも存在する．[10] マルチコアの数に対して，その個数分だけ OS を搭載するデュアル
OS 方式を採用したアーキテクチャも存在する．図 17 のように，CPU の数だけ OS を搭載す
るのだが，組込みの主となる部分，つまりデバイス制御と他のプログラムを実行するもの
を OS 毎別にする手法である．これにより，デバイス等重要な処理を行っている OS と CPU
には他のプログラムから容易にアクセスする事を禁止し，ウイルス等の悪意のあるプログ
ラムから組込み機器を守るものである．その他にも高速処理を組込み機器で実現するため
の MPI を用いたシステムアーキテクチャ等多数存在するが，基本的には組込み機器内部の
アーキテクチャの提案が多く，システム全体を考慮したアーキテクチャはあまり存在しな
いのが現実である．
４．２
Web アプリケーションシステムにおけるアーキテクチャ
Web アプリケーションにおけるアーキテクチャの提案は様々提案されている．Web アプリ
ケーションには様々な技術が組み込まれている．例えばオンラインショッピング等のサイ
トであれば大きく３つに分けられる．例えば商品の一覧を表示する画面，商品の情報を持
つデータベース，そしてこれらを繋げるコントロールプログラムの３点である．この点に
着目したアーキテクチャとして，Web アプリケーションにおける３層 IT アーキテクチャ[11]
19
と呼ばれている．つまり，先ほどのオンラインショッピングを例で言えば，ブラウザに表
示される商品の閲覧する画面をユーザインタフェイス（プレゼンテーション層）
，商品情報
等のコンテンツを管理する，ユーザインタフェイスと連結するビジネスロジック（ファン
クション層）
，そして商品情報を登録，保持しておくデータベース（データ層）と３つの層
に分けられる．これらの一連の動作を示したものが図 18 である．
３層 IT アーキテクチャの特徴は，データ加工処理をサーバ側で実行させることにある．
クライアントとサーバの間のデータ通信量が減るため，低速な回線を使っている場合やク
ライアントの台数が多い場合でも，応答速度が落ちにくいという特徴がある．また開発効
率の面では，アプリケーションを機能的に 3 モジュール（ユーザインタフェイス，ビジネ
スロジック，データベースの３つ）に分離することで，３つのモジュールを並行開発する
ことで，開発効率が向上し，生産性が向上する．また，システムに仕様変更等が発生すれ
ば，３モジュールのどれを変更すればよいかわかりやすく，仕様の変更作業が容易になる．
また，システム保守に関する作業負荷が減ることも期待できる．サーバ上のデータベース
の構造やデータの処理を変更があったとしても，クライアント上のモジュールを変更しな
くて済むからだ．
また３層 IT アーキテクチャとよく似ているが異なる MVC アーキテクチャモデル[12][13]
の述べる．MVC モデルとはソフトウェアアーキテクチャのひとつであり，M は Model，V は
View，C は Controller を示し，これら３つの頭文字を取って MVC モデルと呼ばれている．
Model は処理の中核を担う．つまり，メインのビジネスロジック処理は Model に搭載される
事になる．View はユーザインタフェイスへの出力を担当する．Model 等で処理された結果
をユーザインタフェイスに表示するものである．最後に Controller はユーザインタフェイ
スからのイベント処理を行う．例えば値の取得等が発生すればそれを取得し，処理が必要
な場合は Model に引き渡すものである．また Model からデータベースシステムを参照する
事で，データベースとのアプリケーション部分を独立させている．これらの動作をまとめ
たものが図 19 である．MVC モデルは機能を明確に３つに分ける事で開発性の向上，保守に
1 層目
リクエスト受付
リクエストの
あった情報を渡す
３層目
データ情報
の取得，更新を行う
DB server
(MY SQL)
AP Server
(Tomcat)
Web Server
(Apache)
Client
（Browser）
２層目
HTML
処理結果
ブラウザが解釈
できる HTML 等を返す
リクエストから
処理結果を返す
データ
データベースの
データを返す
図 18 Web における３層 IT アーキテクチャの一連動作
20
UI へ出力
UI からの入力
Controller
処理が無い場合
View
UI : ユーザインタフェイス
処理結果
処理依頼
DB 参照，更新
Model
DB
図 19 MVC モデルのアーキテチャ図
関する作業負担を減らすモデルであり，Web アプリケーションにおける３層 IT アーキテク
チャと同じ目的である．MVC モデルは特に Web アプリケーションに特化したアーキテクチャ
ではなく，アプリケーション全般を対象にしたアーキテクチャである．そのため，Web アプ
リケーションにおける３層 IT アーキテクチャと MVC モデルは見た目は似ているが，使用目
的や，概念が異なるものである．
４．３
cogma システム
本稿は Web サーバシステムと組込み機器を連結するためのアーキテクチャの提案である．
そこで，Web サーバシステムと組込み機器を連結するためのミドルウェアである cogma シス
テムについて述べる．Web サーバと組込み機器を連結するためのソフトウェアとして
cogma[14]と呼ばれるミドルウェアが存在する．cogma は組込み機器間の連携のためのミド
ルウェアである．cogma システムの開発には組込み機器にて利用するために組込み機器用で
ある Personal Javan を利用して開発している．cogma システムの特徴は cogma が搭載され
ている機器間を通信する移動ソフトウェアであり，機器Ａのソフトウェアの状況を機器Ｂ
に通信するものである．しかし，cogma はミドルウェアであり，機器間の通信ミドルウェア
の提案だけである．そこで WebCodGet が提案されている[15]．WebCodget システムとは，
cogma システムをベースにしたミドルウェアであり，各組込み機器に WebCodget と呼ばれ
る移動ソフトウェアを搭載する．移動ソフトウェアはネットワークを通じて自身が移動し，
組込み機器の制御や情報のやりとりを行う．WebCodget には組込み機器を制御するための
機器固有の情報と Web ページを生成するための HTML データを含んでいる．WebCodget は
ネットワーク上の Web サーバ機能を持った WebServerCodget へ移動する．組込み機器を操
作するユーザが WebServerCodget に Web ブラウザからアクセスすることにより，組込み機
器の情報が表示され，Web ブラウザから組込み機器の操作や設定が可能となる．しかし，
WebCodget を用いるだけでは多機種の機器連結ができなかった．そこで，LinkCodget[16]
が提案された．WebCodget を用いた JAVA アプリケーションであり，従来ミドルウェアであ
21
った WebCodget から値を取得，Java アプリケーションで更新する事により，WebCodget に
変更を加えず，組込み機器間の連結を実現可能にしたものである．この LinkCodget を
WebCodget 上にて動作させることにより，ブラウザから組込み機器の連結を実現したのであ
る．図 20 のように，これら３つのソフトウェアを利用する事連結を考慮した組込み機器を
Web アプリケーションにて操作するシステムが完成する．cogma システムは，Web サーバシ
ステムと組込みシステムを連結するソフトウェアは提案されているが，システム全体を考
慮したアーキテクチャではない．
Web サーバ
連結
処理
LinukCodget
組込み機器
WebServerCodget(cogma)
Java(J2DK)
Personal Java
LinuxOS
組込み機器
組込み機器
Cogma 専用組込み機器
WebCogget(cogma)
RS232c
Personal Java
LinuxOS
FireWare
Device Sensor
図 20 cogma を用いた全体のシステム図
22
５章
組込み機器を用いた３層 IT アーキテクチャの提案
従来の Web サーバを用いた組込みシステムの問題を踏まえて，新しい組込み機器を用い
た３層 IT アーキテクチャを提案する．３層 IT アーキテクチャとは，組込みソフトウェア，
アプリケーションソフトウェアを用いた統合システムを容易に開発，且つ高い保守性を提
供するためのシステムアーキテクチャである．本章では３層 IT アーキテクチャを新しく提
案し，その詳細について説明する．
5．1
３層 IT アーキテクチャのシステム例
３層 IT アーキテクチャは，ハードウェア，ソフトウェアの両観点から完全分離する事で
組込み機器とサーバとの依存関係を無くし，システムの拡張性や保守性を向上させるだけ
でなく，開発の容易性を向上させるシステム上のアーキテクチャである．３層 IT アーキテ
クチャを採用した Web アプリケーションのシステム例を図 21 に示す．３層とはハードウェ
ア，ソフトウェアともにサーバ層，コントロールクライアント層，マイクロクライアント
層である．まず，ハードウェアは３層とも別々のコンピュータ（仮想コンピュータも含む），
または組込み機器に相当する．さらにソフトウェアは，サーバ層に Linux 等の OS を搭載し，
Apache の Web サーバを導入し，同時に cgi で作成した Web アプリケーションを構築する．
つまり，従来のクライアントサーバシステムのサーバ部分のプログラムだけを導入する．
主なサーバ層の目的は，ユーザインタフェイスの提供とビジネスロジックの処理実行であ
る．従来の組込み機器を装備した Web アプリケーションとの差は，このサーバ層に組込み
機器の制御やインタフェイスなどの組込み機器依存のプログラムを導入しないことであり．
これにより，サーバと組込み機器のソフトウェア的な依存関係を排除しているところであ
る．さらにサーバ層が通信をするのはコントロールクライアント層だけであり，通信に必
要なデバイスドライバは一般的な通信用プロトコルである TCP/IP を利用し，組込み機器の
影響を排除している．
次に図 21 の２層目の説明をする．２層目はコントロールクライアント層であり，搭載す
る OS は Windows である．このシステム例ではマイクロクライアント層（３層目）の組込み
機器と相性のよい Windows を選択した．更に，３層目の組込み機器を制御するためのデバ
イスドライバや専用クライアントプログラムを導入する．これにより，コントロールクラ
イアント層とマイクロクライアント層はソフトウェア的に依存関係になってしまうが，サ
ーバ層とマイクロクライアント層の依存関係を排除したシステムアーキテクチャである．
３層目のマイクロクライアント層には組込み機器専用のファームウェアが導入され，組込
み機器の実際の動作を制御する．また，コントロールクライアント層とマイクロクライア
23
Webアプリケーション(Wiki.cgi)
Client Program
Apache
Micom_control_API
Hard ControlFirm Ware
OS(Linux)
OS(Windows)
Information Firm Ware
File System
Device Driver
HTML File
CGI File
Device
Driver
Device
Driver
TCP/IP
USB(UPNP)
Control Client
Server
Micro Client
図 21 ３層 IT アーキテクチャ全体像図
ント層の間は USB で接続する例のシステムである．そのために，マイクロクライント層の
コンピュータには USB 通信用のデバイスドライバが必要となる．
5．2
ハードウェアアーキテクチャ
現在の組込み機器を携帯情報端末等から操作する手法として大きく２つあると前述した
（３章参照）
．ひとつは，組込み機器内部へ Web サーバを搭載する．これは組込み機器と Web
サーバという本来ふたつのハードウェアをひとつにすることで，ネットワーク化するもの
である．もうひとつは Web サーバを外部に組込み機器とネットワーク越しに通信するとい
うものである．共に組込み機器をネットワーク化するという手法では共通なのだが，ハー
ドウェア的には全く異なる手法で実現している．しかし，これらのシステムには他のシス
テムや組込み機器との連結が考慮されていないという問題点がある．例えば，組込み機器
内部に Web サーバが内蔵された Web カメラ機器の場合（図 22 の①），その Web サーバにド
アロックセンサの新しい組込み機器の追加をしたい時，Web カメラのマイコンにドアセンサ
のドライバや，Web カメラのマイコンのファームウェアにドアセンサに関するロジックを書
いたプログラムを新しく追加する必要がある．多くの Web カメラのマイコン上のプログラ
ムの ROM 上に書かれており，新規の書き直しは不可能であり，新規にドアセンサの機能追
加ができない．また，Web サーバを通常のコンピュータ上に構築し，Web カメラなどの組込
み機器とハードウェア的に分離した場合（図 22 の②）において，おなじサーバ上で Web カ
メラとドアセンサが制御されている．もし，Web カメラの処理でハングアップした場合，接
続されているドアセンサの処理もハングアップし，システム全体が動作しなくなる危険性
がある．そこで図 23 のようなハードウェアアーキテクチャを提案する．
24
Web カメラ
Web サーバ
内臓
Web カメラ
Web サーバ
内臓
USB
ドライバ
システム全体がハ
ングアップ！
Web サーバに組
み込めない
ドアセンサ
ドアセンサ
①
Server
PC
First
Layer
①
図 22 従来のハードウェアアーキテクチャ
Cntrol
Client
PC
Second
Layer
データ通信
Micom
Device
Motor
Device
LED
Device
sensor
Device
IC Reader
Third Layer
デバイスの管理，操作
データ通信
図 23 ハードウェアアーキテクチャ
の問題
このアーキテクチャは従来のクライアントサーバシステムのアーキテクチャを引き継ぎ
第 1 層目に従来のサーバ PC，第 2 層目にクライアント PC，第 3 層目に組込み機器（マイコ
ン）と分ける．これによって３層目の組込み機器と 1 層めのサーバ PC を完全分離し，ひと
つの組込み機器のハングアップによってシステム全体がダウンすることを防ぐ．図 23 の
「ServerPC」とは Web サーバを導入し，実際のビジネスロジックを書いたプログラムが実
行するＰＣのことである．また，「Cotrol Client PC」とは 1 層目の Web サーバからの「電
灯の ON」などの制御命令をうけとって，マイコンの LED を消灯させる命令を出す部分であ
る．３層目に属するマイコンとは各デバイス（モニタ，LED,IC レコーダなど）を制御する
ためのものであり，直接マイコン上のピンで各デバイスの通信ポートへつながっている．
提案するアーキテクチャの最大の特徴は，クライアントＰＣをコントロールクライアント
と位置づけ，コントロールクライアントにて第３層目である組込み機器を制御することで
ある．つまりコントロールクライアントにて，組込み機器のデバイス管理，もしくは３層
目のマイコンとの通信データの管理を行う．更に Web サーバとコントロールクライアント
間にて通信の規格統一を行う．本来組込み機器と Web サーバを通信するためには通信規格
が統一されなければいけなかった．しかし，本アーキテクチャは組込み機器の通信規格の
違いをコントロールクライアントにて吸収し，一つの規格へ変換することで通信が異なる
規格の機器でも間接的に Web サーバと接続する事が可能である．
ハードウェアの３層構造にすることにより，Web サーバと組込み機器を連結する際に発生
する依存関係を切り離す事が可能となる．
5．3
ソフトウェアアーキテクチャ
ハードウェアアーキテクチャを３層化するに伴い３層ソフトウェアアーキテクチャの提
案も行う．図 24 が３層ソフトウェアアーキテクチャである．３層ソフトウェアアーキテク
25
コントロール
サーバ層
Client Server
Architecture
クライアント層
Web
Server
AP
Server
DB
Server
Network
Server
マイクロクライアント層
Micom
Firmware
Information
Controller
Program
.........
Sensor.Get()
Serverup(){}
Generating
command
Readpin Writepin Binary
API
.........
Read
Out_Electric_
PA0()
Get_Electric_
PB0()
Write
Device
sensor
Device
LED
PA0
×
0
PA1
×
1
×
PB0
0
×
PB1
0
PC0
×
0
Operation Map
Device_Driver
First
Layer
Second
Layer
Third Layer
図 24 ３層ソフトウェアアーキテクチャ
チャは汎用性の向上，安全性，そして開発の容易性を考慮したアーキテクチャである．本
アーキテクチャを 1 層目（サーバ層），２層目（コントロールクライアント層），３層目（マ
イクロクライアント層）の順に説明していく．まずサーバ層へ導入するソフトウェアは，
Web サーバ，AP サーバ（アプリケーションサーバ），DB サーバ（データベースサーバ）など
のサーバ側のプログラムを導入する．サーバ側のプログラムとは，おもにユーザの入力や
情報参照のインタフェイスをグラフィカルに表す部分（Web アプリケーションならば，ブラ
ウザで参照できる部分）と組込み機器間のロジック制御する部分（センサが反応すれば LED
が点灯するなど）を含む．ただし，それぞれの組込み機器を操作するプログラムなどを導
入せず，また組込み機器のドライバなどは導入しない．
続いて，２層目のコントロールクライアント層について述べる．コントロールクライア
ントでは，サーバと通信，組込み機器と通信の 2 種類の通信を行うプログラムを実装する．
まず，サーバとの通信方法について述べる．ここでの通信手法にはとらわれない．つまり
専用の通信プログラムや，IE コンポーネント等のブラウザを実装したプログラムでも通信
可能とする．従来の組込み機器で問題となっていた「専用サーバと専用通信プログラムで
しか動作できなかった問題」を新たにクライアントプログラムの作成で，通信の依存関係
を排除する．更に，組込み機器等のデバイス管理のデバイスドライバ等もコントロールク
ライアント層に導入する．これにより，従来のシステムは，Web アプリケーション構築を行
っているサーバにデバイスドライバ等の導入を行っており，デバイスドライバに障害が発
生するとサーバ全体がダウンする可能性がある．このような重大な影響を避けるために，
サーバ層にデバイスドライバは導入しないことで，サーバの安定化が図れる．
もうひとつのコントロールクライアント層の特徴は組込み機器に関する API 群を用意す
ることである．API とは図 24 の 2 層目の「Program」に示すように，
「Sensor.Get()」メソ
ッドのように直観的に理解しやすいメソッドをコールする．実際は図 24 の２層目の「API」
で示すように，「Out_Electric_PA0()」や「Get_Electric_PB0()」のように，マイコンボー
26
ドの PA0 ピンに電力を供給を停止するとか，PB0 ピンに電力を供給するなどのマイコンを実
際に操作する処理である．API はマイコンごとに異なるが，これらを準備することでクライ
アントプログラム作成が容易となる．ただし，マイコンや組込み機器のメーカよりの API
群提供があればよいが，もし提供がない場合は，この部分を開発者が実装する必要がある．
クライアントプログラムが特定の組込み機器に大きく依存しないためにも，API 群の準備は
必要である．
最後に３目のマイクロクライアント層のソフトウェアを説明する．まず，マイクロクラ
イアント層にはファームウェアが必要である，ファームウェアとは，マイコンを直接制御
するための基礎的なソフトウェアで，コンピュータの OS に相当する．ファームウェアの役
割はマイコンの各ピンに対する電力供給を ON,OFF したり，各ピンからへ１や０の情報を送
ったり，また各ピンからの１や０の情報を受け取る処理を提供することである．もちろん，
マイコンによってファームウェアのピン配列やそれぞれの役割は異なる．各マイコンにシ
ステムの開発者が作成したオリジナルのファームウェアを導入できる場合はよいが，多く
の場合はマイコンのファームウェアは ROM(Read Only Memory)に工場出荷時に書き込まれて
おり，システム開発者であるユーザが容易に書き換えられるものではない．そこで，図 24
のマイクロクライアント層に示すように，Operation Map をもつ．これはマイコンごとのピ
ン配列の差異を吸収するものであり，マイコンごとに，
「PA0 は読み込み専用のピンであり，
現在は 0 である」という情報を各ピンに対応して持つ．PA0 がどのデバイスにつながってい
るかの管理は，マイクロクライアント層の「Control」部分でおこなう．つまり，「LED を
ON」の命令をマイクロクライアント層が受ければ，「Control」プログラムが Operation Map
を参照して，
「PB0 ピンを１にすればよい」という情報を得ることで，
「PB0=1」を実現する
マイコンへのコマンド（ピンへ情報を送る命令）を自動生成して，実際にマイコンへ write
処理をおこなうこととなる．これによって，異なるピン配列のマイコンでも同様の LED 点
灯の処理を実際に行うことができる．
５．４
簡易汎用ファームウェアの提案
ここで，マイクロクライアント層に装備するファームウェアについてもう少し詳しく説
明する．本来はマイコンメーカがあらかじめ ROM に焼き付けたファームウェアが存在し，
容易に変更することはできない．そのために本稿では 5.2 で示すように，Operation Map を
利用した Control プログラムで各マイコンのファームウェアの差異を吸収した．ここでは，
マイコンに新しいファームウェアを書きこめるケースを想定し，開発したファームウェア
について説明する．実際に本稿で実現したシステムはこのファームウェアを導入したマイ
コン上で動作している．
図 25 に今回開発した簡易ファームウェアの利用方法の概要を示す．メーカから変更不可
のフォームウェアを提供された場合と同様に Oepration Map を利用する．さらに，密接な
27
Micom information map
API群
Set_Electronic(byte Binary){
ez-usb.outdata(Binary)
}
Get_Electronic(){
return ez-usb.indata();
}
Get_pulse(byte Binary){
return ez-usb.pulseindata(Binary)
}
Set_pulse(byte Binary byte data){
ez-usb.pulseoutdata(Binary , data)
}
PA０～７
PB０～７
PC０～７
1bit
2bit
3bit
4bit
5bit
6bit
7bit
8bit
PA
0
0
1
0
0
1
0
1
PB
1
1
0
0
0
0
0
1
PC
0
0
1
0
1
1
0
1
PD
1
0
0
0
0
1
1
1
PD０～７
bit
0
0
1
0
0
1
0
1
Pin
name
PA0
PA1
PA2
PA3
PA4
PA5
PA6
PA7
LED
state
OFF
OFF
ON
OFF
OFF
ON
OFF
ON
図 25 簡易汎用ファームウェア
関係があるのがマイコンを操作する API 群である．図 25 の API 群の例では，
「 Get_Electronic() 」や「 Get_Pluse() 」のようにマイコンの状況を読み取る API と
「Set_Electronic()」「Set_Pluse()」のようにマイコンへ命令を送るメソッドをそれぞれ
お提供する．これらのメソッドでは，「ez-usb.pulseindata()」のようなマイコンを直接操
作するメソッドを用意する．このメソッド「ez-usb.pulseindata()」がマイコンメーカか
ら提供された場合とオリジナルでファームウェアとして作成した場合にわかれる．どちら
にしても，Operation Map を利用してマイコンのピン配置とその役割を明確にする．今回開
発したファームウェアでは，LED デバイスへ電力供給し点灯 ON にする場合は，ピン PA0～7
を利用し，LED デバイスの点灯状況を知るにはピン PB0～7 を利用する．また，ドアセンサ
などの状況を知る場合はピン PC0～7，ドアセンサなど命令を送る場合はピン PD0～7 を利用
する（図 25 参照）．また，それぞれの命令には 8 ビットの情報がもてるので，同時に 8 つ
のデバイス，つまり 8 つの LED を操作することが可能である．
簡単システム実装例を図 26 を用いて説明する．図 26 のようなコンセントを挿すと電源
が入るようなコーヒーメーカがある場合，コンセント部分にリレー回路（シーケンス制御）
を搭載したマイクロコンピュータを搭載する．
これを図 25 の簡易汎用ファームウェアの PA0
番目から７番目まで 3.3V の電源を供給を行うために，クライアントプログラムから API 関
数の Out_Electric0()等のメソッドを呼ぶ．これにより，容易にリレー回路に電気を供給，
リレー回路の接点が繋がり，コーヒーメーカの電源が入るというものである．図 26 の実装
例は今回作成したファームウェアを利用したので，PA0～7 などのピン配置を自由に変更で
きるが，あらかじめメーカから提供されたファームウェアの場合は Operation Map を作成
して，それぞれのファームウェアに合わせたピン配列にて命令を実行する必要がある．こ
のように，API 群やファームウェアを用意することで，組込みソフトウェアの開発が容易と
なり，組込み機器のハードウェアインタフェイス依存が低減されたプログラムを作成する
ことができる．また，リモコン等が搭載されている組込み機器において，学習リモコン
28
Client Program
Cofe_maker_ON(){
API.Set_Electronic(1);
}
コーヒーメーカ
API 群
Set_Electronic(Byte Binary){
Ez-usb.outdata(Binary);
100Ｖ
}
bit
0
Pinname PA0
Electronic OFF
ＰＡ0
ＧＮＤ
EZ-USB(Micom)
図 26 簡易汎用ファームウェア実装例
を応用したファームウェアと API も提供する．これにより，メーカから組込み機器を操作
する外部インタフェイスや API が提供されていなくても，家電製品の一部の操作を実現で
きるファームウェアとその API の提供を行う事が可能となる．
29
６章
３層 IT アーキテクチャの試験的実装と検証
６．１試験的実装したシステムの概要
前章で提案した３層 IT アーキテクチャの検証をおこなうために，試験的なシステムを実
装して検証する．システムは図 27 に示すような，赤外線センサと LED を組み合わせたシス
テムである．本システムでは，赤外線センサにて感知すると LED を点灯させるシステムで
ある．つまり，赤外線センサと LED の２つの組込み機器をマイクロクライアントとコント
ロールクライアントで制御し，ユーザは Web 上で制御を確認するシステムである．これに
よって，異機種間の組込み機器の連携が提案するアーキテクチャ上での構築の可能性，さ
らに容易性について検証する．
図 27 試験的に実装したシステム
６．２
３層 IT アーキテクチャ試験的実装
検証用のシステムの具体的な実装の構成を図 28 に示す．図 28 の Server が図 27 の「サ
ーバ」であり，同様に Control Client1 と Control Client2 が「コントロールクライアン
ト」，Micro Client が「マイクロクライアント」にそれぞれ対応する．システムの主な動作
としては，赤外線センサに反応があった場合，LED が点灯するという２つの組込み機器が相
互作用しながら動作するシステムである．構築手順を以下に示す．
30
Server
Apache
(Web Server)
Wiki.cgi
Control Client1
Micro Client
Cleirn Program
① Server Conection
② Micom Control
general-purpose
Firmware
Device Driver
⑤Sensor page
⑥LED page
Control Client2
Cleirn Program
① Server Conection
② Micom Control
Access
Client
Device Driver
PC
Nintendo DS
PSP
③Device Sensor
Micro Client
general-purpose
Firmware
④Device LED
図 28 試験的実装の全体像
1．サーバ層
Step１．サーバに Apache[17]と CGI 動作用に ActivePerl[18]を導入しておく．尚今回は
OS に WindowsXP Pro を採用する．
Step２．サーバプログラム等の設定終了後，Web アプリケーションの導入を行う．今回使
用するプログラムはオープンソースである FreeStyleWiki（URL を入れてくださ
い．）をカスタマイズせずに導入する．
Step３． FreeStyleWiki の設定終了後，接続された組込み機器のそれぞれの情報をアップ
ロードして表示する Web ページを作成しておく．
２．コントロールクライアント層
Step１．複数台数のコントロールクライアント PC を用意し，それぞれに組込み機器のデバ
イスドライバを導入する（図 27 の場合は一台のコントロールクライアント PC に
２つの組込み機器を接続し，それぞれのデバイスドライアを導入している）．コン
トロールクライアントに導入する OS は共に Windows XP Pro を導入しておく．
Step２．２つの機能を搭載したクライアントプログラムを作成する．機能のひとつめとし
て，サーバ層との通信機能である（図 28 の「①Server Connection」）
．組込み機
器に何らかの反応があった場合にサーバ層の Wiki の Web ページ（図 28 の「⑤
Senser page
と
⑥LED page」）に組込み機器の状況を文字列として書き込む機
能である．また，サーバ層に情報を監視し，ユーザが操作の指示をするために文
字列の入力があった場合（更新があった場合）に，その文字列を通信して受け取
る機能である．ふたつめの機能は，組込み機器の制御である（図 28 の「②Micom
31
Control」）．これは本提案のひとつである簡易汎用ファームウェア（図 28 の
「general-purpose Firmware」）の API 群を利用して作成する．
今回実装するのは，
組込み機器の電力状況のチェックと電力送信機能の２点だけを実装する．
３．マイクロクライアント層
Step１．マイクロコンピュータ（以下 EZ-USB[7]）をコントロールクライアント PC に USB
にて接続する．今回は外部との接続に USB を使用するが，X-Port[19]等を用いた
Ethernet 接続でも可能である．
Step２．今回提案する簡易汎用ファームウェア（図 28 の「general-purpose Firmware」）
を EZ-USB の ROM に書き込む．本来 EZ-USB は接続する度にファームウェアを転送
する必要があるのだが，直接書き込む事でその作業を省き，煩雑さを減らす．
Step３．フォトリフレクタを用いた簡易赤外線センサ（図 28 の「③Device Sensor」）を作
成する．これにより，フォトリフレクタの電力状況をコントロールクライアント
が監視することができる．さらに，EZ-USB から電力出力があったかを確認するた
め，発光ダイオード（図 28 の「④Device LED））を取り付けておく．コントロー
ルクライアントと API が正常に作動すれば，EZ-USB から 3.3V の電流が流れ，発
光ダイオードが点灯する．
６．３
３層 IT アーキテクチャ試験的実装詳細説明
６．３．１
サーバ層
試験のサーバ層は一切の特別なソフトウェアの導入を行わず，従来のソフトウェアを使
用するには大きくふたつの狙いがある．ひとつは，サーバと組込み機器との依存関係が無
く動作することを確認するためである．今回 Apache と FreeStyleWiki を使用することによ
り，サーバ側には LED の点灯情報や赤外線の反応状況のデータ情報のみを保存しておく事
しかできないという事を強調するために使用した．ふたつめの狙いは，従来の Web アプリ
ケーションを使用することにより，レスポンスの問題の確認のためである．通常の組込み
システムの場合は，レスポンスを向上させるために専用通信ポートを使用し，専用通信プ
ログラムを作成する必要がある，しかし，専用の通信ポートやプログラムはサーバ層とコ
ントロールクライアント層の間に依存関係が発生しかねない．そのためにも専用通信プロ
グラム無しの従来の Apache と FreeStyleWiki にて組込み機器からのレスポンスと組込み機
器へのレスポンスの性能について調べることが目的である．
32
６．３．２
コントロールクライアント層
コントロールクライアント層に導入するクライアントプログラムには大きくふたつの役
割を有す．ひとつはサーバとの通信プログラム（図 28 の「①Server Connection」），ふた
つめが組込み機器制御プログラム（図 28 の「②Micom Control」）である．サーバ通信は前
述したように専用通信プログラムを使用しない．そこで，サーバとの通信を行うため，ブ
ラウザを経由しサーバ上に存在する Web サーバの特定のページ（図 28 の「⑤Senser page
と ⑥LED page」）を参照する．今回クライアントプログラムをＣ＃にて作成するため，.NET
Framework に搭載される IE コンポーネントを使用してサーバとの通信を行う．ネットワー
ク通信方法を図 29 に示す．IE コンポーネント用いて実行することは Wiki 上に特定の文字
列が書かれているかのチェックと，Wiki 上の書込みページから特定の文字列を取得する方
法である．書き込みページの場合は，コントロールクライアント層からの指示で特定の文
字列が書き込まれる場合と，ユーザが直接 Wiki のページ上で文字列を入力する場合の 2 種
類ある．例えば，Wiki の読み込みページに「SENSOR_ON」等の文字列が入力されると，それ
を感知したコントロールクライアント層のプログラムが LED に電力を共有して LED を点灯
させる．さらに，LED が点灯したので，コントロールクライアント層のプログラムがサーバ
層の Wiki の書き込みページに「LED_ON」の文字列を書き込むという処理の流れである．
SENSOR_ON
Wiki 情報読込みページ
LED_ON
IE コンポーネント
情報取得
情報書込み
GET webString(String, URL){
IE_com.getstring(String);
…………
}
SET webString(String , URL){
IE_com.setform(String);
IE_com.submit();
…………
}
EZ-USB API
Wiki 情報書込みページ
通信
Micom Firmware
EZ-USB
図 29 コントロールクライアントのプログラムのネットワーク通信方法
33
Control class
Main1 () {
string info = GETwebString(string , servername);
If(info = string) Set_Electronic(1);
}
Main2(){
byte ezinfo = Get_Electronic();
SETwebString(byte , sarvername);
}
IE コンポーネント
EZ-USB API
GET webString(String, URL){
IE_com.getstring(String);
…………
}
SET webString(String , URL){
IE_com.setform(String);
IE_com.submit();
…………
}
Set_Electronic(byte Binary){
ez-usb.outdata(Binary)
}
Get_Electronic(){
return ez-usb.indata();
}
図 30 クライアントプログラム詳細
またプログラム詳細図を図 30 に示す．今回作成するクライアントプログラムは Main1 と
Main2 から成り立っている．Main1 は Web ページ上から特定の文字列を検出し，検出された
ならば，API 群の Set_Electronic を呼び出す．呼び出された API により EZ-USB に電力を送
信する命令を送信する事により，EZ-USB に取り付けられている LED が発光するのである．
また Main2 はセンサの状況（電力状況）を常に監視し，センサに反応があった場合 Wiki 上
に文字列を書き込む．書込み方法は先に述べたように特別な通信プログラムを用意せず，
ユーザが Wiki の書込みページから書込みフォームに特定の文字列を書込み，その後書き込
みボタンをプログラム上から押す．またはコントロールクライアント層のプログラムが特
定ページに指定の文字列を書きこむ．これにより，通信プログラム無しでも組込み機器の
状況をアップロードできる他，他システムとの連結も文字列を調べる事で連結することが
可能となる．
６．３．３
マイクロクライアント層
マイクロクライアントにはマイコンと簡易汎用ファームウェアを搭載した EZ-USB を用意
する．EZ-USB とは CPU、メモリ等を搭載した学習用マイコンボードである．これに汎
34
情報取得先 URL 入力フォーム
情報書込み先 URL 入力フォーム
情報取得開始ボタン
情報書込み開始ボタン
図 31 実際に作成したクライアントプログラム
用ファームウェアを搭載する．今回汎用ファームウェアには電力のチェック機能と，電力
出力機能の２点を組み込んだ．電力チェック機能は特定の PIN（マイコンのポート）にある
一定の電圧が掛かれば EZ-USB のレジストリに 1 のフラグがたつ．そのフラグがたっている
かをファーム上でスキャンするものである．また電力出力に関しては，レジストリにフラ
グをたてることにより，Hi の電流（3.3Ｖの電流）を特定の PIN に出力する．これにより，
電力チェック，電力出力を行う仕組みを作成した．後はフォトリフレクタの接続線を EZ-USB
上の指定の PIN へはんだ付けし，また LED の接続線も EZ-USB 上の指定の PIN へはんだ付け
する電子工作をおこない，フォトリフレクタを用いたセンサと発光ダイオードの簡単な組
込み機器を作成した（図 27 の右の図を参照（発光ダイオードと EZ-USB の組込み機器の例））
．
６．４
３層 IT アーキテクチャによる検証
従来の組込み機器を用いた問題点はすでに３章で説明した．以下に簡単にまとめる，
①．他の組込み機器システムとの連結が困難である
②．組込み機器自身に Web サーバを搭載した場合，グローバル IP が必要となる
③．Web サーバに組込み機器管理プロセスが搭載されるため，システムが機器依存にな
る
④．組込み機器等にトラブル発生時，システム全体への影響
本稿で提案する 3 層 IT アーキテクチャは上記の 4 つの問題点に関して有効であるかを検証
する．
① 他の組込み機器システムとの連結
従来のように組込み機器へ Web サーバを組み込んだ場合を考える．例えば，エアコン
35
に組み込まれているマイコンに Web サーバを組み込んで，直接携帯電話からエアコンの
Web サーバへアクセスできるシステムを構築した場合には，温度センサを新しく追加し
て，室温が一定温度以上になった場合エアコンを ON にするという新しいデバイス機器
をこのシステムに組み込むことが現実的に不可能という問題がある．なぜならば，エア
コンのマイコンに直接 Web サーバのプログラムが書き込まれているので，それを変更す
るにはエアコンの製造工程から変更する必要があり，すでに出荷済みのエアコンのマイ
コン上のプログラムを書き換えることが現実には不可能だからだ．また，赤外線センサ
に接続された EZ-USB のマイコンに Web サーバを搭載した組込み機器を作成したとする．
Web サーバのプログラムは赤外線センサの状況を読み込むだけのプログラムがマイコン
にすでに書き込まれている．この赤外線センサの組込み機器に発光ダイオード等を取り
付けて，赤外線センサに反応があった場合に発光ダイオードを点灯させる Web サーバの
プログラムを追加したくても，すでに Web サーバのプログラムは EZ-USB のマイコンに
プログラムが書き込まれており，変更することができない．このようなエアコンや試験
的に作成した赤外線センサの組込み機器の例のように，マイコンに書き込まれたプログ
ラムを変更する必要があるので，他のシステム（今回は他の組込み機器）との連結は困
難である．
そこで，今回作成した３層 IT アーキテクチャの試験的システムでは新規デバイスの
追加が実現できるかを検証した．検証内容は，まず，今回作成したシステムにセンサ機
能だけを持った EZ-USB を取り付けておき，後から発光ダイオードのついた別の EZ-USB
を取り付け，連結が可能かを確かめた．検証内容を図 32 に示す．図 32 の赤い破線で囲
われている発光ダイオードの部分をセンサ機能だけをもったシステムに導入し，実際に
センサに反応があった場合に発光ダイオードが反応するような相互作用するシステム
が容易に構築可能であるかを検証する．
検証結果として，センサに反応があった場合，クライアントプログラムが反応し，指
定した Wiki のページにで「Sensor_OFF」から「Sensor_ON」という文字列に書き換えた．
それを監視していた，LED を管理しているクライアントプログラムが反応，クライアン
トプログラムから EZ-USB に電力命令を出し，発光ダイオードが点灯した．このように，
クライアントプログラムには簡単な書込み先 Web ページに特定の文字を書く，読み込み
先の Web ページに特定の文字があるか等を調べる簡単なプログラムである．実際にセン
サに反応があれば，発光ダイオードが点灯するという組込み機器間の連結をサーバ経由
で行う事が確認できた．今回ひとつのコントロールクライアントで行ったが，他の別の
コントロールクライアントを用意し，ネットワークで接続した際にも同じ結果になった．
これにより，例えば離れている組込み機器同士の連結もコントロールクライアントを複
数代用い，サーバを経由することで連結が可能という事も可能である．ｓ
36
Wiki.cgi
Server
Sensor page
Add System
Control Client1
Client Program
(sensor)
Client Program
(LED)
Device Sensor
Device LED
図 32 検証 1．他の組込み機器との連結
② グローバル IP の必要性
組込み機器へ Web サーバを組み込む場合，携帯電話等からその機器にアクセスする場合，
組込み機器ひとつに対してひとつのグローバル IP を割り振る必要が発生する．これはすべ
ての組込み機器に Web サーバを搭載する際どうしても避けられない問題である．そこで，
今回提案する３層 IT アーキテクチャではサーバに組込み機器の全ての情報を集約する．つ
まり，このサーバに携帯電話等でアクセスするだけで，管理されている全ての組込み機器
を操作する事が可能となる．つまり、複数個の組込み機器がシステムに接続されていたと
してもサーバ層のコンピュータに設定されたひとつのグローバル IP アドレスだけで、すべ
ての組込み機器の操作ができるということである。つまり、Web サーバはシステムに一つし
か存在しないので、このようにグローバル IP アドレスはひとつの設定で動作可能となる．
更に，実装したシステムは FreeStylWiki の Web アプリケーションを用いているため，CGI
が動作する Web サーバなら組込み機器を操作する Web アプリケーションを構築することが
可能である．つまり，自宅に設置したコンピュータに本システムの Web サーバを構築しな
くても，CGI が動作するレンタルサーバを用いる事ですべての組込み機器を操作するシステ
ムを実現する事が可能となる．（図 33 参照）
③ Web サーバに組込み機器管理プロセスが搭載されるため，システムが機器依存になる
従来の組込み機器と Web アプリケーションを連結するには，ひとつの組込み機器を管
理するためにひとつの組込み機器管理プロセスを導入する必要があった．例えば図 34
のように，発光ダイオードを操作する Web アプリケーションがあったとする．ここ
37
A さん宅
Ｃさん宅
Ｄさん宅
レンタルサーバ
（グローバルＩＰ付加）
Ｂさん宅
Wiki A さん用
Wiki Ｂさん用
Wiki Ｃさん用
Wiki Ｄさん用
図 33 １サーバで複数の機器を操作するシステム例
に例えば赤外線センサ（図 34 赤丸点線部分）を追加し，発光ダイオードと一緒に赤外
線センサの管理も行うシステムを構築すると仮定する．実現するためには，発光ダイオ
ードを操作する Web プログラムと，赤外線センサを操作する Web プログラムを連結する
必要性が発生する．これらは実現する事は不可能ではないが，２つの専用プログラムを
連結することはシステムの設計，運用上非常に危険な事である．更に，今回例として赤
外線センサを述べたが，例えば 100 個の新しい機器を追加する等を想定
発光ダイオード専用
Web アプリケーション
発光ダイオード
発光ダイオード専用
通信プログラム
System
赤外線センサ専用
サーバ
Web アプリケーション
赤外線センサ専用
通信プログラム
赤外線センサ
Add System
図 34 専用サーバへ新規組込み機器を追加するための方法
38
Wiki.cgi
コントロールクライアント
発光ダイオード専用
LED page
クライアントプログラム
サーバ
Sensor page
赤外線センサ専用
クライアントプログラム
Add System
赤外線センサ
発光ダイオード
図 35 ３層 IT アーキテクチャによる新規機器追加方法
した場合，100 個の専用プログラムを連結する必要が発生し，現実的に不可能に近い事
なる．
そこで今回実装したシステムの場合のシステム依存のイメージは図 35 となる．新し
く追加する赤外線センサとクライアントプログラムをコントロールクライアントに導
入する．そしてサーバ上にある Wiki にて新しく組込み機器の情報をアップロードする
ための Sensor page を作成しておく．これで他システムの導入が可能となる．また発
光ダイオードと赤外線センサを連結したい場合，クライアントプログラムに機器の情
報を読み込む機能を追加しておくと，発光ダイオードと新規追加した赤外線センサを
連結する事ができ，サーバ上の Web アプリケーションにはプログラムの修正無しで追
加，連結することが可能となり，実際に検証したところ，動作することも確認するこ
とができた．
④ 組込み機器等にトラブル発生時，システム全体への影響
従来のシステムにはサーバ層のコンピュータに Web アプリケーションと組込み機器の
管理プロセスを一緒に管理していた．このようなシステムを大規模システムに適応した
場合に不安要素が発生する．それはひとつの組込み機器のトラブルによってシステム全
体がダウンしてしまう可能性が発生する．具体的なトラブル発生について図 36 を用い
て説明する．図 36 には Web サーバに様々なセンサが取り付けられていて，それぞれを
管理するプロセスを Web サーバに搭載されている．更に Web サーバと DB サーバを連結
し，DB サーバにセンサの状況を保持している．これによって組込み機器を管理する Web
39
センサＡ
DB サーバ
トラブル発生
Web サーバ
センサＢ
本来，問題ないセン
センサＡと通信ができなく，
サだが，サーバの処
処理がそこでストップ
理が止まっているた
センサＣ
め，動作せず
図 36 ひとつの機器にトラブル発生時，システム全体への影響
アプリケーションが構築できている．しかし，ここでセンサＡ（図 36 中点線赤丸）に
トラブルが発生したとする．本来は Web プログラムではセンサＡはトラブルが他のセン
サの機能に影響を与えないシステム設計とすべきである．しかし，未熟な設計者の構造
設計やプログラムミスにより，センサ A の障害が他のセンサの機能へ影響を及ぼす可能
性もある．たとえば，センサ B が ON から OFF に変わった時，センサ A も OFF へ変更す
る場合，センサ A はダウンしているので返答はない．その返答を待ち続けるような設計
ミスやプログラムミスをおかすと，システム全体は Web アプリケーション自身のエラー
でダウン，または Web サーバ（図 36 中点線青丸）がダウンしてしまう可能性が発生す
る．さらに他の組込み機器（図 36 中緑丸）が動作しなくなり，最悪 DB サーバへも影響
を与えてしまう可能性がある．
このように，ひとつの組込み機器のトラブルでシステムに致命的なダメージを与えて
しまうので，今回試作的に作成した環境にてシステムダウンの影響を検証してみた．
まず，最初にひとつの組込み機器がシステム全体へ影響を及ぼす環境を構築する．こ
の環境の概要を図 37 に示す．Web サーバ自身に組込み機器管理プロセスを導入した Web
アプリケーション（ASP にて構築）を作成し，そこに LED がついた EZ-USB，赤外線セン
サがついた EZ-USB のふたつのデバイスを取り付ける．ここで，Web アプリケーションに
おいて，２つの EZ-USB の通信プログラムを Web ページの最初に呼ばれるフォーム
（FormLoad）に記述しておく．その後，何らかのトラブルでケーブルが断線したと想定
して，サーバと EZ-USB2 を接続しているケーブルを切断する．この時本来は EZ-USB2 は
トラブルで動作しないが，EZ-USB１に接続されている LED は動作可能な環境を構築する
べきである．しかし，実際稼動してみると，Web アプリケーションエラーでページの表
記すらされない状況であった．エラーは簡単なもので，先ほどプログラムの最初に呼ば
れるフォームに EZ-USB のそれぞれの通信プログラムを記述してしまったためである．
つまり，EZ-USB2 のケーブルが断線しているのにも関わらず，通信を行おうとし，その
結果エラーが返ってきてしまう．ここで，本来エラーが返ってきたとしても，通信部分
40
EZ-USB1
LED
Web サーバ
EZ-USB2
センサ
Web アプリケーション
(ASP にて構築)
このケーブルをサーバから抜く
EZ-USB1 デバイス管理
EZ-USB2 デバイス管理
図 37 組込み機器の Web サーバへのシステムへの影響力の検証
をスキップし，別処理に行けばよいのだが，プログラムミスでその処理を書き忘れた場
合にはシステム全体が停止してしまう．このようにサーバ自身に組込み機器の管理プロ
セスを導入することにより，ひとつの組込み機器トラブルで，システム全体のトラブル
へと繋がりかねない．
次に，提案する３層 IT アーキテクチャを使ったシステムでのひとつのデバイスダウ
ンによるシステム全体への影響の有無を検証する．検証するためのシステムの概要を図
38 に示す．
図 38 のようにシステムを構築した際，コントロールクライアントを２つに分けるこ
とで，システム全体への影響力を最小限にする事が可能である．例えば，先ほどと同様
コントロール
クライアント 1
EZ-USB1
LED
サーバ通信プログラム
Web サーバ
デバイス管理プロセス
Web アプリケーション
(Wiki.cgi)
コントロール
クライアント 2
EZ-USB2
センサ
サーバ通信プログラム
デバイス管理プロセス
ケーブル切断
図 38 ３層 IT アーキテクチャによるシステムトラブル検証
41
にコントロールクライアント２と EZ-USB２間のケーブルにトラブルが発生したとする．
ここでクライアントプログラムのエラー処理に不備があり，クライアントプログラムが
停止してしまったとする．この時，コントロールクライアントのシステムは停止してし
まうが，サーバの Web アプリケーションはコントロールクライアントから最新の情報の
更新がないだけで済み，他の機器は正常に動作する事が可能となるのである．このよう
に，複数個のコントロールクライアントを確保することにより，例えば電子ロック等重
要な機器を管理するハイリスクなシステムの構築に役立つ．電子ロックのコントロール
クライアントを用意することで，他のシステムからの影響を確実に受けないシステムの
構築も可能である．また，Web サーバがダウンしてしまった場合等の最悪の事態におい
ても，コントロールクライアントにリモートデスクトップ等のターミナル等から入り，
直接機器を操作可能等，最悪の事態への対応も可能となる．実際にこれについて検証を
行ったところ，確かにトラブルが発生した機器のコントロールクライアントプログラム
はエラーで処理が停止していたが，他の組込み機器を問題なく動作させる事が可能であ
り，サーバシステムがダウンするという最悪の事態を避ける事が可能であった．
以上のように従来の組込み機器を導入した Web アプリケーションの４つの問題は提案す
る３層 IT アーキテクチャに基づくシステムによって，回避できることが確認できた．
42
７章
３層 IT アーキテクチャを用いたシステム構築
本章にて３層 IT アーキテクチャを用いた実際に運用するシステムを構築する．構築する
システムはふたつである．ひとつめはニンテンドーDS 等のゲーム機から家電量販店等で販
売されているコーヒーメーカの電源を入れるシステム．ふたつめは著者が自宅で飼育して
いる熱帯魚を管理するシステムの構築である．これらを本提案である３層 IT アーキテクチ
ャを用いて構築する．
７．１ニンテンドーDS からコーヒーメーカの電源を入れるシステムの構築
作成する Web アプリケーションの概要を図 39 で示す．まず，コーヒーメーカの電源を
操作する電子回路（図 39 の電源スイッチ）を作成し，電源スイッチを EZ-USB に接続する．
EZ-USB はあらかじめ電源スイッチへ電力を供給するファームウェアを自作で導入しておく．
さらにノートパソコンに EZ-USB のファームウェアで提供される API 群をつかって，電源の
ＯＮ，OFF を実行するプログラムを導入する．さらに Web アプリケーションのサーバプログ
ラムはブラウザ上にユーザが操作する「ＯＮ」や「OFF」のボタンを表示する．これによっ
て，ユーザがニンテンドーＤＳの OPERA ブラウザで「ON」ボタンをクリックすると，コー
ヒーメーカの電源がＯＮになり，コーヒーが沸かせるシステムである．
（１）サーバ層のプログラム
サーバ層のプログラムは６章では FreeStylewiki（以下 wiki）を当初は用いた．しかし，
wiki を用いてシステムを運用する際，ひとつの組込み機器を操作するたびに，ユーザは特
定の文字列を入力しなければいけない．これはユーザにとって非常に煩雑であり操作性が
悪い．そこで，Web アプリケーションを操作性の良い仕様へ変更した．作成する Web アプリ
ケーションは簡単なもので，ボタンを押せば Web サーバ内にある Coffer.txt 等のテキスト
ファイルを書き換える処理である．例えばコーヒーON というボタンを押せば，サーバ内に
ある Coffer.txt の中身を Coffer_ON と文字列を書き換えるだけである（図 40 参照）．これ
Web サーバプログラム
コントロール
クライアントプログラム
電源スイッチ
ＯＮ
EZ-USB マイコン
ニンテンドーDS
図 39 コーヒーメーカのシステム概要
43
コーヒーメーカ
ボタン A 処理
Coffer.txt
Coffer_ON
Coffer.txt
Default.aspx
ボタン B 処理
Coffer_OFF
図 40 コーヒーメーカ操作の Web アプリケーションの概要
により，このテキストファイルを Web サーバ内に設置，コントロールクライアントからこ
のテキストファイルに直接アクセスしてサーバ内での機器操作状況を取得することも可能
となる．
（２）コントロールクライアント層
コントロールクライアント層のプログラムは 6 章で使用したクライアントプログラムを
変更なしで利用できる．今回作成したクライアントプログラムは，基本的には文字列を参
照するだけのプログラムである．つまり，Web サーバに存在するファイルが HTML 形式やテ
キストファイルでも，ブラウザ等で参照する事ができれば実行可能である．そのため，サ
ーバ側プログラムが少々変更されたとして，特に問題なく動作する事が可能である．
Light_ON
ボタン１の処理
Label1.Text = Light_on;
書込み
or
file_rw.text_write(Light_on);
ボタン２の処理
読込み
Label1.Text = Light_off;
Light_OFF
Light.txt
file_rw.text_write(Light_off);
Food_ON
ボタン３の処理
file_rw.text_write_food(Food_on);
ボタン４の処理
file_rw.text_reder_food();
書込み
読込み
or
Food_OFF
food.txt
図 41 実際のソースコードの一部と動作
44
private Micom_control micomcon = new Micom_control();
Boolean temp = webinfo.Web_Get(Get_URL, "coffer_on");
if (temp == true) micomcon.ON_OFF(1);
else micomcon.ON_OFF(0);
サーバに特定の文字が存在すれば
EZ-USB へ API を経由し，PA1 番ピン
に取り付けられた電子機器に電力を送
る．またなれければ電力供給を止める．
EZ-USB と通信する
ための API をインス
タンス化する
作成した Web サーバ上に
特定のテキストファイル
に指定した文字列がある
かを調べる
図 42 クライアントプログラムに使用する実際のプログラムコードの一部
（３）マイクロクライアント層
家電量販店にて販売されているコーヒーメーカはマイコン等を使わないシンプルな家電
製品である．図 43 が実際に使用しているコーヒーメーカである．このコーヒーメーカを実
際に分解してみたところ，複雑な回路等一切なく，センサらしきものも見当たらなかった．
敢えて言うならばスイッチ部分が１回路２接点（1 つの回路を A と B に切り替える回路）に
なっていたところから，何らかのアクションがあれば回路が切り替わるという程度までは
わかった．つまり，100V の 1 極はスイッチに直接繋がっている事がわかった．そこで，100V
のもう 1 極を探し，図 43 の分解時の写真に白いキャップのような部分がそのもう 1 極であ
る事がわかった．ここに新たな接点（スイッチ）を平行に設け，そのスイッチを操作する
事でコーヒーメーカの主電源を切る仕組みを考えた．そこで，実際に試験的に配線を行い，
電源を投入したところ，激しい火花が飛び散ってしまった．原因を調べたところ，試験的
配線と言う事もあり，ミノムシクリップ型の配線（配線先がクリップになっている
コーヒーメーカの分解後
コーヒーメーカ（象印製）
図 43 コーヒーメーカとその分解写真
45
リレー回路
図 44 コンセント操作する回路図
配線）を使用したのだが，そのクリップ部分が別の部分に当たってしまいショートしたよ
うである．（余談ではあるが，著者はこれで服が若干焦げたのと，軽い火傷を負ったので，
以後 100V の電流を扱う際には細心の注意を心がけるようになりました・・・）
しかし，ここでショートした事で，特に内部に捉われず，コンセントの接点を操作すれ
ばいいと考えた．そこで，図 44 のような簡単な回路を作成した．コンセントの 2 極のうち
1 極の途中に接点を設け，その接点を電気的に制御する簡単なものである．つまり，コンセ
ントの主電源を操作する物である．この接点を設ける部分にリレー回路を設ける．リレー
回路とは，コイルが内蔵されたスイッチのようなもので，コイルに電流が通うと電磁石が
発生，これにより，接点を切り替えるというものである．このリレーの接点部分を 100V の
コンセントを繋げ，コイルに EZ-USB を接続する．EZ-USB からは 3.3V，350mA の直電電流を
発生させる事が可能である．つまりここで必要となるリレーは以下のようなものである
z
接点部分が AC100V 以上の電圧に耐えられる．
z
動作させるには DC3.3V，350mA 以下である．
上記の条件を満たす物が手に入りにくかったので，複数のリレーを用いてこの条件を満た
す接点を作成した．最後に EZ-USB に簡易汎用ファームウェアを転送する事により，コント
ロールクライアントからコンセントの制御を行う組込み機器の完成である．（図 45）
低電圧作動
リレー
中身
高電圧対応
リレー
実際に作成した機器
実際の電子機器
図 45 実際に作成した電源操作電子機器
46
７．２
水槽管理システムの構築
熱帯魚の飼育には様々な面倒な世話が必要である．例えば，日中は照明を付け，夕刻に
なれば照明を切る，夜になればエアレーションの電源を入れる，そしてエサを与える等で
ある．常に決まった時間に自分がその場に滞在できればよいが，外出などで決まった時間
に部屋にいないときがある，水槽の管理ができない場合がある．そこで，このような問題
点を解決するために水槽管理システムを３層 IT アーキテクチャを用いたシステムで解決す
る．
今回作成するシステムをまず簡潔にまとめる．今回使用する機器は電灯，二酸化炭素ボ
ンベ，エアレーション，自動エサやり機である（図 46 参照）．この４つのうち電灯とエア
レーションはコンセントをさすと稼動するので，コーヒーメーカシステムで使った機器と
同じ仕組みを使用する．あとの二酸化炭素ボンベと自動エサやり機は制御が少し特殊なの
で機器を電気的に制御する．
本システムは構築後実際に使用し，現在で役 3 ヶ月間使用しているが，非常に重宝して
おり．安定した動作をしている．
（１）サーバ層
サーバ層は 7.1 のコーヒーメーカで使用した Web アプリケーションと同様のものを流用
する．ただし，コーヒーメーカだけを操作するのではないから，組込み機器の情報を管理
するテキストファイルを追加する処理を加える．尚，今回は Web サーバプログラムに直接
新しく追加したテキストファイルの読み込み処理の追加を行ったが，将来的にはブラウザ
上から新規デバイスの追加というボタンを作り，自動的にテキストファイルを作成するプ
ログラムを実装する予定である．
自動エサやり機
電灯
エサ
光
電磁弁
二酸化炭素
空気
水槽（熱帯魚，水草）
二酸化炭素ボンベ
図 46 水槽管理をする機器
47
エアレーション
Light_ON
ボタン１の処理
Label1.Text = Light_on;
書込み
or
file_rw.text_write(Light_on);
読込み
ボタン２の処理
Light_OFF
Label1.Text = Light_off;
Light.txt
file_rw.text_write(Light_off);
Food_ON
ボタン３の処理
file_rw.text_write_food(Food_on);
ボタン４の処理
file_rw.text_reder_food();
書込み
読込み
or
Food_OFF
food.txt
図 47 実際のソースコードの一部と動作
（２）コントロールクライアント層
クライアントプログラムもコーヒーメーカで使用したクライアントプログラムと同じ物
を利用する．ただし，今回作成する組込み機器はコーヒーメーカと少し異なり，ひとつの
EZ-USB にふたつのデバイス（複数のリレー回路）を追加する．そこで，クライアントプロ
グラムから EZ-USB に送る命令を少しだけ変更する．例えば，コーヒーメーカシステムの場
合，リレー回路がひとつしか搭載されていなかったので，EZ-USB に送るデータに１
クライアントプログラム
EZ-USB. Out_Electnic(0)
OR
EZ-USB. Out_Electnic(1)
OR
EZ-USB. Out_Electnic(2)
OR
値(BIT)
0(00000000)
1(00000001)
2(00000010)
3(00000011)
リレー回路A リレー回路B
OFF
OFF
ON
OFF
OFF
ON
ON
ON
EZ-USB. Out_Electnic(3)
図 48 クライアントプログラム変更点詳細図
48
電力供給すれば蛍光灯，電磁
弁が作動，電力を切ればエア
レーションにが作動する．
Device1
1 回路２接点
蛍光灯
リレー回路
EZ-USB
Pin 配置
電磁弁
Pin PB0
Pin PB1
EZ-USB
エアレーション
1 回路１接点
リレー回路
自動エサやり
電力供給すれば接点が繋がる
Device2
図 49 ひとつの EZ-USB にて複数のデバイスを連結
（Bit で言えば 00000001）を送信していた．しかし，今回は複数のデバイスが搭載されて
いるので，例えばリレー回路がふたつ組み込まれていたならば最大値で４（Bit で 00000011）
を送る必要がある．（図 48）もちろん EZ-USB を複数個分用意すれば，コーヒーメーカと同
じクライアントプログラムと同じでよいが，マイコンをデバイス毎に使用するのはコスト
的に非常に無駄である．そこで図 49 のようにひとつのマイコンボードでデバイス１（図 49
の青点線四角），デバイス２（図 49 の緑点線四角）のように，複数のデバイスを管理する
機器にする．これにより，クライアントプログラムの変更が必要となるが，マイコンの数
がひとつで複数のデバイスを操作する事が可能となる．
EZ-USB へ
ボタン部分
作成する機器
自動エサやり機
図 50 自動エサやり機カスタム方法
49
（３）マイクロクライアント層
マイクロクライアント層には熱帯魚を管理するための 4 つの装置をとりつける．前述し
たように電灯，エアレーション，二酸化炭素ボンベ，自動えさやり機である．特殊なのは
二酸化炭素ボンベと自動えさやり機である．酸化炭素ボンベはボンベにレギュレータが差
し込まれており，そこから付属のコックをひねる事で二酸化炭素を水槽に注入することが
できる．このコックをひねるのが人間の動作である．そこでコック部分を電磁弁に切り替
える．電磁弁とは電気的に弁を開けるものである．これは熱帯魚店等で販売されており，
コンセントをさすと弁が開くものである．つまり電磁弁を用いる事により，コーヒーメー
カシステムと同じ仕組みの機器を使用する事で電気的に制御することができる．また自動
エサやり機も熱帯魚専門店にて販売されており，ボタン部分を押す事により，モータが作
動し，熱帯魚にエサをやるものである．これを電気的に制御する手法として，ボタン部分
にもう一つ並列の接点を設ける方法を設ける．具体的に図 50 に示す．ボタンとは，回路を
繋ぐ接点の事である．つまり，ボタンがなくてもボタン部分から出ている足（基盤につい
ている部分）を直接ショートさせている．このショートさせる部分をリレー回路を用いて
ショートさせ，これによりボタンを押す事と同じ事をする．
続いて，熱帯魚の飼育方法から各装置の同時実行の組み合わせとその実現方法を紹介す
る．熱帯魚は日中の電灯と二酸化炭素の供給を行う．二酸化炭素を供給する理由は水草に
十分な二酸化炭素を与えるためである．そして電灯の光により水草が光合成をし，酸素を
吐き出し，その酸素を熱帯魚が吸収するというサイクルである．つまり，日中は電灯と二
酸化炭素を一緒に供給，電灯が消えれば，水草は光合成をしないので，水槽内が二酸化炭
素で充満する．そこでエアレーションの電源を入れ，酸素を供給する．つまり，日中は電
灯と二酸化炭素が共に電源が入り，夜になればエアレーションの電源を入れる組込みシス
テムを構築する．更に，これとは別でエサをやるという行動がある．つまり，電灯と二酸
化炭素は同時のタイミングで入るためプロセスＡ，エアレーションを入れるタイミングを
電力供給
電力供給
プロセスＡ：
リレー回路
（1 接点 2 回路）
リレー回路
（1 接点 1 回路）
電灯
二酸化炭素ボンベ
プロセスＢ：エアレーション
プロセスＣ：自動エサやり機
プロセスＡ
電力
ON
OFF
プロセスＢ
プロセスＡプロセスＢ
稼動
停止
停止
稼動
プロセスＣ
電力
ON
OFF
プロセスＣ
稼動
停止
図 51 システムを考慮した電子機器設計
50
プロセスＢ，
そして不特定なエサやりをプロセスＣと考えると図 51 のような回路を考える．
つまり，プロセスＡとＢをひとつめのリレー回路（1 接点 2 回路），プロセスＣをふたつめ
のリレー回路（1 接点 2 回路）とする．これにより，水槽を管理する機器を全て管理する事
が可能となる．
51
８章おわりに
ユビキタス社会における組込み機器と Web サーバを利用した組込みシステム Web アプリ
ケーションを実現する方法には大きく２つがある．ひとつは組込み機器のマイコン上に Web
サーバを搭載する方法，もうひとつは組込み機器と別のコンピュータ上に導入した Web サ
ーバとネットワーク通信する方法である．両者共に複数の組込み機器の相互作用する連携
や，保守，運用，拡張性に等様々な問題がある．そこで，組込み機器と Web サーバを利用
した組込みシステム Web アプリケーションを実現する新しい３層 IT アーキテクチャを提案
した．３層とはサーバ層，コントロールクライアント層，マイクロクライアント層である．
３層 IT アーキテクチャは従来のクライアントサーバシステムのクライアント部分をコント
ロールクライアントと位置づけ，コントロールクライアントにマイクロクライアント層に
属する組込み機器を接続する事により，サーバと組込み機器の依存関係を無くすものであ
る．更に，このアーキテクチャを用いてを実際に発光ダイオードとフォトリフレクタを使
ったセンサを用いて，「センサに反応があった場合発光ダイオードを点灯させる」という複
数の組込み機器の相互作用する連結の検証を行った．次に，実際に運用できるシステムか
を検証するため，コーヒーメーカをニンテンドーDS から操作するシステムを作ったり，熱
帯魚管理システムをつくって３ヶ月運用した．結果，現在に至るまで大きなトラブルの発
生もなく，著者自身も非常に愛用している．
以上のように 3 層アーキテクチャを用いる事により，組込み機器を用いた Web アプリケ
ーションの構造が，サーバと組込み機器の間に直接的な依存関係が無くなり，拡張性や保
守性，柔軟性の高いシステムが構築できた．これにより，従来アーキテクチャの問題点で
あった他の組込み機器との連携問題や，保守問題が解決できた．今後の課題として，通信
問題に焦点をしぼり，通信レスポンスの性能評価，セキュリティ面の向上等を視野にいれ，
今後の研究としていきたいと考えている．
52
参考文献
[1]
http://kakaku.com/
[2]
http://www.soumu.go.jp/menu_02/ict/u-japan/index.html
[3]
http://www.soumu.go.jp/
[4]
http://www.hotspot.ne.jp/
[5]
http://www.amazon.co.jp/
[6]
http://www.ertl.jp/ITRON/home-j.html
[7]
http://www2.strawberry-linux.com/products/ezusb/
[8] 井上勝博，西村朋子，“マイコン組み込みシステムのためのソフトウェア・アーキテ
クチャ設計の一手法” ，研究報告ソフトウェア工学 Vol.1991 No.66：pp.9-16 ペー
ジ
[9]
出原章雄，田原康宏，山本整，菅井尚人，飯塚剛，“組込みマルチコアプロセッ
サ向け SMP Linux における省電力機能の実装と評価”，組込みシンポジウム 2008
[10] 酒井淳嗣，“安全・安心のためのマルチコア技術”，組込みシンポジウム 2008
[11] 中島久弥日系 BP 社，システム設計
[12]
完全ガイド 2008，2007.9.30 pp74-123
John J. Donovan, ”Business Re-engineering with Information Technology”,
Prentice Hall,ISBN 0-13-125907-5.
[13]
菊池支典，小泉寿男
”3 階層 Web アプリケーションシステムの構築とその評価”，
マルチメディア通信と分散処理，情報処理学会
研究報告，Vol.2002 No.12 ，
pp.61-66,2002.
[14]
河口信夫，稲垣康善, ”cogma:動的ネットワーク環境における組み込み機器間の連
携用ミドルウェア”, 情報処理学会コンピュータシステム・シンポジウム，pp.1-8, Nov.
2001.
[15]
河口信夫，春原雅志, ”WebCodget: Web サーバに移動して動作する組込み機器向
け移動ソフトウェア”, 情報処理学会ユビキタスコンピューティング研究会，
2005-UBI-009, pp.41-44,2005.
[16]
春原雅志，河口信夫, ”LinkCodget: Web サーバ上の移動ソフトウェアを用いた機
器間連携機構”, マルチメディア，分散，協調とモバイル(DICOMO2006) シンポジウ
ム論文集(I), Vol.2006, No. 6, pp.213-216, Jul. 2006.
[17]
http://www.apache.jp/
[18]
http://www.activestate.com/activeperl/
[19]
http://www.lantronix.jp/products/ds_xport.shtml
53
謝辞
本研究において，阪南大学学会支援事業部に給付金の支給により研究の支援をして頂き非
常に感謝致します．
本論文査読者になって頂いた他にも現代ＧＰにて協力して頂いた前田
利之先生に感謝致
します．
本論文査読者になって頂いた他，授業では多々迷惑を掛け，且つ現代ＧＰでも迷惑をお掛
け致しました，神沢
正典先生に感謝致します．
学部時代から現在まで，様々な御指導を頂いた筒井
茂義先生に感謝致します．
研究，学業，相談，遊びにいつも付き合って頂いた修了生の麻山
勇樹氏，池宮
直氏に
非常に感謝致します．
研究，遊び，その他にも多大な迷惑を掛けた後輩の野口
真司氏に感謝致します．
いつも無茶な依頼，私のわがままに付き添って頂いた，学部４回生，学部３回生に感謝致
します
いつも，私と担当教員花川共に揃って多大な御迷惑をお掛け続けた，情報システム課，阪
本様，濱田様，森様に感謝致します．
備品購入等の予算について，いつも相談させて頂き，いつも私を支援して下さった研究助
成課，後藤様に感謝致します．
いつも深夜に大学に来て作業をする際，出入り口で不審者と思わず学校へ入れてくれた警
備員皆様に感謝致します．
そして，修士論文提出 1 週間前だというのに何もできていない私に 1 週間付き添って頂き，
且つ，様々な御指導をして頂いた花川
典子先生に，心をこめて感謝致します．
54

Download Report