안녕하십니까!

최근 클라우드 영상 감시 서비스가 인기를 얻고 있다는 것은 아마도 비밀이 아닐 것입니다. 그리고 이런 일이 발생하는 이유는 분명합니다. 비디오는 스토리지에 인프라와 대용량 디스크 스토리지가 필요한 "무거운" 콘텐츠입니다. 온프레미스 비디오 감시 시스템을 사용하려면 수백 대의 감시 카메라를 사용하는 조직과 여러 대의 카메라를 사용하는 개인 사용자 모두를 위한 운영 및 지원 자금이 ​​필요합니다.

클라우드 영상 감시 시스템은 고객에게 기존 영상 저장 및 처리 인프라를 제공하여 이 문제를 해결합니다. 클라우드 비디오 감시 클라이언트는 카메라를 인터넷에 연결하고 클라우드 계정에 연결하기만 하면 됩니다.

카메라를 클라우드에 연결하는 기술적인 방법에는 여러 가지가 있습니다. 의심할 여지 없이 가장 편리하고 저렴한 방법은 서버나 레코더 등의 추가 장비 없이 카메라가 클라우드에 직접 연결되어 작동하는 것입니다.

이를 위해서는 클라우드와 함께 작동하는 소프트웨어 모듈을 카메라에 설치해야 합니다. 그러나 저렴한 카메라에 대해 이야기하면 하드웨어 리소스가 매우 제한되어 카메라 공급업체의 기본 펌웨어가 거의 100% 점유하고 있으며 클라우드 플러그인에 필요한 리소스가 없습니다. ivideon의 개발자들은 이 문제를 해결했습니다. статью, 저렴한 카메라에 플러그인을 설치할 수 없는 이유를 설명합니다. 결과적으로 카메라의 최소 가격은 5000루블(80달러)이며 장비 구입에 수백만 달러가 소요됩니다.

우리는 이 문제를 성공적으로 해결했습니다. 방법에 관심이 있다면 컷에 오신 것을 환영합니다.

역사의 비트

2016년에 우리는 Rostelecom을 위한 클라우드 영상 감시 플랫폼 개발을 시작했습니다.

카메라 소프트웨어 측면에서 우리는 첫 번째 단계에서 이러한 작업을 위한 "표준" 경로를 따랐습니다. 즉, 공급업체 카메라의 표준 펌웨어에 설치되고 클라우드에서 작동하는 자체 플러그인을 개발했습니다. 그러나 설계 과정에서 가장 가볍고 효율적인 솔루션을 사용했다는 점은 주목할 가치가 있습니다(예: protobuf, libev, mbedtls의 일반 C 구현 및 Boost와 같은 편리하지만 무거운 라이브러리는 완전히 포기함)

현재 IP 카메라 시장에는 보편적인 통합 솔루션이 없습니다. 각 공급업체에는 플러그인을 설치하는 자체 방법, 펌웨어 작동을 위한 자체 API 세트 및 고유한 업데이트 메커니즘이 있습니다.

이는 각 카메라 공급업체가 포괄적인 통합 소프트웨어 계층을 개별적으로 개발해야 함을 의미합니다. 그리고 개발 시작 시점에는 클라우드 작업을 위한 로직 개발에 팀의 노력을 집중하기 위해 1개의 벤더와만 협력하는 것이 좋습니다.

첫 번째로 선택된 공급업체는 잘 문서화된 API와 유능한 엔지니어링 기술 지원을 제공하는 카메라 시장의 세계적 리더 중 하나인 Hikvision이었습니다.

우리는 Hikvision 카메라를 사용하여 첫 번째 파일럿 프로젝트인 클라우드 비디오 감시 Video Comfort를 시작했습니다.

출시 직후 사용자들은 다른 제조업체의 저렴한 카메라를 서비스에 연결할 수 있는지에 대해 질문하기 시작했습니다.

저는 각 공급업체에 대한 통합 레이어를 구현하는 옵션을 거의 즉시 거부했습니다. 이는 확장성이 낮고 카메라 하드웨어에 심각한 기술 요구 사항을 부과하기 때문입니다. 이러한 입력 요구 사항을 충족하는 카메라 비용: ~60-70$

따라서 저는 더 깊이 파고들어 모든 공급업체의 카메라용 펌웨어를 직접 만들기로 결정했습니다. 이 접근 방식은 카메라 하드웨어 리소스에 대한 요구 사항을 크게 줄여줍니다. 클라우드 작업을 위한 레이어는 비디오 애플리케이션과 훨씬 더 효과적으로 통합되며 펌웨어에 불필요하게 사용되지 않는 지방이 없습니다.

그리고 중요한 것은 낮은 수준에서 카메라를 사용할 때 저전력 CPU에 추가 부하를 발생시키지 않고 데이터를 암호화하는 하드웨어 AES를 사용할 수 있다는 것입니다.

그 순간 우리에게는 아무것도 없었습니다. 전혀 없습니다.

