ソフトウェアの品質を学びまくる

ソフトウェアの品質、ソフトウェアテストなどについて学んだことを記録するブログです。

「IoTデバイスをテストする能力」 #IoTテストアドカレ(10)

はじめに

 この記事は、IoTのテストに関するネットの記事を読んでいく、「IoTテスト アドベントカレンダー」の10日目です。二けた目突入したよ! 9日目はコチラ。

kzsuzuki.hatenablog.com

プロファイル

  • タイトル: 『The power of testing IoT devices』
  • 著者: Rohde & Schwarz
  • 参照サイト: Rohde & Schwarz

ポイント

 ワイヤレスなIoTデバイスにおいて鍵となるのは、正確な機能性、プロダクト利用期間における品質、そして性能である。IoTデバイスが普及し、ビジネスや個人生活により大きな影響を与えるようになると、それらへの期待も高くなる。  

ネットワーク接続性

 アプリケーションによってはグローバルなカバレッジ*1が必要で、LTE-MやNB-IoTといったセルラー*2の通信技術にフォーカスすることになる。 一方、多くのデバイスは、非セルラー系のワイヤレス技術(BluetoothWi-FiZigBee、THREAD、EnOcean、SIGFOX、LoRaなど)を用いる。
 複数のワイヤレス技術が共存しうることも含めて、IoTデバイスの通信の全体的なふるまいをテストすることが重要。「スマートメーターが地下にある」「モデムが高速移動する車の中にある」といったテストの条件や、「電池が10年以上もつ」といった要件から、設計の妥当性を確認しなければならない。

規格への準拠

 ワイヤレスデバイスでは、「適用される規格に準拠しているか」「事業者特有の要件に合致しているか」をテストする必要がある。

  • セルラー系のデバイス: GCFの要件への準拠。3GPPが定義したMTC機能に特化したテストを含む。
  • セルラー系のデバイス: ETSIやFCCが定義した規制の要件や、Bluetooth SIGやLoRa Allianceなどが定義した規格の要件を満たす必要がある。

 ワイヤレス技術のテストはこのように非常に複雑で、時間も食うしコストもかかる。Rohde & Schwarzは主要なセルラー系・非セルラー系の技術のテストおよび計測をカバーしてお...(続きを読む)

所感

 7日目の記事と出展が同じですね。通信方式と遵守すべき規格が山ほどあり、複雑きわまりないよという話とともに、「そこで弊社です!」的なトークに移っていく素直さに好感がもてます。でも確かに、ノウハウなしでこの世界に飛び込んでいくのは、玉砕ルートしかなさそうですね。

 略語がたくさん出てきたので、一部を確認しておきます。言葉を調べてメモしているだけですが。

LTE-MとNB-IoT

 こちらに2つの方式の説明がありますが、冒頭の文章から日本語率が低くてさわやかです。

LTEをベースとしたLPWAの主要方式には、NB-IoTとLTE-Mの2つがある。

 WikipediaによるとLPWAは「Low Power, Wide Area」の略で、Bluetoothなどの近距離無線(〜数十m程度)では満たせないカバレッジの無線の分類」だそうです。これまでの資料にも出てきたLoRa、SIGFOXなどはこのLPWAに分類されています。これらが免許不要のISMバンドを利用した特定小電力無線である一方、LTE-MとNB-IoTは免許が必要なバンドを使う技術です。すみません、この辺で勘弁してください。こちらに詳しい説明がありました。

wirelesswire.jp

 また無線通信規格全般について、Qiitaの以下の記事で最近の動向が説明されていました。こういう価値のある記事を読んでしまうと、我が身を振り返って泣きたくなってしまいますが。

qiita.com

GCF (Global Certification Forum)

 本家サイトによると、「GCFの認証は、製造業者が最新のスマートフォン、ハンドセット、ワイヤレスデバイスが世界のモバイルネットワークで正しく動作することを担保するためのもの」としています。NTTドコモ開示している資料によると、GCF認証試験として以下の2つがあるようです。

  • GCF Conformance Test: 端末が仕様準拠であるかのチェック(端末とシミュレータとの対向試験)
  • GCF Field Trial: 端末が複数オペレータNWとの相互接続性があるかのチェック
