機能検証フェーズ

機能検証フェーズでは、論理的検証段階での検証によりアプリケーションに最適化され た設計に基づき、実装と機能検証を行う。一般にソフトウェアやネットワークシステムの

実証環境での実践的実験 未知の外乱 ルーティング

推定データ量

デバイス性能

移動 デバイス役割

未知 未知

小規模単純な環境での 実装機能中心の検証

論理検証に基づく 実装 概念を基に論理的な アーキテクチャ設計

実環境向け実装の作成 ルーティング

推定データ量

デバイス機能 デバイス役割

電波伝播特性 地形

移動

決定した設計 未知の外乱

未知の特性

推定した特性 推定データ量

論理的検証 ルーティング

デバイス役割

デバイス機能

電波伝播特性 地形

移動

推定データ量

未知の外乱

図 8.19: 環境特性の積極的推定による設計へのフィードバックの効果

より大規模な連結試験 数台での連結試験

1台での機能試験

GPS MOTION STORAGE IMAGE

Receiver/Server AP

14:00

14:00

14:00 14:00

14:00 14:00

14:00

14:00 14:00

14:00 14:00

14:00

14:00 14:00

14:00 14:00

単一機種での検証規模拡大

図 8.20: 単一機種の規模拡大による機能検証

単一機種の機能検証を規模を拡大して行う。ノードの複製を作成するだけで よく容易に作成可能だが、ノードの役割分担が有る場合は、単一機種だけで は検証できない機能がある。

より大規模な連結試験 数台での連結試験

最小構成での連結試験

GPS MOTION STORAGE IMAGE

Receiver/Server AP

14:00

14:00

14:00

14:00

14:00

14:00 14:00

14:00

機種混合での検証規模拡大

STORAGE

Monitor

図 8.21: 機種混合での規模拡大による機能検証

機種混合での機能検証を規模を拡大して行う。同一機種のノードの増加は複 製を作成するだけでよく容易に作成可能だが、機種の種類毎に作成する必要 がある。ノードの役割分担が有っても全システムを構成する機種数で機能検 証を行う事で、全機能の検証を行う事が可能である。

機能検証では、単体機能検証、連携機能検証などを行う。IoTによるユビキタス環境で利 用するアプリケーションの場合、想定するデバイスの種類が多岐にわたり、場合によって はデバイスの種類毎に実装も異なる事から、デバイスの種類毎の機能検証が必要となる事 が多い。そこで、まずこのフェーズでは実装後、図8.20の様に単一のデバイスで単体機能 検証を行い、次にシステムに必要な最小構成の種類で検証を行い、徐々に種類とデバイス の数を増加させて図 8.21の様な連携機能検証を行う。この機能検証フェーズでは、設計に 基づく機能検証に主眼を置き、ネットワークの構成は、単純で安定した状態で行う。

8.3.1 機能検証に特化した検証環境構築支援ツール

大規模なシステムの実証実験を行う場合、まずは比較的小規模な実証検証環境を構築し、

機能的な検証を行った後、様々な環境特性を再現した大規模な実証検証環境を構築し、実 践的な検証を行う事が一般的である。しかし、大規模な実証検証環境の構築は作成した環 境と、希望した環境の同一性の確認や環境の健全性の確認が難しい。特に初期の段階で検 証を行う担当者が、実証検証環境の構築に不慣れであった場合はその影響が顕著になる。

また、実証実験ではソフトウェアのチューニングも行われるため、反復的な実験環境の構 築、段階的な規模の拡張が行われる。そのような環境構築を柔軟に行う為には、実験環境 の構築確度の向上や、環境構築の速度向上が望まれる。本論文では、このような初期の実 証実験環境を効率的に作成する為に、一般的な作図ソフトで作成した実験環境の構成図を 基に実験環境を構築するStarBuilderを実装した。

StarBuilderでは、実験環境構築時に利用するコンポーネントと呼ぶノードのディスクイ

メージとメモリ量やネットワークインターフェース数、IPアドレスなどの設定情報を共有 する事が可能である。その為、実験者は自分が利用したいノードのテンプレートとなるコ ンポーネントが既に登録されている場合は、自分でOSのインストール作業などをせずに 設定情報の変更のみで自身の実験に利用出来る。これにより、実験者はOSイメージの作 成のコストを削減できる。この効果は、利用するノードが汎用的なOSで有るほど高い再 利用効率を期待出来る。また、StarBuilderでは複数のノードを利用する場合、コンポーネ ントが共通であれば、設定情報を必要台数分入力することで単一種別のノードを指定数作 成する事が可能である。機能検証フェーズで行われる単一デバイスでの単体機能検証では、

一つのデバイスイメージを作成すれば設定ファイルを用意する事で、規模を拡大した単体 機能検証が可能となる。また、複数のデバイスで単体機能検証を行ったあと、そのイメー

ジを再利用し、設定ファイルを修正することで、連携機能検証へスムーズに移行すること も可能としている。

StarBuilderのこれらの機能を利用し、機能検証環境を構築する事でより柔軟な検証環境

の構築が行える。