平安城市视频监控的综合调度平台系统设计.docx

平安城市视频监控的综合调度平台系统设计.docx

《平安城市视频监控的综合调度平台系统设计.docx》由会员分享，可在线阅读，更多相关《平安城市视频监控的综合调度平台系统设计.docx（27页珍藏版）》请在冰豆网上搜索。

平安城市视频监控的综合调度平台系统设计

摘要

随着城市经济的高速发展，城市治安管理面临的压力也越来越大，传统的以人力防范和事后处理为主的公安管理模式已经开始制约城市治安管理水平的进一步提高。

城市公安管理部门迫切需要采取更多的技术防犯手段来提高管理的范围和效率，弥补人力管理资源缺乏和效率低下的缺点。

随着城市宽带网覆盖范围的扩大和使用费用的降低，城市公安管理部门提出了逐步整合完善公安部门原有的各种监控系统，构建一个城市统一的一体化综合监控管理平台的需求。

本系统是一套用于“平安城市”视频监控的综合调度平台，目标是将“平安城市”中所有的视频矩阵——无论是大型矩阵，还是社区和单位的小型矩阵——全部统合到一个平台上使用和管理，使得用户能够使用一个键盘将城市中任何一台摄像机的图像显示在任何一块监控屏幕上。

本系统率先将先进的物联网技术应用于“平安城市”视频监控领域。

通过将城市中所有现存的摄像机进行统一使用和管理，使得每一个角落都能被实时监控到，在预防、发现、控制和打击违法犯罪、提供破案线索、固定违法犯罪证据等方面发挥着人防、物防所不可替代的重要作用，真正实现“平安城市”。

关键词：

“平安城市”；物联网；视频监控系统

Abstract

Withtherapiddevelopmentoftheurbaneconomy,publicsecurityadministrationfacesgrowingpressure.Traditionalmanagementmodeofpublicsecurity,whichemphasisonpreventionandpost-processing,hasbegunrestrictingtofurtherimprovethemanagementlevelofpublicsecurity.Publicsecurityadministrationisurgentlyneededtoimprovethescopeandefficiencyofmanagement.Theywanttotakemoreguardagainsttechnicalmeansandmakesupforthedisadvantagesofmanpowerresourcesandinefficiency.

Withtheexpansionofurbanbroadbandnetworkcoverageandlowercosts,urbanpublicsecurityadministrationproposestobuildacityunifiedintegratedmanagementplatformneeds.

ThispaperimplementsavideomonitorplatformfortheSAFECITYTprogram.Theplatformcollectstheentirevideomatrix--regardlessoflargematrix,alsoiscommunityandunitsofsmallmatrix.Throughthisplatform,userscanmanageallkindsofpublicsecurityvideosbyusingonekeyboard.

AsfarasIknow,itisthefirsttimetoapply InternetofThingstechnologiesintheareaofpublicsecurityvideomonitorsystem.Byunifiedalltheexistingcamerasinuseandmanagement,everycornercanbemonitoredinrealtime.Itmakestheplatformplayinganimportantroleinpreventing,detecting,controllingandcombatingcrime,providingaclue,fixingplaysdefense,suchascriminalevidence,whichmakesimportantcontributionstotheSAFECITYprogram.

Keywords：

SAFECITYprogram；InternetofThings；videomonitorsystem

目录  

1系统概述及软件开发背景技术

1.1系统概述

本系统是一套用于“平安城市”视频监控的综合调度平台，目标是将“平安城市”中所有的视频矩阵——无论是大型矩阵，还是社区和单位的小型矩阵——全部统合到一个平台上使用和管理，使得用户能够使用一个键盘将城市中任何一台摄像机的图像显示在任何一块监控屏幕上。

本产品率先将先进的物联网技术应用于“平安城市”视频监控领域，在国内尚属首创。

本系统可以将城市中所有现存的摄像机进行统一使用和管理，使得每一个角落都能被实时监控到，在预防、发现、控制和打击违法犯罪、提供破案线索、固定违法犯罪证据等方面发挥着人防、物防所不可替代的重要作用，真正实现“平安城市”。

图1.1整体系统结构图

图1.2Pad键盘软件系统结构图

整个系统分为传输服务层、服务层和应用层三个层次。

