A

２００８年度

修士論文

指導教員 花川 典子 教授

マイコンを利用した３層 IT アーキテクチャ設計の提案

Three layer IT architecture design using micro computers

阪南大学大学院 企業情報研究科

企業情報選専攻

8107002 尾花 将輝

B

目次

１章 はじめに 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 アーキテクチャによる検証 P35

C

７章 ３層 IT アーキテクチャを用いたシステム構築 P43 ７．１ ニンテンドーDS からコーヒーメーカの電源を入れるシステムの構築 P43 ７．２ 水槽管理システムの構築 P47 ８章 おわりに P52 参考文献 P53 謝辞 P54

1

１章 はじめに

近年，様々な機器にネットワーク機能を搭載した携帯情報端末が登場し，無線 LAN 等を

用いる事で，どこでもインターネット検索を行える環境が実現しつつある．ここで言う携

帯情報端末とは，ニンテンドーDS や，PSP，または携帯電話等の機器を指す．このような機

器を用いると，インターネット検索のみならず様々な事が実現可能となっている．例えば，

外出先にて商品の購入を検討していた場合，その商品Ａの値段が 15000 円だったとする．

当然，他店ではどのぐらいの値段で販売されているかを考慮し商品を購入する判断をおこ

なう．しかし，他店に行って商品 A の値段を確認する時間がない場合にはこのような携帯

情報端末を用いた環境が非常に有効である．多くの商品の店舗ごとの販売価格が提示され

ている価格.com[1]の Web ページへ携帯電話でアクセスし，商品Ａが他店ではどのぐらいの

値段で販売されているかを確認することが可能であるからだ．そこで，他店での 安値が

16000 円という情報を取得できれば，この店舗の商品Ａの 15000 円が も安いという事がわ

かり，商品購入の判断がスムーズにおこなえるという使い方である．このように手軽に且

つ高速に様々な情報を取得できる事が，現在の携帯情報端末と無線 LAN などの通信技術を

つかった環境の 大の利点であり，総務省が提唱するユビキタス社会の一端であると言え

る．

しかし，これでは不十分であるという思いがあった．確かに，直接店舗に行かなくても

販売価格がわかる価格.com サイトや，その商品を購入できるオンラインショッピング等，

10 年前には考えられないシステムが多く登場している．しかし，携帯情報端末等から取得

できるものは，サーバサイドに蓄積された情報というものに特化されている．つまり，サ

ーバに蓄積された様々な店舗の商品の販売価格を単に携帯情報端末上から参照できる等の

参照型のシステムである．本来のユビキタス社会を実現するためには，参照型のシステム

ではなく，例えば，個人の家の窓の開閉をする，エアコンなどの家電製品を外出先から操

作したい等，携帯情報端末からの特定の機器の操作を要求するような PUSH 型のシステムも

必要ということである．著者の生活での例を述べるなら，いつも朝起きてコーヒーとタバ

コを吸うのが日課であるが，ここでコーヒーを作るのが非常に面倒である．コーヒーメー

カにコーヒー豆をセットし，水を入れ，ボタンを押して 3～5 分程待たなければいけない．

この時間をベッドで過ごしたいというのが私の素直な気持ちでもあり，ベッドの中からコ

ーヒーメーカを携帯情報端末で操作できるような PUSH 型のシステムがあればと考えた．

そこで，著者はニンテンドーDS 等の携帯情報端末からコーヒーメーカを操作するシステ

ムを開発することを考えた．コーヒーの準備は，前もって水とコーヒー豆をセットしてお

くと，スイッチ部分をニンテンドーDS から ON に入れれば，ベッドから起きてキッチンに着

いたころにいい香りのコーヒーが出来上がっているということが実現できるというアイデ

2

ィアである．コーヒーメーカのシステムは，携帯電話で操作するための web アプリケーシ

ョンとコーヒーメーカの電源部分の ON,OFF を入れ替える組込み機器を作成してコーヒーメ

ーカにつなぐことで．ベッドからのコーヒーを入れることに成功した．さらに，このよう

なシステムは，汎用性を高めることで様々な家電製品やモータを操作することが可能であ

る．例えば，エアコンやカーテン（モータを設置してモータを制御する），窓の開閉，自動

ロックなどである．しかし，汎用性を高めるためには，コーヒーメーカに特化したプログ

ラムや機器の構成を排除して，どのような家電製品や機器でもプログラムから自由に操作

で切る仕組みを考える必要があった．

そこで，３層 IT アーキテクチャの提案をする．これはコーヒーメーカに特化した携帯情

報端末から操作するシステムを一般化し，様々な家電製品や機器に接続可能なソフトウェ

アとハードウェアのアーキテクチャである．特徴は，ソフトウェア，ハードウェアともに

完全に独立した３層の構造をもち，家電製品や機器に依存部分を特定の箇所に集約するこ

とで，システム全体としての大きな構造の変更なく新しい機器や電化製品を追加したり，

削除できるシステムアーキテクチャである．つまり，一度システムを構築した後に新製品

の家電製品が新たに加わったとしても，容易にその新製品を操作するシステムを組み入れ

ることができるシステムアーキテクチャである．

本稿では，2 章に総務省が推進するユビキタス社会とその要素技術である組込み技術や

Web アプリケーション技術について紹介し，３章では従来の組込み技術をユビキタス社会に

利用するときの問題点を述べる．また，４章では組込みシステムや Web システムの従来の

アーキテクチャを紹介し，５章では３層 IT アーキテクチャの提案をおこなう．6 章では提

案したアーキテクチャを試験的に実装したシステムを紹介するとともに提案アーキテクチ

ャを検証する．７章では実践的なシステム構築事例を紹介する．まとめと今後の課題を８

章で述べる．

3

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 時間取引が可能なオンラインシステム等である．我が

4

阪南大学もこれに先立ち，自慢のシステム 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 戦略概要 出典：総務省 HP

5

すべきサービスを提唱している．

２．２ ユビキタス社会を実現する技術要素

u-Japan 戦略におけるユビキタス社会を実現するために必要な技術として大きく２つの

要素がある．ひとつはネットワークのインフラの整備である．e-Japan におけるインフラ整

備はブロードバンドにおけるネットワークの提供であった．しかしブロードバンドは住宅，

オフィス，教育機関等の建物への導入が基本である．つまり有線での接続が基本であった．

しかし，u-Japan 政策は外出先，つまりは公共の道路や駅等で接続可能な環境の推進である

（図２参照）．そのため無線通信が基本となる．ネットワーク無線通信で も有名なものは

無線 LAN（WiFi）接続である．家電量販店等でも販売されている無線 LAN ルータを使用する

ことで無線通信が可能となる．無線 LAN はある一定の範囲内に 2.4GHz 帯の電波を飛ばし，

コンピュータに設置された無専用機器でその電波をキャッチすることで接続可能となる．

無線 LAN にも様々な規格も存在し，1394.11b,1394.11a,1394.11g 等の様々な通信規格が存

在する．この技術を用いて前述したホットスポット等のサービスを実現している．しかし，

無線 LAN 技術だけではユビキタス社会の実現はできない．つまり，広域な公共エリアをす

べて無線ＬＡＮで網羅することは不可能であるからだ．そこでふたつめである携帯電話等

の携帯情報端末の性能の向上である．

近年の携帯情報端末は非常に高性能になりつつある．例えば携帯電話は，10 年程前まで

図２ u-Japan 戦略の将来像の例 引用：総務省 HP

6

は電話しか出来なかった．しかし，携帯電話の性能は向上しメールができるようになり，

写真等の機能が搭載され，さらに，パソコンでしか閲覧できなかった 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 アプリケーションと言う．

7

Web アプリケーションの特徴は，ブラウザから与えられた情報を元にサーバ内で処理を実

行し，その結果をブラウザに伝えるシステムが特徴である．つまり，ブラウザは昔と同じ

く基本的には HTML 等のタグ言語（XML 等）を解釈する機能しか搭載されていない．（ただし，

JavaScript にて簡単な処理を行う事が可能であるが，ブラウザの種類によるのでここでは

省く）つまり，サーバにて CGI，JAVA 等の言語を用いて処理を行い，その結果をブラウザ

に伝える，これが Web アプリケーションである．（図４参照）

サーバ クライアント

Index.HTML <html> <head> <title>修士論文</title> </head> <body> 修士論文 </body> </html>

ブラウザ

アクセス Index.HTML を解析 文字，画像の表示

表示

図３ Web システム概要図

サーバ クライアント

Index.HTMLIndex.cgi 値を引渡し

値の受取処理 処理Ａ 処理Ｂ

HTML 文 生成

ブラウザ

