みなさん、こんにちは！

最近、クラウドビデオ監視サービスの人気が高まっていることはおそらく周知の事実でしょう。 なぜこのようなことが起こるかは明らかです。ビデオは「重い」コンテンツであり、そのストレージにはインフラストラクチャと大量のディスク ストレージが必要です。 オンプレミスのビデオ監視システムを使用するには、数百台の監視カメラを使用する組織と、複数のカメラを使用する個人ユーザーの両方の運用とサポートのための資金が必要です。

クラウドビデオ監視システムは、顧客に既存のビデオストレージと処理インフラストラクチャを提供することで、この問題を解決します。 クラウド ビデオ監視クライアントは、カメラをインターネットに接続し、クラウド アカウントにリンクするだけで済みます。

カメラをクラウドに接続する技術的な方法はいくつかあります。 間違いなく、最も便利で安価な方法は、サーバーやレコーダーなどの追加機器を使用せずに、カメラをクラウドに直接接続して動作させることです。

これを行うには、クラウドと連携するソフトウェア モジュールがカメラにインストールされている必要があります。 ただし、安価なカメラについて言えば、ハードウェア リソースが非常に限られており、カメラ ベンダーのネイティブ ファームウェアによってほぼ 100% 占有されており、クラウド プラグインに必要なリソースはありません。 ivideon の開発者がこの問題を提供しました статью、これは、安価なカメラにプラグインをインストールできない理由を説明しています。 その結果、カメラの最低価格は5000ルーブル（80ドル）となり、機材には数百万ドルが費やされることになる。

私たちはこの問題を無事に解決しました。 方法に興味があるなら - カットへようこそ

歴史を少し

2016 年に、当社は Rostelecom 向けのクラウド ビデオ監視プラットフォームの開発を開始しました。

カメラ ソフトウェアに関しては、最初の段階で、このようなタスクの「標準」パスに従いました。独自のプラグインを開発しました。これは、ベンダーのカメラの標準ファームウェアにインストールされ、クラウドで動作します。 ただし、設計中に最も軽量で効率的なソリューションを使用したことは注目に値します (たとえば、protobuf、libev、mbedtls のプレーンな C 実装、および boost のような便利だが重いライブラリは完全に放棄されました)。

現在、IP カメラ市場には汎用の統合ソリューションはありません。各ベンダーは、プラグインをインストールする独自の方法、ファームウェアを操作するための独自の API セット、および独自の更新メカニズムを持っています。

これは、各カメラ ベンダーが統合ソフトウェアの包括的なレイヤーを個別に開発する必要があることを意味します。 また、開発を開始する時点では、チームの労力をクラウドと連携するためのロジックの開発に集中させるために、1 つのベンダーとのみ連携することをお勧めします。

最初に選ばれたベンダーは、カメラ市場の世界的リーダーの XNUMX つである Hikvision で、十分に文書化された API と有能なエンジニアリング技術サポートを提供しています。

当社は、Hikvision カメラを使用した最初のパイロット プロジェクト、クラウド ビデオ監視 Video Comfort を開始しました。

リリース直後、ユーザーは他のメーカーの安価なカメラをサービスに接続する可能性について質問をし始めました。

私は、ベンダーごとに統合レイヤーを実装するというオプションをすぐに拒否しました。拡張性が低く、カメラ ハードウェアに重大な技術要件を課すためです。 これらの入力要件を満たすカメラのコスト: ~60 ～ 70 ドル

そこで、私はさらに深く掘り下げて、どのベンダーのカメラでも使用できる独自のファームウェアを作成することにしました。 このアプローチにより、カメラのハードウェア リソースの要件が大幅に軽減されます。 クラウドを操作するためのレイヤーはビデオ アプリケーションとより効果的に統合されており、ファームウェアには不要な未使用の要素がありません。

そして重要なのは、カメラを低レベルで操作する場合、低電力 CPU に追加の負荷を与えることなくデータを暗号化するハードウェア AES を使用できることです。

その瞬間、私たちには何もありませんでした。 何もありません。

ほとんどすべてのベンダーは、このような低いレベルで私たちと協力する準備ができていませんでした。 回路やコンポーネントに関する情報はなく、チップセットの公式 SDK やセンサーのドキュメントもありません。
技術サポートもありません。

すべての質問は、リバース エンジニアリング、つまり試行錯誤によって答える必要がありました。 しかし、私たちはなんとかなりました。

私たちがテストした最初のカメラモデルは、Xiaomi Yi Ants、Hikvision、Dahua、Spezvision、D-Link カメラ、およびいくつかの超安価な無名中国製カメラでした。