MTC (machine type communications)

 エリクソン・ジャパンの記事に読む限り、M2M通信と称しているものと本質的な違いはないようですが、「必ずしも人間の介入を必要としないデータ通信の一形態」と定義されているとのことです。

 とにかく無線ネットワーク規格の知識のなさが命取りになりそうです。

 11日目はコチラです。(12月11日の0時に公開されます)

kzsuzuki.hatenablog.com

*1:ネットワーク通信のカバレッジのことだと思います。

*2:バイル通信のために通信事業者が提供しているネットワークの技術、という意味です。

「IoTテストでより賢く」 #IoTテストアドカレ(9)

はじめに

 この記事は、IoTのテストに関するネットの記事を読んでいく、「IoTテスト アドベントカレンダー」の9日目です。8日目はコチラ。

kzsuzuki.hatenablog.com

プロファイル

  • タイトル: 『Getting Smarter at IoT Testing: National Instruments』
  • 著者: Eric Starkloff
  • 参照サイト: RT Insights.com

ポイント

 急速に広がるIoTとそのデバイスにおいて、鍵となる安全性・信頼性を守るのはテストエンジニアである。デバイスの進化と物量に追随して、費用対効果の高いテストを行うには、従来の自動テストでは不十分。

 スマートなIoTデバイスのために、自動化されたスマートなテスト環境*1が必要。
 プラットフォームベースアプローチ(platform-based approach)は、構成要素同士が相互接続性を持つ柔軟なハードウェアアーキテクチャから成る単一のテスト環境上に、多数のアプリケーションの配置するもの。テスト環境のハードウェア・ソフトウェアではなく、テスト対象であるアプリケーション自体のイノベーションにフォーカスできるようにする。

 デバイスの多くの問題は、ソフトウェアの問題に置き換えることができる。

  • 飛行機内での電子機器の操作は、「機内モード」の実装により許容された。
  • Teslaは、自社の自動車にハードウェア的な問題があった際、無線でソフトウェアアップデートすることで対応した。

 同じようにテスト環境も、その時点の課題だけでなく将来の要求にも適応できるように、ソフトウェアデファインドでインテリジェントなものにする必要がある。

所感

 元記事も短いものですが、要約したらものすごく短くなってしまいました。
 これまでの資料では、自動テストについての言及は意外なほど少なかった。この資料では、テスト実行の自動化はもとより、テスト環境の自動化とスマートさ・柔軟さが重要だとしています。次々と出てくるアプリケーションごとに、そのアプリケーションにしか使えないテスト環境を準備するのは現実的でない。ソフトウェアデファインドで柔軟に構成変更のできるテストベッドを持つことが必要だということですね。

 この資料の中で言及されたTeslaのワイヤレスアップデートについては、以下などが参考になります。

www.huffingtonpost.jp

 10日目はコチラです。(12月10日の0時に公開されます)

kzsuzuki.hatenablog.com

*1:Test Eqiopment

「IoTテストの3つの課題」 #IoTテストアドカレ(8)

はじめに

 この記事は、IoTのテストに関するネットの記事を読んでいく、「IoTテスト アドベントカレンダー」の8日目です。エッこれでまだ1/3ですか? 7日目はコチラ。

kzsuzuki.hatenablog.com

プロファイル

  • タイトル: 『Internet Of Things. Introduction & Testing Challenges』
  • 著者: Kelly Hill
  • 参照サイト: RCR Wireless News

ポイント

 SIMカードを通じたセルラーネットワークの接続に取り組んできたCisco Jasper社がWiFiの接続にも手を伸ばすにあたり、単なる無線の機能検証を超えた3つの課題を挙げている。

サプライチェーン内での接続機能の担保

 IoTデバイスのサプライチェーン(部品製造・組み立て・販売・消費者)は、地理的にはグローバル、時間的にも数か月単位。チェーン内部の必要なタイミングで必要な接続性を発揮できることをテストしなければならない。
 たとえば、製造工程において必要な最低限のモバイルネットワーク接続や、販売先において顧客に機能を見せるためのネットワーク接続など。

セキュアなネットワーク権限の担保

 適正でセキュアなネットワーク権限に基づいてデバイスが構成されていることをテストで確認する。
 たとえばコネクテッドな*1自動販売機について、一部の人間だけが通信できて、他の人間やマシン同士の通信は限定しないといけない。

