オープンIoTプラットフォームである同社の「LANDLOG」、天気予報サービスを提供するウェザーニューズ社による、世界中700万台の船舶の位置情報、気象・海象情報を考慮しつつ、気象予測・最適な航路提案まで行う「Safety Status Monitoring(セーフティ・ステータス・モニタリング)」などが挙げられる。IDC Japanによると国内IoT市場の市場規模は、2017年に5兆8160億円、2022年には11兆7010億円 にも上ると見られている 。このようにIoT製品の社会への適用は拡大の一途をたどっている。複数の異なるドメインに属するプログラムが協調して動作するという複雑なシステムに対し、我々テストエンジニアはどのような見地からシステムのテスト、品質保証にあたるべきであるかを考察する。

IoT アーキテクチャから導かれる品質の属性

テストエンジニアとして IoT システムを理解、分解、再構成する際に留意すべきポイントとして、IoTはあくまでシステム、あるいはシステムオブシステムズのつくり、アーキテクチャであり、エンドユーザに対する何らかの振る舞いを表現するものではないと言う点が挙げられる。テストエンジニアがテストという活動に取り掛かる際に初めに行うのは、仕様書の読解、実際の製品の試用、ステークホルダーへのヒアリングなどを通じた対象物の理解である。まず、IoT という “構造” が持つ特性を振り返り、その特性から導かれる考慮すべき品質の属性を考えてみたい。

IoTの “構造” として、主として無数の組み込み製品で構成されるデバイス層、デバイスから収集したデータの1次処理を担うエッジコンピューティング（フォグコンピューティング）層、加工されたデータの活用や他サービスとの連携を担う、クラウドコンピューティング層の三層構造を想定する。

クラウドコンピューティング層

クラウドコンピューティング層を “単体”で見た場合、これに要求される品質の属性は一般的な業務システム、クラウドサービスに求められるものとさほど変わりはない。多くの業務システムやBIツールと同様に、エッジコンピューティング層から上がってくるデータをどのように整理して、どのように示すことで、何の役に立つのか、といった主としてビジネス要求に重きを置いてテスト戦略を検討することになる。この層に求められる品質の属性を強いて挙げるなら、エッジコンピューティングから吸い上げられるデータを取り扱う際のセキュリティ、可用性、応答性が着目すべき点となるだろう。セキュリティについては後編で主として取り扱う。

エッジコンピューティング層

エッジコンピューティング層の役割は、デバイス層への高速な応答と、収集されたデータの一次加工、及びクラウドコンピューティング層への送信、である。一見単純なプロキシのように思えるが、データの加工が伴うため、どちらかというとフィーチャーフォン時代によく見られたPC向けのウェブサイトをモバイル端末でも閲覧可能なように変換するゲートウェイと類似している。このような観点からこの層を眺めるとき、求められる品質の属性には以下のようなものが考えられる。

• 大量のデバイスから送出されるデータの一次受けとしての処理性能、可用性
• データ加工時の機能性
• 即応性（例えば自動運転車におけるデータに基づく判断など）

三層アーキテクチャモデルにおける中間に位置するこの層に求められる役割は年々拡大している。エッジコンピューティングの時点でAIによるデータの取捨選択や、クラウドコンピューティング層を介さずに、予め想定された人に提示するための情報をデバイスへの応答など、IoTアーキテクチャの重心はこちらに移動し、クラウドコンピューティング層はサービスにますます特化していくことが予想される。エンドユーザが直接触れるサービスではなく、IoTシステムとしてのテストを考えるとき、上下の層とコミュニケーションを取るこの層を起点にテスト戦略を考えていくことは、エッジコンピューティング層が、システム全体のパフォーマンスを左右する層であることからも、有効なアプローチとなるだろう。

デバイス層

最後に、デバイス層である。IoT はしばしば「モノのインターネット」と表現される。このモノにあたるものがデバイスであり、実体としてはセンサー、アクチュエータ、ビーコンなどの物理現象に対して反応を返すものから、それらの反応をコンピュータが理解できる形に変換し、ネットワークに送出する役割までを一体として担う、スマートデバイス が含まれる。

総務省による平成30年版 情報通信白書 （上記図２、図３） によると、世界のIoTデバイス数は年間15％以上の割合で増加しており、特に産業用途、自動車、医療などの分野において成長が著しい。一方、スマートフォンや通信機器などは市場が成熟しているため、相対的に低成長が見込まれている。活用される分野が自動車、医療などクリティカルな領域を含むことに注意したい。このように増加を続けるスマートデバイスのテストに関しては、組み込み製品の開発で活用されているテスト観点、テスト技法も活用したい。

