量産編

本章では Armadillo を組み込んだ最終製品をお客様が製造・量産するうえで、必要となる情報や作業について記載します。

4.1. 概略

量産の進め方の概略図を図4.1「Armadillo 量産時の概略図」に示します。 お客様の製品仕様や製造工程の要件によってはこの例とは違った工程順となる場合や、工程の追加・削除がある可能性があります。

images/armadillo-manufacturing-flow.png

図4.1 Armadillo 量産時の概略図


4.1.1. リードタイムと在庫

量産モデルを発注後、お客様に納品されるまでにリードタイムが発生します。 開発セットや少量の量産モデル購入の場合、アットマークテクノや代理店在庫によって、短期間で納品できることもあります。 しかし、まとまった数量の量産モデルの場合、納品までにお時間をいただくことがあります。 新規に製品を量産・出荷する場合はリードタイムを考慮したスケジューリングをお願いします。 また、リピート製造をする場合でも、欠品を起こさないよう適切な在庫の確保をお願いいたします。

リードタイムは状況・タイミングによって異なりますので、都度、弊社営業、ご利用の販売代理店にお問い合わせください。

4.1.2. Armaidllo 納品後の製造・量産作業

お客様が Armadillo を納品後に次に示すようなキッティング作業、組み立て、検査を実施し出荷を行います。

  • ソフトウェア書き込み

    • Armadillo Base OS やアプリケーションコンテナイメージの書き込み
    • 設定ファイルの書き込み

      eMMC のデータリテンションを設定する場合は設定ファイル書き込み前に行ってください。 eMMC のデータリテンションの設定に関しては 「eMMC のデータリテンション」 を参照してください。

  • 別部品の組み立て

    • SD カード/ SIM カード/ RTC バックアップ電池等の接続
    • 拡張基板接続やセンサー・外部機器の接続
    • お客様専用筐体への組み込み
  • 検査

    • Armadillo の受け入れ検査
    • 組み立て後の通電電検・機能検査
    • 目視検査
  • 梱包作業
  • 出荷作業

有償の BTO サービスを利用することで、これらの作業の一部をアットマークテクノへ委託・実施済みの状態で Armadillo を納品することも可能です。 費用はいただきますがお客様による工程立ち上げ、場所の確保、作業者の教育、品質管理等のトータルコストを考えると委託した方が安く済むケースが多いです。

また、 BTO サービスではお受けできないようなキッティング、検査、作業については、実施可能な業者をご紹介する等、個別の対応をすることで解決できる場合もございます。 詳しくは弊社担当の営業、またはご利用の販売代理店にご相談ください。

4.2. BTO サービスを使わない場合と使う場合の違い

images/bto-scope.png

図4.2 BTO サービスで対応する範囲


4.2.1. BTO サービスを利用しない(標準ラインアップ品)

有償の量産サービスを利用しない場合、標準ラインアップ仕様での納品となります。 大きく分けて試作開発用途で使う「開発セット」と量産向けの「量産モデル」の2種類があります。 量産用途では「量産モデル」をご利用ください。

「量産モデル」には AC アダプタ等のオプション品が付属されておりませんので、内容物を確認の上、発注をお願いいたします。 ラインアップ一覧については「製品ラインアップ」をご確認ください。

4.2.1.1. 標準ラインアップ品に書き込まれているソフトウェア

標準ラインアップ品に書き込まれるソフトウェアイメージ(Armadillo Base OS)は、アットマークテクノで公開している標準イメージとなります。 また、ソフトウェアバージョンは指定することができず、ランニングチェンジで随時最新版を適用していきます。 このため、納品後の Armadillo 個体では、開発段階で評価した Armadillo Base OS と異なるバージョンが書き込まれている可能性があります。

また、アプリケーションコンテナについては何も書き込まれていない状態となります。

納品後、お客様の量産工程でソフトウェアの書き込み作業が必要となります。詳しくは「量産時のイメージ書き込み手法」をご確認ください。

4.2.2. BTO サービスを利用する

BTO サービスは、セミオーダー式メニューから選択して Armadillo の量産品を一括手配いただける有償サービスです。 標準ラインアップ品の仕様をベースとして、搭載するモジュールの種類やケース、 AC アダプタの有無、お客様支給品の SD カードや SIM カードの接続、お客様ご指定のソフトウェアイメージ書き込みなど、メニュー内から指定可能なキッティング項目を選択・指定することが可能です。