HTML 文を解析 文字，画像の表示

処理した HTML 文を ブラウザに渡す

フォーム等から値を引渡

し

図４ Web アプリケーションの仕組み

8

２．４ 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（以下クッキー）を用いたセッション管理方法である．クッキーとは，サー

バからクライアントに一時的に情報を保存しておく事が可能なデータである．クッキーに

様々なデータ（ユーザの状態等）と共にセッションＩＤと呼ばれるＩＤをサーバが発行す

る．そのセッションＩＤを元にどのユーザであるかを判別するものである．（図５参照）こ

の技術を用いる事で，例えば多くの入力項目がある入力フォーム（例えばオンラインショ

ッピングの購入画面等）の入力途中で，何らかのトラブルにて通信が途絶えても，再ログ

9

インする必要ない等，入力が完了した項目までのデータをサーバが保持する等，ユーザに

とって恩恵の多い技術となっている．

２．５ 組込みシステムとは

組込みシステムとは，汎用コンピュータ（ここではパソコン）とは全く反対のコンピュ

ータシステムの事を指し，特定の目的（特定の機能）のための専用コンピュータシステム

を一般的に指す．組込みシステムには様々な呼び方が存在する．組込みシステムは，別名

で組込み機器と呼ばれる事が多いが，実際には組込みシステムと組込み機器とは正確には

意味が違う．また，近年はユビキタス社会の実現に大きな役割を担う事が多く別名ユビキ

タスコンピュータと呼ばれる事もある．このように組込みシステムには複数の呼び方が存

在するが，世間一般的によく使われているのは組込み機器が多い．

続いて組込みシステムについて述べる．組込みシステムとは，ソフトウェア，ハードウ

ェアの２つの要素を特定の目的のために 小限で構築されたコンピュータシステムを指し，

組込みシステムを制御するソフトウェアを組込みソフトウェアと呼ぶ．この特定の目的の

ために開発されると言う点に組込みシステムの 大の特徴があるのだが，この特定の目的

という定義について述べる．組込みシステムとは対象的である汎用コンピュータは，デバ

イスや CPU 等をある程度定められている物である．これにより，様々な処理をプログラム

によって実行するのがコンピュータである．つまり，特定のデバイスや CPU 等に合わせた

OS を搭載することにより，様々なアプリケーション等が実行できるコンピュータを汎用コ

サーバ

クライアントＡ

クライアントＢ

クライアントＣどれが，誰から

の通信かわか

らない・・・

サーバ

クライアントＡ

(Cookie 101)

クライアントＢ

クライアントＣ

Cookie101 だからクライ

アントＡさんだ

図５ Cookie を用いたセッション管理図

事前に Cookie を渡す

10

ンピュータと呼ぶ．これに対して組込みシステムとは，特定の処理だけを行えるハードウ

ェア構成で成り立っており，特定のプログラムしか処理できないシステム構成となってい

るシステムを指す．そのため，デバイスや 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言語等で記述する事が近年一般的になりつつ

11

ある．今回著者が使用した EZ-USB[7]もマイコンとファームウェアを使用している．この

EZ-USB を用いて簡単にシステムの流れを説明する（図７参照）．

ファームウェアをマイコン上の ROM（電源を切ってもプログラムを保持できるメモリ）

に書込み（図７の①），電源導入時に ROM 上のプログラムが RAM（電源を切ると内容が消

えるメモリ）に移動する（図７の②）ことにより，システムが稼動する．尚今回使用す

る EZ-USB は学習用マイコンであるため，USBPort から直接 RAM へ Firmware を転送する事

が可能なっており，ROM を経由し動作する必要がない特殊なマイコンボードである．

続いて，組込みソフトウェアの説明をする．組込みソフトウェアとは組込みシステム

に搭載されているソフトウェア全般を指す．例えば，携帯電話のソフトウェアを例に挙

げると図８のようになる．ハードウェアの管理等を行う OS が搭載され，ミドルウェアが

マイコンボード

CPU & RAM

EEPROM(ROM)

CPU

RAM USBPort

ROM

Firmware

Program① ②

マイコンボード

図７ 実際のマイコンボードとマイコン動作例

無線 LAN ルータ

分解

マイクロコンピュータ 制御プログラム DHCP サーバ

物理的ハードウェア

図６ 無線 LAN 機器の分解写真と内容

12

導入され，そしてアプリケーションが動作するというものである．もう少しわかりやす

く言うならば，携帯電話用の OS（リアルタイム性 OS）が搭載された上に携帯用の JAVA

（ミドルウェア）が搭載され，その上で携帯用アプリが動くというものである．このよ

うに，組込みソフトウェアとは，この組込みシステム専用ソフトウェア全てを指す．た

だし，重要な点として，組込みシステムはこの全ての要素は必要としない．図８の右側

を見ればわかるが，マイコンとアプリケーションだけで動作する組込みシステムも数多

く存在する．本論文で開発したマイコンもこれに相当する．

また組込みシステムにはリアルタイム組込みシステムと呼ばれるシステムも存在する．

リアルタイム組込みシステムは主に機器を制御する際に使われるシステムであり，特定

のプロセスを制約時間内に処理をするシステムの事を指す．例えば，ある組込み機器の

ボタンを押せばその動作を 優先で実行するというものである．つまり，外部イベント

に対して，タイムリーに応答するシステムの事を指す．これらのシステムはソフトウェ

ア内のスケジューリング機能が特定の処理を行う事に優先的に設計されている事がひと

つの理由である．この技術を応用した OS がリアルタイム OS であり，前述した携帯電話

等に組み込まれている ITROM OS がリアルタイム OS である．

２．７ Web サーバと組込み機器

近年新しい組込み機器の考えかたとして，Web サーバシステムを導入した組込みシステム

が提案されつつある．これは u-Japan 戦略のひとつであり，ユビキタス社会において，家

電等の物もどこからでも操作できるユビキタス社会の構築を目指しているからである．そ

こで，従来の Web サーバシステムと組込みシステムの両方を連結し，Web アプリケーション

から組込み機器を操作するシステムが世の中に広まりつつある．

現在組込み機器を Web アプリケーションから操作するシステムには大きくふたつの方法

が存在する．ひとつは組込み機器内部に Web サーバ機能を搭載するシステムである（図９）．

組込み機器のカメラの内部にネットワーク機能と，Web サーバシステムを搭載する．これに

アプリケーション

ミドルウェア

OS

マイコン

ソフトウェア

ハードウェア

アプリケーション

マイコン

携帯電話等の 組込みソフトウェア例

今回作成した 組込みソフトウェア

ハードウェア

ソフトウェア

図８ 組込みソフトウェア例

13

より，Web ブラウザでもカメラの映像を見ることができるネットワークカメラができるとい

うものである．つまり，図６の無線 LAN ルータのように，無線 LAN 機能に DHCP サーバを搭

載することでネットワークルーティング機能を搭載する事とほぼ同様の事を行い，組込み

機器を Web アプリケーション化するのである．ふたつめの方法として，汎用コンピュータ

上の Web サーバシステムに組込み機器管理機能を搭載する方法である（図１０）．これは組

込み機器にネットワーク機能を搭載し，従来の Web サーバシステムに組込み機器を操作す

る専用 Web アプリケーションを構築することによって実現する手法である．例えば， 近

の HDD レコーダの場合，メーカが提供する Web サーバにアクセスし，そこで会員登録をす

る．その後 DVD レコーダにその会員登録をした情報を入力，その後携帯電話等でメーカの

Web アプリケーションにアクセスすることにより，携帯電話等から HDD レコーダを操作する

事ができるというものである．つまり，従来のクライアントサーバシステムのクライアン

ト部分が組込み機器になったというイメージである．ふたつの方法は Web アプリケーショ

ンから組込み機器を操作という共通の目的であるが，実現方法は全く異なる方法で実現し

ている．

カメラ

Web サーバ機能

カメラ機能

機器内部に組み込む DVD/HDD レコーダ

Web サーバ機能

レコーダ専用サーバ （メーカ）

ネットワーク通信

機器通信，制御機能

図９ 組込み機器と Web サーバ１ 図１０ 組込み機器と Web サーバ２

14

3章 組込み機器 Web システムの問題点

ユビキタス社会における組込み機器と Web サーバの連携は，携帯情報端末等から家電製

品（以下組込み機器）を操作するためには非常に重要な要素義中である．主に２つの方法

がある．ひとつめは Web サーバを組込み機器自身に搭載し制御を行う方法である，ふたつ

めは別のコンピュータに搭載された Web サーバ等を経由して組込み機器の制御を行う方法

である．しかし，両者ともに様々な問題点が存在する．それらの問題点を本章にて述べる．