传输服务层用于与服务器之间传递异步消息。

服务层使用底层的异步传输服务和本地数据库操作API，将业务逻辑封装成了KeyPress传输服务、认证授权服务、数据服务和Log服务，为应用层提供服务API。

应用层主要包含各项UI，用于捕获用户输入和显示系统内部状态。

1.2软件开发背景技术

1.2.1可配置的矩阵接入技术

传统的矩阵接入方案，需要向程序代码中添加接入矩阵的对应的命令解析代码，这种方案具有以下两个弊端：

可扩展性差。

不同品牌的矩阵通常具有不同的通信协议，与配套的控制键盘相对应。

由于历史原因，监控网络中存在着大量不同厂家的矩阵和键盘，为了实现这些监控网络中视频的调度，传统方案中必须包含处理所有通信协议的程序代码。

当新的矩阵或者键盘接入网络时，就需要在原有代码中增加所需的处理代码，修改原有程序，扩展性差。

低鲁棒性。

由于每一次新品牌的矩阵或者键盘接入网络后，都需要重新修改程序处理代码，在一个大规模的监控网络中，这种修改为程序的安全运行带来了极大的风险，在某些情况下，很可能造成核心程序运行错误，系统无法正常工作。

可配置的矩阵接入技术，将软件系统的扩展接口留在了矩阵端。

当新矩阵接入监控系统的时候，通过添加新矩阵对应的配置文件，极大的方便了系统的扩展。

统的时候，通过添加新矩阵对应的配置文件，极大的方便了系统的扩展。

1.2.2自主研发的多协议命令路由技术

在大型的监控系统中，由于存在不同的矩阵，并且不同矩阵之间的通信协议不同，系统中的摄像头通过矩阵进行联网时，控制键盘发出的命令必须要正确的路由到目标摄像头。

大型监控网络中，要求每个键盘要控制任何目标摄像头，这带来两个问题

1.控制键盘发出的命令必须能够被目标摄像头所在的矩阵正确识别

2.控制键盘发出的命令必须能够正确路由到目标摄像头所在矩阵

多协议命令路由技术，通过将各种控制键盘的命令转换为系统设定的统一的控制命令集，并且根据控制命令中目标摄像头所在矩阵，将控制命令传送至目标矩阵。

多协议命令路由技术的使用，极大提升了系统的兼容性，有效地保护了历史投资。

2系统需求分析

2.1功能性需求

系统的主要功能是实现视频监视人员使用键盘将任意摄像机的视频流显示在任意显示器上，并且能够控制摄像机的转动。

2.1.1切换视频

操作人员可以按照2.1小节描述的规则和优先级顺序，通过一个键盘，切换显示在任何显示器上的视频源。

用户在键盘上的一般性操作是：

1.在键盘上输入任意机顶盒编号；

2.在键盘上输入任意摄像机编号；

3.在键盘上确认。

用户的输入不仅限于这种模式，键盘上的前后切换键也可以被用于切换视频。

系统响应用户操作，按照约定的“视频切换的优先级规则”进行视频切换；系统通过处理和转发键盘命令到合适的矩阵来完成真正的切换操作。

系统将操作的执行结果（包括矩阵的执行结果）返回给键盘。

2.1.2控制摄像机

操作人员可以通过键盘上的摇杆控制当前接入的摄像机，包括云台转动、摄像机变焦、光圈、聚焦调整。

当前接入的摄像机编号为键盘最后输入的摄像机编号，或者为当前接入的机顶盒对应的摄像机编号。

当两者都不存在时，系统对键盘返回错误码。

操作人员移动摇杆时，键盘将发出一系列命令。

系统将对这一系列命令进行处理和响应。

系统通过处理和转发键盘命令到合适的矩阵完成真正的控制操作。

2.1.3后台管理

后台管理功能包括1）系统管理员用户登陆和密码修改、2）设备管理，包括设备配置信息和状态的查看，以及增删改设备配置信息。

设备包括摄像机、摄像机矩阵、键盘、机顶盒。

各设备的详细配置字段请参看“数据库设计”章节。

系统管理员可配置系统中键盘与矩阵之间的应用层协议，以支持多种键盘。

系统管理员通过服务器提供的Web页面完成配置工作。