販売代理店またはアットマークテクノの窓口からお申し込みいただけます。

製品ごとに、対応できる作業とできない作業がございます。また、販売直後の製品の場合など BTO サービスに未対応である場合もあります。 詳しくは Armadilloサイトの BTO サービス をご確認ください。

4.3. 量産時のイメージ書き込み手法

量産時に必要な手順は最終製品によって異なりますが、開発したソフトウェアをArmadilloに書き込む手順は必ず実施することになります。 Armadillo Base OS 搭載製品において、量産時に任意のソフトウェアを書き込む際には、以下の2つの手法のどちらかを用いると実現できます。

  • インストールディスクを用いてソフトウェアを書き込む
  • SWUpdateを用いてソフトウェアを書き込む

ただし、SWUpdateは運用中のArmadilloのアップデート機能であり、量産時のイメージ書き込みは本来の用途でないため、基本的にはイメージ書き込みに特化しているインストールディスクを用いた方法を選択してください。

それぞれの手法の特徴を表4.1「インストールディスクとSWUpdateによるソフトウェア書き込みの比較」にまとめます。 ソフトウェア書き込み工程を決定する際の参考にしてください。

表4.1 インストールディスクとSWUpdateによるソフトウェア書き込みの比較

Pros Cons

インストールディスク

  • インストールの前後処理を行なうシェルスクリプトのテンプレートが用意されている
  • インストールの前後処理は、SDカード内にシェルスクリプトを配置するだけなので製造担当者にも編集しやすい
  • インストール実行にはジャンパピンをショートにするために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 したコンテナイメージについてもアップデート後に引き継がれるので、本ドキュメントのサンプルアプリケーションの場合は実行する必要はありません。

[armadillo /]# persist_file -p <ファイルのパス>

図4.3 任意のファイルパスを/etc/swupdate_preserve_filesに追記する


4.4.2. Armadillo Base OSの更新

Armadillo-IoT ゲートウェイ G4 Armadillo Base OSから「Armadillo-IoT ゲートウェイ G4用 SWUイメージイメージファイル」のURLをコピーして、図4.4「Armadillo Base OSをアップデートする」に示すコマンドを実行することでArmadillo Base OSを最新版にアップデートできます。

[armadillo /]# swupdate -d '-u https://armadillo.atmark-techno.com/files/downloads/{url-product-dir}/image/baseos-x2-[VERSION].swu'

図4.4 Armadillo Base OSをアップデートする


正常に実行された場合は自動的に再起動します。

4.4.3. パスワードの確認と変更

initial_setup.swu の作成」 で SWUpdate の初回アップデートを行った際に、各ユーザーのパスワード設定をしました。 開発中はログインしやすいような単純なパスワードにしていることがよくあるので、製品に適用しないようにこのタイミングで強固なパスワードに変更しておきましょう。

[armadillo /]# passwd 1
Changing password for root
New password: 2
Retype password: 3
passwd: password for root changed by root

[armadillo /]# passwd atmark 4
Changing password for atmark
New password: 5
Retype password: 6
passwd: password for atmark changed by root

[armadillo /]# persist_file /etc/shadow 7

図4.5 パスワードを変更する


1

rootユーザのパスワードを変更します。

2

新しいrootユーザ用パスワードを入力します。

3

再度新しいrootユーザ用パスワードを入力します。

4

atmarkユーザのパスワードを変更します。

5

新しいatmarkユーザ用パスワードを入力します。

6

再度新しいatmarkユーザ用パスワードを入力します。

7

パスワードの変更を永続化させます。

4.4.4. 開発したシステムをインストールディスクにする

Armadillo Base OSでは、 abos-ctrl make-installer コマンドを実行することで、現在起動しているルートファイルシステム及びブートローダーをそのままインストールディスクイメージとして出力し、microSDカードに書き込むことができます。

abos-ctrl make-installer コマンドを実行する前に、Armadilloがインターネットに接続されており、かつ 10GB 以上の空き容量がある microSDカードが挿入されていることを確認してください。 microSDカード内のデータはインストールディスク作成時に上書きされて消えてしまうので、必要なデータは予めバックアップを取っておいてください。

[armadillo /]# abos-ctrl make-installer
An installer system is already available on SD card. Use it? [Y/n] 1