３．１ Web サーバを組込み機器自身に搭載し制御を行う場合における問題

組込み機器とはマイコン（Micro Computer）を搭載したデジタル機器を指す．まず，Web

サーバを組込み機器自身に搭載する方法について説明する．Web カメラはコンピュータでは

なくあくまでもカメラであるのだが，分解するとマイクロコンピュータとメモリを載せた

小さな基盤がある．これ Web カメラに内蔵されたマイクロコンピュータとメモリ上で Web

サーバが動作する．つまり，Web カメラのみあれば，サーバ用の PC がなくても，携帯電話

から Web カメラの画像が参照できるシステムを構築することができる．この場合，Web カメ

ラだけでなく，センサのマイコンに Web サーバを搭載すると，カメラだけでなくセンサの

反応状況を携帯情報端末で確認する Web アプリケーションが容易にできる．現在の組込み

機器の Web アプリケーションの多くは，このように組込み機器のマイコンに Web サーバを

搭載する手段を使っている（図 10 参照）．

しかし，組込み機器自身へ Web サーバを搭載するにあたり２つの問題点がある．ひとつ

めの問題点は，他の機器との連結が困難な点である．他の組込み機器との連携するために

は，追加したい機器を追加する機器に物理的に組込み機器自身に搭載する必要がある．例

えば，図 11 のような携帯電話で操作できる換気扇（Web サーバを搭載したマイコン内蔵）

が稼働しているとする．そこに煙センサを組込んで，煙を検知すると自動的に換気扇が回

Web サーバ内臓

Web カメラ

映像の確認

図 10 Web サーバを搭載した組込み機器のシステム例

IP アドレス

照明スイッチ

Web サーバ内臓

IP アドレス

15

る仕組みへ拡張したいと希望したケースを考える．すでに換気扇のマイコンには換気扇の

回り方を制御するプログラムと携帯電話から指示をうける 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 サーバが動作する方法である．つまり，組込み機器をサーバコンピ

Web サーバ機能を搭載した換気扇

換気扇 Web サーバ マイコン

既に１つの組込み機器

煙センサ

追加したい！

追加するには以下の 2 点があるた

めほぼ不可能！ 電子機器の回路の変更 電子機器を制御するソフトの

変更

図 11 換気扇と Web サーバが搭載されている組込み機器における問題

16

ュータへ直接接続し，サーバ機が直接組込み機器からの情報取得や操作を実行する仕組み

のシステムである．サーバ用コンピュータには各組込み機器のデバイスドライバの導入が

必要となる．

別コンピュータの Web サーバ等を経由し，組込み機器の制御を行う場合も問題点が存在

する．ひとつめとしては，Web サーバ自身，つまり Web アプリケーション内に組込み機器を

管理，制御する専用のプログラムを導入する点にある．図 13 のように DVD/HDD レコーダが

操作できる Web アプリケーションが存在したとする．そこへカメラも操作可能にしたい場

合，カメラ専用プログラムを導入するために，Web アプリケーションの変更が必要となる．

また後から換気扇を操作したいとなると，更に換気扇専用プログラムの導入が必要となる．

このように，新しい組込み機器をシステムに追加するたびに Web アプリーションを変更が

発生する．つまり，新しい組込み機器を追加するたびに Web アプリケーションの本体の変

更が発生し，サーバを停止してサーバプログラムのメンテナンス時間を設ける必要がある．

24 時間稼働を要求される高信頼性を要求されるシステムでは度々のメンテナンス時間は社

会に与える影響が大きく好ましくない．

ふたつめの問題として，システム全体のトラブルについてである．システム全体のトラ

サーバ

組込み機器 Web アプリケーション

DVD/HDD レコーダ専用 プログラム

Web カメラ専用 プログラム

図 13 Web サーバへ組込み機器専用プログラム導入問題１

換気扇専用 プログラム

プログラムの追加以外に 従来のシステムの変更も必要

Web カメラ

映像の確認

図 12 別コンピュータの Web サーバを経由した組込み機器のシステム例

照明スイッチ

Web サーバ

Web サーバ用コンピュータ

Web カメラ用 デバイスドライバ

スイッチ用 デバイスドライバ

17

ブルとは，例えば，図 14 のような場合，ひとつの組込み機器にトラブルが発生した場合，

それに影響されてサーバシステム全体がストップすることである．具体的には，サーバプ

ログラム上にある DVD/HDD レコーダの組込み機器のデバイスに特定の処理を実行させるプ

ログラムが実行された時，何らかの理由で DVD/HDD レコーダの組込み機器が故障しており，

デバイス呼び出しに失敗し返答が無いケースである．本来はタイムアウト等でその処理を

スキップし，他のシステムに影響を与えないようにすべきである．しかし，未熟なプログ

ラマによる開発やプログラムミスがある場合，スキップ処理を忘れたことによって，故障

を起こした機器だけが制御不能になるだけではなく，システム全体がダウンしてしまう可

能性がある．

以上のように従来の組込み機器を使用した Web アプリケーションのアーキテクチャは，

拡張性の問題や IP アドレス問題，さらに保守性や信頼性の問題が内在するアーキテクチャ

である．

サーバ

組込み機器 Web アプリケーション

DVD/HDD レコーダ専用 プログラム

Web カメラ専用 プログラム

図 14 Web サーバへ組込み機器専用プログラム導入問題２

換気扇専用 プログラム

トラブル発生

機器から返事が

ないから次の処

理いけない！

処理がストップ あれ？ 動かない

動かない！

18

4 章 関連研究

本章では，ハードウェアやソフトウェアをつかってシステムを作る場合のシステムアー

キテクチャの現在の動向について説明する．本稿で提案する３層 IT アーキテクチャとの比

較の上で，従来のシステムアーキテクチャの内容とその問題点は重要である．そこで，本

稿の提案でも利用する組込みシステムのアーキテクチャと Web アプリケーションのアーキ

テクチャについて紹介する．

４．１ 組込みシステムにおけるアーキテクチャ

組込みシステムのアーキテクチャは数多く存在する．東芝システム・ソフトウェア技術

研究所の井上氏が提唱するマイコンにおけるソフトウェアアーキテクチャ[8]がある．これ

はマイコン等の組込み機器システムの主な役割はリアルタイム制御にあり，リアルタイム

システムには，並列化（並列処理）が一般的に用いられている．そこで，効率よく並列化

を行うためのソフトウェアアーキテクチャモデルの提唱を行っている．並列化を行うには

マルチタスクの概念が必要となる．このマルチタスクであるが，どの処理をひとつのタス

クにし，どのタスクをスケジューラに登録するかが重要な要素となる．そこで，リアルタ

イム組込みシステムの概念を利用したソフトウェアアーキテクチャを提唱している．リア

ルタイム組込みは入力装置からの入力を処理し，出力装置に出力する概念を分け，入力装

置，出力装置等の周辺機器（デバイス）を並列化するものである．また周辺機器の制御は

低レベル（小さな処理）に分ける事が可能であり，これらを抽象化する事でひとつのタス

クとして処理することが可能となる．このひとつのタスクを DIT(Device Interface Task)

と呼び，組込み機器の機能部の処理を FT(Functional Task)と呼ぶことで，図 15 のような

アーキテクチャを提唱している．

また近年，携帯電話等の組込みシステム（組込みソフトウェア）が肥大化しつつあり，

そのため高性能な CPU が必要となる．しかし，CPU の性能を向上（動作周波数向上）させる

と必然的に消費電力が上がってしまう．そこで，近年は消費電力に着目したアーキテクチ

ャが多い[9]．高速処理を実現し，且つ消費電力の低減を実現するためには動作周波数を抑

入力デバイス１

入力デバイス２

DIT

DIT FT

DIT

DIT

DIT

出力デバイス１

出力デバイス２

出力デバイス３

スケジューラ タスク 並列実行可能

図 15 マイコン組込みシステム アーキテクチャモデル図

19

えた複数の CPU をひとつのチップにまとめたマルチコアプロセッサを用いたシステムが現

在 も有効とされている．複数の CPU を搭載した組込みシステムが低負荷時はシステムを

稼動させる 低限の CPU だけを起動しシステムを維持し，逆にシステムに複数のタスク（プ

ログラム）が実行される環境になればソフトウェア的に CPU を稼動させ，それぞれの CPU

にタスクを割り振り，円滑に処理を実行するアーキテクチャが現在主流となっている．（図

16）更にマルチコア技術を応用し，セキュリティ性の向上を考慮したシステムアーキテク

チャも存在する．[10] マルチコアの数に対して，その個数分だけ OS を搭載するデュアル

