はじめに
この記事は、IoTのテストに関するネットの記事を読んでいく、「IoTテスト アドベントカレンダー」の16日目です。15日目はコチラ。
プロファイル
- タイトル: 『Automated Testing for the Internet of Things』
- 著者: Vassili van der Mersch
- 参照サイト: NORDIC APIS
ポイント
IoTプロダクトの開発
- 組み込みシステムが本質的に自己完結的で、個別に動作することができたのに対し、IoTではネットワークに接続されたオブジェクトが互いにコミュニケーションする必要がある。
- 無線ネットワークを通じたファームウェアアップデートは、ハードウェアプロダクトの陳腐化のスピードを下げることになった。プロダクトをリリースした後に、新しい機能を追加することもできる。ただし、十分なバージョン管理とテストが必要である。
- 組み込みソフトウェアには以下のような特徴があり、IoTプロダクトもその課題を引き継ぐことがある。
- プログラマブルな電子デバイスの安全性・信頼性を担保するために、IEC 61508やMISRAなどの規制上の要求事項にも従う必要がある。
- プログラミング言語として、CやC++が使用される。性能面では利があるが、プログラミングのリードタイムが長く、明示的なメモリ管理が必要。移植性に欠けるので、開発環境と実環境でクロスコンパイルが必要になる。
- Webアプリケーションやモバイルアプリケーションの開発においては、継続的インテグレーション（CI）が成熟しており、テスト駆動開発も支持されている。一方組み込みソフトウェアでは、モノリシックなレガシーコードに依存性をもっていることがしばしばで、CIの原則を後から持ち込むことが難しい。
- ハードウェアが入ってくると、アジャイル開発にも別のやり方が求められる。たとえば、前のイテレーションにおける成果を捨てるというのは、ソフトウェアと比べてコストが高い。
- IoTプロダクトのテストには、以下のような難しさがある。
- IoTではサブシステムの所有者が様々であることがある。テストに必要なサブシステムや、依存性のあるコンポーネントが揃っているとは限らない。
- 天気の状態、大気圧といった、現実世界の網羅的なテストデータを手に入れることが難しい。
- ネットワーク帯域の制約、電池の故障、電波の干渉などを中心とした非機能要件が難しい。
対応方法
- 慣れたアーキテクチャを選択する（たとえばOSをLinuxのみとする、など）ことで、テスト計画において当て推量に頼らざるを得なかった範囲を絞る。
- ハードウェアからプログラミングロジックから分離することで、テストを容易にする。
- 実世界におけるユーザの入力データや環境のデータを記録しておき、テスト環境で再生することで、テストデータの品質を保つ。
- 規制や標準に対する準拠のテストは、静的解析ツールによる自動化を行う。
ハードウェアのシミュレーション
ハードウェアのシミュレートすることで環境の一部の抽象化し、ハードウェア特性に関するテストを加速することができる。シミュレータは高度化しており、たとえば以下のような機能をサポートしている。
- パフォーマンスとメモリのテスト
- セキュリティテスト
- エッジケースのテスト
- フォールトインジェクション: ネットワーク接続状態の低下や、センサデータにノイズを発生させる電磁気的な干渉など。
「ハードウェアラボ」は、モデル・コンダクター・ハードウェアのデザインパターンに従う。
- モデル: システムを支える抽象ロジックを定義し、システムの状態を保持し、外部にAPIを提供する。
- コンダクター: ステートレスなコンポーネントで、モデルとハードウェアの間の双方向のやりとりを連携させる。
- ハードウェア: 物理的なハードウェアをラップする。コンダクターとのコミュニケーションによって、イベントを発生させたりイベントに反応したりする。
しかしシミュレーションは完全でなく、特に人間との相互作用についてのテストは難しいため、実際のハードウェアを使用した最後の品質保証プロセスは依然として必要である。
所感
組み込みテストの課題をそのまま引き継いだうえに、新たな難しさも増えているのがIoTのテストです。 ハードウェアラボの「MCHデザインパターン」というのは初めて聞いたのですが、たとえば以下に情報があります。そのまんま、「ハードウェアとロジックの分離」という節です。
17日目はコチラです。（12月17日の0時に公開されます）
