-平安城市-视频监控毕业设计.doc

摘要
随着城市经济的高速发展，城市治安管理面临的压力也越来越大，传统的以人力防范和事后处理为主的公安管理模式已经开始制约城市治安管理水平的进一步提高。城市公安管理部门迫切需要采取更多的技术防犯手段来提高管理的范围和效率，弥补人力管理资源缺乏和效率低下的缺点。
随着城市宽带网覆盖范围的扩大和使用费用的降低，城市公安管理部门提出了逐步整合完善公安部门原有的各种监控系统，构建一个城市统一的一体化综合监控管理平台的需求。
本系统是一套用于“平安城市”视频监控的综合调度平台，目标是将“平安城市”中所有的视频矩阵——无论是大型矩阵，还是社区和单位的小型矩阵——全部统合到一个平台上使用和管理，使得用户能够使用一个键盘将城市中任何一台摄像机的图像显示在任何一块监控屏幕上。
本系统率先将先进的物联网技术应用于“平安城市”视频监控领域。通过将城市中所有现存的摄像机进行统一使用和管理，使得每一个角落都能被实时监控到，在预防、发现、控制和打击违法犯罪、提供破案线索、固定违法犯罪证据等方面发挥着人防、物防所不可替代的重要作用，真正实现“平安城市”。
关键词：“平安城市”；物联网；视频监控系统
Abstract
With the rapid development of the urban economy, public security administration faces growing pressure. Traditional management mode of public security, which emphasis on prevention and post-processing, has begun restricting to further improve the management level of public security. Public security administration is urgently needed to improve the scope and efficiency of management. They want to take more guard against technical means and makes up for the disadvantages of manpower resources and inefficiency.
With the expansion of urban broadband network coverage and lower costs, urban public security administration proposes to build a city unified integrated management platform needs.
This paper implements a video monitor platform for the SAFE CITYT program. The platform collects the entire video matrix--regardless of large matrix, also is community and units of small matrix. Through this platform, users can manage all kinds of public security videos by using one keyboard.
As far as I know, it is the first time to apply Internet of Things technologies in the area of public security video monitor system. By unified all the existing cameras in use and management, every corner can be monitored in real time. It makes the platform playing an important role in preventing, detecting, controlling and combating crime, providing a clue, fixing plays defense, such as criminal evidence, which makes important contributions to the SAFE CITY program.
Keywords：SAFE CITY program；Internet of Things；video monitor system

目 录  
1系统概述及软件开发背景技术 1
1.1系统概述 1
1.2软件开发背景技术 2
1.2.1 可配置的矩阵接入技术 2
1.2.2 自主研发的多协议命令路由技术 3
2 系统需求分析 4
2.1功能性需求 4
2.1.1切换视频 4
2.1.2 控制摄像机 4
2.1.3 后台管理 4
2.1.4日志系统 5
2.2非功能性需求 5
2.2.1可靠性 5
2.2.2实时性 5
2.2.3鲁棒性 5
3 系统设计 6
3.1 软件的整体发明内容 6
3.2软件的功能模块及意外应对机制 6
3.2.1服务器 6
3.2.2Message消息传递系统 9
3.2.3异步传输API 10
3.3软件的具体实施方式 13
3.3.1应用系统协调器 13
3.3.2登录界面 14
3.3.3软键盘 15
3.3.4 摄像机阵列 16
3.3.5 收藏组 18
3.3.6 巡航 21
3.3.7 配置 22
结论 23
参考文献 24
致谢 25

1 系统概述及软件开发背景技术
1.1系统概述
本系统是一套用于“平安城市”视频监控的综合调度平台，目标是将“平安城市”中所有的视频矩阵——无论是大型矩阵，还是社区和单位的小型矩阵——全部统合到一个平台上使用和管理，使得用户能够使用一个键盘将城市中任何一台摄像机的图像显示在任何一块监控屏幕上。
本产品率先将先进的物联网技术应用于“平安城市”视频监控领域，在国内尚属首创。本系统可以将城市中所有现存的摄像机进行统一使用和管理，使得每一个角落都能被实时监控到，在预防、发现、控制和打击违法犯罪、提供破案线索、固定违法犯罪证据等方面发挥着人防、物防所不可替代的重要作用，真正实现“平安城市”。