OS 方式を採用したアーキテクチャも存在する．図 17 のように，CPU の数だけ OS を搭載す

るのだが，組込みの主となる部分，つまりデバイス制御と他のプログラムを実行するもの

を OS 毎別にする手法である．これにより，デバイス等重要な処理を行っている OS と CPU

には他のプログラムから容易にアクセスする事を禁止し，ウイルス等の悪意のあるプログ

ラムから組込み機器を守るものである．その他にも高速処理を組込み機器で実現するため

の MPI を用いたシステムアーキテクチャ等多数存在するが，基本的には組込み機器内部の

アーキテクチャの提案が多く，システム全体を考慮したアーキテクチャはあまり存在しな

いのが現実である．

４．２ Web アプリケーションシステムにおけるアーキテクチャ

Web アプリケーションにおけるアーキテクチャの提案は様々提案されている．Web アプリ

ケーションには様々な技術が組み込まれている．例えばオンラインショッピング等のサイ

トであれば大きく３つに分けられる．例えば商品の一覧を表示する画面，商品の情報を持

つデータベース，そしてこれらを繋げるコントロールプログラムの３点である．この点に

着目したアーキテクチャとして，Webアプリケーションにおける３層ITアーキテクチャ[11]

タスク状況により CPU を復帰，遮断

CPU 復帰命令

システム

制御 タスク

タスク 3 タスク 4

CPU1 CPU2

タスク状況

CPU Hotplug

Sysfs(System Filesystem)

CPU Add CPU Remove

Linux Kernel

CPU 遮断命令

CPU1 CPU2 CPU3 CPU4

OS OS OS OS

タスク 4

スケジューラ によりタスク を割振る

メイン処理を行う

OS と CPU

アクセス禁止

図 16 消費電力設計 図 17 マルチタスクとセキュリティ

20

と呼ばれている．つまり，先ほどのオンラインショッピングを例で言えば，ブラウザに表

示される商品の閲覧する画面をユーザインタフェイス（プレゼンテーション層），商品情報

等のコンテンツを管理する，ユーザインタフェイスと連結するビジネスロジック（ファン

クション層），そして商品情報を登録，保持しておくデータベース（データ層）と３つの層

に分けられる．これらの一連の動作を示したものが図 18 である．

３層 IT アーキテクチャの特徴は，データ加工処理をサーバ側で実行させることにある．

クライアントとサーバの間のデータ通信量が減るため，低速な回線を使っている場合やク

ライアントの台数が多い場合でも，応答速度が落ちにくいという特徴がある．また開発効

率の面では，アプリケーションを機能的に 3 モジュール（ユーザインタフェイス，ビジネ

スロジック，データベースの３つ）に分離することで，３つのモジュールを並行開発する

ことで，開発効率が向上し，生産性が向上する．また，システムに仕様変更等が発生すれ

ば，３モジュールのどれを変更すればよいかわかりやすく，仕様の変更作業が容易になる．

また，システム保守に関する作業負荷が減ることも期待できる．サーバ上のデータベース

の構造やデータの処理を変更があったとしても，クライアント上のモジュールを変更しな

くて済むからだ．

また３層 IT アーキテクチャとよく似ているが異なる MVC アーキテクチャモデル[12][13]

の述べる．MVC モデルとはソフトウェアアーキテクチャのひとつであり，M は Model，V は

View，C は Controller を示し，これら３つの頭文字を取って MVC モデルと呼ばれている．

Model は処理の中核を担う．つまり，メインのビジネスロジック処理は Model に搭載される

事になる．View はユーザインタフェイスへの出力を担当する．Model 等で処理された結果

をユーザインタフェイスに表示するものである． 後に Controller はユーザインタフェイ

スからのイベント処理を行う．例えば値の取得等が発生すればそれを取得し，処理が必要

な場合は Model に引き渡すものである．また Model からデータベースシステムを参照する

事で，データベースとのアプリケーション部分を独立させている．これらの動作をまとめ

たものが図 19 である．MVC モデルは機能を明確に３つに分ける事で開発性の向上，保守に

Client （Browser）

Web Server(Apache)

AP Server(Tomcat)

DB server(MY SQL)

リクエスト受付 リクエストの

あった情報を渡す

データ情報 の取得，更新を行う

データ

データベースの データを返す

処理結果HTML リクエストから 処理結果を返す

ブラウザが解釈 できる HTML 等を返す

1 層目 ３層目

図 18 Web における３層 IT アーキテクチャの一連動作

２層目

21

関する作業負担を減らすモデルであり，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 アプリケーションであり，従来ミドルウェアであ

Model

View Controller

DB

UI からの入力 UI へ出力

処理依頼 処理結果

処理が無い場合

DB 参照，更新

UI : ユーザインタフェイス

図 19 MVC モデルのアーキテチャ図

22

った WebCodget から値を取得，Java アプリケーションで更新する事により，WebCodget に

変更を加えず，組込み機器間の連結を実現可能にしたものである．この LinkCodget を

WebCodget 上にて動作させることにより，ブラウザから組込み機器の連結を実現したのであ

る．図 20 のように，これら３つのソフトウェアを利用する事連結を考慮した組込み機器を

Web アプリケーションにて操作するシステムが完成する．cogma システムは，Web サーバシ

ステムと組込みシステムを連結するソフトウェアは提案されているが，システム全体を考

慮したアーキテクチャではない．

組込み機器

FireWare

Device Sensor

RS232c

Cogma 専用組込み機器

LinuxOS

Personal Java

WebCogget(cogma)

組込み機器

組込み機器 LinuxOS

Personal Java Java(J2DK)

WebServerCodget(cogma)

LinukCodget

Web サーバ

連結 処理

図 20 cogma を用いた全体のシステム図

23

５章 組込み機器を用いた３層 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 を選択した．更に，３層目の組込み機器を制御するためのデバ

イスドライバや専用クライアントプログラムを導入する．これにより，コントロールクラ

イアント層とマイクロクライアント層はソフトウェア的に依存関係になってしまうが，サ

ーバ層とマイクロクライアント層の依存関係を排除したシステムアーキテクチャである．

３層目のマイクロクライアント層には組込み機器専用のファームウェアが導入され，組込

み機器の実際の動作を制御する．また，コントロールクライアント層とマイクロクライア

24

ント層の間は USB で接続する例のシステムである．そのために，マイクロクライント層の

コンピュータには USB 通信用のデバイスドライバが必要となる．

5．2 ハードウェアアーキテクチャ

現在の組込み機器を携帯情報端末等から操作する手法として大きく２つあると前述した

（３章参照）．ひとつは，組込み機器内部へ Web サーバを搭載する．これは組込み機器と Web

サーバという本来ふたつのハードウェアをひとつにすることで，ネットワーク化するもの

である．もうひとつは Web サーバを外部に組込み機器とネットワーク越しに通信するとい

うものである．共に組込み機器をネットワーク化するという手法では共通なのだが，ハー

ドウェア的には全く異なる手法で実現している．しかし，これらのシステムには他のシス

テムや組込み機器との連結が考慮されていないという問題点がある．例えば，組込み機器

内部に Web サーバが内蔵された Web カメラ機器の場合（図 22 の①），その Web サーバにド

アロックセンサの新しい組込み機器の追加をしたい時，Web カメラのマイコンにドアセンサ

のドライバや，Web カメラのマイコンのファームウェアにドアセンサに関するロジックを書

いたプログラムを新しく追加する必要がある．多くの Web カメラのマイコン上のプログラ

ムの ROM 上に書かれており，新規の書き直しは不可能であり，新規にドアセンサの機能追

加ができない．また，Web サーバを通常のコンピュータ上に構築し，Web カメラなどの組込

み機器とハードウェア的に分離した場合（図 22 の②）において，おなじサーバ上で Web カ

メラとドアセンサが制御されている．もし，Web カメラの処理でハングアップした場合，接

続されているドアセンサの処理もハングアップし，システム全体が動作しなくなる危険性

がある．そこで図 23 のようなハードウェアアーキテクチャを提案する．

図 21 ３層 IT アーキテクチャ全体像図

Webアプリケーション(Wiki.cgi)

Apache

OS(Linux)

File System Device Driver

HTML FileCGI File

Client Program

Micom_control_API

OS(Windows)

Device Driver

Hard ControlFirm Ware

Information Firm Ware

USB(UPNP)TCP/IP

Device Driver

Server Control Client Micro Client

25

このアーキテクチャは従来のクライアントサーバシステムのアーキテクチャを引き継ぎ

第 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 が３層ソフトウェアアーキテクチャである．３層ソフトウェアアーキテク

図 23 ハードウェアアーキテクチャ

