シミュレーションによるDevOpsでハードウェアの問題を解決する方法 - Part 2

May 02, 2022 Simics

著者:Jeff Gowan/ジェフ・ゴーエン

前回のPart1では、DevOpsのプラクティスをレベルアップするための課題について取り上げ、ROIにアプローチする方法をご紹介しました。また、インテリジェントエッジ向けの開発では、ハードウェアが課題になることと、シミュレーションがその答えになるということをお伝えしました。今回は、ハードウェアが引き起こす可能性がある問題の4つの要因と、シミュレーションによってそれを解決する方法をご紹介します。では、さっそく始めましょう。

1. 開発ライフサイクルを阻むボトルネック

例えば、設計チームが、設計中のデバイスやシステムに最適なプロセッサとOSの組み合わせで、まだ広く生産されていないコンポーネントが含まれていると判断したとします。あるいは、使用予定のハードウェアは生産されてはいるものの、コストが高すぎて、各チームメンバーがラボで作業ができない状況かもしれません。一方で、すぐに開発に着手しなければ、納期に間に合わないというリスクがあります。 このシナリオに、やっと設計・実装した、待ち望んでいたDevOpsパイプラインを追加したとしましょう。この状況は、どこにも売っていない特定の種類の燃料しか燃やせない高級スポーツカーを所有しているようなものです。

似たようなハードウェアを入手できれば、開発したいものによってはそれで十分かもしれません。しかし、お客様の多くは、100万回以上正確に失敗なくタスクを実行する必要のある産業用ロボットや、何百人もの乗客をA地点からB地点まで安全に運ぶ航空機など、高度な技術を要するデバイスの製造を担っています。このようなお客様にとっては、「十分である」という言葉は通用しません。

2. 精度 vs スピード

一部の企業は、ハードウェアがないという問題に対して、ハードウェアやシステムのモデルやシミュレーションを何らかの形で利用することで対処しています。モデルを選択する際、精度とスピードの間に境界があり、一方が他方にトレードオフされると考える人もいます。しかし、私は2つの理由から、それほど単純な話ではないと思っています。すべてのユースケースで同じモデルを使えるわけではないことや、中にはモデルをまったく使わないこともあるためです。ユースケースによって、モデルに必要な明確さのレベルを決める必要があります。例えば、入手できないインテル®チップをベースにした特定のSoCを開発する場合、エミュレートしたx86システムで開発とテストを行うのか、類似のデバイスでより一般的なx86ベースの開発をするのかです。不具合が見つかったり、自分の設計が確かであるという誤った安心感を持つこともあるかもしれません。しかし、最終的なボードで開発することができれば、それは根拠のないものであるとわかります。

設計の微調整をおこないたい場合や、ソリューションがデプロイされる実際のデバイスや周辺機器に関する複雑なロジックを構築して早期にテストを開始したい場合は、開発の早い段階でDevOpsパイプラインに統合できる忠実度が高いモデルを持つことが優れた選択となります。

よりモデルが鮮明であれば、テストの精度も上がり、結果に対する信頼度も高くなります。もし、低解像度のモデルで合格率が80%だったら、どれだけ安心できるでしょうか?もし、精度の高いモデルであれば、その80%の合格率にもっと安心できるはずです。つまり、DevOpsパイプラインのシミュレーションの精度が高ければ高いほど、コードやソフトウェア出荷の準備に対する信頼度が高くなるということです。

この精度の高さは、認証取得の準備をする際にも重要になります。ほとんどの場合、実際の認証にシミュレーションを使用することはできませんが、認証に至るまでのテストにシミュレーションを使用することで、より信頼性の高い(そしてより迅速な)認証取得に備えることができます。

3. 非破壊検査

非破壊検査は、シミュレーションの利点が明白な分野です。前述のように、デバイスの認証が必要な場合があります。繰り返しになりますが、実際の認証にシミュレーションを使うことはできないかもしれません。しかし認証取得の準備には、ハードウェアを破壊する可能性のあるすべての脆弱性を探す必要があります。デバイスにストレスを与える可能性のある様々なシナリオを想定し、起こりうることを確認する必要があります。問題は、ラボを破壊したり、デバイスの物理モデルや実機そのものを壊すことなく、どのようにストレステストを行ったらいいかということです。デバイスを繰り返しテストして破壊し、すべての脆弱性を見つけなければならないとしたら、危険であることは言うまでもありませんが、相当の費用がかかるでしょう。

シミュレーションを活用すれば、DevOps実践の価値を高め、認証への道を早めると同時に、ハードウェアラボのコストを削減することができます。プリフライトシミュレーションを行うことにより、事実上無限のシナリオの組み合わせを限度なくテストすることができます。夜間に実行し、翌朝ログインしたときに結果が表示されるよう、テストを自動化設定することもできます。サーバーに影響を与えることはありません。

