ArmベースのGravitonインスタンス、Yocto Project、SOAFEEに基づく、エッジとクラウドで共通の自動車用組み込みLinuxイメージの構築

この記事は、Building an Automotive Embedded Linux Image for Edge and Cloud Using Arm-based Graviton Instances, Yocto Project, and SOAFEEを翻訳したのものです。

自動車業界の組み込みソフトウェア開発者は、何十年もほとんど変わらない伝統的な組み込み開発手法を使用してきました。特定の組み込みシステムをターゲットとしてソフトウェアを開発する場合、その組み込みシステムは、メモリ、演算、I/Oの性能が限られているなど、もともとリソースに制約があります。さらに、開発用の組み込みシステムは高価であることが多く、新しい電子制御ユニット（ECU）やシステムオンチップ（SoC）のアーキテクチャに取り組む開発チームにとって、希少なものとなっています。この希少性は、最近の自動車業界における世界的なチップ不足により、さらに顕著なものとなっています。

そのため、ソフトウェア開発者は、組み込みプラットフォーム自体で直接ソフトウェアを開発することを避け、代わりに強力な開発マシンやホスト上で開発しています。ホストマシン上での開発やテストで実行するソフトウェアを作成する際に使用したコンパイラやツールチェーンは、組み込み先に展開する際には直接使用することはできません。多くの場合、組み込みシステムで使用されているオペレーティングシステム (OS) 自体をホストマシン上で使用することはできません。開発者は、面倒なホストマシン上のOSエミュレーションツールや、クロスコンパイルという特殊なコンパイラを使ってターゲットシステム用の実行コードを作成するプロセスに頼っています。コードが開発システム上にあれば、最終的な統合と検証テストを行うことができますが、現状、スケーリング性能は物理的なハードウェアの数に制限されます。組み込みシステムの典型的な開発、統合、検証のワークフローは、今日では次のようになっています。

旧来の開発者のワークフローにおけるコード開発からターゲットへのデプロイまでの流れ、クロスコンパイルと統合テストの必要性を説明しています。

本ブログでは、クラウドを利用してネイティブにコンパイルされたソフトウェアの作成・テスト・デバッグを支援する、新しい自動車ソフトウェア開発コンセプトの構成要素を紹介します。これにより、ワークフローを大幅に簡素化することができます。このコンセプトは、しばしば環境パリティと呼ばれ、ArmとAmazon Web Services（AWS）のホワイトペーパー、およびKevin Hoffmanの著書「Beyond the Twelve-Factor App」で詳しく説明されています。

“環境パリティの目的は、あなたのチームと組織全体に、アプリケーションがどこでも動くという確信を与えることです。”    —ケビン・ホフマン

クラウドネイティブなソフトウェアディファインドビークルの目的を達成するうえで、環境パリティは主要な要素です。

Arm、AWS、そしてSOAFEE

Armのテクノロジーは、コンピューティングの未来を定義しています。エネルギー効率の高いArmのプロセッサ設計とソフトウェアプラットフォームは、2250億以上のチップで高度なコンピューティングを実現し、そのテクノロジーによって、センサーからスマートフォン、スーパーコンピュータに至るまで様々な製品が安全に動いています。また、1000以上の技術的パートナーとともに、あらゆる場所で人工知能が動作することを可能にしています。サイバーセキュリティの分野では、チップからクラウドまで、デジタルな世界における信頼の基礎を提供しています。Armアーキテクチャは、車載インフォテインメントや車体制御、非常に繊細な機能安全関連のコンピュート・ワークロードを含め、現代における自動車内部で最もよく使われています。

2021年、Arm、AWS、その他の創設メンバーは、Scalable Open Architecture for Embedded Edge (SOAFEE) Special Interest Groupを発表しました。SOAFEEには、自動車メーカー、半導体、クラウド技術のリーダーが集まり、ソフトウェアディファインドビークルのスタックの最下層群を実装するうえでの、オープンスタンダードベースの新しいアーキテクチャを定義しています。

SOAFEEは、マイクロサービス、コンテナ、オーケストレーションシステムといったクラウドネイティブなテクノロジーを、環境パリティを維持したまま、自動車の機能安全性と組み合わせることを可能にするリファレンスアーキテクチャを初めて提供しています。

SOAFEEによるクラウドから組み込みエッジまでのISAパリティの確保

AWSとArmには長い歴史があります。この歴史には、AWS Gravitonプロセッサに使われているAWSカスタムビルドのSoC内部における、64ビットプロセッサの利用が含まれてます。AWS Gravitonプロセッサはクラウドのワークロードのために最適な価格と性能を提供しています。これらのプロセッサをより多くのインスタンスタイプに搭載することにより、自動車開発者は、AWSパートナーであるADLINK社のAVA Developer Platformなど、自動車組み込みプラットフォームでも使用されているArmの知的財産（IP）とツールを使用したクラウドネイティブなアプリケーションとツールチェーンの開発と実行をすることができます。