機器

Hisilicon 3518E チップセットをベースにしたカメラ。 カメラのハードウェア特性は次のとおりです。

Xiaomi Yi Ants
NONAME

SoCの
ハイシリコン 3518E
ハイシリコン 3518E

RAM
64MB
64MB

FLASH
16MB
8MB

無線LAN
mt7601/bcm43143
-

センサー
ov9732 (720p)
ov9712 (720p)

イーサネット
-
+

MicroSD
+
+

マイク
+
+

スピーカー
+
+

IRLED
+
+

IRカット
+
+

私たちは彼らから始めました。

現在、Hisilicon 3516/3518 チップセットと Ambarella S2L/S2LM をサポートしています。 カメラのモデルは数十あります。

ファームウェア構成

潜水艦

uboot はブート ローダーであり、電源投入後に最初に起動し、ハードウェアを初期化し、Linux カーネルをロードします。

カメラの読み込みスクリプトは非常に簡単です。

bootargs=mem=38M console=ttyAMA0,115200 rootfstype=ramfs mtdparts=hi_sfc:256K(boot),64K(tech),4096K(kernel),8192K(app),-(config) hw_type=101
bootcmd=sf probe 0; sf read 0x82000000 0x50000 0x400000; bootm 0x82000000; setenv bootargs $(bootargs) bkp=1; sf read 0x82000000 0x450000 0x400000; bootm 0x82000000

特徴のXNUMXつはXNUMX回呼び出されることです。 bootm、これについては、少し後で、更新サブシステムに到達するときに詳しく説明します。

ラインに注目 mem=38M。 はい、はい、これはタイプミスではありません。Linux カーネルとすべてのすべてのアプリケーションは、38 メガバイトの RAM にしかアクセスできません。

また、uboot の隣には、と呼ばれる特別なブロックがあります。 reg_info、これには、DDR と SoC のいくつかのシステム レジスタを初期化するための低レベル スクリプトが含まれています。 コンテンツ reg_info カメラのモデルによって異なります。これが正しくない場合、カメラは uboot をロードすることさえできず、ロードの非常に初期の段階でフリーズします。

最初、ベンダーのサポートを受けずに作業していたときは、このブロックを元のカメラのファームウェアからコピーするだけでした。

Linux カーネルと rootfs

カメラは、チップの SDK の一部である Linux カーネルを使用します。通常、これらは 3.x ブランチの最新カーネルではないため、多くの場合、追加機器のドライバーが使用されているカーネルと互換性がないという事実に対処する必要があります。そして、それらをカーネルカメラにバックポートする必要があります。

もう 8 つの問題は、カーネルのサイズです。 FLASH サイズがわずか XNUMXMB の場合、すべてのバイトが重要になるため、サイズを最小限に抑えるために、未使用のカーネル機能をすべて慎重に無効にすることがタスクとなります。

Rootfs は基本的なファイル システムです。 それには以下が含まれます busybox、Wi-Fi モジュール ドライバー、標準システム ライブラリのセット、など libld и libc、LED 制御ロジック、ネットワーク接続管理、ファームウェアの更新を担当するソフトウェアも含まれます。

ルート ファイル システムは initramfs としてカーネルに接続されており、ビルドの結果として XNUMX つのファイルを取得します。 uImage、これにはカーネルと rootfs の両方が含まれます。

ビデオアプリケーション

ファームウェアの最も複雑でリソースを大量に消費する部分はアプリケーションです。アプリケーションは、ビデオ/オーディオ キャプチャ、ビデオ エンコーディングを提供し、画像パラメータを構成し、モーション検出器やサウンド検出器などのビデオ分析を実装し、PTZ を制御し、曜日と時刻の切り替えを担当します。ナイトモード。

重要な、鍵となる機能とさえ言えるのは、ビデオ アプリケーションがクラウド プラグインとどのように対話するかです。

従来のソリューション「ベンダー ファームウェア + クラウド プラグイン」では、安価なハードウェアでは動作せず、カメラ内のビデオは RTSP プロトコル経由で送信されます。これは、ソケット経由でのデータのコピーと送信、不必要なシステムコールなど、膨大なオーバーヘッドになります。

ここでは共有メモリ メカニズムを使用します。ビデオは、カメラ ソフトウェア コンポーネント間のソケットを介してコピーまたは送信されません。これにより、カメラの控えめなハードウェア機能が最適かつ慎重に使用されます。

サブシステムの更新

特別な誇りは、オンライン ファームウェア アップデート用のフォールト トレラント サブシステムです。