거의 모든 공급업체가 그렇게 낮은 수준에서 우리와 협력할 준비가 되어 있지 않았습니다. 회로 설계 및 구성 요소에 대한 정보가 없으며 칩셋 및 센서 문서의 공식 SDK도 없습니다.
기술지원도 없습니다.

모든 질문은 리버스 엔지니어링(시행 착오)을 통해 답해야 했습니다. 하지만 우리는 성공했습니다.

우리가 테스트한 첫 번째 카메라 모델은 Xiaomi Yi Ants, Hikvision, Dahua, Spezvision, D-Link 카메라 및 몇몇 이름 없는 초저가 중국 카메라였습니다.

기술

Hisilicon 3518E 칩셋을 기반으로 한 카메라입니다. 카메라의 하드웨어 특성은 다음과 같습니다.

샤오미 이 개미
제목 없음

SoC를
히실리콘 3518E
히실리콘 3518E

램
64MB
64MB

플래시
16MB
8MB

WiFi
mt7601/bcm43143
-

감지기
ov9732 (720p)
ov9712 (720p)

Ethernet
-
+

마이크로
+
+

마이크로폰
+
+

Speaker
+
+

IRL됨
+
+

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

특징 중 하나는 두 번 호출된다는 것입니다. bootm, 이에 대한 자세한 내용은 나중에 업데이트 하위 시스템에 도달할 때 설명하겠습니다.

라인에 주목 mem=38M. 예, 예, 이것은 오타가 아닙니다. Linux 커널과 모든 응용 프로그램은 38MB의 RAM에만 액세스할 수 있습니다.

또한 uboot 옆에는 다음과 같은 특수 블록이 있습니다. reg_info여기에는 DDR을 초기화하기 위한 하위 수준 스크립트와 SoC의 여러 시스템 레지스터가 포함되어 있습니다. 콘텐츠 reg_info 카메라 모델에 따라 다르며 올바르지 않은 경우 카메라는 uboot를 로드할 수 없으며 로딩 초기 단계에서 정지됩니다.

처음에 공급업체 지원 없이 작업할 때는 원래 카메라 펌웨어에서 이 블록을 복사했습니다.

리눅스 커널과 rootfs

카메라는 칩 SDK의 일부인 Linux 커널을 사용합니다. 일반적으로 이러한 커널은 3.x 브랜치의 최신 커널이 아니므로 추가 장비용 드라이버가 사용된 커널과 호환되지 않는다는 사실을 종종 처리해야 합니다. , 이를 커널 카메라로 백포트해야 합니다.

또 다른 문제는 커널의 크기입니다. FLASH 크기가 8MB에 불과하면 모든 바이트가 중요하며 우리의 임무는 크기를 최소로 줄이기 위해 사용되지 않는 모든 커널 기능을 조심스럽게 비활성화하는 것입니다.

Rootfs는 기본 파일 시스템입니다. 그것은 다음을 포함합니다 busybox, Wi-Fi 모듈 드라이버, 표준 시스템 라이브러리 세트 libld и libc, LED 제어 로직, 네트워크 연결 관리 및 펌웨어 업데이트를 담당하는 소프트웨어도 있습니다.

루트 파일 시스템은 initramfs로 커널에 연결되며 빌드 결과로 하나의 파일을 얻습니다. uImage, 커널과 rootfs가 모두 포함되어 있습니다.

영상응용

펌웨어에서 가장 복잡하고 리소스 집약적인 부분은 비디오-오디오 캡처, 비디오 인코딩을 제공하고, 그림 매개변수를 구성하고, 동작 또는 소리 감지기와 같은 비디오 분석을 구현하고, PTZ를 제어하고 요일 및 전환을 담당하는 애플리케이션입니다. 야간 모드.

중요한 기능은 비디오 애플리케이션이 클라우드 플러그인과 상호 작용하는 방식입니다.

저렴한 하드웨어에서는 작동하지 않는 기존 솔루션인 '벤더 펌웨어 + 클라우드 플러그인'에서는 카메라 내부의 영상이 RTSP 프로토콜을 통해 전송되는데, 이는 소켓을 통해 데이터를 복사하고 전송하는 불필요한 시스템 호출 등 엄청난 오버헤드입니다.

여기서 우리는 공유 메모리 메커니즘을 사용합니다. 비디오는 카메라 소프트웨어 구성 요소 사이의 소켓을 통해 복사되거나 전송되지 않으므로 카메라의 적당한 하드웨어 기능을 최적으로 신중하게 사용합니다.

하위 시스템 업데이트

특별한 자부심은 온라인 펌웨어 업데이트를 위한 내결함성 하위 시스템입니다.

문제를 설명하겠습니다. 펌웨어 업데이트는 기술적으로 원자적 작업이 아니며, 업데이트 도중에 정전이 발생하면 플래시 메모리에 "작성된" 새 펌웨어의 일부가 포함됩니다. 특별한 조치를 취하지 않으면 카메라는 서비스 센터로 가져가야 할 "벽돌"이 됩니다.