2.1.4日志系统

每一次键盘操作都应该被详细记录下来，包括时间戳、原始命令、处理后的命令、键盘信息、矩阵信息、摄像机信息、机顶盒信息。

每一次登陆和对配置项的增删改操作都需要被记录下来，包括时间戳、用户信息、配置项目名称、配置项目的原值和新值。

系统管理员可以通过服务器提供的Web界面查看日志。

2.2非功能性需求

2.2.1可靠性

作为系统的关键节点，系统监控服务器需要7*24小时在线。

2.2.2实时性

键盘操作应该实时得到反馈结果，因此要求系统能够快速转发键盘命令，尽量减少延迟。

2.2.3鲁棒性

操作人员的误操作应该被系统识别并且避免导致错误后果。

3系统设计

3.1软件的整体发明内容

我们通过该软件在AndroidPad上实现视频监控软键盘，同时完成更多人性化和安全功能：

1.实现视频监控软键盘；

2.更多的人性化功能；

3.更多更好的权限控制功能；

4.功能个性化定制。

3.2软件的功能模块及意外应对机制

3.2.1服务器

服务器端控制程序的主要功能是搭建键盘与矩阵之间的信息交互平台，同时要求可以兼容接入不同类型的键盘和矩阵。

系统采用Proxy模型为主体架构，即每个键盘和矩阵都通过一个代理（KeyboardProxy和MatrixProxy）实体接入一个统一的信息交换结构（SwitchFabric）。

代理实体在软件上抹平了不同种键盘及矩阵的差异；信息交换结构则描述了网络的结构，实现了键盘与矩阵间的信息交换。

图3–图3.1服务器端系统模型

从上图中可以看出，系统模型由三部分构成：

第一部分：

按键解码过程，负责将收到的字节流识别为一个一个KeyPress，即一个一个的按键动作，然后将这些按键动作组合翻译成一种标准描述。

服务器程序从键盘收到的信息是断续的字节流，按键解码过程的第一步是将这些字节流分割成一个一个有意义的按键动作，即KeyPress。

KeyPress指键盘的一次按键动作，例如“按键1被按一次”，对应类KeyPress。

需要区分的是，键盘上的每一个键称之为KeyCode，对应类KeyCode；KeyCode代表键本身，是固定不变的；KeyPress是一次动作，它在键盘的按键被按下后产生，是动态产生的。

识别出单独一个KeyPress在很多时候并不能表示出用户的完整意图，例如，用户需要连续按“screen”，一系列数字键，最后按一个“return”键之后，才能表示“选中某个屏幕（或机顶盒）”。

因此，我们需要定义一个结构来表示用户的每个完整的意图。

这个结构就是Command。

Command是服务器程序内部表示用户的一个完整意图的结构。

它与任何特定类型的键盘或特定类型的矩阵都无关，是一套通用的键盘与矩阵间的标准协议。

任何一种特定的键盘或矩阵都可以将自己的特定协议映射到这个协议上来；它也可以转化为任何一种特定键盘和矩阵的之间的协议。

按键解码过程第二步就是将一个或者多个KeyPress翻译成标准结构来表示完整的用户意图，即Command。

这一部分实际上处理的是“键盘输入什么”，做法是：

无论键盘输入什么，都将被翻译成一种标准格式，即Command。

这样，任何键盘都可以被接入系统中，而不影响其它部分。

第二部分：

内部处理过程。

用户意图在被识别成Command之后，接下来是如何“投递”用户意图的过程。

图3.2优先级规则判定流程实际上是用户意图的“投递”流程

这一部分处理的是“如何将键盘的命令送到合适的矩阵和机顶盒”，实际上处理的是系统内各组件的连接方式。

当然，更加复杂的逻辑也可以在这里实现。

需要注意的是，由于这一过程处于纯粹的Command环境中，与键盘和矩阵的硬件细节完全隔离开，仅仅需要考虑设备之间的逻辑连接关系即可。

第三部分：

信号重新编码过程。

确定用户意图（即Command）的投递方向之后，需要将Command翻译成目标设备（即特定类型的矩阵）可接受的信号模式，序列化成字节流发送到目标设备。

这一部分处理的是“矩阵能接受的命令格式”，做法是：