CntrolClient

PC

Micom

Devicesensor

DeviceLED

DeviceMotor

DeviceIC Reader

ServerPC

FirstLayer

SecondLayer Third Layer

デバイスの管理，操作データ通信

データ通信図 22 従来のハードウェアアーキテクチャ

の問題

①

Web カメラ Web サーバ 内臓

ドアセンサ

①

Web カメラ Web サーバ 内臓

ドアセンサ

Web サーバに組

み込めない

USB ドライバ

システム全体がハ

ングアップ！

26

チャは汎用性の向上，安全性，そして開発の容易性を考慮したアーキテクチャである．本

アーキテクチャを 1層目（サーバ層），２層目（コントロールクライアント層），３層目（マ

イクロクライアント層）の順に説明していく．まずサーバ層へ導入するソフトウェアは，

Web サーバ，AP サーバ（アプリケーションサーバ），DB サーバ（データベースサーバ）など

のサーバ側のプログラムを導入する．サーバ側のプログラムとは，おもにユーザの入力や

情報参照のインタフェイスをグラフィカルに表す部分（Web アプリケーションならば，ブラ

ウザで参照できる部分）と組込み機器間のロジック制御する部分（センサが反応すれば LED

が点灯するなど）を含む．ただし，それぞれの組込み機器を操作するプログラムなどを導

入せず，また組込み機器のドライバなどは導入しない．

続いて，２層目のコントロールクライアント層について述べる．コントロールクライア

ントでは，サーバと通信，組込み機器と通信の 2種類の通信を行うプログラムを実装する．

まず，サーバとの通信方法について述べる．ここでの通信手法にはとらわれない．つまり

専用の通信プログラムや，IE コンポーネント等のブラウザを実装したプログラムでも通信

可能とする．従来の組込み機器で問題となっていた「専用サーバと専用通信プログラムで

しか動作できなかった問題」を新たにクライアントプログラムの作成で，通信の依存関係

を排除する．更に，組込み機器等のデバイス管理のデバイスドライバ等もコントロールク

ライアント層に導入する．これにより，従来のシステムは，Web アプリケーション構築を行

っているサーバにデバイスドライバ等の導入を行っており，デバイスドライバに障害が発

生するとサーバ全体がダウンする可能性がある．このような重大な影響を避けるために，

サーバ層にデバイスドライバは導入しないことで，サーバの安定化が図れる．

もうひとつのコントロールクライアント層の特徴は組込み機器に関する API 群を用意す

ることである．API とは図 24 の 2 層目の「Program」に示すように，「Sensor.Get()」メソ

ッドのように直観的に理解しやすいメソッドをコールする．実際は図 24 の２層目の「API」

で示すように，「Out_Electric_PA0()」や「Get_Electric_PB0()」のように，マイコンボー

API.........

Out_Electric_PA0()

Get_Electric_PB0()

Micom

×

PB1

PB0

×

×

Writepin

0PC0

0×

0×

1PA1

0PA0

BinaryReadpin

×

PB1

PB0

×

×

Writepin

0PC0

0×

0×

1PA1

0PA0

BinaryReadpin

Operation Map

Controller

Devicesensor

Generating command

WriteRead

APServer

WebServer

DBServer

NetworkServer

Client Server Architecture

Program.........

Sensor.Get()Serverup(){}

Device_Driver

Firmware Information

FirstLayer

SecondLayer Third Layer

DeviceLED

図 24 ３層ソフトウェアアーキテクチャ

サーバ層 コントロール クライアント層 マイクロクライアント層

27

ドの 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 を利用する．さらに，密接な

28

関係があるのがマイコンを操作する 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 群やファームウェアを用意することで，組込みソフトウェアの開発が容易と

なり，組込み機器のハードウェアインタフェイス依存が低減されたプログラムを作成する

ことができる．また，リモコン等が搭載されている組込み機器において，学習リモコン

PA０～７

PB０～７

PC０～７

PD０～７

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)}

11100001PD

10110100PC

10000011PB

10100100PA

8bit7bit6bit5bit4bit3bit2bit1bit

11100001PD

10110100PC

10000011PB

10100100PA

8bit7bit6bit5bit4bit3bit2bit1bit

Micom information map

PA7PA6PA5PA4PA3PA2PA1PA0Pinname

ONOFFONOFFOFFONOFFOFFLEDstate

10100100bit

PA7PA6PA5PA4PA3PA2PA1PA0Pinname

ONOFFONOFFOFFONOFFOFFLEDstate

10100100bit

図 25 簡易汎用ファームウェア

29

を応用したファームウェアと API も提供する．これにより，メーカから組込み機器を操作

する外部インタフェイスや API が提供されていなくても，家電製品の一部の操作を実現で

きるファームウェアとその API の提供を行う事が可能となる．

Cofe_maker_ON(){ API.Set_Electronic(1); }

Client Program

Set_Electronic(Byte Binary){ Ez-usb.outdata(Binary); }

API 群

EZ-USB(Micom)

ＰＡ0

ＧＮＤ

bit 0Pinname PA0Electronic OFF

100Ｖ

コーヒーメーカ

図 26 簡易汎用ファームウェア実装例

30

６章 ３層 IT アーキテクチャの試験的実装と検証

６．１ 試験的実装したシステムの概要

前章で提案した３層 IT アーキテクチャの検証をおこなうために，試験的なシステムを実

装して検証する．システムは図 27 に示すような，赤外線センサと LED を組み合わせたシス

テムである．本システムでは，赤外線センサにて感知すると LED を点灯させるシステムで

ある．つまり，赤外線センサと LED の２つの組込み機器をマイクロクライアントとコント

ロールクライアントで制御し，ユーザは Web 上で制御を確認するシステムである．これに

よって，異機種間の組込み機器の連携が提案するアーキテクチャ上での構築の可能性，さ

らに容易性について検証する．

６．２ ３層 IT アーキテクチャ試験的実装

検証用のシステムの具体的な実装の構成を図 28 に示す．図 28 の Server が図 27 の「サ

ーバ」であり，同様に Control Client1 と Control Client2 が「コントロールクライアン

ト」，Micro Client が「マイクロクライアント」にそれぞれ対応する．システムの主な動作

としては，赤外線センサに反応があった場合，LED が点灯するという２つの組込み機器が相

互作用しながら動作するシステムである．構築手順を以下に示す．

図 27 試験的に実装したシステム

31

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

Server Control Client1 Micro Client

Wiki.cgi

⑤Sensor page

⑥LED page

Apache (Web Server)

Cleirn Program① Server Conection② Micom Control Device Driver

general-purpose Firmware

③Device Sensor

Control Client2

Cleirn Program① Server Conection② Micom Control

Device Driver

Micro Client

general-purpose Firmware

④Device LED

Client

PC Nintendo DS PSP

Access

図 28 試験的実装の全体像

32

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 にて組込み機器からのレスポンスと組込み機

器へのレスポンスの性能について調べることが目的である．

33

６．３．２ コントロールクライアント層

コントロールクライアント層に導入するクライアントプログラムには大きくふたつの役

割を有す．ひとつはサーバとの通信プログラム（図 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」の文字列を書き込むという処理の流れである．

Wiki 情報読込みページ

Wiki 情報書込みページ

IE コンポーネント

GET webString(String, URL){ IE_com.getstring(String); ………… } SET webString(String , URL){ IE_com.setform(String); IE_com.submit(); ………… }

EZ-USB API

情報取得

情報書込み

EZ-USB

Micom Firmware

通信

図 29 コントロールクライアントのプログラムのネットワーク通信方法

SENSOR_ON

LED_ON

34

またプログラム詳細図を図 30 に示す．今回作成するクライアントプログラムは Main1 と

Main2 から成り立っている．Main1 は Web ページ上から特定の文字列を検出し，検出された

ならば，API 群の Set_Electronic を呼び出す．呼び出された API により EZ-USB に電力を送

信する命令を送信する事により，EZ-USB に取り付けられている LED が発光するのである．

また Main2 はセンサの状況（電力状況）を常に監視し，センサに反応があった場合 Wiki 上

に文字列を書き込む．書込み方法は先に述べたように特別な通信プログラムを用意せず，

ユーザが Wiki の書込みページから書込みフォームに特定の文字列を書込み，その後書き込

みボタンをプログラム上から押す．またはコントロールクライアント層のプログラムが特

定ページに指定の文字列を書きこむ．これにより，通信プログラム無しでも組込み機器の

状況をアップロードできる他，他システムとの連結も文字列を調べる事で連結することが

可能となる．

６．３．３ マイクロクライアント層

マイクロクライアントにはマイコンと簡易汎用ファームウェアを搭載した EZ-USB を用意