우리도 이 문제를 다루었습니다. 업데이트 중에 카메라가 꺼지더라도 사용자 개입 없이 자동으로 클라우드에서 펌웨어를 다운로드하고 작업을 복원합니다.

이 기술을 더 자세히 살펴보겠습니다.

가장 취약한 점은 Linux 커널과 루트 파일 시스템으로 파티션을 덮어쓰는 것입니다. 이러한 구성 요소 중 하나가 손상되면 카메라는 클라우드에서 펌웨어를 다운로드할 수 없는 uboot 부트로더 이상으로 전혀 부팅되지 않습니다.

이는 업데이트 프로세스 중 언제든지 카메라에 작동하는 커널과 rootfs가 있는지 확인해야 함을 의미합니다. 가장 간단한 해결책은 플래시 메모리에 rootfs가 포함된 커널 복사본 두 개를 지속적으로 저장하고, 기본 커널이 손상된 경우 백업 복사본에서 로드하는 것인 것 같습니다.

좋은 해결책입니다. 그러나 rootfs가 있는 커널은 약 3.5MB를 차지하며 영구 백업을 위해서는 3.5MB를 할당해야 합니다. 가장 저렴한 카메라에는 백업 커널을 위한 여유 공간이 그렇게 많지 않습니다.

따라서 펌웨어 업데이트 중에 커널을 백업하기 위해 응용 프로그램 파티션을 사용합니다.
그리고 커널로 원하는 파티션을 선택하려면 두 가지 명령이 사용됩니다. bootm uboot에서 - 처음에는 메인 커널을 로드하려고 시도하고 손상된 경우에는 백업 커널을 로드합니다.

이렇게 하면 언제든지 카메라에 rootfs가 포함된 올바른 커널이 있고 펌웨어를 부팅하고 복원할 수 있습니다.

펌웨어 구축 및 배포를 위한 CI/CD 시스템

펌웨어를 빌드하기 위해 지원되는 모든 카메라 모델에 대한 펌웨어를 자동으로 빌드하는 gitlab CI를 사용하며, 펌웨어 빌드 후에는 카메라 소프트웨어 업데이트 서비스에 자동으로 배포됩니다.

서비스에서 펌웨어 업데이트는 QA 테스트 카메라로 전달되고, 모든 테스트 단계가 완료되면 사용자의 카메라로 전달됩니다.

정보 보안

오늘날 정보 보안이 카메라를 포함한 모든 IoT 장치의 가장 중요한 측면이라는 것은 비밀이 아닙니다. Mirai와 같은 봇넷은 인터넷을 돌아다니며 공급업체의 표준 펌웨어로 수백만 대의 카메라를 감염시키고 있습니다. 카메라 공급업체에 대한 모든 존경심을 가지고 표준 펌웨어에는 클라우드 작업에 필요하지 않은 많은 기능이 포함되어 있지만 봇넷이 활용하는 많은 취약점이 포함되어 있다는 점을 언급하지 않을 수 없습니다.

따라서 펌웨어에서 사용되지 않는 모든 기능이 비활성화되고 모든 tcp/udp 포트가 닫히고 펌웨어를 업데이트할 때 소프트웨어의 디지털 서명이 확인됩니다.

이 외에도 펌웨어는 정보 보안 연구소에서 정기적으로 테스트를 거칩니다.

결론

이제 우리 펌웨어는 비디오 감시 프로젝트에 적극적으로 사용됩니다. 아마도 그 중 가장 큰 것은 러시아 연방 대통령 선거 당일 투표 방송일 것입니다.
이 프로젝트에는 우리나라의 투표소에 설치된 펌웨어가 포함된 70만 대 이상의 카메라가 포함되었습니다.

여러 가지 복잡하고 어떤 곳에서는 당시에도 거의 불가능한 문제를 해결한 덕분에 우리는 물론 엔지니어로서 큰 만족을 얻었지만 이 외에도 카메라 구입 비용도 수백만 달러를 절약했습니다. 이 경우 비용 절감은 단어와 이론적 계산뿐만 아니라 이미 완료된 장비 구매 입찰 결과입니다. 따라서 클라우드 비디오 감시에 대해 이야기하면 두 가지 접근 방식이 있습니다. 낮은 수준의 전문 지식과 개발에 전략적으로 의존하여 장비 비용을 크게 절감하거나 고가의 장비를 사용하는 것입니다. 소비자 특성을 구체적으로 살펴보면 사실상 그렇지 않습니다. 비슷한 저가형과는 다릅니다.

가능한 한 빨리 통합 접근 방식을 선택하는 것이 전략적으로 중요한 이유는 무엇입니까? 플러그인을 개발할 때 개발자는 특정 기술(라이브러리, 프로토콜, 표준)에 의존합니다. 그리고 값비싼 장비에 대해서만 일련의 기술을 선택한다면, 미래에 값싼 카메라로 전환하려는 시도는 최소한 엄청나게 오랜 시간이 걸리거나 심지어 실패하고 값비싼 장비로 돌아가게 될 가능성이 높습니다.

출처 : habr.com