停车场道闸系统关于不停车通行停车场系统的两个问题(数据库UPS-录像)的说明

关于不停车通行停车场系统的两个问题的说明

关于停车场系统配备UPS的说明

? 问题的提出: 截至目前,我们的停车场系统数据库损坏次数总和<10次,但每次损坏都会带来支持,甚至要研发人员介入,有时候还是无法修复数据库.

? 解答:

最佳方案是建议用户购买ups不间断电源,配置到数据库运行的计算机上;如果用户不愿意购买ups,把问题的严重性交代清楚;需要的ups配置不要求很高,因为ups随着使用容量会不断下降,因此,这ups只要保证计算机可以工作15分钟以内就可以了(随着容量下降,到二年后还能保证支持计算机一分钟也就够了).

? 说明: 大家知道,我们使用的是一种关系型数据库firebird,是类似于SQL server或者Oracle,MySQL的数据库.用来保存,处理我们停车场系统运行过程中的数据; 这些数据都被保存在文件中. 数据库文件的安全至关重要. 对于一个重要的数据库服务器来说,配置ups不间断电源是必须要求.

但是我们的现场情况大家都知道,计算机的配置方面就不提了,最糟糕的是可能随时掉电! 而且这是无法要求用户保证的.所谓的数据库损坏,其实就是这个数据库文件写数据不完整,问题就发生在写数据的瞬间. 经过我们实际测试,在没有写数据的时候,突然掉电(插线板开关一次)的损坏率为0(测试200次),在写数据的时候,只要是在写的过程中,突然掉电损坏率为100%(测试60次,完全死循环写数据). 过去我们要求用户购买专用的ups不间断电源,要求都比较高,用户很难接受这个要求;实际上,在停车场实际应用中,一种情况是,计算机以及周边的设备同时掉电,这种情况下,很可能有数据在传输以及写入数据库,假如这时计算机断电,写数据未完成的概率大大增加,数据库损坏的几率就比较大了,但如果有一台ups维持计算机工作几分钟,待数据写入完成,则数据库损坏的概率几乎降为0; 第二种情况是,只有计算机的电源(插线板)被误关闭了,这时,周边的设备还在工作,数据在正常传输,如果有ups,用户发现弄错了,再补救,则相当于没有发生这件事一样,导致数据库损坏的概率也几乎为0.

? 特别注意:

我们的系统每天都在备份数据库,出现状况的时候千万提醒用户不要随意的删除文件夹,结果在数据库无法修复的情况下,基础信息都无法恢复了,这样的损失时极大的.

1

关于录像码流的问题

? 问题的提出:

最近有技术人员问及我们的停车场系统是否有录像功能,包括原来也有人问及需要显示实时视频.

? 解答:

此功能 “可以” 实现,但暂时属于调试使用,不准备推荐给用户使用.

? 原因:

1. 解码要占据cpu 一旦录像或者有视频,就必须传输码流(H.264是一种高性

能的视频编解码技术,最大的优势是具有很高的数据压缩比率，在同等图像质量的条件下，H.264的压缩比是MPEG-2的2倍以上，是MPEG-4的1.5～2倍。具有高压缩比的同时还拥有高质量流畅的图像,在网络传输过程中所需要的带宽更少，也更加经济) 不论是哪一种编码,到了播放端都需要解码.如同我们拷贝了一个rar压缩文件,使用的时候必须先解压缩一样,解码需要大量的运算,必然占用一定的cpu资源.

2. 多台同时解码 因为我们的系统架构是几台高清摄像机连接到一台计算机

的模式,这个解码操作要在一台计算机上完成,因此,对于这台计算机的cpu提出了很高的要求. 我们平时有几个人在你的计算机上同时播放两部甚至多部高清视频? 这样有可能累死cpu(cpu的占用率在80%以上,计算机十分缓慢,甚至假死)

3. 我们现在的高清有300万像素,甚至达到500万像素,随着像素的提高,cpu的解

码工作大大增加.

4. 我们的停车场系统的cpu都去忙解码了,正常的停车场处理事务可能就会忙不

过来,导致系统不能正常工作.得不偿失.

5. 我们现在的系统的模式是只是接收高清网络摄像机的截图,唯一的工作就是网

络传输一个50到100KB大小的jpg压缩图片文件.

6. 如果以后采用了每个岗亭单独运作的架构,将 “有可能” 一定程度上解决上述

问题,因为一个岗亭连接的出入口毕竟有限. 7. 如果需要监控,建议还是安装独立的监控系统.

补充: 码流最高是720P，此时截图为720P；当截图时200万以上时，码流只有D1或CIF.

2