Would you like to create a windows partition?
That partition would only be used for customization script at the end of
install, leave at 0 to skip creating it.
Custom partition size (MB, [0] - 30026): 500 2
Checking and growing installer main partition
GPT data structures destroyed! You may now partition the disk using fdisk or
other utilities.
The operation has completed successfully.
Trying to install mkfs.exfat (exfatprogs) in memory from internet
fetch http://pc-gtr.atmark.tech/products/yakushima/99_www/download/alpine/v3.16/atmark/aarch64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.16/main/aarch64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.16/community/aarch64/APKINDEX.tar.gz
(1/1) Installing exfatprogs (1.1.3-r0)
Executing busybox-1.35.0-r14.trigger
OK: 159 MiB in 215 packages
exfatprogs version : 1.1.3
Creating exFAT filesystem(/dev/mmcblk1p2, cluster size=32768)

Writing volume boot record: done
Writing backup volume boot record: done
Fat table creation: done
Allocation bitmap creation: done
Upcase table creation: done
Writing root directory entry: done
Synchronizing...

exFAT format complete!
Resize device id 1 (/dev/mmcblk1p1) from 400.00MiB to max
Currently booted on /dev/mmcblk2p1
Copying boot image
Copying rootfs
314572800 bytes (315 MB, 300 MiB) copied, 11 s, 28.5 MB/s
300+0 records in
300+0 records out
314572800 bytes (315 MB, 300 MiB) copied, 11.0192 s, 28.5 MB/s
Copying /opt/firmware filesystem
Copying appfs
At subvol app/snapshots/volumes
At subvol app/snapshots/boot_volumes
At subvol app/snapshots/boot_containers_storage
Cleaning up and syncing changes to disk...
Installer updated successfully!

図4.6 開発完了後のシステムをインストールディスクイメージにする


1

Enterキーを押下します。

2

インストールディスク内にインストールログを保存したい場合など、自由に使用できる第2パーティションを指定したサイズ作成します。詳細は「インストール時に任意のシェルスクリプトを実行する」を参照してください。

「Installer updated successfully!」と表示されれば、正常にmicroSDカードにインストールディスクイメージを書き込むことができています。 ArmadilloからmicroSDカードを抜去してください。

4.4.5. インストール時に任意のシェルスクリプトを実行する

作成したインストールディスクの所定の場所に、 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.5.1. 個体ごとに異なる固定IPアドレスを設定する

インストール時に任意のシェルスクリプトを実行できる機能を利用して、複数のArmadilloに対して異なる固定IPアドレスを割り当てる例を紹介します。

INST_DATA 内の installer_overrides.sh.sampleip_config.txt.sample は個体ごとに異なるIPアドレスを割り振る処理を行なうサンプルファイルです。 それぞれ installer_overrides.ship_config.txt にリネームすることで、 ip_config.txt に記載されている条件の通りに個体ごとに異なる固定IPアドレスを設定することができます。 全てをここでは説明しませんので、詳細はそれぞれのファイル内の記述も参照してください。

今回はそれぞれのファイルの内容は変更せず使用します。 サンプルそのままですが、 ip_config.txt の内容を図4.7「ip_config.txtの内容」に示します。

# mandatory first IP to allocate, inclusive
START_IP=10.3.4.2 1

# mandatory last IP to allocate, inclusive
END_IP=10.3.4.249 2

# netmask to use for the IP, default to 24
#NETMASK=24 3

# Gateway to configure
# not set if absent
GATEWAY=10.3.4.1 4

# DNS servers to configure if present, semi-colon separated list
# not set if absent
DNS="1.1.1.1;8.8.8.8" 5

# interface to configure, default to eth0
#IFACE=eth0 6

図4.7 ip_config.txtの内容


1

このインストールディスクで割り振るIPアドレスの範囲の始まりを指定します。

2

このインストールディスクで割り振るIPアドレスの範囲の終わりを指定します。

3

ネットマスクを指定します。指定しない場合は24になります。デフォルトでコメントアウトされています。

4

ゲートウェイアドレスを指定します。

5

DNSアドレスを指定します。セミコロンで区切ることでセカンダリアドレスも指定できます。

6

IPアドレスの設定を行なうインターフェースを指定します。指定しない場合はeth0になります。デフォルトでコメントアウトされています。

[警告]

インストール作業の並列化の為に、複数枚のインストールディスクで固定IPアドレスを割り振る場合は、それぞれのインストールディスクが割り振るIPアドレスの範囲が被らないように ip_config.txt を設定してください。