图1.1 整体系统结构图

图1.2 Pad键盘软件系统结构图
整个系统分为传输服务层、服务层和应用层三个层次。传输服务层用于与服务器之间传递异步消息。服务层使用底层的异步传输服务和本地数据库操作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 软件的整体发明内容
我们通过该软件在Android Pad上实现视频监控软键盘，同时完成更多人性化和安全功能：
1. 实现视频监控软键盘；
2. 更多的人性化功能；
3. 更多更好的权限控制功能；
4. 功能个性化定制。
3.2软件的功能模块及意外应对机制
3.2.1服务器
服务器端控制程序的主要功能是搭建键盘与矩阵之间的信息交互平台，同时要求可以兼容接入不同类型的键盘和矩阵。
系统采用Proxy模型为主体架构，即每个键盘和矩阵都通过一个代理(KeyboardProxy和MatrixProxy)实体接入一个统一的信息交换结构(SwitchFabric)。代理实体在软件上抹平了不同种键盘及矩阵的差异；信息交换结构则描述了网络的结构，实现了键盘与矩阵间的信息交换。
图3 – 图3.1 服务器端系统模型
从上图中可以看出，系统模型由三部分构成：
第一部分：按键解码过程，负责将收到的字节流识别为一个一个KeyPress，即一个一个的按键动作，然后将这些按键动作组合翻译成一种标准描述。
服务器程序从键盘收到的信息是断续的字节流，按键解码过程的第一步是将这些字节流分割成一个一个有意义的按键动作，即KeyPress。
KeyPress指键盘的一次按键动作，例如“按键1被按一次”，对应类KeyPress。需要区分的是，键盘上的每一个键称之为Key Code，对应类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登录的主要目的是向服务器请求一个具有对应权限的临时Keyboard。服务器端的KeyboardUser对象(即存储Pad用户信息的类)附加有一个Keyboard对象，该Keyboard对象具有已经定义好的设备权限。
当多个Pad使用同一个用户名和密码登陆时，服务器将为每个Pad分配一个具有同样权限的临时Keyboard。在服务器端，采用Clone模式实现：每次接纳一个Pad，则克隆一个对应的KeyboardUser.keyboard，并且为它分配一个新的keybaord.no，同时注册到系统的数据服务和设备权限管理服务中，使得它可以像普通的键盘一样被系统其它部分接纳。
数据服务向上层提供对本地数据库的CRUD的操作，尤其是对同步自服务器的数据进行查询服务：
1. 提供对本地数据库的CRUD接口；
2. 提供本地数据库更新事件通知；
3. 提供对本地数据状态(包括版本)的查询操作。
KeyPress传输服务顾名思义负责传输KeyPress，包括：
1. 对KeyPress编码，并且通过异步传输API将KeyPress发送到服务器；
2. 对KeyPressAck解码，并且将之广播给监听者。
本地数据管理主要是将服务器上的数据同步到本地数据库中，供上层应用程序使用。
a)数据同步的内容
包括：
1. 授权用户所能够切换或控制的Camera、Matrix、Channel和STB信息；
2. 系统配置的收藏组信息，例如每个派出所就在一个系统收藏组内。

b)数据同步的时机
服务器将维护系统内部数据的版本号，如果Pad上的数据库版本号与之不相等，则将触发自动数据同步：
Pad键盘使用一个单独的Meta数据库来存储一些信息：
上次登录使用的username和password——如果用户上次选择了“自动登录”，那么下次启动时将使用这些账号信息自动登录；
每个账号都对应一个设备数据库，以及该数据库的数据版本号；
登陆后，加载该username对应的设备数据库，并更新该数据库。这样，一个Pad上可以存储多个账号的设备数据信息，当用户使用不同的账号登陆时，不会每次都去重新下载数据库；
Pad键盘启动时，认证完成之后，将向服务器询问最新数据版本号；
如果版本号低于服务器，则删除本地已经加载的数据库，重新从服务器加载，同时将其信息存入Meta数据库中备用。
c)对等体
非对称体，服务器端的对等体需要实现完全不同的功能。
服务器需要依据Pad键盘的认证信息确定发给Pad键盘什么样的数据。
当服务器上的数据发生版本变化时，将主动要求Pad键盘更新本地数据。
服务器发送数据时，数据量比较多，因此需要在附加电路板的转发通道上控制数据的完整性，防止数据丢失。
Log服务用于：
1. 提供记录本地操作日志的接口；
2. 统计本地日志；
3. 向外提供本地日志统计信息。
3.3软件的具体实施方式
3.3.1应用系统协调器
协调器包括至少2部分功能：
1. 保存和维护应用系统的公共内部状态，该项内部状态装载了对整个Pad键盘软件系统的描述，这些状态在不同的应用之间共享，至少包括：
a. 当前的M、C和CH；
2. 协调各个应用之间的相互调用、画面切换和配合；
3. 处理Pad的硬按键，配置、回退。
目前，系统内部状态由KeyboardAuthService的内部变量Keyboard代为存储，在整个系统范围内都可以随时访问内部状态。
3.3.2登录界面