このIPをクラウドとエッジの両方で使用することにより、開発者は命令セットアーキテクチャ（ISA）レベルで最初のレベルの環境パリティを達成することができます。しかし、さらに高いレベルのパリティを実現するためには、SOAFEEがサポートに取り組んでいる、車載グレードのOS、抽象化レイヤー、オーケストレーションレイヤーが必要となります。下図は、異なるレベルのパリティと、それらのアプローチに関連する開発者のペルソナを示しています。

このようなレベルのパリティを実現することで、次のセクションで説明するように、組み込みソフトウェアの開発と検証のためのまったく新しいワークフローが促進されます。

OSレベルのパリティの実現を容易にするためのISAパリティの使用

このブログ記事で説明するコンセプトを実証するための参考OSとして、Yocto Projectを使用してカスタムLinuxディストリビューションを作成します。Yocto Projectは、開発者がハードウェアに関係なくLinuxベースのカスタムシステムを作成するのを手助けする、オープンソースのコラボレーションプロジェクトです。Yocto Projectは、SOAFEEのリファレンスアーキテクチャと同様に、Linux Foundationの一部であるAutomotive Grade Linuxイニシアチブを含む、多くの組み込みプロジェクトで使用されています。

OSレベルのパリティを実現するために、ArmとAWSは共同で、Yocto ProjectをベースにしたGravitonインスタンス用のAmazon Machine Image（AMI）を作成しました。AMIは、OSやアプリケーションなどのソフトウェア構成を含むテンプレートです。AMIから仮想サーバとして稼働するAmazon EC2インスタンスを起動することができます。また、開発されたAMIには、SOAFEEアーキテクチャのオープンソースのリファレンスアーキテクチャであるArmのEdge Workload Abstraction and Orchestration Layer（EWAOL）が含まれており、アプリケーション、コンテナ、OSの環境パリティをさらに容易に確保することが可能です。

EWAOLは、組み込みアプリケーションとオーケストレーションの双方にコンテナを使用する、標準的なフレームワークを提供します。このアプローチにより、開発者はクラウド上でコードの記述とテストを開始することができ、ワークフローを大幅に改善し、拡張することができます。より具体的には、SOAFEEは以下を容易にします。

EWAOLの詳細については、Arm GitLabをご覧ください。

OSレベルとISAレベルのパリティの概念を導入することで、不要になった多くのステップを削減し、組み込み開発者のワークフローを次の図に示すように変更することができます。

このブログ記事の残りの部分では、AWS Gravitonベースのインスタンス用に、Yocto Projectを使用して独自のカスタムLinuxベースのAMIを作成する方法を紹介します。このチュートリアルは、既に作成されたAMIをAWS上にデプロイする方法だけを教えるのではなく、組み込みシステムで使用する独自のLinuxイメージをクラウド上に持ってくるための方法を、開発者に提供することを目的としています。

Yocto Projectを用いたAWS Gravitonプロセッサ用カスタムLinux AMIの作成方法

このガイドでは、Amazon EC2インスタンスを起動するために使用可能な、カスタムLinux AMIの作成方法について説明します。必要なリソースを作成するためには、適切な権限を持つAWSアカウントへのアクセスが必要です。AWSアカウントを所有していない場合は、アカウントを作成/アクティベートしてください。

開始する前に、GitHubに記載の詳細な手順を確認してください。このリポジトリには、EWAOLを含むカスタムLinux AMIを作成する方法についての最新の情報が含まれています。

Yoctoを使用してカスタムAMIを作成するには、5つの主要なステップがあります。それらについて順を追って確認し、以下に示すようなアーキテクチャを構築していきます。

1. AWSリソースの設定

まず、AWS CloudFormationを用いて、AWSアカウントの設定と構成を行う必要があります。AWS CloudFormation を使うことで、インフラをコードとして扱い、AWSやサードパーティのリソースをモデル化、プロビジョニングや管理をすることが可能です。ここでは、設定ファイルを使ってAWSリソースをプロビジョニングし、手間を省くためにAWS CloudFormationを使います。

2. Yocto を用いたビルドに使用するAmazon EC2インスタンスを作成する

Yocto Projectを使ったカスタムLinuxイメージのコンパイルとビルドのための開発環境として使用するAmazon EC2インスタンスを作成し、Secure Shell（SSH）接続します。

3. Yocto Project を使ってカスタム Linux イメージをビルドする

次に、ステップ2で作成したビルド用インスタンスにSSH接続します。このインスタンスへの接続には、任意のSSHクライアントを使用することができます。

注意：YAML設定ファイルの内容を確認し、あなたのプロジェクトに必要な修正を加えてください。

Header

header:
aversion: 10
includes:
– repo: meta-ewaol
file: meta-ewaol-config/kas/ewaol-base.yml
– repo: meta-ewaol
file: meta-ewaol-config/kas/arm-machines.yml

このセクショでは、EWAOLリポジトリからインクルードする他のいくつかのYAMLファイル（後で説明）と共に、どのバージョンのファイルスキーマを使用しているかをkasに伝えます。これらのインクルードファイルは、EWAOLの基本設定といくつかの標準的なArmマシン定義を読み込みます。