4. 1台のデバイスか、複数のデバイスか

1台のデバイスで実行するテストをセットアップするのは、簡単とは言いませんが、たった1台でしかありません。もし、複数のデバイスを含むシステムを構築するのであればどうでしょうか?それぞれのデバイスが異なる環境にあったり、異なることをする必要があるにもかかわらず、ネットワークに接続されていたり、ネットワークに依存していたりするとしたらどうでしょうか?10台、100台、1000台以上のデバイスを接続したラボを立ち上げてテストを行うことは可能ですが、簡単ではありません。あるお客様は、会社全体にあるネットワークにすべてのテストデバイスを接続することで、それを実現しました。テストは成功しましたが、かなりの手間とコストがかかりました。複数のデバイスを購入し、そのすべてをネットワークに接続する時間を要しました。オフィスの隅々にまでデバイスが散らばっていないとしても、最良のシナリオはあらゆる方向に配線接続されたラボをもつことです。しかし、それは混乱するだけでなく、管理上とても難しいことです。

では、物理的なラボをセットアップした後、変更が必要になったとき、DevOpsパイプラインはどうなるのでしょうか?単一のボックス上でコードの一部をテストすることは、それ自体十分に困難なことですが、ネットワーク上で作業している場合はそれだけでは不十分です。すべてのハードウェアを、可能な限り、デプロイされる環境でテストする必要があります。

もう一つ重要なことは、テストの頻度です。複数のコンポーネントを設置した物理的なテストラボがある場合、どれくらいの頻度でテストを行うことができるでしょうか?より頻繁なデプロイを目標としている場合に、毎月、毎週、毎日、あるいは1日に何度もテストすることができるでしょうか。

シミュレーションを活用すれば、必要な数のデバイスを無制限に、完全な環境にセットアップすることができます。1台のデバイスでも1,000台のデバイスでも、一度環境を構築すれば、必要に応じてデバイスを追加したり、設定を変更したりすることが簡単にできます。新しい設定や変数をテストしたい場合も、問題ありません。元の設定に戻したい場合も簡単です。どの配線がどのデバイスに繋がっているのかを確認する必要はありません。さらに、すべてのモデルをシミュレーションすることで、より頻繁にテストを行うことができ、テストの信頼性が高まり、製品の品質も向上します。

繰り返しになりますが、インテリジェントエッジ向けの開発を行う場合、ハードウェアが課題です。良いニュースは、シミュレーションがその問題を解決してくれるということです。

物理的なデバイスでテストすることは可能ですが、それが最適ではない理由はたくさんあります。物理的なハードウェアに依存すると、コストとデプロイに要する時間が増加し、同時に信頼性と品質が低下する危険性があります。ハードウェアの可用性に起因するボトルネックは、出荷日を遅らせたり、完全なテストをおこなう能力を制限します。市場投入時期の遅れは、競合他社に追いつかれる可能性をつくり、顧客の不満につながります。一方、納期を守っても、十分なテスト時間を確保できなければ、顧客のニーズを満たさない製品を提供するリスクが高まります。

シミュレーションモデルを決定する際に、正確さよりもスピードを優先させると、実際に納品遅れを招く危険性があります。低解像度や不正確なものを使うと、信頼できるテスト結果を得ることができず、結局はより多くの作業を行う必要性がでてくるのです。

非破壊検査がおのずと示すのは、ハードウェアを破壊するたびにコストは上昇するということです。

多くのデバイスをテストする場合、デバイスを追加するたびにコストを押し上げることになります。また、デバイスのコストだけでなく、テストする物理ネットワークの接続や管理にもコストがかかります。

一方、Simicsを使ったシミュレーションは、最初から正確なモデルを使って、すぐに作業を開始することができます。サプライヤーからハードウェアが入手できるようになるのを待ったり、それを必要とするエンジニアのためにラボの時間を確保する必要はないのです。始めから精度の高いモデルで作業することができるため、必要なすべてのテストシナリオを実行するための十分な時間を確保しながら、納期に間に合わせることができます。また、これらのテストを自動化することで、各変更をDevOpsパイプラインに直接フィードし、必要な頻度でデプロイすることが可能になります。

シミュレーションしたモデルが壊れても、ボタンを押せば瞬時に復旧できます。さらに、自動でセットアップと再度実行するように設定すれば、結果を確認するだけでよいのです。

ネットワークのテストが必要な場合はどうでしょう?必要なだけコンポーネントを追加してください。基本的にコピー&ペーストで追加することができます。ユースケースによっては、他のネットワークや物理デバイスにリンクし、テストすることも可能です。

このシリーズを紹介する動画を作成しました。以下からご覧いただけます。
https://www.windriver.com/resources/webinars/devops-with-simulation-can-solve-your-hardware-problem

Wind River Simicsについての詳細は以下をご覧ください。
https://www.windriver.com/japan/products/simics