将标准格式翻译成Matrix要求的特定格式。

这样，任何可控装置都可以被接入系统中，而不影响其他部分。

最后，矩阵返回的ACK信号的处理模型同KeyPress模型是一样的，只是信号传递的方向不同。

综合以上所述，服务器端的控制程序整体实现如下：

图5–图3.3服务器端控制程序的实现

图3.4服务器模型：

数据处理流程

连接器确定了Pad如何连接到主控服务器。

目前通过两种方式：

蓝牙和Wifi。

蓝牙方式实际上是连接到附加电路板的蓝牙上，附加电路板后面有一个透明通道可以让Pad和服务器直接通信，此时Pad就像直接连接到了服务器上一样。

Wifi方式则是直接通过TCP/IP连接到服务器上。

连接器的主要工作就是将一个字节流发送到服务器的对等连接器上。

这些字节流（byte[]）将被直接交给连接器后端的Message系统，由MessageCodec进行编解码，获得具体的Message。

在连接断开时，连接器将试图自动重新建立连接。

3.2.2Message消息传递系统

系统的消息传递系统由如下三部分构成：

1.Message基类；

2.MessageCodec，Message编解码器；

3.Message系统的使用者（即系统中其它模块）自定义的Message子类。

Message消息系统的设计目标是：

1.允许用户自定义任意形式的Message子类，能够无缝接入Messag基本系统；

2.允许用户自定义Message子类的编解码过程，该过程能够无缝接入Messag基本系统；

3.用户仅仅需要定义以上两项，即可直接实现自定Message子类的编解码——即从byte[]组装出Message子类对象，将Message子类对象转换成byte[]。

Message是整个Message系统的基类，所有需要Codec编解码的类都必须继承自它：

1.Message基类中定义了Message的基本结构，同时实现了该基础结构的编解码方法；

2.Message基类中最重要的方法是setPayload和getPayload方法，子类必须实现这两个函数，以实现子类本身的解码和编码过程——实际上，Message基类在完成自身基础结构的编解码之后，将调用子类的setPayload和getPayload方法来编解码其自身的payload域。

编解码器用于1）将Message编码成字节流，2）从连接器接收到的字节流中解码出Message。

字节流的格式采用:

{前导字符}{长度}{序列号}{回复序列号}{类型}{负载}{校验码}{结尾字符}

其中，长度定义为去除前导和结尾字符之外的byte数。

Message包含一个虚的getType和getPayload方法，分别获得类型和负载的字节数组，子类需要实现这两个函数。

getPayload方法用于对Message子类对象的payload进行编码。

如果异步API没有设置Message的序列号，Codec会自动设置。

解码时，Codec使用PacketSlicer从字节流中切出合法的包，然后识别其中的序列号和类型。

Codec需要依据类型从MessageCodec类的Message子类注册信息中获得一个Message实例（采用克隆模式），然后调用其setPayload方法来解析其负载内容，并获得真正的Message子类。

MessageCodec使用Register和Clone模式构建，这样可以使得其可以直接从输入的byte[]中解码出Message的子类对象，而不仅仅是Message这个基类。

其实现方法是：

1.外部组件需要向MessageCodec注册其所实现的Message子类类型（即其type字段），同时注册一个子类对象；这些注册信息全局可用；所有的Message子类的注册代码位于cybertrue-commons-base工程的KeyboardCodec4Message函数中。

2.MessageCodec解码时，将根据输入的byte[]中解出来的type信息从子类注册表中查找对应的Message子类对象；一旦查到，则克隆该对象，作为解码出的返回对象；如果查不到注册信息，则直接返回新建的Message对象；

3.在注册信息中查到Message子类对象之后，MessageCodec的解码过程将把Message的payload字节数组交由该子类对象的setPayload方法来进行进一步的解码操作。

这样，MessageCodec能够完全解码输入的byte[]：

获得准确的Message子类对象，同时解码出Message子类中所有的成员变量。

Message子类对象的编码和解码过程可以使用一个叫做Transmitter的工具类轻松实现，该类封装了对基础数据类型的编码（transimit）和解码（parse）操作。

这样，Message子类的编解码操作实际上变成了在setPayload和getPaylaod函数中简单使用Transmitter工具针对每个成员变量的编解码过程。