Repositories

repos:

meta-ewaol:

url: “https://git.gitlab.arm.com/ewaol/meta-ewaol.git”
path: layers/meta-ewaol
refspec: v0.2.4

meta-aws:

url: https://github.com/aws/meta-aws.git
path: layers/meta-aws
refspec: hardknott
meta-virtualization:
refspec: hardknott

meta-ewaol-ext:

path: meta-ewaol-ext
refspec: hardknott

meta-openembedded:

refspec: hardknott

poky:

refspec: hardknott

このセクションでは、どのYoctoレイヤーを使いたいか、どこでダウンロードするか、どのバージョンを使うか、そしてどこに保存するかをkasに指示します。この例では、リファレンスSOAFEE実装レイヤーのmeta-ewaolと、AWSエッジソフトウェア機能のレシピを提供するaws-metaを使用しています。ヘッダには「ewaol-base.yml」が含まれており、そこにはさらに多くのリポジトリが格納されています。このファイルには、Yoctoの標準レイヤーである「poky」と「meta-openembedded」もロードされています。さらに、meta-ewaol-extレイヤーは、パッチとbbappendファイルを使って、cloud-initとOpenSSHのレシピをカスタマイズします。

Machine

machine: generic-arm64

上記の行は、Yocto にどのマシンをターゲットにしたイメージを作成するかを指示します。今の例では 「generic-arm64っっっっっっｓ」を使っています。これにより、汎用的なブートメカニズム(ここではUEFIを用いますが、これについてはあとでAMIのところで設定します)をサポートするほとんどの Arm デバイスで起動可能なイメージを作成します。

Custom config

local_conf_header:

meta-custom: |
FILESEXTRAPATHS_prepend_pn-linux-yocto = “${TOPDIR}/../kernelconfig/:”
SRC_URI_append_pn-linux-yocto = ” file://gravitonKernelConfigs.cfg “

INHERIT += “extrausers”
# Hardening: Locking the root password. Creating the ewaol without password for ssh key-based login only
EXTRA_USERS_PARAMS = “usermod -L root; useradd -p ‘*’ ewaol”

EXTRA_IMAGE_FEATURES_append = “ssh-server-openssh”
# Forcing removal of debug-tweakes as ewaol includes it in all targets by default and that leads to reversing some sshd_config hardening done in our bbappend when do_rootfs runs
EXTRA_IMAGE_FEATURES_remove = “debug-tweaks”
IMAGE_INSTALL_append = ” rng-tools awscli cloud-init cloud-init-systemd e2fsprogs e2fsprogs-resize2fs e2fsprogs-tune2fs e2fsprogs-e2fsck e2fsprogs-mke2fs parted sudo sudo-sudo openssh-sftp-server”
IMAGE_FSTYPES += ” wic wic.vhdx”

このセクションでは、このサンプル固有のカスタムコンフィグ設定を行います。

Target

Target:

– ewaol-image-docker

これはどのターゲットイメージをビルドするかをYoctoに対して指示しています。今回は、dockerイメージのみをビルドするようにします(podmanイメージはビルドしません)。

Kernel configuration fragment

YoctoがAWS Graviton2プロセッサで動作するように設定するには、いくつかの追加のカーネル設定を有効にする必要があります。それらはgravitonKernelConfigs.cfgに含まれています。

4. イメージファイルからの AMI の作成

"`
$ sudo poweroff
"`

5. 新規のAMIを使用したEC2インスタンスの起動

新しく作成したAMIを用いたインスタンスを起動手順は、上述のEC2インスタンスの設定と同様です。

"`
$ uname –r
10.107-yocto-standard
"`

おめでとうございます。これで、Yocto Projectを用いて、独自のカスタムLinuxイメージを構築し、起動することができました。このイメージは、クラウド上で開発や検証のために使用することができます。

カスタムイメージで何か問題が発生した場合、インスタンスのシリアルコンソールにアクセスしてデバッグすることができます。この機能は、デフォルトでは有効になっていません。詳細はこちらでご確認ください：https://docs.thinkwithwp.com/AWSEC2/latest/UserGuide/ec2-serial-console.html

ソフトウェアによる定義は自動車の未来

このブログでは、環境パリティのハイレベルな概念と、Arm、AWS、その他のパートナーが目指しているもの、つまりソフトウェアによって定義されたシステムを構築し、自動車のソフトウェア開発を加速させることに関して説明をしました。また、ArmベースのAWS Gravitonプロセッサを使用した独自の開発ワークフローのために、Yocto Projectを使用してカスタムAMIを作成する方法についてのチュートリアルを提供しました。

このコンセプトをより深く知りたい方は、このブログで作成したAMIを使用して自動車開発用の自動ソフトウェア開発パイプラインを作成し、環境パリティを実証する方法を詳細に説明したこのハンズオンワークショップをご覧ください。

Scalable Open Architecture for Embedded Edge (SOAFEE) プロジェクトの詳細については、soafee.io を参照してください。

このブログはソリューションアーキテクトの渡邊翼、畔栁 竜生が翻訳しました。