Building Linux-based NVRs

Overview

この記事では、NVR のようなハードウェア製品、つまり、プリインストールされたサーバー アプリケーションを備えた組み込みコンピューター (ここでは「NVR」と呼びます) を作りたいパートナーに共通のステップについて解説しています。 通常、このような NVR は、ARM CPU を搭載した Linux ベースのコンピューターです。

このような製品を作るための基本的な手順は以下のとおりです。

  • ハードウェアの選択
    • プラットフォーム

    • ストレージ
  • Linuxフレーバーの選択
  • サーバー アプリケーションのインストール
  • 追加機能の実装
  • サポート方針の確立

これらのステップについて、以下で詳しく説明します。

ハードウェアの選択

製品を成功させるには、費用対効果が高く、必要なパフォーマンスを提供し、希望するビットレート/解像度のカメラ台数をサポートする必要があります。 使用するハードウェアは、少なくとも1GBのRAMとARM Cortex A7チップセットまたはそれ以上である必要があります。

サポートされている ARM プラットフォームの性能をまず調べ(そのようなプラットフォームのリストについては、ARM サポート ポリシーを参照)、次に要件に最も近いプラットフォームを選択することが推奨されます。 標準の Raspberry Pi メインボードなど)、場合によってはカスタム ケースおよび電源ユニット付き、

  • 周辺機器インターフェイスやハード ドライブ コントローラーなどの追加ハードウェア コンポーネントをホストできるメインボードを備えたカスタム コンピューターを設計するための参照として使用できます。
  • NVR が、ユーザーに Web インターフェイスを提供する Web サーバー、ビデオ解析ソフトウェア (たとえば、VMS プラグインおよび/またはそのバックエンド) など、サーバー アプリケーション以外の追加ソフトウェアをオンボードで搭載すると考えられる場合、それをカバーする十分な RAM および CPU 処理能力を追加することを確認する必要があります。

    計算能力が限られているため、ARM デバイスではビデオ トランスコーディングはサポートされていません。 さらに、OpenSSL などの一部の依存関係には互換性の問題がある可能性があります。 初期の分析で、典型的な ARM ベースのプラットフォームが必要なパフォーマンスを提供できないことが分かった場合、x64 プラットフォームを検討することができます。

    プラットフォームのストレージ パフォーマンスは、計画された負荷に対して十分であるべきです。 たとえば、SATA-over-USB などのソリューションでは HDD の性能が低く、必要な数のカメラを記録するには不十分であることが知られています。

    プラットフォームのネットワーク性能は、計画された負荷に対して十分である必要があります。 例えば、ソフトウェアベースのイーサネット実装のようなソリューションは、多くのCPUリソースを必要とするため、カメラの録画中やクライアントへのストリーミング中にフレームドロップやその他の問題につながる可能性があることが知られています。 さらに、USB ハブを介してイーサネットを実装したハードウェアモデルは、宣伝されているネットワーク帯域幅よりも小さいかもしれません。

    プラットフォームはリアルタイムクロック (RTC) ハードウェアを装備し、ネットワーク経由で時間の同期(例:NTP プロトコル使用)を有効にする必要があります – VMS が正しく機能するために、OS の日付と時刻は正しい必要があります。 ハードウェア RTC がなく、日付/時間のソースがネットワークのみである場合、日付/時間の同期ができない場合にデバイスの起動を拒否することをお勧めします。

    Storage

    VMSが正しく機能するために、ファイルシステムに十分なスペースがあることを確認してください。 サーバーは次のストレージ場所を使用します:

    • VMS インストール – バイナリおよび動的ライブラリ (.so ファイル)
      • Located at /opt/<vendor>/mediaserver/
      • Required space: 割り当てるファイルの合計サイズとマージンを計算してください: 余裕があれば、将来のバージョンへの更新で問題が生じる確率が減少するでしょう。 一般に、30%のマージンが推奨されます。
      • /optに十分なストレージがない場合、.soファイルはシンボリックリンクを介して、FAT32ストレージを含む別の場所に移動できます(ただしこの場合、シンボリックリンクではないファイルのみ移動可能です)。
        • 通常 /opt/<vendor>/mediaserver/var/ に配置されます。
      • Server Analytics データベース – Analytics プラグインによって生成された Video Analytics メタデータを保存
        • 通常は /opt/<vendor>/mediaserver/var/data に配置され、サーバー構成ファイルで変更可能です。
        • 必要な領域: このサーバーで Analytics プラグインが使用されているかどうか、およびプラグインが送信するメタデータの量に依存します。 一般に、このサーバーで Analytics プラグインが使用されている場合、Video Archive Storage サイズの 20% を推奨します。
      • サーバー ログ
        • 場所は /opt/<vendor>/mediaserver/var/log/
          • mediaserver.log を介して移動することができます。
        • ログはループで自動的に上書きされます。

        • 必要な容量:少なくとも260MBを推奨。
        • 注意:特定のARMデバイス(例. Raspberry Pi 3 など) では、内部フラッシュ メモリ (その場合は Micro SD) がログを受け入れるのに十分でないことに気づきました。 最大で4秒間フリーズすることがありました。 そのようなデバイスには、ログをビデオ アーカイブと同じ場所にリダイレクトすることを推奨しました。
      • ビデオ アーカイブ – カメラから録画したビデオを保存
        • 通常は /opt/<vendor>/mediaserver に配置されます。
        • システム パーティションは、少なくとも 10 GB の空き容量がない限り、デフォルトで録画が制限される可能性があります。
        • 内蔵フラッシュ メモリ (eMMC) または SD カード
            • メモリが許容できる書き込みサイクルの数を推定してください。 ビデオアーカイブはループで自動的に上書きされるため、1回の書き込みサイクルの時間は、空き容量をサーバーに記録されているすべてのカメラの合計ビットレートで割ることによって計算できます。
            • メモリのスループットが、サーバーに記録されているすべてのカメラの合計ビットレートに対して十分であることを、30%の安全マージンをもって確認してください。
        • 内蔵 HDD または SSD
            • ディスクのスループットが、サーバーに記録されているすべてのカメラの合計ビットレートに対して十分であることを、30%の安全マージンをもって確認してください。
        • 外部 NAS
            • ネットワーク アダプターの実際の帯域幅が、サーバーで録画するすべてのカメラの合計ビットレートを 2 倍した値 (カメラはおそらく同じネットワーク アダプターを使ってサーバーにストリームを送信するので) に十分で、30%の安全マージンを持つことを確認すること。
        • サーバー アプリケーションのアップデート ファイル
          • アップデートできるようにするには、サーバー アプリケーションは新しいバージョンをダウンロードし、それを解凍する必要があります。 将来のバージョンへのアップデートで問題が発生する可能性を最小限に抑えるため、より多くの容量を推奨します。
          • OS 一時ファイル
            • 通常 /tmp/
            • 必要な容量:少なくとも 100 MB を推奨。

            上記に挙げたもののほとんどは、Server 設定ファイルで別の場所に保存されるように割り当てることができます。 /opt/<vendor>/mediaserver/etc/mediaserver.conf

            The typical SD card storage is not reliable and known to fail during intensive read-write operations, we recommend to install the OS and store the video archive on a hard drive(s). ビデオ アーカイブの保存に SSD/ハード ドライブまたは SD カードを検討する場合、サポートされる希望するカメラの標準ビットレートにサポートされる希望するカメラの数を乗じたものを使用して、複数の書き換え操作に対するその能力を評価します。

      • 外付けハードディスクにOS(Raspbian)をインストールします。 詳しくは、USB大容量記憶装置からRaspberry Piを起動する方法の記事を参照してください。 このプロセスは、ARM デバイスがどのように配布されるかに応じて自動化する必要があります:
        • ハードディスクあり – VMS をインストールした設定済みのイメージを作成し、ハードディスクにクローンを作成します。 これはかなり複雑で時間のかかる作業です。

    Choose Linux Flavor

    通常、特定の NVR の Linux OS にはいくつかの選択肢があります:

    • “Busybox” – Linux カーネルとコマンド ライン ツールの基本セットのみ。
    • 標準的な Debian、または Ubuntu のようなそのフレーバーの一つ。
    • Debian または他の Linux ディストリビューションの修正版、通常はデバイスベンダーによって修正されたもの (例,

    一般に、NVR が基づいているプラットフォームのネイティブな Linux バリアントを選択することをお勧めします。 たとえば、Raspberry Pi とハードウェアが似ている (あるいは、正確な Raspberry Pi メインボードを使用している) NVR を開発する場合、Raspbian を選択することをお勧めします。

    異なるパッケージのセットを持つ複数の Linux ディストリビューションをデバイス用に利用できる場合、最も重くないものをお勧めします。 たとえば、NVR で GUI を表示する予定がない場合、X Window System は必要ありません。

    Linux のバージョンとそのパッケージ・セットが VMS の要件を満たしていることを確認してください。 ARM ベースのデバイスの場合、ARM サポート ポリシーで指定されている OS の詳細を参照してください。

    サーバー アプリケーションのインストール

    NVRに適切なLinux OSをロードしたら、NVRにサーバー アプリケーションをインストールする必要があります。 基本的に 2 つのオプションがあります:

    1. Debian ベースの OS の場合: dpkg.
    • デバイスに VMS をインストールする詳細手順を参照して、VMS 配布から公式 .deb パッケージをインストールします。 ARM SBC インストール手順
  • Busybox ベースの OS の場合: VMS .deb パッケージから必要なファイルを目的のディレクトリに展開し、以下の点を手動で確認します:
    • 起動時にどのようにサーバーを起動するか、ディストリビューションの system.d サポートは適切ではないか?
    • Server はインストールした Linux で見つからない .so ライブラリをどこに持っていくか?
    • VMS の標準的な自動更新システムは有効になりますか。

    あまり典型的ではない OS セットアップの場合、オプション 1 と 2 の組み合わせが必要になることがあります。

    追加機能の実装

    一般的に、NVR はサーバー アプリケーションをインストールした標準の Linux コンピューターではなく、ユーザーに追加機能を提供することが多いです。

  • ネットワーク・オプションなど、独自の Web インターフェイスでサーバー・アプリケーションをセットアップするだけでなく、NVR をカスタマイズできる Web インターフェイス。 IP アドレス、サブネットなど;
  • システム時刻とタイムゾーン;
  • ビデオ出力 (例:, VMS と並行して動作する追加ソフトウェア (構成デーモンやビデオ解析バックエンドなど)。
    • 追加ソフトウェアがエンド ユーザーに対してパスワード ベースの認証を行う場合、VMS サーバーのパスワードが追加ソフトウェアのパスワードと常に同じになるよう、パスワード同期の実装を検討してください。 NVR にアクセスするためにユーザーに ssh が提供されている場合、そのパスワードの同期も考慮します。
  • ビデオ (GPU) メモリの最小化など、追加の微調整を実施します。 たとえば、Raspberry Pi 3 B+ の場合、GPU メモリを 16 MB に設定します。 詳細については、Raspberry Pi のドキュメントを参照してください。
  • このような機能を実装するには、サーバー アプリケーションを制御するスクリプトの作成または修正、あるいは C/C++ で追加のプログラムの作成が必要になる場合があります。

    時刻同期

    電力損失時に NVR のクロックがリセットされないよう、CMOS バッテリーが内蔵されていることを確認します。 例えば、Raspberry Pi 3 B+はCMOSバッテリーを内蔵していません。 デバイスを再起動すると、時刻がリセットされ、誤ったアーカイブの書き込みが発生します。 これを回避するために、いくつかのオプションがあります:

    • 時間を同期するためにインターネットに接続されていることを確認する。
    • 閉じたネットワークである場合、NTPサーバーを設定する必要があります。
    • ボードにリアルタイムクロック(RTC)モジュールを追加し、事前に設定します。 Raspberry Pi にリアルタイム クロックを追加する」を参照してください。

    NVR 用エンクロージャを探す/構築する

    上記のハードウェアすべてに適合するケースを探すか設計する必要があります。

    Conduct Extensive Load/Sress Test

    すべてが一緒に機能するように、過熱や部品の誤作動がないよう、集中ストレス テストを計画することが必要です。 テストでは、CPU、メモリ、ハード ディスク、ネットワーク、および Wi-Fi (必要な場合) などのすべてのシステム コンポーネントに負荷をかけることができるはずです。

    サポート ポリシーの確立

    NVRはエンド ユーザーに提供されるため、何らかの技術サポートが必ず必要になります。 VMS ベンダーのサポート・チームはエンド・ユーザーにそのようなサービスを提供できないため、オンライン・サポート・デスクやコミュニティ・フォーラムなど、そのようなサポートを提供するためのポリシーを開発する必要があります。

    NVRベンダーのサポート・チームは、特定の問題がNVR自体の仕様に関係なく、むしろVMSの問題であると確信する場合、上記のARMサポート・ポリシーに従ってVMSベンダーにサポートを要求し、このサポート事例の結果を使用してエンド・ユーザーからのサポート要求を満足させることができるのです。

    Questions

    このトピックに関する質問がある場合、または自分の経験を他のコミュニティ メンバーや当社チームと共有したい場合は、当社のサポート コミュニティに参加するか、地域の販売代理店に連絡してください。

    コメントを残す

    メールアドレスが公開されることはありません。