これらのファイルを配置したインストールディスクでインストールを実行したArmadilloが、正しく設定できていることを確認します。

[armadillo /]# ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff
    inet 10.3.4.2/24 brd 10.3.4.255 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet6 ffff::ffff:ffff:ffff:ffff/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

図4.8 IPアドレスの確認


また、サンプルスクリプトをそのまま使用すると、インストールディスクの第2パーティションに allocated_ips.csv というファイルが生成されます。 このファイルには、このインストールディスクを使用してIPアドレスの設定を行なった個体のシリアル番号、MACアドレス、設定したIPアドレスが追記されていきます。

SN,MAC,IP
00C700010009,00:11:22:33:44:55,10.3.4.2

図4.9 allocated_ips.csvの内容


[警告]

2台目以降のArmadilloにこのインストールディスクでIPアドレスの設定を行なう際に、 allocated_ips.csv を参照して次に割り振るIPアドレスを決めますので、誤って削除しないように注意してください。

4.4.5.2. インストール実行時のログを保存する

installer_overrides.sh 内の send_log 関数は、インストール処理の最後に実行されます。 インストールしたルートファイルシステムやファームウェアのチェックサムなどの情報が記録されたログファイルのパスが LOG_FILE に入るため、この関数内でインストールディスクの第2パーティションに保存したり、外部のログサーバにアップロードしたりすることが可能です。

図4.10「インストールログを保存する」は、インストールディスクの第2パーティションにインストールログを保存する場合の send_log 実装例です。

send_log() {
        : "This function is called after aggregating logs for archival"
        local LOG_FILE="$1"

        if [ -n "$USER_MOUNT" ]; then
                        mount /dev/mmcblk1p2 "$USER_MOUNT" 1
                        cp $LOG_FILE $USER_MOUNT/${SN}_install.log 2
                        umount "$USER_MOUNT" 3
        fi
}

図4.10 インストールログを保存する


1

send_log関数中では、SDカードの第2パーティション(/dev/mmcblk1p2)はマウントされていないのでマウントします。

2

ログファイルを <シリアル番号>_install.log というファイル名で第2パーティションにコピーします。

3

第2パーティションをアンマウントします。

これらの変更を行なったインストールディスクでインストールを実行した後に、インストールディスクをPCなどに接続して正しくログを保存できていることを確認してください。 保存したログファイルの中身の例を図4.11「インストールログの中身」に示します。

RESULT:OK
abos-ctrl make-rootfs on Tue Jun 21 17:57:07 JST 2022 4194304 6b8250df711de66b
abos-ctrl make-rootfs on Tue Jun 21 17:57:24 JST 2022 314572800 58a9b6664158943e
firm 8e9d83d1ba4db65d
appfs 5108 1fa2cbaff09c2dbf

図4.11 インストールログの中身


4.4.6. インストールの実行

前章までの手順で作成したインストールディスクを、開発に使用した Armadillo 以外の Armadillo に対して適用します。

クローン先の Armadillo の eMMC 内のデータは上書きされて消えるため、必要なデータは予めバックアップを取っておいてください。

「インストールディスクを使用する」を参照して、クローン先の Armadillo にインストールディスクを適用してください。

ここまで完了したら、「イメージ書き込み後の動作確認」に進んでください。

4.5. SWUpdate を用いてイメージ書き込みする

4.5.1. SWU イメージの準備

ここでは、sample-container という名称のコンテナの開発を終了したとします。 コンテナアーカイブの作成方法は 「コンテナの自動作成やアップデート」 を参照ください。

  1. sample-container-v1.0.0.tar (動かしたいアプリケーションを含むコンテナイメージアーカイブ)
  2. sample-container.conf (コンテナ自動実行用設定ファイル)

これらのファイルを /home/atmark/mkswu/sample-container ディレクトリを作成して配置した例を記載します。

[ATDE ~/mkswu/sample-container]$ ls
sample-container-v1.0.0.tar  sample-container.conf

図4.12 Armadilloに書き込みたいソフトウェアをATDEに配置


4.5.2. descファイルの記述

SWUpdate実行時に、「SWU イメージの準備」で挙げたファイルをArmadilloに書き込むような SWU イメージを生成します。

SWUイメージを作成するためには、SWUpdate時に実行する処理等を示したdescファイルを記述し、そのdescファイルを入力として mkswu コマンドを実行することで、SWUイメージが出来上がります。