图3.5 登陆界面
a. 提供类似QQ的登陆界面，其中包括“记住用户名和密码”以及“自动登录”多选框，用户选定后，将本次本次登陆使用的用户名和密码存入数据库中，以便下次自动登录时使用；
b. 如果只选择“记住用户名和密码”，那么在登陆界面，用户可在username选择下拉框中选择使用哪个帐号，而不需要每次都重新输入；
c. 一个Pad上可能有不同的用户使用不同的账号登陆，最后一个选择了“自动登录”的账号将自动登录；
d. 对用户名输入框的修改会消除密码框中的内容;
e. 登陆界面，正在从服务器取数据时，显示“正在从服务器加载用户数据”；
f. 登录界面，如果发现连接没有建立，应该使用popup提示框提示用户，“无法连接到服务器，请稍后再尝试登录”。
g.登录界面，点击“登录”后，隐藏系统软键盘。
3.3.3软键盘

图3.6 键盘UI
1. 每一个按键都将触发相应的事件，这些事件的处理函数需要：
a. 向认证授权服务询问确认Pad键盘已经登录并且仍然有效；
b. 将按键名传递给KeyPress传输服务，触发KeyPress传输过程；
c. 更新内部状态。
2.F1~F3按钮用于功能自定义，将为现有的一些功能生成快捷入口，用户可以通过F1~F3键进入这些快捷入口。
内部状态：
1. UI显示的的M、C和CH；
2. 摇杆快慢模式；
接收的事件包括：
1. 收到KeyPressAck；
2. 收到应用系统公共内部状态更新通知；
3. 画面切换通知；
3.3.4 摄像机阵列

图3.7 摄像机阵列
1. C+/C-和P+/P-处理方式与软键盘按键处理方式相同；
2. 摄像机编号按钮：
a. 能够显示在这里的摄像机编号都是已经经过认证的，不需要再进行权限验证；
b. 点击时，自动取当前M值，同时从Button的关联数据中取出C值，尝试切换；
c. 在尝试切换过程中，当前的Camera按钮变成背景浅橘红色；上一个Camera，即当前正在显示的Camera按钮颜色不变；
d. 如果切换成功，背景变成橘红色，上一个Camera变成普通灰色；再次点击时，出现快捷云台控制面板；
e. 如果切换失败，变回普通灰色；
f. 长按摄像机按钮，弹出菜单，包括“添加到组”，如下图；