する．EZ-USB とは CPU、メモリ等を搭載した学習用マイコンボードである．これに汎

IE コンポーネント

GET webString(String, URL){ IE_com.getstring(String); ………… } SET webString(String , URL){ IE_com.setform(String); IE_com.submit(); ………… }

Control class Main1 () { string info = GETwebString(string , servername); If(info = string) Set_Electronic(1); } Main2(){ byte ezinfo = Get_Electronic(); SETwebString(byte , sarvername); }

Set_Electronic(byte Binary){ ez-usb.outdata(Binary) } Get_Electronic(){ return ez-usb.indata(); }

EZ-USB API

図 30 クライアントプログラム詳細

35

用ファームウェアを搭載する．今回汎用ファームウェアには電力のチェック機能と，電力

出力機能の２点を組み込んだ．電力チェック機能は特定の 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 サーバを組み込んだ場合を考える．例えば，エアコン

情報取得先 URL 入力フォーム

情報書込み先 URL 入力フォーム

情報取得開始ボタン

情報書込み開始ボタン

図 31 実際に作成したクライアントプログラム

36

に組み込まれているマイコンに 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 ページに特定の文字があるか等を調べる簡単なプログラムである．実際にセン

サに反応があれば，発光ダイオードが点灯するという組込み機器間の連結をサーバ経由

で行う事が確認できた．今回ひとつのコントロールクライアントで行ったが，他の別の

コントロールクライアントを用意し，ネットワークで接続した際にも同じ結果になった．

これにより，例えば離れている組込み機器同士の連結もコントロールクライアントを複

数代用い，サーバを経由することで連結が可能という事も可能である．ｓ

37

② グローバル IP の必要性

組込み機器へ Web サーバを組み込む場合，携帯電話等からその機器にアクセスする場合，

組込み機器ひとつに対してひとつのグローバル IP を割り振る必要が発生する．これはすべ

ての組込み機器に Web サーバを搭載する際どうしても避けられない問題である．そこで，

今回提案する３層 IT アーキテクチャではサーバに組込み機器の全ての情報を集約する．つ

まり，このサーバに携帯電話等でアクセスするだけで，管理されている全ての組込み機器

を操作する事が可能となる．つまり、複数個の組込み機器がシステムに接続されていたと

してもサーバ層のコンピュータに設定されたひとつのグローバル IP アドレスだけで、すべ

ての組込み機器の操作ができるということである。つまり、Web サーバはシステムに一つし

か存在しないので、このようにグローバル IP アドレスはひとつの設定で動作可能となる．

更に，実装したシステムは FreeStylWiki の Web アプリケーションを用いているため，CGI

が動作する Web サーバなら組込み機器を操作する Web アプリケーションを構築することが

可能である．つまり，自宅に設置したコンピュータに本システムの Web サーバを構築しな

くても，CGI が動作するレンタルサーバを用いる事ですべての組込み機器を操作するシステ

ムを実現する事が可能となる．（図 33 参照）

③ Web サーバに組込み機器管理プロセスが搭載されるため，システムが機器依存になる

従来の組込み機器と Web アプリケーションを連結するには，ひとつの組込み機器を管

理するためにひとつの組込み機器管理プロセスを導入する必要があった．例えば図 34

のように，発光ダイオードを操作する Web アプリケーションがあったとする．ここ

Server Wiki.cgi

Sensor page

Control Client1Client Program(sensor)

Client Program(LED)

Device Sensor

Device LED

Add System

図 32 検証 1．他の組込み機器との連結

38

に例えば赤外線センサ（図 34 赤丸点線部分）を追加し，発光ダイオードと一緒に赤外

線センサの管理も行うシステムを構築すると仮定する．実現するためには，発光ダイオ

ードを操作する Web プログラムと，赤外線センサを操作する Web プログラムを連結する

必要性が発生する．これらは実現する事は不可能ではないが，２つの専用プログラムを

連結することはシステムの設計，運用上非常に危険な事である．更に，今回例として赤

外線センサを述べたが，例えば 100 個の新しい機器を追加する等を想定

サーバ

発光ダイオード

発光ダイオード専用 Web アプリケーション

発光ダイオード専用 通信プログラム

赤外線センサ

赤外線センサ専用 Web アプリケーション

赤外線センサ専用 通信プログラム

Add System

System

図 34 専用サーバへ新規組込み機器を追加するための方法

レンタルサーバ （グローバルＩＰ付加）

A さん宅

Ｂさん宅

Ｃさん宅

Ｄさん宅

Wiki A さん用

Wiki Ｂさん用

Wiki Ｃさん用

Wiki Ｄさん用

図 33 １サーバで複数の機器を操作するシステム例

39

した場合，100 個の専用プログラムを連結する必要が発生し，現実的に不可能に近い事

なる．

そこで今回実装したシステムの場合のシステム依存のイメージは図 35 となる．新し

く追加する赤外線センサとクライアントプログラムをコントロールクライアントに導

入する．そしてサーバ上にある Wiki にて新しく組込み機器の情報をアップロードする

ための Sensor page を作成しておく．これで他システムの導入が可能となる．また発

光ダイオードと赤外線センサを連結したい場合，クライアントプログラムに機器の情

報を読み込む機能を追加しておくと，発光ダイオードと新規追加した赤外線センサを

連結する事ができ，サーバ上の Web アプリケーションにはプログラムの修正無しで追

加，連結することが可能となり，実際に検証したところ，動作することも確認するこ

とができた．

④ 組込み機器等にトラブル発生時，システム全体への影響

従来のシステムにはサーバ層のコンピュータにWebアプリケーションと組込み機器の

管理プロセスを一緒に管理していた．このようなシステムを大規模システムに適応した

場合に不安要素が発生する．それはひとつの組込み機器のトラブルによってシステム全

体がダウンしてしまう可能性が発生する．具体的なトラブル発生について図 36 を用い

て説明する．図 36 には Web サーバに様々なセンサが取り付けられていて，それぞれを

管理するプロセスを Web サーバに搭載されている．更に Web サーバと DB サーバを連結

し，DB サーバにセンサの状況を保持している．これによって組込み機器を管理する Web

サーバ

Wiki.cgi

LED page

Sensor page

コントロールクライアント

発光ダイオード専用 クライアントプログラム

赤外線センサ専用 クライアントプログラム

赤外線センサ

Add System

発光ダイオード

図 35 ３層 IT アーキテクチャによる新規機器追加方法

40

アプリケーションが構築できている．しかし，ここでセンサＡ（図 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 のケーブルが断線しているのにも関わらず，通信を行おうとし，その

結果エラーが返ってきてしまう．ここで，本来エラーが返ってきたとしても，通信部分

Web サーバ DB サーバ

センサＡ

センサＢ

センサＣ

トラブル発生

センサＡと通信ができなく，

処理がそこでストップ

本来，問題ないセン

サだが，サーバの処

理が止まっているた

め，動作せず

図 36 ひとつの機器にトラブル発生時，システム全体への影響

41

をスキップし，別処理に行けばよいのだが，プログラムミスでその処理を書き忘れた場

合にはシステム全体が停止してしまう．このようにサーバ自身に組込み機器の管理プロ

セスを導入することにより，ひとつの組込み機器トラブルで，システム全体のトラブル

へと繋がりかねない．

次に，提案する３層 IT アーキテクチャを使ったシステムでのひとつのデバイスダウ

ンによるシステム全体への影響の有無を検証する．検証するためのシステムの概要を図

38 に示す．

図 38 のようにシステムを構築した際，コントロールクライアントを２つに分けるこ

とで，システム全体への影響力を 小限にする事が可能である．例えば，先ほどと同様

EZ-USB1 LED

Web サーバ

EZ-USB2 センサ

コントロール クライアント1

コントロール クライアント 2

Web アプリケーション (Wiki.cgi)

サーバ通信プログラム

デバイス管理プロセス

サーバ通信プログラム

デバイス管理プロセス

ケーブル切断

図 38 ３層 IT アーキテクチャによるシステムトラブル検証

EZ-USB1

EZ-USB2

LED

センサ Web サーバ

Web アプリケーション (ASP にて構築)

EZ-USB1 デバイス管理

EZ-USB2 デバイス管理

このケーブルをサーバから抜く

図 37 組込み機器の Web サーバへのシステムへの影響力の検証

42

にコントロールクライアント２と EZ-USB２間のケーブルにトラブルが発生したとする．

ここでクライアントプログラムのエラー処理に不備があり，クライアントプログラムが

停止してしまったとする．この時，コントロールクライアントのシステムは停止してし

