ハードウェア抽象化レイヤーがプロジェクトを変革する 5 つの方法

ベナンのヤコブ | 2023 年 6 月 5 日

組み込みソフトウェア開発者は通常、ハードウェア抽象化レイヤー (HAL) はパフォーマンスを低下させ、コードの複雑さを増大させるとして、これを避けてきました。 残念ながら、開発者が HAL を採用する場合、ベンダー提供の HAL は多くの場合、ハードウェアを抽象化せず、ハードウェアとの密結合を保証します。 結局のところ、実際に抽象化された HAL を使用すると、開発者は任意のベンダーをすぐに使用できるようになります。 ただし、独自の HAL の使用または開発がソフトウェアに影響を与える可能性がある方法は数多くあります。 この投稿では、HAL がソフトウェア プロジェクトを変革し、これまで実現できなかったスピードと価値を解き放つ 5 つの驚くべき方法を探っていきます。

一般的に、開発者にはお気に入りのマイクロコントローラー ベンダーが存在することが多いことがわかりました。 通常、最初に組み込みソフトウェアを作成したベンダー、またはよく知っているベンダーです。 私にも他の人と同じようにお気に入りがありますが、HAL やソフトウェア ライブラリに依存してソフトウェアを作成するのは危険な場合があります。 たとえば、マイクロコントローラーが突然入手できなくなったらどうしますか? 新しいサプライヤーを選択し、製品を書き直し、テストし、場合によっては認定する必要もあります。 それは速くも安くもありません！ そんなことはありそうもないことだと思うかもしれないが、このようなことは新型コロナウイルス感染症の期間中だけでなく、それ以前にも何度も起きていた。

優れた HAL を使用すると、ハードウェアに依存せず、移植性が高く再利用可能なアプリケーション コードを作成できます。 これは、多くの組み込みチームにとって大きな変革です。 たとえば、ベンダー A を使用してコードを実行し、ビルド内のフラグを変更することでベンダー B 用にコンパイルすることができます。ハードウェアの独立性により、必要なハードウェアを柔軟に使用できるようになり、マイクロコントローラー ベンダーへの依存がなくなりました。

ベンダー提供の HAL を使用するというアイデアが気に入った場合でも、いくつかの重要な機能を確認していれば問題ありません。 まず、HAL は本物の HAL である必要があります。 つまり、ハードウェアの依存関係を解消するインターフェースを定義する必要があります。 これについては、「C でのハードウェア抽象化レイヤー (HAL) の作成」というタイトルのブログで説明しました。 単に関数を実装しただけの「HAL」をよく見かけます。 これは依存関係逆転の原則に従っておらず、コードを更新するのも同様に困難です。 次に、HAL を実装とは別に定義する必要があります。 最後に、インターフェイスによって呼び出される関数をすばやく交換できるようになります。 これら 3 つが揃っていない場合は、ハードウェアに依存しません。 ハードウェアに依存しています!

価値を解き放ち、ソフトウェア開発を変革する鍵は、HAL の使用から始まります。 HAL はさらに、自動化された単体テストや統合テストの有効化などの追加の変換を可能にします。 組み込み開発者は、ハードウェアに触れるコードを作成するため、単体テストに苦労することがよくあります。 つまり、テストはマイクロコントローラーで実行する必要があります。 適切な HAL を配置した場合でも、ターゲット上でドライバーをテストする必要がありますが、すべてのアプリケーション コードが突然解放されます。 アプリケーション コードは、ハードウェアに依存せずにホスト マシン上で単体テストおよび統合テストを実行できるようになりました。

方程式からハードウェアを削除し、テストをホストに移すことは、開発者にとって利益になります。 まず、速いです。 この部分の消去と書き込みのサイクルが遅いことを心配する必要はありません。 次に、テスト ハーネスのサイズやテストの数を心配する必要がありません。 コードとテストをマイクロコントローラーに適合させようとするのではなく、最初にホスト上のすべてのアプリケーション コードをテストするだけです。 次に、オフターゲットのテストに移行すると、継続的インテグレーションや、必要に応じて継続的デプロイメントを利用できるようになります。 その結果、バグをより早く発見し、コストを削減し、品質を向上させることができます。