图3.8 摄像机阵列添加到组
g. 摄像机阵列添加到收藏时，字体变大；
h. 添加到组菜单项中包括用户自定义的组，用户可选择一个加入。
3. 右侧的快捷过滤按钮：
a. 点击时，在中上部的快速查找栏中填入相应的数字，同时过滤摄像机按钮；
b. 点击高清/标清/全部时，将两个条件叠加起来过滤；
c. 中部快速查找栏右侧的X能够清空先前输入的快速过滤条件。
4. 摄像机阵列界面上的每个按钮，除了其编号之外，还需要显示其他信息，获得这些信息的方法是：首先尝试获得camera.name，如果为空则尝试获得camera.location,如果还是为空则尝试获得 camera.owner。
5. 摄像机阵列界面侧面“高清”和“标清”过滤按钮功能。这两个按钮所代表的过滤条件和下面的数字所代表的过滤条件是叠加的，即如果按“高清”和“98”，显示的是包含98数字的所有高清摄像机。另外，“高清”和“标清”按钮按下去之后不会立即弹起来，而是变成橘色，表示该项过滤条件是有效的；再次按下时恢复成黑色，表示该项过滤条件无效。“高清”和“标清”两个同时只有一个能够被按下，即当一个被按时，另一个需要马上弹起来恢复到黑色，并且清除其过滤条件。
6. 摄像机阵列页面，点击摄像机按钮向服务器发送切换消息，如果服务器返回消息表明没有正确切换（即返回的camera不是刚才点击的camera），那么清除刚才点击的摄像机按钮，高亮显示返回的camera的那个按钮。
内部状态：
1. UI显示的的当前的M、C和CH；
2. 摇杆快慢模式；
3. 目前选中的摄像机按钮；
4. 当前的快速查找栏状态——高清/标清/全部，过滤数字；
5. 当前显示的组或者预案。
接收的事件包括：
1. 收到KeyPressAck；
2. 收到应用系统公共内部状态更新通知；
3. 画面切换通知；
3.3.5 收藏组
收藏组分为两类：
1. CameraGroup，是一个Camera集；
2. ChannelGroup，是一个Channel集。
同时，收藏组的来源也分为两部分：
1. 来自于服务器的账户公用的组，其边框和文字是蓝色；
2. 用户自定义的私有的组。
当Pad键盘加载这收藏组时，需要：
1. 从本地数据库中读取用户自定义的组；
2. 从服务器获取公用收藏组。
公用收藏组并非全部都是公用的，不同账号能够访问的收藏组不一样，这个权限设置应当在KeyboardUser即账号中存储。

图3.9 组阵列
1. C+/C-和P+/P-处理方式与软键盘按键处理方式相同；
2. 组按钮：
a. 显示组名和组内摄像机的概况；
b. 点击时，切换到摄像机阵列；
c. 选中的收藏组，背景橘红色；
d. 长按2秒，弹出组编辑菜单;
e. 空的收藏组长按不出现任何修改框；
f. 系统组为空时，不再显示在屏幕上。
3. 组添加按钮：
a. 点击时，弹出空白组添加类型如下图

图3.10 添加组
b.选择组添加类型后可根据所选类型添加摄像机或频道如下图

图3.11 组编辑弹出菜单
1. UI显示的的当前的M、C和CH；
2. 当前选中的组；
接收的事件包括：
1. 收到应用系统公共内部状态更新通知；
2. 画面切换通知；
3.3.6 巡航

图3.12 选择巡航组菜单
点击“巡航”按钮，跳到组页面并弹出选择巡航组提示。
点击要巡航的组，程序自动从组的第一个位置开始巡航，巡航时，会依次切换摄像机画面。
系统默认巡航中每个摄像机画面停留5s，也可以在设置界面设置摄像机画面停留时间。
3.3.7 配置

图3.13 设置界面
点击WIFI链接模式开关，使用WIFI链接系统监控服务器实现键盘控制功能；
点击蓝牙链接模式开关，使用蓝牙连接到机顶盒的附加电路板上的蓝牙接收模块，通过蓝牙信号转换模块将请求信号通过网口链接到视频监控服务器实现键盘控制功能；
启动时，依据配置信息在ConnectorLayer调用相应的连接建立函数；
当用户所选的网络不存在时（wifi没有接入或者蓝牙没有配对时），跳到系统对应的配置页面，而不是直接退出。

结论
本系统是一套用于“平安城市”视频监控的综合调度平台，目标是将“平安城市”中所有的视频矩阵——无论是大型矩阵，还是社区和单位的小型矩阵——全部统合到一个平台上使用和管理，使得用户能够使用一个键盘将城市中任何一台摄像机的图像显示在任何一块监控屏幕上。
本产品率先将先进的物联网技术应用于“平安城市”视频监控领域，在国内尚属首创。本系统可以将城市中所有现存的摄像机进行统一使用和管理，使得每一个角落都能被实时监控到，在预防、发现、控制和打击违法犯罪、提供破案线索、固定违法犯罪证据等方面发挥着人防、物防所不可替代的重要作用，真正实现“平安城市”。
它不仅可以满足治安管理，城市管理，应急指