[ATDE ~/mkswu/sample-container]$ cat sample-container.desc
swdesc_option component=sample-container
swdesc_option version=1
swdesc_option POST_ACTION=poweroff 1

swdesc_embed_container "sample-container-v1.0.0.tar" 2
swdesc_files --extra-os --dest /etc/atmark/containers/ "sample-container.conf" 3

図4.13 descファイルの記述例


1

SWUpdate完了後に電源を切るように設定します。

2

コンテナイメージファイルをswuイメージに組み込み、Armadilloに転送します。

3

コンテナ起動設定ファイルをArmadilloに転送します。

ここまで完了したら、「イメージ書き込み後の動作確認」に進んでください。 desc ファイルの詳細な書式については、「mkswu の .desc ファイルを編集する」を参照してください。 また、作成されたSWUイメージの内容を確認したい場合は、「SWU イメージの内容の確認」を参照してください。

4.6. イメージ書き込み後の動作確認

「インストールディスクを用いてイメージ書き込みする」で作成したインストールディスクを使用してインストール、または「SWUpdate を用いてイメージ書き込みする」にて SWUpdate によってイメージ書き込みを行った後には、イメージが書き込まれた Armadillo が正しく動作するか、実際に動かして確認してみます。

再度電源を投入して、期待したアプリケーションが動作することを確認してください。

ここまで完了したならば、量産時のイメージ書き込みは完了です。

4.7. 量産時の組み立て

Armadillo-IoT ゲートウェイ G4 を組み立てる際に必要な情報を紹介します。

4.7.1. 拡張ボードの組み付け

Armadillo-IoT ゲートウェイ G4の拡張インターフェース(CON11、CON12)に拡張ボードを接続する場合は、作成した拡張ボードにもよりますが図3.28「Armadillo-IoT ゲートウェイ G4の拡張ボード例」に示す図のように組み付けを行ってください。

4.7.2. オプションケース(金属製)への組み付け

Armadillo-IoT ゲートウェイ G4 と 専用のオプションケース(金属製)を組み付ける際には、以下の組み立て図に従って行ってください。

オプションケース(金属製)の詳細な仕様については、「オプションケース(金属製)」を参照してください。

オプションケース(金属製)は、SoCの熱をケースに伝導させて放熱する構造で設計しています。 基板裏のIC1に放熱シートを貼り付け、ケース(下)と放熱シートを接触させた状態で基板をねじ止めします。 ねじの締め付けトルクは 31.5cN•m です。

images/g4-metal-case-heat-sheet.svg

図4.14 オプションケース(金属製) 放熱シート貼付


WLAN+BTコンボモジュールが搭載されたモデルの場合は、基板裏にもう1箇所放熱シートを貼り付けます。

images/g4-metal-case-heat-sheet-wlan.svg

図4.15 オプションケース(金属製) 放熱シート貼付(WLAN+BTコンボモジュール搭載モデル)


images/g4-metal-case-assy-bottom.svg

図4.16 オプションケース(金属製) ケース(下)ねじ止め


images/common-images/callouts/1.svg
なべ小ねじ、ワッシャ、スプリングワッシャ付き(M3、L=6mm) × 4
images/common-images/callouts/2.svg
放熱シート(15×15×4mm)
images/common-images/callouts/3.svg
放熱シート(15×15×4.5mm) ※WLAN+BTコンボモジュール搭載モデルのみ

ケース(上)は、ケース(下)とフロント側を支点に嵌め合わせます。 このとき、コネクタ、スイッチ、LEDが曲がらないように注意しながら、 フロントに空いた穴に嵌めつつ閉めます。 LTEモデルの場合には、3G/LTEモジュールの熱をケースに伝導させて放熱する構造で設計しています。 3G/LTEモジュール上部に貼り付けられた放熱シートをケース(上)に接触させた状態で嵌め合わせます。

images/g4-metal-case-assy-top-bottom.svg

図4.17 オプションケース(金属製) ケース嵌め合わせ


ケース(上)とケース(下)は2箇所ねじ止めします。 ねじの締め付けトルクは 17.5cN•m です。

images/g4-metal-case-assy-top.svg

図4.18 オプションケース(金属製) ケース(上)ねじ止め


images/common-images/callouts/1.svg
皿ねじ(M2.6、L=4mm) × 2