優れた HAL を使用してハードウェアを考慮に入れると、あらゆる実装をその背後に置くことができます。 つまり、ターゲット、テスト ハーネス、シミュレーション環境の実装が可能になります。 多くの場合、組み込みソフトウェア開発者は、ハードウェアが入手可能になる前にソフトウェアの作成を開始する必要があります。 したがって、開発ボードを使用して開始することもできますが、優れた HAL を使用すれば、代わりにアプリケーション コードでシミュレーションを実行できます。

アプリケーション コードをシミュレートすると、開発者にとって多くの利点が得られます。 まず、アプリケーション コードを顧客の前でより早く入手できるようになります。 顧客は考えを変えるのが好きで、製品を試してみるまでは製品がどのように機能するかを視覚化するのが難しいことは誰もが知っています。 シミュレーションは、顧客が製品を理解し、生産的なフィードバックをより早く提供するのに役立ち、開発サイクル後半での高価で時間のかかる変更を減らすことができます。

次に、シミュレーションにより、ハードウェアを使用せずに障害やその他の異常な動作をテストできるため、より堅牢なテストが可能になります。 たとえば、センサーを誤動作させたり、ターゲット プロセッサでハードウェア例外を強制したりすることは、多くの場合困難な場合があります。 シミュレーション環境では、これは問題ありません。 その結果、再び、より堅牢なソフトウェアが得られます。

ターゲット上でデバッグする場合、変更が加えられるたびに、クロスコンパイル、フラッシュの消去、フラッシュのプログラム、アプリケーションの実行のサイクルが発生します。 アプリケーションによっては、専門的なツールを使用した場合でも、プロセス全体にかなりの時間がかかる場合があります。 HAL を使用してアプリケーションを分離すると、コードのデバッグが高速化されます。 ホストでは、コンパイルと実行のサイクルがはるかに短くなります。 つまり、開発者はより迅速に問題に対処し、必要に応じて最終的なデバッグされたバージョンをハードウェアでテストできるようになります。

HAL が提供する他の変換を実現できるようにすると、単体テストを使用して開発を推進することになり、デバッグに費やす時間も短縮されます。 テストに合格するためのコードのみを記述します。 ソフトウェアは少しずつ作成され、途中でテストが検証されます。 何かを壊した場合は、回帰テストですぐに検出されます。 その結果、デバッグがより速く、より効率的になり、生活やプロジェクトからデバッグがほぼ完全に排除されることになります。 素晴らしいと思いませんか?

HAL を使用して組み込みソフトウェアを開発する場合の究極の変革は、コストと市場投入までの時間を削減できることです。 HAL は、ほとんどのチームが夢にも思わなかった柔軟性を組み込みソフトウェアにもたらします。 顧客からのフィードバックをすぐに得ることができれば、開発サイクルの後半での手戻りが少なくなることが簡単にわかります。 さらに、デバッグをなくすことができれば、それは非常に大きなことです。 ほとんどのチームは、開発サイクルの平均 20 ～ 40% をデバッグに費やしています。 これは、1 人あたり年間 2.4 ～ 4.5 か月に相当します。 すべては、アプリケーション コードをテストしてデバッグ時間を短縮できる HAL を使用したためです。

市場投入までの時間が短縮されると、コストが削減されることは明らかです。 開発サイクルを円滑に進めるために、HAL 開発、テスト ハーネス、その他のツールへの投資が確実に行われています。 ただし、これらのコストは、節約されるコストよりも 1 桁少ないことがよくあります。 初期開発コストを軽く上回る可能性があるメンテナンス関連の費用についても言及していません。

クライアントや同僚から、私がどれだけの仕事をできるかについてコメントされることがよくあります。 その秘密は、HAL が組み込み開発者に提供できる変換のロックを解除したことです。 この投稿で見たように、「本物の」HAL を使用すると、プロジェクトと組み込みソフトウェアの開発方法を劇的に変えることができます。

組み込みソフトウェア開発者は伝統的にこれらの手法を使用してこなかったため、これまで説明してきた変換の一部は少し異質に思えるかもしれません。 ただし、これらの機能を理解し、組み込みソフトウェアの開発方法を劇的に改善できるようにするには、それほど時間はかかりません。 メリットはもうお分かりいただけたでしょう。 問題は、それらを受け入れて、マイクロコントローラーに依存しない HAL をソフトウェアに組み込み始めるかどうかです。 そうすれば、組み込み製品の開発方法に革命が起こると思います。

テキスト形式の詳細