まうが，サーバの Web アプリケーションはコントロールクライアントから 新の情報の

更新がないだけで済み，他の機器は正常に動作する事が可能となるのである．このよう

に，複数個のコントロールクライアントを確保することにより，例えば電子ロック等重

要な機器を管理するハイリスクなシステムの構築に役立つ．電子ロックのコントロール

クライアントを用意することで，他のシステムからの影響を確実に受けないシステムの

構築も可能である．また，Web サーバがダウンしてしまった場合等の 悪の事態におい

ても，コントロールクライアントにリモートデスクトップ等のターミナル等から入り，

直接機器を操作可能等， 悪の事態への対応も可能となる．実際にこれについて検証を

行ったところ，確かにトラブルが発生した機器のコントロールクライアントプログラム

はエラーで処理が停止していたが，他の組込み機器を問題なく動作させる事が可能であ

り，サーバシステムがダウンするという 悪の事態を避ける事が可能であった．

以上のように従来の組込み機器を導入した Web アプリケーションの４つの問題は提案す

る３層 IT アーキテクチャに基づくシステムによって，回避できることが確認できた．

43

７章 ３層 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 参照）．これ

図 39 コーヒーメーカのシステム概要

EZ-USB マイコン

電源スイッチ

コーヒーメーカ

コントロール クライアントプログラム

Web サーバプログラム

ＯＮ

ニンテンドーDS

44

により，このテキストファイルを Web サーバ内に設置，コントロールクライアントからこ

のテキストファイルに直接アクセスしてサーバ内での機器操作状況を取得することも可能

となる．

（２）コントロールクライアント層

コントロールクライアント層のプログラムは 6 章で使用したクライアントプログラムを

変更なしで利用できる．今回作成したクライアントプログラムは，基本的には文字列を参

照するだけのプログラムである．つまり，Web サーバに存在するファイルが HTML 形式やテ

キストファイルでも，ブラウザ等で参照する事ができれば実行可能である．そのため，サ

ーバ側プログラムが少々変更されたとして，特に問題なく動作する事が可能である．

ボタン１の処理

Label1.Text = Light_on;

file_rw.text_write(Light_on);

ボタン２の処理

Label1.Text = Light_off;

file_rw.text_write(Light_off);

ボタン３の処理

file_rw.text_write_food(Food_on);

ボタン４の処理

file_rw.text_reder_food();

Light_ON or Light_OFF

Food_ON or Food_OFF

Light.txt

food.txt

書込み

書込み

読込み

読込み

図 41 実際のソースコードの一部と動作

Default.aspx

Coffer_ON

Coffer.txt

Coffer_OFFCoffer.txt

ボタン A 処理

ボタン B 処理

図 40 コーヒーメーカ操作の Web アプリケーションの概要

45

（３）マイクロクライアント層

家電量販店にて販売されているコーヒーメーカはマイコン等を使わないシンプルな家電

製品である．図 43 が実際に使用しているコーヒーメーカである．このコーヒーメーカを実

際に分解してみたところ，複雑な回路等一切なく，センサらしきものも見当たらなかった．

敢えて言うならばスイッチ部分が１回路２接点（1つの回路を Aと Bに切り替える回路）に

なっていたところから，何らかのアクションがあれば回路が切り替わるという程度までは

わかった．つまり，100V の 1 極はスイッチに直接繋がっている事がわかった．そこで，100V

のもう 1極を探し，図 43 の分解時の写真に白いキャップのような部分がそのもう 1極であ

る事がわかった．ここに新たな接点（スイッチ）を平行に設け，そのスイッチを操作する

事でコーヒーメーカの主電源を切る仕組みを考えた．そこで，実際に試験的に配線を行い，

電源を投入したところ，激しい火花が飛び散ってしまった．原因を調べたところ，試験的

配線と言う事もあり，ミノムシクリップ型の配線（配線先がクリップになっている

コーヒーメーカ（象印製） コーヒーメーカの分解後

図 43 コーヒーメーカとその分解写真

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 をインス

タンス化する

サーバに特定の文字が存在すれば

EZ-USB へ API を経由し，PA1 番ピン

に取り付けられた電子機器に電力を送

る．またなれければ電力供給を止める．

作成した Web サーバ上に

特定のテキストファイル

に指定した文字列がある

かを調べる

図 42 クライアントプログラムに使用する実際のプログラムコードの一部

46

配線）を使用したのだが，そのクリップ部分が別の部分に当たってしまいショートしたよ

うである．（余談ではあるが，著者はこれで服が若干焦げたのと，軽い火傷を負ったので，

以後 100V の電流を扱う際には細心の注意を心がけるようになりました・・・）

しかし，ここでショートした事で，特に内部に捉われず，コンセントの接点を操作すれ

ばいいと考えた．そこで，図 44 のような簡単な回路を作成した．コンセントの 2極のうち

1極の途中に接点を設け，その接点を電気的に制御する簡単なものである．つまり，コンセ

ントの主電源を操作する物である．この接点を設ける部分にリレー回路を設ける．リレー

回路とは，コイルが内蔵されたスイッチのようなもので，コイルに電流が通うと電磁石が

発生，これにより，接点を切り替えるというものである．このリレーの接点部分を 100V の

コンセントを繋げ，コイルに EZ-USB を接続する．EZ-USB からは 3.3V，350mA の直電電流を

発生させる事が可能である．つまりここで必要となるリレーは以下のようなものである

接点部分が AC100V 以上の電圧に耐えられる．

動作させるには DC3.3V，350mA 以下である．

上記の条件を満たす物が手に入りにくかったので，複数のリレーを用いてこの条件を満た

す接点を作成した． 後に EZ-USB に簡易汎用ファームウェアを転送する事により，コント

ロールクライアントからコンセントの制御を行う組込み機器の完成である．（図 45）

リレー回路

図 44 コンセント操作する回路図

実際に作成した機器

中身

実際の電子機器

低電圧作動 リレー

高電圧対応 リレー

図 45 実際に作成した電源操作電子機器

47

７．２ 水槽管理システムの構築

熱帯魚の飼育には様々な面倒な世話が必要である．例えば，日中は照明を付け，夕刻に

なれば照明を切る，夜になればエアレーションの電源を入れる，そしてエサを与える等で

ある．常に決まった時間に自分がその場に滞在できればよいが，外出などで決まった時間

に部屋にいないときがある，水槽の管理ができない場合がある．そこで，このような問題

点を解決するために水槽管理システムを３層 IT アーキテクチャを用いたシステムで解決す

る．

今回作成するシステムをまず簡潔にまとめる．今回使用する機器は電灯，二酸化炭素ボ

ンベ，エアレーション，自動エサやり機である（図 46 参照）．この４つのうち電灯とエア

レーションはコンセントをさすと稼動するので，コーヒーメーカシステムで使った機器と

同じ仕組みを使用する．あとの二酸化炭素ボンベと自動エサやり機は制御が少し特殊なの

で機器を電気的に制御する．

本システムは構築後実際に使用し，現在で役 3 ヶ月間使用しているが，非常に重宝して

おり．安定した動作をしている．

（１）サーバ層

サーバ層は 7.1 のコーヒーメーカで使用した Web アプリケーションと同様のものを流用

する．ただし，コーヒーメーカだけを操作するのではないから，組込み機器の情報を管理

するテキストファイルを追加する処理を加える．尚，今回は Web サーバプログラムに直接

新しく追加したテキストファイルの読み込み処理の追加を行ったが，将来的にはブラウザ

上から新規デバイスの追加というボタンを作り，自動的にテキストファイルを作成するプ

ログラムを実装する予定である．

電灯

二酸化炭素ボンベ エアレーション

自動エサやり機

図 46 水槽管理をする機器

光

二酸化炭素

電磁弁

空気

エサ

水槽（熱帯魚，水草）

48

（２）コントロールクライアント層

クライアントプログラムもコーヒーメーカで使用したクライアントプログラムと同じ物

を利用する．ただし，今回作成する組込み機器はコーヒーメーカと少し異なり，ひとつの

EZ-USB にふたつのデバイス（複数のリレー回路）を追加する．そこで，クライアントプロ

グラムから EZ-USB に送る命令を少しだけ変更する．例えば，コーヒーメーカシステムの場

合，リレー回路がひとつしか搭載されていなかったので，EZ-USB に送るデータに１

ボタン１の処理

Label1.Text = Light_on;

file_rw.text_write(Light_on);

ボタン２の処理

Label1.Text = Light_off;

file_rw.text_write(Light_off);

ボタン３の処理

file_rw.text_write_food(Food_on);

ボタン４の処理

file_rw.text_reder_food();

Light_ON or Light_OFF

