ONVIF
当安防视频监控从模拟时代慢慢步入网络时代,网络摄像机,网络硬盘录像机等网络安防设备被应用到实际安防项目中时,有个问题越来越被重视。
前端摄像机使用的品牌A的产品,那后端存储也必须使用品牌A的产品,因为前端摄像机和后端存储设备接入必须使用品牌A的私有协议。如果小项目,问题不大。如果比较大型的项目,涉及到的产品种类多,后期还可能扩容,那问题就大了。一是品牌A可能没有项目中需要的所有产品,二是品牌A的有些产品可能难于满足项目需求,三是品牌A的某些产品性价比可能比品牌B差……
问题的核心在于实际项目中容易被某单一品牌绑架,这是甲方不愿意看到的,长远看,对整个安防行业发展也不利,开放才是趋势。
于是,2008年,由安讯士,博世安防和索尼共同发起成立了一个全球性的开放式网络视频接口论坛,英文名称Open Network Video Interface Forum,简称ONVIF。其目的在于为安防行业提供和制定一个标准化开放接口,以实现不同厂家的网络安防产品能有效连接和互操作性。
ONVIF
愿景目标
MISSION: To provide and promote open interfaces to the security industry for
effective interoperability.
VISION: All security systems share one interface.
发展历程
成员
ONVIF的成员主要包括安防设备的生产厂家,软件开发商,系统集成商,终端用户。
ONVIF将这些成员分成了4个等级:高级会员、开发会员、用户会员、观察会员。
- 高级会员与开发会员可以参与ONVIF相关标准制定工作;
- 用户会员适合希望使用开放网络接口规范并且想对规范提出建议,但不想参与ONVIF任何工作的企业或组织;
- 观察会员适合不想参与ONVIF组织任何工作,只想享受部分会员权益如使用ONVIF规范与测试工具的企业或组织。
对应的会费标准为:高级会员$20,000/年,开发者会员USD$10,000/年,用户会员USD$2,000/年,观察者会员USD$500/年。
截止2020.8.28,ONVIF官网上显示,共有高级会员24,开发者会员13,用户会员395,观察者会员48。
ONVIF协议
ONVIF协议版本历史
- Version 20.06 – June 2020
- Version 19.12 – December 2019
- Version 19.06 – June 2019
- Version 18.12 – December 2018
- Version 18.06 – June 2018
- Version 17.12 – December 2017
- Version 17.06 – June 2017
- Version 16.12 – December 2016
- Version 16.06 – June 2016
- Version 2.61 – December 2015
- Version 2.6 – June 2015
- Version 2.5 – December 2014
- Version 2.42 – June 2014
- Version 2.41 – December 2013
- Version 2.4 – August 2013
- Version 2.3 – May 2013
- Version 2.21 – December 2012
- Version 2.2 – September 2012
- Version 2.1.1 – January 2012
- Version 2.1 – June 2011
- Version 2.0 – November 2010
- Version 1.0.2 – June 2010
- Version 1.0.1 – July 2009
- Version 1.0 – November 2008
详细内容可以访问 ONVIF Specification History 查看。
协议分类
- Profile A,主要针对门禁控制系统的配置,信息检索查询等。。
- Profile C,用于门禁控制和事件管理。
- Profile D(预发布版本),用于门禁外围设备,如读卡器,传感器,输出设备等。
- Profile G,用于边缘存储和检索。
- Profile Q,主要用于设备发现,配置,检索等功能。
- Profile S,基本的视频流和配置,PTZ控制,音频,报警等。
- Profile T,S的升级版,用于高级视频流,如H.265,HTTPS流传输,图像配置,移动报警,双向音频等。不是Profile S的替代,和Profile S配合使用。
- Profile M(预发布版本),用于智能应用元数据和分析。也就是各种智能功能。
协议中,A,C和D与访问控制系统有关,G,Q,S和T与视频系统有关。
详细的协议内容可以访问 ONVIF Profile Feature Overview v2.3 查看。
其他
相关组织及标准
PSIA
PSIA,即Physical Security Interoperability Alliance,物理安防互操作性联盟。该联盟的目标是为实体安防系统的硬件和软件平台创立一种标准化的接口,致力于使基于IP网络的不同安防系统具有兼容性。从字面看,PSIA和ONVIF目的非常一致。
虽然PSIA成立时间早于ONVIF(PSIA成立于2008年8月,ONVIF是2008年11月),但是现在市面上鲜见支持PSIA的网络安防产品。国内仅海康,大华,宇视等几个巨头的产品支持PSIA协议。甚至PSIA的曾经官网(psialliance.org)居然处于无法访问的状态。
HDCCTV
HDCCTV是曾经和ONVIF,PSIA并驾齐驱的三个安防产品的联盟之一,但是命运比PSIA还要差,官网早已废弃(此处还可以访问其官网的历史存档),安防界少有人提起。其联盟主席曾经说过的网络没有未来,同轴高清才是未来的豪言壮语,早已被碾压于历史车轮下,令人不胜嘘唏。另一个值得注意的是HDCCTV曾经吸纳大华的HDCVI技术标准作为其标准体系中的一个分支。
GB/T28181-2016
28181协议全称是公共安全视频监控联网系统信息传输、交换、控制技术要求,标准号是GB/T28181,所以简称28181协议。其功能和作用和ONVIF基本一样,实现不同厂家的安防产品能互联互通。已经有了ONVIF,国内还大力推广28181的目的就是希望能实现国内自主可控,特别是在公共安全领域。开放是趋势,开放以后就又开始封闭了,如此循环往复。
国内公共安全领域地方标准
在GB/T28181协议之前,国内公共安全领域还有一些地方标准,比如上海的DB31,浙江DB33等等。28181协议出台以后,这些地方标准基本就不用了。
ONVIF工具
- 官方的ONVIF工具
ONVIF官方有提供一些onvif协议的测试工具,以验证产品是否符合标准。早期的ONVIF_Device_Test_Tool-V14-06和ONVIF_Device_Test_Tool_V12_06,虽然版本比较旧了,但是用来测试产品是否符合ONVIF基本要求还是可以的。ONVIF Test Tool的使用方法。
而最新的ONVIF官方工具只面向会员提供了。
另外ONVIF官方提供了验证产品是否符合ONVIF的测试要求,可以参考。 - 第三方ONVIF工具
ONVIF官网上有列出一些第三方的ONVIF测试工具和软件,可以参考使用。
ODM(Onvif Device Manager)是一款流传使用很广的第三方ONVIF验证测试工具。可以搜索出支持ONVIF的网络设备,显示其相应的信息,还可以显示设备的rtsp地址,支持PTZ控制等,功能很强大。ODM英文说明及下载介绍可以参见此处,中文版的简介可以参见我曾经拟写过的文章:第三方的ONVIF协议测试工具:ONVIF Device Manager。 - 手机
ONVIF手机端的app除了上面介绍的ONVIF官网列出的一些第三方ONVIF测试工具和软件里的部分外,另一个值得推荐的就是Onvifer。Onvifer手机客户端支持对onvif设备的搜索,添加,实时监控,PTZ控制等功能。具体也可以看我曾经写过的介绍文章:手机版onvif测试工具。
支持二次开发的其他协议
实际项目中,我们除了使用ONVIF,私有协议等进行不同产品之间的对接外,还可以使用产品的SDK,各种接口等进行二次开发。常见的进行二次开发对接的协议还有:
- SDK
Software Develop Kits,即软件开发工具包。是为硬件产品进行软件对接提供的特定的开发工具的集合,包括软件包、软件框架、硬件平台、操作系统等。 - CGI
CGI(Common Gateway Interface)公共网关接口,是外部扩展应用程序与 Web 服务器交互的一个标准接口。服务器端与客户端进行交互的常见方式多,CGI 技术就是其中之一。根据CGI标准,编写外部扩展应用程序,可以对客户端浏览器输入的数据进行处理,完成客户端与服务器的交互操作。简单的说,通过提供的CGI接口,前端安防设备能处理客户端浏览器输入的数据。 -
ISAPI
ISAPI(Internet Server Application Programming Interface)作为一种可用来替代CGI的方法,是由微软和Process软件公司联合提出的Web服务器上的API标准。ISAPI与Web服务器结合紧密,功能强大,能够获得大量的信息,因此利用ISAPI可以开发出灵活高效的Web服务器增强程序。
ISAPI程序和CGI程序完成类似的功能,但是实现方法不同。 -
ISAPI程序以DLL形式被Web服务器加载到自己的进程空间中,因此和服务器共用同一个地址空间,且在没有客户请求时可以将其从内存中卸载;而对客户端发来的每个对CGI程序的请求则需要服务器为它单独启动一个进程,这需要耗费大量的时间和内存。当并发的请求数目很大时,使用CGI在效率上不如ISAPI。
- CGI程序通过环境块和标准输入输出与Web服务器进行通信,而ISAPI程序与服务器结合得更为紧密,与服务器共享同一个进程上下文,主要通过一个参数块与服务器进行交互,可以从服务器那里获得关于当前HTTP连接的大量信息。