IoTデバイスの平常時のふるまいの理解

 IoTデバイスが平常時にどうふるまうかを把握しなければいけない。
 たとえば水道メーターでは、起動は1日1回、ネットワークへの通信は1回あたり数キロバイト、といった情報。期待するふるまいを適切に設定できれば、テストも可能になるし、配備後のモニターもできる。

所感

 2016年にCiscoに買収された、IoTサービスプラットフォーム事業者・JasperのTheresa Bui Revon氏へのインタビュー記事です。2つ目の「課題」はほかの記事にもあったものですが、1つ目と3つ目は目新しいですね。

 1つ目の課題について、前日の記事でもIoTデバイスのライフサイクルに言及があり、R&Dといった開発前段階から、量産以降までのテストを扱っていました。本日の資料ではこの後半部分にも焦点を当てており、量産以降の接続性の担保を強調しています。このブログは基本的に、ソフトウェアのテストをテーマに書いていますが、IoTという文脈においてはハードウェアのサプライチェーンから意識する必要があるのですね(組み込みでもそうでしょうけれど)。

 3つ目は、テストに限らず、リリース後の運用にまで含めた観点です。
 IoTでなくとも、サービスを運用しているサーバーのリソース使用率や、ネットワーク機器のI/O状態の「平常状態」を押さえたうえで、テストなり運用において異常がないかを確認する必要があります。ただIoTにおいては、その対象となるデバイスの数と種別が段違いになるので、別の難しさがありそうです。

 詳細レポートはこちらからダウンロードできるようなので、このアドベントカレンダーの後半で扱うかもしれません。
 9日目はコチラです。(12月9日の0時に公開されます)

kzsuzuki.hatenablog.com

*1:connectedという過去分詞がこのようにナチュラルに使われだすと、今後どう訳されていくんでしょう。「接続された」だと、IoTの文脈でのconnectedの意味を失ってしまうため、ここでは「コネクテッドな」という表現に逃げています。

「モノのインターネットの紹介とテストの課題」 #IoTテストアドカレ(7)

はじめに

 この記事は、IoTのテストに関するネットの記事を読んでいく、「IoTテスト アドベントカレンダー」の7日目です。1週間も終わっていませんが、すでに息切れ感がありますよ。6日目はコチラ。

kzsuzuki.hatenablog.com

プロファイル

  • タイトル: 『Internet Of Things. Introduction & Testing Challenges』
  • 著者: Tony Opferman
  • 参照サイト: ROHDE&SCHWARZ ※リンク先は外部ページです

ポイント

IoTの概観

  • IoTのデバイスは「3つのA」の特性をもっている。
    • AWARE: 周囲の何らかの情報(位置、温度、動き、光量など)を検知することができる
    • AUTONOMOUS: デバイスからセンターに自動的にデータが送られる
    • ACTIONABLE: データは、よりよい決定を行うために使われる
  • IoTを担う無線技術がたくさんある。
  • IoTの展開における「食物連鎖」。
    バイル通信事業者 - チップセットの製造業者 - 組み込みモデム開発者 - デバイスの製造業者 - システムインテグレーター

IoTデバイスのテストの課題

  • テスト計画・テスト要件の決定
  • テスト計画の実装
  • テストのコスト
  • 無線通信のテストの専門家不在

IoTテストの段階

 テストの内容を、プロダクトのライフサイクルごとに考える必要がある。

初期のR&D/妥当性確認
  • RAT*2間ハンドオーバー
  • データのスループット: 最大データレート、リトライ
  • 電力消費: ドレイン電流、アプリケーション特有の要件
  • バイス内の共存: IoTデバイス内で起こる、複数の無線通信の共存と使用帯域の重複
  • パラメトリックテスト*3
標準準拠確認テスト

 標準に対する要件のほか、通信事業者の受け入れのための認証もある。

量産におけるテスト

 以下のような課題がある。

  • テストが限られるので、複数デバイスの同時テスト/測定などが必要
  • 適切なインタフェースがないために自動化が時に困難
  • OSが様々
  • チップセットのインタフェースが標準化されていない