Food_ON or Food_OFF

Light.txt

food.txt

書込み

書込み

読込み

読込み

図 47 実際のソースコードの一部と動作

クライアントプログラム

値(BIT) リレー回路Aリレー回路B0(00000000) OFF OFF1(00000001) ON OFF2(00000010) OFF ON3(00000011) ON ON

EZ-USB. Out_Electnic(0)

EZ-USB. Out_Electnic(1)

EZ-USB. Out_Electnic(2)

EZ-USB. Out_Electnic(3)

OR

OR

OR

図 48 クライアントプログラム変更点詳細図

49

（Bit で言えば 00000001）を送信していた．しかし，今回は複数のデバイスが搭載されて

いるので，例えばリレー回路がふたつ組み込まれていたならば 大値で４（Bit で 00000011）

を送る必要がある．（図 48）もちろん EZ-USB を複数個分用意すれば，コーヒーメーカと同

じクライアントプログラムと同じでよいが，マイコンをデバイス毎に使用するのはコスト

的に非常に無駄である．そこで図 49 のようにひとつのマイコンボードでデバイス１（図 49

の青点線四角），デバイス２（図 49 の緑点線四角）のように，複数のデバイスを管理する

機器にする．これにより，クライアントプログラムの変更が必要となるが，マイコンの数

がひとつで複数のデバイスを操作する事が可能となる．

自動エサやり機

ボタン部分 EZ-USB へ

作成する機器

図 50 自動エサやり機カスタム方法

1 回路２接点 リレー回路

1 回路１接点 リレー回路

蛍光灯

電磁弁

エアレーション

自動エサやり

EZ-USB

Pin PB0

Pin PB1

電力供給すれば接点が繋がる

電力供給すれば蛍光灯，電磁

弁が作動，電力を切ればエア

レーションにが作動する．

EZ-USB Pin 配置

図 49 ひとつの EZ-USB にて複数のデバイスを連結

Device2

Device1

50

（３）マイクロクライアント層

マイクロクライアント層には熱帯魚を管理するための 4 つの装置をとりつける．前述し

たように電灯，エアレーション，二酸化炭素ボンベ，自動えさやり機である．特殊なのは

二酸化炭素ボンベと自動えさやり機である．酸化炭素ボンベはボンベにレギュレータが差

し込まれており，そこから付属のコックをひねる事で二酸化炭素を水槽に注入することが

できる．このコックをひねるのが人間の動作である．そこでコック部分を電磁弁に切り替

える．電磁弁とは電気的に弁を開けるものである．これは熱帯魚店等で販売されており，

コンセントをさすと弁が開くものである．つまり電磁弁を用いる事により，コーヒーメー

カシステムと同じ仕組みの機器を使用する事で電気的に制御することができる．また自動

エサやり機も熱帯魚専門店にて販売されており，ボタン部分を押す事により，モータが作

動し，熱帯魚にエサをやるものである．これを電気的に制御する手法として，ボタン部分

にもう一つ並列の接点を設ける方法を設ける．具体的に図 50 に示す．ボタンとは，回路を

繋ぐ接点の事である．つまり，ボタンがなくてもボタン部分から出ている足（基盤につい

ている部分）を直接ショートさせている．このショートさせる部分をリレー回路を用いて

ショートさせ，これによりボタンを押す事と同じ事をする．

続いて，熱帯魚の飼育方法から各装置の同時実行の組み合わせとその実現方法を紹介す

る．熱帯魚は日中の電灯と二酸化炭素の供給を行う．二酸化炭素を供給する理由は水草に

十分な二酸化炭素を与えるためである．そして電灯の光により水草が光合成をし，酸素を

吐き出し，その酸素を熱帯魚が吸収するというサイクルである．つまり，日中は電灯と二

酸化炭素を一緒に供給，電灯が消えれば，水草は光合成をしないので，水槽内が二酸化炭

素で充満する．そこでエアレーションの電源を入れ，酸素を供給する．つまり，日中は電

灯と二酸化炭素が共に電源が入り，夜になればエアレーションの電源を入れる組込みシス

テムを構築する．更に，これとは別でエサをやるという行動がある．つまり，電灯と二酸

化炭素は同時のタイミングで入るためプロセスＡ，エアレーションを入れるタイミングを

リレー回路 （1接点 2回路）

電力供給

プロセスＡ プロセスＢ

リレー回路 （1接点 1回路）

電力供給

プロセスＣ

電力 プロセスＣON 稼動OFF 停止

電力 プロセスＡ プロセスＢON 稼動 停止OFF 停止 稼動

電灯二酸化炭素ボンベ

プロセスＢ： エアレーション

プロセスＣ： 自動エサやり機

プロセスＡ：

図 51 システムを考慮した電子機器設計

51

プロセスＢ，そして不特定なエサやりをプロセスＣと考えると図 51のような回路を考える．

つまり，プロセスＡとＢをひとつめのリレー回路（1 接点 2 回路），プロセスＣをふたつめ

のリレー回路（1接点 2回路）とする．これにより，水槽を管理する機器を全て管理する事

が可能となる．

52

８章 おわりに

ユビキタス社会における組込み機器と Web サーバを利用した組込みシステム Web アプリ

ケーションを実現する方法には大きく２つがある．ひとつは組込み機器のマイコン上に Web

サーバを搭載する方法，もうひとつは組込み機器と別のコンピュータ上に導入した Web サ

ーバとネットワーク通信する方法である．両者共に複数の組込み機器の相互作用する連携

や，保守，運用，拡張性に等様々な問題がある．そこで，組込み機器と Web サーバを利用

した組込みシステム Web アプリケーションを実現する新しい３層 IT アーキテクチャを提案

した．３層とはサーバ層，コントロールクライアント層，マイクロクライアント層である．

３層 ITアーキテクチャは従来のクライアントサーバシステムのクライアント部分をコント

ロールクライアントと位置づけ，コントロールクライアントにマイクロクライアント層に

属する組込み機器を接続する事により，サーバと組込み機器の依存関係を無くすものであ

る．更に，このアーキテクチャを用いてを実際に発光ダイオードとフォトリフレクタを使

ったセンサを用いて，「センサに反応があった場合発光ダイオードを点灯させる」という複

数の組込み機器の相互作用する連結の検証を行った．次に，実際に運用できるシステムか

を検証するため，コーヒーメーカをニンテンドーDS から操作するシステムを作ったり，熱

帯魚管理システムをつくって３ヶ月運用した．結果，現在に至るまで大きなトラブルの発

生もなく，著者自身も非常に愛用している．

以上のように 3 層アーキテクチャを用いる事により，組込み機器を用いた Web アプリケ

ーションの構造が，サーバと組込み機器の間に直接的な依存関係が無くなり，拡張性や保

守性，柔軟性の高いシステムが構築できた．これにより，従来アーキテクチャの問題点で

あった他の組込み機器との連携問題や，保守問題が解決できた．今後の課題として，通信

問題に焦点をしぼり，通信レスポンスの性能評価，セキュリティ面の向上等を視野にいれ，

今後の研究としていきたいと考えている．

53

参考文献

[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 社，システム設計 完全ガイド 2008，2007.9.30 pp74-123

[12] 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

54

謝辞

本研究において，阪南大学学会支援事業部に給付金の支給により研究の支援をして頂き非

常に感謝致します． 本論文査読者になって頂いた他にも現代ＧＰにて協力して頂いた前田 利之先生に感謝致

します． 本論文査読者になって頂いた他，授業では多々迷惑を掛け，且つ現代ＧＰでも迷惑をお掛

け致しました，神沢 正典先生に感謝致します． 学部時代から現在まで，様々な御指導を頂いた筒井 茂義先生に感謝致します． 研究，学業，相談，遊びにいつも付き合って頂いた修了生の麻山 勇樹氏，池宮 直氏に

非常に感謝致します． 研究，遊び，その他にも多大な迷惑を掛けた後輩の野口 真司氏に感謝致します． いつも無茶な依頼，私のわがままに付き添って頂いた，学部４回生，学部３回生に感謝致

します いつも，私と担当教員花川共に揃って多大な御迷惑をお掛け続けた，情報システム課，阪

本様，濱田様，森様に感謝致します． 備品購入等の予算について，いつも相談させて頂き，いつも私を支援して下さった研究助

成課，後藤様に感謝致します． いつも深夜に大学に来て作業をする際，出入り口で不審者と思わず学校へ入れてくれた警

備員皆様に感謝致します． そして，修士論文提出 1 週間前だというのに何もできていない私に 1 週間付き添って頂き，

且つ，様々な御指導をして頂いた花川 典子先生に，心をこめて感謝致します．