問題を説明しましょう。 ファームウェアの更新は技術的にはアトミックな操作ではなく、更新の途中で停電が発生した場合、フラッシュ メモリには「下書きされた」新しいファームウェアの一部が含まれることになります。 特別な措置を講じないと、カメラはサービスセンターに持ち込まなければならない「レンガ」になってしまいます。

私たちもこの問題に対処しました。 アップデート中にカメラの電源がオフになった場合でも、ユーザーの介入なしに自動的にファームウェアがクラウドからダウンロードされ、動作が復元されます。

このテクニックをさらに詳しく見てみましょう。

最も脆弱な点は、Linux カーネルとルート ファイル システムでパーティションを上書きすることです。 これらのコンポーネントのいずれかが破損すると、カメラは uboot ブートローダーを超えてまったく起動しなくなり、クラウドからファームウェアをダウンロードできなくなります。

これは、更新プロセス中いつでも、カメラに動作するカーネルと rootfs があることを確認する必要があることを意味します。 最も簡単な解決策は、rootfs を含むカーネルの XNUMX つのコピーをフラッシュ メモリに常に保存し、メイン カーネルが破損した場合はバックアップ コピーからロードすることだと思われます。

良い解決策ですが、rootfs を使用するカーネルは約 3.5MB を占有し、永続バックアップには 3.5MB を割り当てる必要があります。 最も安価なカメラには、バックアップ カーネル用の空きスペースがあまりありません。

したがって、ファームウェアの更新中にカーネルをバックアップするには、アプリケーション パーティションを使用します。
カーネルで目的のパーティションを選択するには、XNUMX つのコマンドを使用します。 bootm uboot では、最初にメイン カーネルをロードしようとしますが、それが破損している場合は、バックアップ カーネルをロードします。

これにより、いつでもカメラに rootfs を備えた正しいカーネルが確保され、ファームウェアを起動して復元できるようになります。

ファームウェアを構築および展開するための CI/CD システム

ファームウェアの構築には、サポートされているすべてのカメラ モデルのファームウェアを自動的に構築する gitlab CI を使用します。ファームウェアの構築後、カメラ ソフトウェア アップデート サービスに自動的に展開されます。

このサービスから、ファームウェアのアップデートが QA テスト カメラに配信され、すべてのテスト段階が完了するとユーザーのカメラに配信されます。

情報セキュリティ

現在、情報セキュリティがカメラを含むあらゆる IoT デバイスにとって最も重要な側面であることは周知の事実です。 Mirai のようなボットネットがインターネット上を徘徊し、ベンダーの標準ファームウェアを搭載した何百万台ものカメラに感染しています。 カメラ ベンダーに敬意を表し、標準ファームウェアにはクラウドでの作業に必要のない機能が多数含まれているものの、ボットネットが悪用する多くの脆弱性が含まれていることを指摘せざるを得ません。

したがって、ファームウェアの未使用の機能はすべて無効になり、すべての tcp/udp ポートが閉じられ、ファームウェアを更新するときにソフトウェアのデジタル署名がチェックされます。

これに加えて、ファームウェアは情報セキュリティ研究所で定期的にテストされます。

まとめ

現在、当社のファームウェアはビデオ監視プロジェクトで積極的に使用されています。 おそらくそれらの最大のものは、ロシア連邦大統領選挙当日の投票の放送です。
このプロジェクトには、当社のファームウェアを搭載した 70 万台以上のカメラが関与し、我が国の投票所に設置されました。

多くの複雑な、そして一部の場所では当時でさえほとんど不可能だった問題を解決できたので、私たちはエンジニアとしてもちろん大きな満足を得ましたが、これに加えて、カメラの購入にかかる何百万ドルも節約できました。 そしてこの場合、節約は単なる言葉や理論的な計算ではなく、すでに完了した設備購入の入札の結果です。 したがって、クラウドビデオ監視について話す場合、XNUMX つのアプローチがあります。XNUMX つは低レベルの専門知識と開発に戦略的に依存し、結果として機器を大幅に節約する方法、または高価な機器を使用する方法ですが、特に消費者の特性に着目すると、実際には使用する必要はありません。似たような安価なものとは異なります。

できるだけ早く統合アプローチの選択を決定することが戦略的に重要なのはなぜですか? プラグインを開発するとき、開発者は特定のテクノロジー (ライブラリ、プロトコル、標準) に依存します。 そして、高価な機器に対してのみ一連のテクノロジーが選択されている場合、将来的には安価なカメラに切り替えようとすると、少なくとも非常に長い時間がかかるか、失敗して高価な機器に戻る可能性が高くなります。

出所： habr.com