Amazon Web Services ブログ

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は以下を容易にします。

  • 開発中のソフトウェア単位だけでなく、組み込みOSを含む組み込みソフトウェアスタック全体のクラウド実装
  • クラウドから組み込み先となるエッジへのシームレスなポータビリティ – クロスコンパイルやエミュレーション(およびコンパイルエラーやパフォーマンス低下などの関連する問題)は不要

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を使います。

  1. このAWS CloudFormationテンプレートファイルをGitHubのリポジトリからローカルマシンにダウンロードします。
  2. AWS CloudFormationのダッシュボードに移動します。
  3. スタックの作成」をクリックします。
  4. テンプレートファイルのアップロード」 を選択し、手順1でダウンロードしたテンプレートファイルを選択し、「次へ」 をクリックして次に進みます。
  5. スタック名は 「yocto-build」と入力します。create new S3 bucketを 「yes」に切り替え、任意のユニークなバケット名を入力します。「次へ」を選択して次に進みます。
  6. このページはデフォルトのまま、「次へ」を選択します。
  7. 最後に設定を確認し、「AWS CloudFormation によって IAM リソースがカスタム名で作成される場合があることを承認します。」にチェックをして、「スタックの作成」を選択します。
  8. 作成には数分かかるはずです。スタックのステータスに「CREATE_COMPLETE」が表示されたら、次のステップに進むことができます。

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

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

  1. Amazon EC2ダッシュボードに移動します。
  2. サイドバーメニューの 「インスタンス」をクリックします。
  3. オレンジ色の 「インスタンスを起動」ボタンをクリックします。
  4. Ubuntu Server 20.04 LTS」と「64-bit (Arm)」を選択します。
  5. インスタンスタイプは 「c6g.4xlarge」を選択します。コンパイルに使用するCPUに最適化されたインスタンスであるという理由でc6g.4xlargeを選択しましたが、、要件に応じて他のインスタンスタイプを使用することも可能です。
  6. 新しいキーペアを作成し、ダウンロードします。この鍵は、後でSSHセッションを暗号化するために使用します。
  7. セキュリティグループを作成する」で、「からの SSH トラフィックを許可するを選択します。ドロップダウンメニューで、「自分のIP」を選択します。
  8. ストレージを設定」で、ルートボリュームが100GBのgp2(General Purpose SSD)になるよう調整します。
  9. 高度な詳細」で、Cloud Formationのステップで作成した 「IAM インスタンスプロフィール」を選択して、次のステップに必要な権限をインスタンスに付与する必要があります。「yocto-build-VMBuilderEC2Role-」の後にランダムな文字が続いているはずです。
  10. 残りの設定はすべてデフォルトのままにして、「インスタンスを起動」を選択します。
  11. 最後に 「すべてのインスタンスを表示」ボタンを選択し、インスタンスが 「実行中」になるのを待ちます。

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

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

  1. SSHコマンドは、リストでインスタンスを選択し、「接続」ボタンをクリックすることで見つけることができます。
    1. SSH クライアントを使用して、表示されたコマンドを使用してサーバーに接続します。例:ssh -i  “keypair.pem” ubuntu@ec2-[ip-address].compute-1.amazonaws.com.
  2. GitHubリポジトリに記載されているように、ビルドに関わるディペンデンシーをインストールします。
  3. 同リポジトリに記載の「EWAOLの構築」を完了します。このリポジトリに従って、cloud-initmeta-ewaolmeta-aws、およびAMIをサポートするためのSSHを含む基本的なYocto Project Linuxディストリビューションを設定します。

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

  1. 上記の「kas build」ステップの完了後、新しいLinuxディストリビューションのビルドが完了するまで約50分かかるはずです。
  2. その間に、必須ではありませんが、このプロジェクトで使用している YAML ファイルとカーネル設定について、さらに深く掘り下げてみるとよいです。

(Optional Deep Dive) kas用のYAMLファイルとカーネルの設定についての説明

この YAML ファイルには、Yocto Project がどのように Linux イメージを構築すべきか、kas用に記載されています。

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っっっっっっs」を使っています。これにより、汎用的なブートメカニズム(ここでは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”

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

  • cloud-initを追加します。これはブート時に特定のAmazon EC2インスタンスにAMIを設定するために使用します。
  • 追加のカーネル設定をします。
  • SSHサーバーや、AWSサービスを管理する統一的なツールであるAWS Command Line Interface (AWS CLI)などの機能を追加します。

Target

Target:

– ewaol-image-docker

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

Kernel configuration fragment

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

    • CONFIG_BLK_DEV_NVME は、NVMe ストレージを動作させるために必要です。
    • CONFIG_ENA_ETHERNET は、ネットワークが動作するために必要です。
    • CONFIG_SERIAL_8250_PCI は、シリアルポートに必要です。

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

  1. イメージのビルドが完了したので、AMI自体を作成する必要があります。
  2. GitHub リポジトリに記載の指示に従い、create-ami.sh スクリプトを実行します。
  3. これで対象のAWSアカウントに自動的に新しいAMIが生成されます。
  4. 最後に、このビルドに使用したAmazon EC2インスタンスはもう必要ないので、シャットダウンします。
"`
$ sudo poweroff
"`

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

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

  1. Amazon EC2ダッシュボードに移動します。
  2. 左側のメニューでAMIをクリックして、AMIのページを開きます。
  3. 先ほど作成したAMIを選択します。
  4. AMIからインスタンスを起動」ボタンをクリックします。以下の画面は、このガイドの最初の部分と同様です。
  5. ドロップダウン・メニューから、先ほど作成した同じキーペアを選択します。
  6. セキュリティグループを作成する」で 「からの SSH トラフィックを許可する」 を選択し、ドロップダウンで 「自分のIP」を選択します。
  7. その他のインスタンス設定はデフォルトのままで構いませんので、「インスタンスを起動」をクリックします。
  8. では、SSHユーティリティを使用してカスタムLinuxインスタンスに接続します。リストでインスタンスを選択し、「接続」ボタンをクリックして、SSHコマンドを見つけます。ただし、以下のようにユーザー名を自分で「ewaol」に修正する必要があります。
    1. 例:ssh -i “keypair.pem” ewaol@ec2-[ip-address].compute-1.amazonaws.com
  9. 以下のコマンドを実行し、このインスタンスがYocto Projectを用いて構築したものであることを確認しましょう。
"`
$ uname –r
10.107-yocto-standard
"`
  1. 最後に、このチュートリアルで作成したStackとすべてのリソースが不要になったら、コスト発生を避けるために必ず削除してください。

おめでとうございます。これで、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 を参照してください。

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