需要注意的是，编解码操作必须一一对应，以保证编解码的正确性。

对等体属于基础结构，服务器端的对等体与Pad端的是一样的。

实现方式是：

1.连接器发现连接断开时，触发连接断开事件，这个事件将调用”destroyed”函数；

2.重连机制捕获这一事件，启动一个Timer，不断尝试重新连到服务器（蓝牙模式下是附加电路板）上；

3.一旦重新建立了连接，连接器将触发连接建立事件；

4.重连机制捕获这一事件，停止重连Timer。

3.2.3异步传输API

异步传输API用于在Pad与服务器之间异步地传输Message——即双方在发送Message之后可以直接返回，等待回复Message或者超时。

通过异步API发送Message时，它会确定该Message是否需要回复——当Message需要回复时，它需要指定一个MessageReceiveHandler来等待回复Message；那么当Message指定了自身的MessageReceiveHandler时，我们认为该Message是需要回复的。

如果Message需要回复，那么异步API会记录下该Message，并且等待收到“回复序列号”与该Message相同的Message。

一旦收到，那么它会将两个Message通过先前指定的MessageReceiveHandler向外部组件汇报。

如果长时间收不到，则发出超时消息给该MessageReceiveHandler。

异步API需要维护Message的序列号。

一般而言，异步API会自动按顺序增加自己所发送的Message的序列号。

如果上层需要针对某个收到的Message作出回复，则在调用异步API发送回复Message时，需要指定该回复Message是对哪个已经收到的Message的回复，异步API据此维护回复Message的“回复序列号”，即将回复Message的回复序列号设定为收到的Message的序列号。

当异步传输API接收到Message时，为了寻找合适的接收者，它将：

1.依据“回复序列号”查找注册的Message，据此查到ResponseReceiver，传递Message；

2.依据Message的类型，查找注册的MessageReceiver列表，传递Message；

3.依据Message的类型，查找注册的MessageSniffer列表，传递Message。

无法确定Message的接收者时，丢弃该Message。

Pad键盘端如果在大量数据突发时发送速率过快，可能：

1.对蓝牙造成压力，导致数据丢失；

2.对服务器造成压力，导致响应变慢。

因此，我们需要在Pad键盘端建立流控机制，抹平突发的数据流。

Zc-connector-base包中的FlowControlledXmitter和CreditBasedFlowController建立了一种基于漏桶的流控机制：

1.每隔一定时间FlowController产生一个Credit；

2.FlowController维护一个Credit队列，存储产生的Credit；

3.Xmitter需要发送数据时，需要先向FlowController申请一个Credit，即获得允许；

4.如果FlowController的允许Xmitter发送（即Credit队列不为空），那么Xmitter将立即将数据发送出去，并且消耗这一个Credit（即FlowController丢弃一个Credit）；

5.如果FlowController不允许Xmitter发送（即Credit队列为空），那么Xmitter将数据缓存起来，等待FlowController通知其发送数据；

6.FlowController的Credit队列中每次添加第一个Credit时（即队列本来为空，时间间隔到了时产生了一个新的Credit），会触发“允许发送”事件，这个事件将通知Xmitter启动数据发送流程。

所有的服务层都提供：

1.保存自身的状态，并且提供对状态的查询；

2.服务动作；

3.通知。

Pad需要向服务器证实自己的合法性，并且依据自己的身份获得相应的数据信息。

认证的目标应该是服务器端的连接端子，即服务器要附加一个账号信息到服务器端的一个连接上，通过该连接发起的其它请求都具有该账号所具有的权限。

登陆/认证/授权机制在连接建立后开始启动。

当Pad无法确定自己的身份时，它会弹出一个事件，要求用户输入账号和密码。

登陆成功后，Pad下次启动时自动会使用原有的账号信息。

可以在Pad的设置栏中清除记录的账号信息。

认证授权服务提供：

1.对Pad键盘的认证，即login函数；包括一个autoLogin函数，用于自动登录；

2.认证完成/认证超时事件通知；

3.对当前登陆状态的查询服务，即认证授权服务的状态查询，状态包括服务器端临时分配的Keyboard信息。

如果登录失败，则进不去主界面。

实际上，Pad登录的主要目的是向服务