所感

 無線ネットワークについては3日目の記事でも言及がありましたが、今回の資料はプロトコルよりよりハードウェアに近い部分に対するテストでした。そしてその範囲も、R&Dの段階から量産・サービスに至るまでを対象としており、これまでとはかなり色合いが違います。
 IoTのテスト自体の難しさ(たとえば複数の通信規格の混在状態)もありますが、IoTにかかわる主体が上流から下流まで多彩であること、求められるテストがライフサイクルによって様々であることが特に主張されている資料でした。

 8日目はコチラです。(12月8日の0時に公開されます)

kzsuzuki.hatenablog.com

*1:Low Rate Wireless Personal Area Network

*2:Radio Access Technology

*3:通常parametic testingというと、統計の分布に1つ以上の仮定をおくことのようですが、ここでは無線に関係する各種の量を変化させて動作を確認することを指しているものと思われます

「性能テストのいろは: IoTにどうアプローチするか」 #IoTテストアドカレ(6)

はじめに

 この記事は、IoTのテストに関するネットの記事を読んでいく、「IoTテスト アドベントカレンダー」の6日目です。5日目はコチラ。

kzsuzuki.hatenablog.com

プロファイル

  • タイトル: 『Performance Testing 101: How to Approach the Internet of Things』
  • 著者: Henrik Rexed
  • 参照サイト: Neotys

ポイント

 IoTアプリケーションに対する負荷テスト・性能テストは、これまでのWebアプリケーション・モバイルアプリケーションと大きく違うわけではないが、理解しておくべき点はある。

  • 増大する複雑さ: 「モノ」や、それを操作するためのスマートフォンなど、考慮に入れるデバイスの数が異なる
  • モノからのメッセージの記録: Webやモバイルのように、メッセージを記録しやすい形になっているとは限らない
  • 様々な使用状況: ユーザのインターネットへの接続状態が大きな意味を持つ。帯域幅や遅延、パケットロス、同時接続数なども考慮要

 温度・電力量・メモリ使用量の変化といったシステムの統計を注意深くモニターすることと、異なるネットワークレイヤー間のレスポンスタイムを測定することも必要。そのさい、Wiresharkのようなネットワークスニファーツールが必要になる。記録することができれば、それを生成することも可能である。

 以下のように進めることになる。

  1. 対象のオブジェクトのSLAを明確にする。
  2. サーバに対し一度に接続してくることが予測されるオブジェクトの数を踏まえて最大負荷を決める。
  3. テストケースを作るために典型的なユースケースとそうでないユースケースを定義する。
  4. アプリケーションが特別なプロトコルを使用しているかを確認し、それらのプロトコルに対して迅速かつ容易に性能テストを行うことのできるテストツールを選ぶ。

所感

 これまでにはなかった、「性能」の観点での記事です。モバイルやWebと本質的には変わらないものの、デバイスの量に増加により複雑さが増していることと、プロトコルが特有であることに注意すべきとしています。
 デバイス-センサー間の近距離無線通信の方式については5日目の資料でも言及があったのですが、センサーから先のプロトコルについて意識していませんでした。知識が乏しすぎるので、一行紹介にとどめます。。

  • MQTT (Message Queuing Telemetry Transport): 本家によると、「M2MやIoTの接続プロトコル。メッセージ転送の受信・配信を行うために、きわめて軽量にデザインされている」。

  • XMPP (Extensible Messaging and Presence Protocol): Wikipediaによると、「オープンソースインスタントメッセンジャープロトコルおよび、クライアント、サーバの総称」。

  • DDS (Data Distribution Service?): Wikipediaによると、「スケーラブルでリアルタイム性があり、高信頼性・高性能で互換性のあるデータ交換を目的とした、OMG(Object Management Group)のM2M規格である」。

  • AMQP (Advanced Message Queuing Protocol): 本家によると、「アプリケーションや組織間でメッセージをやりとりするためのオープンな規格。システムを接続し、ビジネスプロセスに必要な情報を与え、目標を達成するための指示を伝える」。

  • CoAP (Constrained Application Protocol): 本家によると、「IoTにおいて制約のあるノード・ネットワークで使用されるWeb用転送プロトコル。スマートエナジーやビルディングオートメーションといったM2Mアプリケーションのために設計されている」。

 う、う~ん。抽象的でこれじゃ全然わからないですね。価値のない情報で申し訳もござらん。。。

 7日目はコチラです。(12月7日の0時に公開されます)

kzsuzuki.hatenablog.com