量産の進め方の概略図を図4.1「Armadillo 量産時の概略図」に示します。
お客様の製品仕様や製造工程の要件によってはこの例とは違った工程順となる場合や、工程の追加・削除がある可能性があります。
4.1.1. Armadillo Twin を契約する
Armadillo Twin を使用したデバイス運用管理を行う場合は、量産モデルの発注とは別にArmadillo Twin の契約が必要となります。
Armadillo Twin の契約の詳細については、弊社営業、ご利用の販売代理店にお問い合わせください。
量産モデルを発注後、お客様に納品されるまでにリードタイムが発生します。
開発セットや少量の量産モデル購入の場合、アットマークテクノや代理店在庫によって、短期間で納品できることもあります。
しかし、まとまった数量の量産モデルの場合、納品までにお時間をいただくことがあります。
新規に製品を量産・出荷する場合はリードタイムを考慮したスケジューリングをお願いします。
また、リピート製造をする場合でも、欠品を起こさないよう適切な在庫の確保をお願いいたします。
リードタイムは状況・タイミングによって異なりますので、都度、弊社営業、ご利用の販売代理店にお問い合わせください。
4.1.3. Armaidllo 納品後の製造・量産作業
お客様が Armadillo を納品後に次に示すようなキッティング作業、組み立て、検査を実施し出荷を行います。
ソフトウェア書き込み
-
Armadillo Base OS やアプリケーションコンテナイメージの書き込み
-
設定ファイルの書き込み
別部品の組み立て
-
SD カード/ SIM カード/ RTC バックアップ電池等の接続
-
拡張基板接続やセンサー・外部機器の接続
-
お客様専用筐体への組み込み
検査
-
Armadillo の受け入れ検査
-
組み立て後の通電電検・機能検査
-
目視検査
-
梱包作業
-
出荷作業
有償の BTO サービスを利用することで、これらの作業の一部をアットマークテクノへ委託・実施済みの状態で Armadillo を納品することも可能です。
費用はいただきますがお客様による工程立ち上げ、場所の確保、作業者の教育、品質管理等のトータルコストを考えると委託した方が安く済むケースが多いです。
また、 BTO サービスではお受けできないようなキッティング、検査、作業については、実施可能な業者をご紹介する等、個別の対応をすることで解決できる場合もございます。
詳しくは弊社担当の営業、またはご利用の販売代理店にご相談ください。
4.2. BTO サービスを使わない場合と使う場合の違い
4.2.1. BTO サービスを利用しない(標準ラインアップ品)
有償の量産サービスを利用しない場合、標準ラインアップ仕様での納品となります。
大きく分けて試作開発用途で使う「開発セット」と量産向けの「量産モデル」の2種類があります。
量産用途では「量産モデル」をご利用ください。
「量産モデル」には AC アダプタ等のオプション品が付属されておりませんので、内容物を確認の上、発注をお願いいたします。
ラインアップ一覧については「製品ラインアップ」をご確認ください。
4.2.1.1. 標準ラインアップ品に書き込まれているソフトウェア
標準ラインアップ品に書き込まれるソフトウェアイメージ(Armadillo Base OS)は、アットマークテクノで公開している標準イメージとなります。
また、ソフトウェアバージョンは指定することができず、ランニングチェンジで随時最新版を適用していきます。
このため、納品後の Armadillo 個体では、開発段階で評価した Armadillo Base OS と異なるバージョンが書き込まれている可能性があります。
また、アプリケーションコンテナについては何も書き込まれていない状態となります。
納品後、お客様の量産工程でソフトウェアの書き込み作業が必要となります。詳しくは「量産時のイメージ書き込み手法」をご確認ください。
BTO サービスは、セミオーダー式メニューから選択して Armadillo の量産品を一括手配いただける有償サービスです。
標準ラインアップ品の仕様をベースとして、搭載するモジュールの種類やケース、 AC アダプタの有無、お客様支給品の SD カードや SIM カードの接続、お客様ご指定のソフトウェアイメージ書き込みなど、メニュー内から指定可能なキッティング項目を選択・指定することが可能です。
販売代理店またはアットマークテクノの窓口からお申し込みいただけます。
製品ごとに、対応できる作業とできない作業がございます。また、販売直後の製品の場合など BTO サービスに未対応である場合もあります。
詳しくは Armadilloサイトの BTO サービス をご確認ください。
量産時に必要な手順は最終製品によって異なりますが、開発したソフトウェアをArmadilloに書き込む手順は必ず実施することになります。
Armadillo Base OS 搭載製品において、量産時に任意のソフトウェアを書き込む際には、以下の2つの手法のどちらかを用いると実現できます。
-
インストールディスクを用いてソフトウェアを書き込む
-
SWUpdateを用いてソフトウェアを書き込む
ただし、SWUpdateは運用中のArmadilloのアップデート機能であり、量産時のイメージ書き込みは本来の用途でないため、基本的にはイメージ書き込みに特化しているインストールディスクを用いた方法を選択してください。
それぞれの手法の特徴を表4.1「インストールディスクとSWUpdateによるソフトウェア書き込みの比較」にまとめます。
ソフトウェア書き込み工程を決定する際の参考にしてください。
表4.1 インストールディスクとSWUpdateによるソフトウェア書き込みの比較
手段 | メリット | デメリット |
---|
インストールディスク | -
インストールの前後処理を行なうシェルスクリプトのテンプレートが用意されている
-
インストールの前後処理は、microSDカード内にシェルスクリプトを配置するだけなので製造担当者にも編集しやすい
| -
インストール実行にはジャンパピンをショートにするためにArmadilloのケースを開ける必要がある
-
動いているシステムをそのままインストールディスクにするため、出荷時の標準イメージから手動で同じ環境を構築する手順が残らない
|
SWUpdate | -
ジャンパピンをショートにせずに実行できるため、Armadilloのケースを開ける必要がない
-
必ず必要となる初回アップデートを別途実行する必要がない
| -
swuイメージの作成には、mkswuを使用できる環境とdescファイルの記述方法を知る必要があるため、開発担当者以外にswuイメージを更新させるハードルが少し高い
-
ログの取得など、インストール前後の処理が必要な場合は自分で記述する必要がある
|
量産時のイメージ書き込みにインストールディスクを使用する場合は、「インストールディスクを用いてイメージ書き込みする」に進んでください。
量産時のイメージ書き込みにSWUpdateを使用する場合は、「SWUpdate を用いてイメージ書き込みする」に進んでください。
4.4. インストールディスクを用いてイメージ書き込みする
「インストールディスクについて」でも紹介したとおり、 Armadillo Base OS 搭載製品では、開発が完了した Armadillo のクローン用インストールディスクを作成することができます。
以下では、クローン用インストールディスクを作成する手順を準備段階から紹介します。
4.4.1. /etc/swupdate_preserve_fileへの追記
Armadillo Base OS のバージョンを最新版にしておくことを推奨しています。
最新版でない場合は、バージョンが古いゆえに以下の作業を実施出来ない場合もありますので、ここで Armadillo Base OS のバージョンをアップデートしてください。
ここでは SWUpdate を使用して Armadillo Base OS のアップデートを行ないますが、このアップデートを行なうと、/etc/swupdate_preserve_filesに記載の無いファイルは消えてしまいます。
Armadillo Base OS のルートファイルシステム上に消えてほしくないファイルを開発中に配置していた場合は、図4.3「任意のファイルパスを/etc/swupdate_preserve_filesに追記する」に示すコマンドを実行することで /etc/swupdate_preserve_files にそのファイルが追記され、アップデート後も保持し続けるようになります。
一部のファイルやディレクトリは初めから /etc/swupdate_preserve_files に記載されている他、 podman commit
したコンテナイメージについてもアップデート後に引き継がれるので、本ドキュメントのサンプルアプリケーションの場合は実行する必要はありません。
「initial_setup.swu
の作成」 で SWUpdate の初回アップデートを行った際に、各ユーザーのパスワード設定をしました。
開発中はログインしやすいような単純なパスワードにしていることがよくあるので、製品に適用しないようにこのタイミングで強固なパスワードに変更しておきましょう。
|
rootユーザのパスワードを変更します。
|
|
新しいrootユーザ用パスワードを入力します。
|
|
再度新しいrootユーザ用パスワードを入力します。
|
|
atmarkユーザのパスワードを変更します。
|
|
新しいatmarkユーザ用パスワードを入力します。
|
|
再度新しいatmarkユーザ用パスワードを入力します。
|
|
パスワードの変更を永続化させます。
|
4.4.4. 開発したシステムをインストールディスクにする
Armadillo Base OSでは、現在起動しているルートファイルシステム及びブートローダーをそのままインストールディスクイメージとして生成することができます。
インストールディスクイメージの生成方法は二種類あります。それぞれの特徴をまとめます。
ATDE と VSCode を使用して、開発したシステムのインストールディスクイメージを USB メモリ上に生成します。USBメモリは vfat もしくは ext4 形式でフォーマットし、空き容量が 10GB 以上のものを使用してください。
VSCode に開発用エクステンションである ABOSDE をインストールする必要があります。
abos-ctrl make-installer
コマンドを実行すると microSDカードにインストールディスクイメージを生成することができます。
コマンド実行前に、Armadilloがインターネットに接続されており、かつ 10GB 以上の空き容量がある microSDカードが挿入されていることを確認してください。
microSDカード内のデータはインストールディスク作成時に上書きされて消えてしまうので、必要なデータは予めバックアップを取っておいてください。
microSDカード上にインストールディスクイメージを生成した場合、インストール時に任意のシェルスクリプトを実行することが可能です。
この機能が必要な場合はコマンドラインからの生成を推奨します。
ATDE と VSCode を使用して、開発したシステムのインストールディスクイメージを生成します。
「VSCodeのセットアップ」 を参考に、 ATDE に VSCode 開発用エクステンションをインストールしてください。
VSCode を使用してインストールディスクを生成する場合は以下の手順になります。
-
VSCode を使用したインストールディスク作成用 SWU の生成
-
Armadillo に USBメモリを挿入
-
インストールディスク作成用 SWU を ABOS Web からインストール
-
USBメモリ上にインストールディスクイメージを生成
| |
---|
この機能を使用するには、以下に示すバージョンのソフトウェアが必要です。 -
ABOSDE 1.6.0 以上
-
mkswu 5.3 以上
-
abos-base 2.3 以上
|
4.4.5.1. VSCode を使用したインストールディスク作成用 SWU の生成
VSCode の左ペインの [COMMON PROJECT COMMAND] から [Generate Installer On USB Swu] を実行します。
次に、対象製品を選択します。
無事に生成された場合、コンソールに以下のログが出力されます。
|
パスワードの入力を求められますので、初期化用 swu を生成したときと同じパスワードを入力します
|
/home/atmark/mkswu
ディレクトリ内に make-installer.swu
が作成されます。
4.4.5.2. Armadillo に USBメモリを挿入
Armadillo に電源を投入し、インストールディスクを保存するための USB メモリを挿入してください。
| |
---|
USB メモリは vfat もしくは ext4 形式でフォーマットし、空き容量が 10GB 以上のものを使用してください。
Armadillo-640 への USB メモリのマウントは不要です。 インストールディスクイメージは installer.img という名前で保存します。すでに同名のファイルが存在する場合は上書きされます。 |
4.4.5.3. インストールディスク作成用 SWU を ABOS Web からインストール
ABOS Web を使用して、生成した make-installer.swu
をインストールします。
「SWUインストール」を参考に make-installer.swu
を Armadillo へインストールしてください。
実行時は ABOS Web 上に図4.9「make-installer.swu インストール時のログ」ようなログが表示されます。
完了後、USBメモリを抜いてください。
もし、エラーが出た場合はArmadillo-640の電源を再投入してやり直してください。
4.4.5.4. USBメモリ上にインストールディスクイメージを生成
無事に生成が完了した場合、USBメモリ上に installer.img
が保存されています。
この installer.img
を microSD カードに書き込むことでインストールディスクを作成することができます。動作確認については「インストールディスクの動作確認を行う」をご参照ください。
これで、VSCode を使用してインストールディスクを生成する方法については終了です。
4.4.6. インストールディスクの動作確認を行う
作成したインストールディスクの動作確認を実施してください。開発に使用した Armadillo 以外の個体が必要になります。また、インストール先の Armadillo の eMMC 内のデータは上書きされて消えるため、必要なデータは予めバックアップを取っておいてください。
「開発したシステムをインストールディスクにする」 の手順で使用した USB メモリの中に installer.img が存在しますので、ATDE 上でこのイメージをもとに microSD カードにインストールディスクを作成してください。ATDE 上に installer.img をコピーした場合、コマンドは以下のようになります。/dev/sd[X] の [X] は microSD を示す文字を指定してください。
[ATDE ~] sudo dd if=installer.img of=/dev/sd[X] bs=1M oflag=direct status=progress
上記コマンドで作成した microSD のインストールディスクを、インストール先の Armadillo に挿入してください。その後、SW2 (起動デバイス設定スイッチ)を ON にしてから電源を入れます。 Armadilloがインストールディスクから起動し、自動的にインストールスクリプトが動作します。
しばらくすると「reboot: Power down」と表示されるので、Armadilloの電源を切ります。 その後 Armadillo から microSD カードを抜き、SW2 (起動デバイス設定スイッチ)を OFF にします。 再度電源を投入することで、インストールは完了です。
実際にクローンした Armadillo が想定した通りの動作をすることを確認してください。
abos-ctrl make-installer
コマンドを実行して、microSDカードにインストールディスクイメージを生成します。
「Installer updated successfully!」と表示されれば、正常にmicroSDカードにインストールディスクイメージを書き込むことができています。
ArmadilloからmicroSDカードを抜去してください。
| |
---|
セキュリティーの観点から、インストールディスクによるインストール実行時に以下のファイルを再生成しております: -
/etc/machine-id (ランダムな個体識別番号)
-
/etc/abos_web/tls (ABOS-Web の https 鍵)
-
/etc/ssh/ssh_host_*key* (ssh サーバーの鍵。なければ生成しません)ABOS 3.19.1-at.3 以降
他のファイルを個体毎に変更したい場合は 「インストール時に任意のシェルスクリプトを実行する」 で対応してください。 |
4.4.7.1. インストール時に任意のシェルスクリプトを実行する
作成したインストールディスクの所定の場所に、 installer_overrides.sh
というファイル名でシェルスクリプトを配置することで、インストール処理の前後で任意の処理を行なうことができます。
installer_overrides.sh
に記載された表4.2「インストール中に実行される関数」に示す3つの名前の関数のみが、それぞれ特定のタイミングで実行されます。
表4.2 インストール中に実行される関数
関数名 | 備考 |
---|
preinstall | インストール中、eMMCのパーティションが分割される前に実行されます。 |
postinstall | send_log関数を除く全てのインストール処理の後に実行されます。 |
send_log | 全てのインストール処理が完了した後に実行されます。指定した場所にインストールログを保存できます。 |
installer_overrides.sh
を書くためのサンプルとして、 インストールディスクイメージの第1パーティション及び、「開発したシステムをインストールディスクにする」で作成したのであれば第2パーティション直下に installer_overrides.sh.sample
を用意してあります。
このサンプルをコピーして編集するなどして、行ないたい処理を記述してください。
作成した installer_overrides.sh
は、インストールディスクの第1パーティション(ラベル名は"rootfs_0")か、「開発したシステムをインストールディスクにする」で作成したのであれば第2パーティション(ラベル名は"INST_DATA")の直下に配置することで実行されます。
両方に配置した場合は、第2パーティションに配置した記述が適用されます。
| |
---|
インストールディスクの第1パーティションはbtrfs、第2パーティションはexfatでフォーマットされているため、第2パーティションのみWindows PCでもマウントして読み書きすることができます。 製造担当者が installer_overrides.sh を記述する場合に、仮にWindows PCしか作業環境がない場合でも、第2パーティションを作成しておくことで作業を行なうことができるというメリットもあります。 |
これを利用することで、複数台のArmadilloに対してそれぞれに異なる固定IPアドレスを設定したり、各種クラウドへの接続鍵などを個体ごとに配置したりしたいなど、個体ごとに異なる設定を行なうなど柔軟な製造を行なうことも可能です。
以下ではこの機能を利用して、個体ごとに異なる固定IPアドレスを設定する方法と、インストール実行時のログを保存する方法を紹介します。
これらを必要としない場合は「インストールの実行」に進んでください。
4.4.7.2. 個体ごとに異なる固定IPアドレスを設定する
インストール時に任意のシェルスクリプトを実行できる機能を利用して、複数のArmadilloに対して異なる固定IPアドレスを割り当てる例を紹介します。
INST_DATA
内の installer_overrides.sh.sample
と ip_config.txt.sample
は個体ごとに異なるIPアドレスを割り振る処理を行なうサンプルファイルです。
それぞれ installer_overrides.sh
と ip_config.txt
にリネームすることで、 ip_config.txt
に記載されている条件の通りに個体ごとに異なる固定IPアドレスを設定することができます。
全てをここでは説明しませんので、詳細はそれぞれのファイル内の記述も参照してください。
今回はそれぞれのファイルの内容は変更せず使用します。
サンプルそのままですが、 ip_config.txt
の内容を図4.11「ip_config.txtの内容」に示します。
|
このインストールディスクで割り振るIPアドレスの範囲の始まりを指定します。
|
|
このインストールディスクで割り振るIPアドレスの範囲の終わりを指定します。
|
|
ネットマスクを指定します。指定しない場合は24になります。デフォルトでコメントアウトされています。
|
|
ゲートウェイアドレスを指定します。
|
|
DNSアドレスを指定します。セミコロンで区切ることでセカンダリアドレスも指定できます。
|
|
IPアドレスの設定を行なうインターフェースを指定します。指定しない場合はeth0になります。デフォルトでコメントアウトされています。
|
| |
---|
インストール作業の並列化の為に、複数枚のインストールディスクで固定IPアドレスを割り振る場合は、それぞれのインストールディスクが割り振るIPアドレスの範囲が被らないように ip_config.txt を設定してください。 |
これらのファイルを配置したインストールディスクでインストールを実行したArmadilloが、正しく設定できていることを確認します。
また、サンプルスクリプトをそのまま使用すると、インストールディスクの第2パーティションに allocated_ips.csv
というファイルが生成されます。
このファイルには、このインストールディスクを使用してIPアドレスの設定を行なった個体のシリアル番号、MACアドレス、設定したIPアドレスが追記されていきます。
| |
---|
2台目以降のArmadilloにこのインストールディスクでIPアドレスの設定を行なう際に、 allocated_ips.csv を参照して次に割り振るIPアドレスを決めますので、誤って削除しないように注意してください。 |
4.4.7.3. インストール実行時のログを保存する
installer_overrides.sh
内の send_log
関数は、インストール処理の最後に実行されます。
インストールしたルートファイルシステムやファームウェアのチェックサムなどの情報が記録されたログファイルのパスが LOG_FILE
に入るため、この関数内でインストールディスクの第2パーティションに保存したり、外部のログサーバにアップロードしたりすることが可能です。
図4.14「インストールログを保存する」は、インストールディスクの第2パーティションにインストールログを保存する場合の send_log
実装例です。
|
send_log関数中では、SDカードの第2パーティション(/dev/mmcblk1p2)はマウントされていないのでマウントします。
|
|
ログファイルを <シリアル番号>_install.log というファイル名で第2パーティションにコピーします。
|
|
第2パーティションをアンマウントします。
|
これらの変更を行なったインストールディスクでインストールを実行した後に、インストールディスクをPCなどに接続して正しくログを保存できていることを確認してください。
保存したログファイルの中身の例を図4.15「インストールログの中身」に示します。
前章までの手順で作成したインストールディスクを、開発に使用した Armadillo 以外の Armadillo に対して適用します。
クローン先の Armadillo の eMMC 内のデータは上書きされて消えるため、必要なデータは予めバックアップを取っておいてください。
「インストールディスクを使用する」を参照して、クローン先の Armadillo にインストールディスクを適用してください。
ここまで完了したら、「イメージ書き込み後の動作確認」に進んでください。
4.5. SWUpdate を用いてイメージ書き込みする
ここでは、sample-container という名称のコンテナの開発を終了したとします。
コンテナアーカイブの作成方法は 「コンテナの自動作成やアップデート」 を参照ください。
-
sample-container-v1.0.0.tar (動かしたいアプリケーションを含むコンテナイメージアーカイブ)
-
sample-container.conf (コンテナ自動実行用設定ファイル)
これらのファイルを /home/atmark/mkswu/sample-container ディレクトリを作成して配置した例を記載します。
SWUpdate実行時に、「SWU イメージの準備」で挙げたファイルをArmadilloに書き込むような SWU イメージを生成します。
SWUイメージを作成するためには、SWUpdate時に実行する処理等を示したdescファイルを記述し、そのdescファイルを入力として mkswu
コマンドを実行することで、SWUイメージが出来上がります。
|
SWUpdate完了後に電源を切るように設定します。
|
|
コンテナイメージファイルをswuイメージに組み込み、Armadilloに転送します。
|
|
コンテナ起動設定ファイルをArmadilloに転送します。
|
ここまで完了したら、「イメージ書き込み後の動作確認」に進んでください。
desc ファイルの詳細な書式については、「mkswu の .desc ファイルを編集する」を参照してください。
また、作成されたSWUイメージの内容を確認したい場合は、「SWU イメージの内容の確認」を参照してください。