2000年代、移動体通信がソフトウェアの配信に実用的な速度を発揮できるまでの間、組み込み製品では出荷後にソフトウェアを更新することが困難であった。組み込み製品は、出荷時点でバグを可能な限り除去せねばならず、かつ、その出荷台数は10万、100万台単位にも及ぶ。つまり、再現率が1万分の1のバグであっても、市場では10人、100人がそのバグに遭遇することになる。そのため、組み込み製品の開発では、この1万分の1の再現率のバグを検出するためにテスト技法の発明、利活用が進んだ。IoTデバイスの時代においては4G、5Gといった超高速通信網が既に発達しているため、出荷後のソフトウェアのアップデートは当時とは比較にならないぐらい容易になっているものの、IoTシステムが社会に与える影響を鑑みるに、出荷時点でできるだけバグを取り除いておくべきであることに変わりはない。そのすべてが組み込み開発由来という訳ではないが、JSTQB AL TA に挙げられているテスト技法（特に組み合わせテスト、状態遷移テストなど）はIoTデバイスのテストにおいても、採用を検討する価値があるだろう。

IoTシステムにおいて、デバイスは既製品を外部から調達する場合がある。前述のようなクリティカルなシステムであったり、タイミングや応答性にシビアな要求が存在したりする場合などは、調達してきた部品に対する受け入れテストも求められる。デバイスを調達する際には、どのような情報を感知し、エッジコンピューティング層にどのような情報を送出するか？という要件に基づいて製品が選定される。基本的な要件を満たしていること、ステークホルダー間での合意に基づく非機能要件の検証などを基本とした上で、運用上起こり得る異常系の振る舞いを検出するためにHAZOPなどの手法を活用することも受け入れテスト計画に含めたい。デバイスを一から開発する場合においては、テストの文脈からは少し外れるが、組み込みシステムの開発過程における品質指標を定めた ESQR [IPA/SEC, 2011] (※1)や、IPA/SECによるテストの事例集 [IPA/SEC, 2012] (※2)などを参考にテスト計画を組み立てつつ、IoTシステムを構成する組み込み製品における品質の属性としては以下のようなものに着目したい。

• 単独で長期運用できる可用性
• 想定される値域において正確なデータを送出し続けられる能力
• デバイスが送出するデータの相互運用性

第一に、通常、IoTデバイスは一度設置を行ったらそれ以降はなるべくメンテナンスを行わずに済むことが求められる。ファームウェアのアップデートや、リソースの枯渇などに伴う再起動時においても、設置した時点と同様の能力を発揮することが求められる。 第二に、センサーデバイスにおいては感知する物理現象を送出するデータに変換する機能に対しては、正確・厳密に精査のうえ、送出されていることを検証したい。(※3)
データの精度に加えて、異常値の扱いとしてHigh/Low パスフィルタでの切り捨てや、異常値の発生自体がどのように処理されるのかを合わせて検証する。

最後にデータの相互互換性として、横の互換性と縦の互換性を考える。横の互換性とは、IoTデバイス同士、縦の互換性とは、IoTデバイスとエッジコンピューティング層との互換性を指す。横の互換性は、デバイス層同士が相互に関連することでデータを構成する場合の、デバイス間インターフェースの適合性に着目する。例えば高速で移動する車両の情報をIoTデバイス間でハンドオーバーし、一定のデータが構成できた時点でエッジコンピューティングに送出するような場合を指す。縦の互換性は、一般に既に流通しているものをIoTデバイスとして活用するような場合、送出されるデータのフォーマットの微細な違い、例えばJSON形式のデータにおいてリスト要素の末尾にカンマを付与するか否か、といったアプリケーションレベルのものから、伝送経路の仕様によるデータ整合性の保証の有無などが検証すべき観点として挙げられるだろう。

• ※1SEC BOOKS：ESQR　Ver.1.1：【改訂版】組込みソフトウェア開発向け品質作り込みガイド　 IPA 独立行政法人 情報処理推進機構: https://www.ipa.go.jp/sec/publish/tn12-001.html
• ※2SEC BOOKS：組込みソフトウェア開発における品質向上の勧め[テスト編～事例集～] IPA 独立行政法人 情報処理推進機構: https://www.ipa.go.jp/sec/publish/tn12-004.html
• ※3RFC793 1.2.2 Robustness Principle 「受信するものは寛容に、送信するものは厳密に」（ポステルの法則）

後編に向けて

本稿では、IoTシステムの概要、およびその構造として三層アーキテクチャを取り上げ、それぞれの層、特にエッジコンピューティング層、デバイス層についてのテスト・保証すべき品質の属性とテストのアプローチについて述べた。後編では、他システムと比べて特にIoTシステムに対して強く求められる品質の属性である、セキュリティ について考察していきたい。

テストエンジニアから見た構造物としての「IoT」とそのテストにおけるアプローチの考察【後編】

この記事をシェアする