公共楼宇（精选3篇）
公共楼宇 篇1
漳州地处我国东南沿海, 属南亚热带海洋性季风气候, 面临台湾海峡, 是福建省受气象灾害影响最严重的地区之一。近年来, 极端气候现象和灾害性天气不断发生, 给漳州人民生产、生活带来极大影响, 造成重大经济损失, 严重制约了漳州经济和社会的可持续发展。漳州面临着日益严重的气象灾害威胁, 如何加强气象防灾减灾工作, 有效减少灾害性天气带来的损失, 已经摆在各级政府和气象部门的面前。
一、漳州楼宇视屏气象灾害公共预警网建设的现状
如何及时、准确地把灾害性天气的气象信息进行传播, 真正做到为民所用, 是气象部门在开展防灾减灾工作上的一大难题。气象楼宇视屏主要安装在电梯口、小区、学校、医院、车站、加油站等人员相对密集的场所, 受众面广, 真正做到及时、准确地传递气象信息。
1. 建设项目的争取
为进一步做好气象灾害防御工作, 有效减少灾害性天气带来的损失, 市政府下发《漳州市人民政府办公室关于加强漳州气象预警系统建设的通知》后, 漳州市气象局紧紧抓住这一机遇, 按照"政府引导、社会参与、气象主办、人民受益"的方针, 广泛征求各有关部门和公众的意见, 在市委、市政府的大力支持下, 于2009年开展楼宇视屏气象灾害公共预警网的推广普及工作。
2. 当前运行的基本情况
经与有关单位沟通, 借助通信运营商的网络分布广的优点, 历时一年时间, 漳州市气象局2010年完成了多个居民小区楼宇视屏的安装建设与运行, 实现了气象信息直通居民社区的”零距离“传递。经过半年的运行, 各使用单位一致反映, 在居民小区布设气象楼宇视屏, 可以确保人民群众最直接、快捷地获取每日的天气预报信息尤其是各种灾害天气预警信息, 极大地方便了人民的生产与生活以及防御各种突发性灾害天气。今年, 漳州气象部门还将在更多的小区内安装这种气象楼宇视屏。
3. 项目建设的意义
以前, 气象信息通常只能在传统的媒体如电视、广播、报纸上发布, 在时效性、覆盖面等方面有一定的局限性, 楼宇视屏则可以弥补这方面的缺憾。气象楼宇视屏不仅能不断更新未来天气预报和天气提示内容, 而且遇有灾害性天气发生时, 能及时预警, 并可发布动态信息, 使气象信息覆盖面不断延伸。例如当台风、暴雨、寒潮等灾害性天气入侵时, 安装在各居民小区的气象楼宇视屏, 在15分钟内便可发布预警信息及信号, 提醒市民提前做好准备。这既有利于做好防灾减灾工作, 又有利于提升气象信息的关注度。
二、楼宇视屏系统结构及工作原理
1. 系统结构
气象灾害公共预警网系统由气象信息发布平台 (设在漳州市气象局) 、网络环境、终端播放器 (设在各通信运营商) 和显示终端 (设在漳州市公共场所及人流密集地带) 组成, 制作人员每天通过气象信息发布平台进行信息编辑、节目制作, 再经由通信网络, 将信息传输到显示终端, 实现同步显示。
2. 工作原理
通过网络环境, 利用虚拟网卡软件模拟集线器的功能, 建立VPN通道, 将办公室电脑连接到虚拟的HUB上与户外气象电子屏内的电脑组成局域网。用户可在任何一台办公电脑制作天气预报文件 (待播放文件) , 制作完毕后使用“楼宇视屏同步播放软件”发送制作好的天气预报文件到电子显示屏电脑主机 (服务器) 上播放。客户端在发送文件时, 先判断服务器上是否已经存在最新的相同文件, 若存在则不发送该文件, 否则发送文件到屏幕主机上, 并在屏幕主机上创建同名文件或替换旧文件。全部文件发送完毕后, 屏幕主机关闭当前的播放程序, 然后播放刚接收到的天气预报文件, 发送文件的通信方式采用TCP/IP协议, 将文件可靠的发送到电脑主机。
三、楼宇视屏远程控制系统的设计
1. 控制软件的设计
针对漳州市气象局楼宇视屏分散于各个场所, 应尽可能避免前往显示屏现场进行系统维护的实际情况, 设计了该系统的控制软件, 系统功能完善, 运行稳定, 并且具有一定的可扩充性, 便于管理多个显示屏并与不断发展的通讯方式进行有机结合。主要技术特点:
(1) 市局显示屏控制主机和远端显示屏硬件上是完全分离的, 显示屏的播放既不依赖也不影响控制主机的工作, 市局任何一台办公电脑可兼做显示屏控制主机;
(2) 控制软件设计了更改、停止、暂停播放节目等系统功能, 可在当前播放状态下切换播放文件或在播放内容中插播用户方的政务信息, 如宣传材料、各种通知、迎接领导的欢迎词等, 增加了市局的控制主动权;
(3) 远程电脑管理:可实现远程的虚拟VPN, 达到完全控制远端显示屏电脑主机的功能。
四、漳州楼宇视屏气象灾害公共预警网建设思考
1. 强化气象楼宇视屏基础设施建设
当前, 漳州使用的气象楼宇视屏是通过漳州电信广告服务系统。
2. 提高气象楼宇视屏覆盖率
仅仅依靠气象部门和通信运营商推广气象楼宇视屏, 推广面不广, 很难覆盖到各个乡镇。气象部门应努力争取楼宇视屏气象灾害公共预警网的建设成为市政府的一项为民办实事工程, 由市政府发文, 在全市范围内建立楼宇视屏气象灾害公共预警网, 使灾害性气象信息覆盖率达到98%以上, 基本实现气象信息进入社区、村镇, 实现气象信息的广泛覆盖。
3. 加大宣传力度, 普及防灾减灾知识
加大气象科普和防灾减灾知识宣传力度, 深入普及气象防灾减灾知识, 充分发挥气象部门的权威性。
4. 规范气象楼宇视屏信息服务管理
为加强气象楼宇视屏信息服务工作的管理, 使显示屏服务工作制度化、规范化、程序化, 确保发布信息的权威性、及时性和准确性, 严格按照《漳州市电子显示屏气象信息服务工作管理办法》, 根据信息重要程度和时效性, 掌握电子显示屏服务信息发布的优先原则。
五、结束语
楼宇视屏是传播气象服务信息最为直接有效的现代化工具, 也是气象部门扩展防灾减灾服务的重要途径之一。群众通过在分散于各个场所的楼宇视屏, 及时了解最新天气和相关科普内容, 这种“准确、及时、优质、高效”的“零距离”无偿服务受到一致认可, 体现公众气象服务要贯彻“以人为本, 无所不在, 无微不至”的服务理念, 为社会公众及时掌握气象信息发挥了重要作用。
公共楼宇 篇2
广播及背景音乐系统具备背景音乐广播、公共广播、消防紧急广播三项功能。其实质是将背景音乐广播系统、公共广播及消防广播结合一体, 共用一套功放及扬声器。平时可播放背景音乐, 各区可同时进行选择性公共广播, 而非公共广播区则照样播放背景音乐。按照火灾报警设计、施工及验收规范的规定, 当发生火灾时, 系统按照消防要求设定的区域 (如N-1、N、N+1) 进行紧急广播, 在紧急广播时, 应自动切断背景音乐、公共广播, 保证紧急广播处于最优先级。
2 系统构成
2.1 系统构成及设备配置
IP公共广播系统拓扑如图1所示, 系统由话筒、音源播放设备、调音台、主控服务器、分控服务器、网络解码适配器、网络解码功放、前置放大器、功放、扬声器等设备及其承载业务网络组成。
本项目中, 1层~35层的每个楼层设一个广播分区, 地下两层为一个广播分区, 每一层配置一个解码器;当发生火灾时, 系统按照消防要求设定的区域 (如N-1、N、N+1) 进行紧急广播;共有8个分控室和一个总控室, 每个分控室管2层 (分别是管理1层~16层) , 其他由主控室管理。
2.2 组件功能说明
IP公共广播系统各主要组件的功能如下:
主控服务器:负责整个广播系统的业务流量的生成和管理, 复制转发分控服务器流量, 对广播系统内的所有设备执行权限管理、轮询等工作。麦克风、收音调谐设备、CD卡座等音源汇聚到调音台后, 通过音频线缆连接主控服务器的声卡输入端口, 主控服务器将音源信号编码成128kbps的语音数据流发送到TCP/IP网络上。当点播存储在本主控服务器上的MP3文件时, 主控服务器则按照MP3文件的编码码率向网络中发送音频数据流。
分控服务器:负责所管辖的区域内业务流量的生成, 把生成的语音流量发送到主控服务器, 并通过主控服务器转发到网络解码适配器或由网络解码功放播出。
网络解码适配器:负责接收主控服务器产生或转发的音频数据流, 解码并通过功放驱动喇叭发声。
网络解码功放:作用与网络解码适配器相似, 也是接收主控服务器产生或转发的音频数据流并解码, 直接驱动喇叭发声。
3 系统业务流量分析
本项目的主要业务包括:背景音乐播放、通常播音与通告、消防联动广播。
3.1 背景音乐播放业务流量
3.1.1 工作流程
(1) 播放主控服务器本地存储背景音乐时, 主控服务器从本机硬盘上读取MP3文件, 按照MP3文件自身的码流速率 (通常为128kbps) , 将音频数据流发送到TCP/IP网络上, 数据流的目的地址为指定分区的网络解码适配器或网络解码功放。网络解码适配器/网络解码功放将音频数据流解码并驱动喇叭发声, 播放过程实现。
(2) 播放主控服务器声卡采集的音源信号 (比如收音调谐设备、CD卡座等) 时, 服务器按照128kbps的采样速率编码音频流, 并以同样的速率向TCP/IP网络传送音频数据流。
(3) 从分控服务器上点播主控服务器本地存储的背景音乐时, 分控服务器与主控服务器之间首先进行信令交互, 在完成授权验证等工作之后, 播放过程和产生的流量与“工作流程1”完全相同。
(4) 在分控服务器上点播其本地存储的背景音乐时, 分控服务器与主控服务器之间首先进行信令交互, 在完成授权验证等工作之后, 分控服务器将本地MP3文件按照文件自身的码流速率 (通常为128kbps) 转换为音频数据流, 通过TCP/IP网络发送到主控服务器上。主控服务器此时执行媒体流转换, 将收到的音频数据流做复制转发, 转发给相应的网络解码适配器进行解码播放。转换过程中音频数据流的编码、协议等特征保持不变。
3.1.2 单播流量分析
(1) 主控服务器背景音乐播放流。主控服务器背景音乐播放流是单向流, 从主控服务器到网络解码适配器或网络解码功放, 报文基于UDP协议, 为MP3编码格式, 数据流大小通常为128kbps, 当播放本地MP3文件时, 数据流大小取决于所播放MP3文件的码率, 当播放声卡采集的外部音源时恒定速率为128kbps, 数据流对延迟、抖动和丢包都敏感。由于网络解码适配器播放接收到的数据流会缓冲3个报文 (12个MP3帧) 大概400ms左右数据, 因此该数据流可容忍的抖动应小于400ms。本系统中广播分区总共36个 (网络解码适配器/解码器共37个) , 极限情况下每个分区的背景音乐都不相同, 若都选择从主控服务器上播放本地MP3做背景音乐且MP3文件的码率都为128kbps, 则网络上背景音乐流所占带宽最大为128kbps×37=4736kbps≈4.7Mbps。若MP3文件码率大于128kbps, 则网络上业务流量所占带宽也会相应增大。流量路径如图2所示。
(2) 主控服务器与网络解码适配器 (网络解码功放) 之间的交互信令报文流。信令报文流是双向流量, 用于主控服务器与网络解码适配器 (网络解码功放) 之间建立、维护和终止背景音乐流。报文基于UDP协议, 数据流流量小, 对延迟、抖动不敏感, 但对丢包率有一定要求。流量路径如图3所示。
(3) 分控服务器背景音乐播放流。分控服务器背景音乐播放流是单向流, 从分控服务器流向主控服务器, 在主控服务器上做复制转发到网络解码适配器 (网络解码功放) 终结。该流量报文基于UDP协议, 为MP3编码格式, 数据流大小取决于分控服务器所播放的本地MP3文件的码率, 通常为128kbps, 数据流对延迟、抖动和丢包都敏感。由于网络解码适配器播放接收到的数据流会缓冲3个报文 (12个MP3帧) 大概400ms左右数据, 因此该数据流可容忍的抖动应小于400ms。本系统中共8个分控服务器, 每个服务器管理两个分区, 极限情况下每个分区的背景音乐都不相同, 若都选择从分控服务器上播放本地MP3做背景音乐且MP3文件的码率都为128kbps, 则分控服务器发送给主控服务器的流量最大为128kbps×16=2048kbps=2Mbps;主控服务器将这些流量转发给相应分区的终端设备时, 网络上背景音乐流所占带宽最大为128kbps×16=2048kbps=2Mbps。若MP3文件码率大于128kbps, 则网络上业务流量所占带宽也会相应增大。流量路径如图4所示。
(4) 分控服务器与主控服务器之间的交互信令报文流。分控服务器与主控服务器之间的交互信令报文流是双向流量, 用于实现主控服务器对分控发起的业务请求识别、鉴权及建立、维护和终止主控与分控服务器之间的背景音乐播放流量。数据流完全由信令报文组成, 基于UDP协议, 流量小, 对延迟、抖动不敏感, 但对丢包率有一定要求。流量路径如图5所示。
3.1.3 组播流量分析
当在本系统中使用组播替代单播向多个分区的网络解码适配器发送同一路背景音乐时, 主控服务器会选择一个组播地址, 并将背景音乐流的目的地址填写为该组播地址发送到TCP/IP网络上。主控服务器与网络解码适配器 (网络解码功放) 进行信令交互时, 会将该组播地址告诉网络解码适配器 (网络解码功放) , 随后网络解码适配器 (网络解码功放) 主动发起IGMP加入报文, 加入该组播组并接收背景音乐数据流。会引起以下数据流发生变化:
(1) 主控服务器背景音乐播放流 (组播) 。主控服务器背景音乐播放流 (组播) 是单向流, 从主控服务器发送到网络中, 报文基于UDP协议, 为MP3编码格式, 与单播流量的特征完全相同, 仅目的地址是组播地址, 因此, 对其特征不再赘述。
(2) 分控服务器背景音乐播放流 (组播) 。分控服务器背景音乐播放流是单向流, 从分控服务器流向主控服务器, 在主控服务器上将目的地址转变为组播地址后转发到TCP/IP网络上。与单播流相比, 流特征完全相同, 仅目的地址是组播地址, 因此, 对其特征不再赘述。
3.2 通常播音与通告业务流量
3.2.1 工作流程
(1) 主控服务器通常执行播音与通告业务, 从本机声卡对麦克风信号进行采样, 将采样信号编码成音频数据流, 并以128kbps的速率通过TCP/IP网络发送到指定分区的网络解码适配器或网络解码功放, 由网络解码适配器或网络解码功放进行解码播放。
(2) 分控服务器通常执行播音与通告业务时, 先与主控服务器进行信令交互以完成授权验证等工作, 获得相应权限后, 从分控服务器声卡对麦克风信号进行采样, 将采样信号编码成音频数据流, 并以128kbps, 的速率通过TCP/IP网络发送到主控服务器。主控服务器执行媒体流转换, 将收到的音频数据流做复制转发, 转发给相应的网络解码适配器 (网络解码功放) 进行解码播放。转换过程中音频数据流的编码、协议等特征保持不变。
3.2.2 单播流量分析
(1) 主控服务器执行通常播音与通告业务流。主控服务器的播音与通告业务流是单向流, 从主控服务器到网络解码适配器或网络解码功放, 报文基于UDP协议, 为MP3编码格式, 数据流带宽恒定为128kbps, 数据流对延迟、抖动和丢包都敏感。由于网络解码适配器播放接收到的数据流会缓冲3个报文 (12个MP3帧) 大概400ms左右数据, 因此该数据流可容忍的抖动应小于400ms。主控服务器只能接一路麦克风, 但通常情况下, 播音与通告业务流量需单播到全网所有网络解码适配器 (网络解码功放) 上, 因此网络中的通常播音与通告业务流最大128kbps×37=4736kbps≈4.7Mbps。流量路径如图6所示。
(2) 主控服务器与网络解码适配器 (网络解码功放) 之间的交互信令报文流。信令报文流是双向流量, 用于主控服务器与网络解码适配器 (网络解码功放) 之间建立、维护和终止通常播音与通告业务流。报文基于UDP协议, 数据流流量小, 对延迟、抖动不敏感, 但对丢包率有一定要求。流量路径如图7所示。
(3) 分控服务器执行通常播音与通告业务流。分控服务器通常播音与通告业务流是单向流, 从分控服务器流向主控服务器, 在主控服务器上做复制转发到网络解码适配器 (网络解码功放) 终结。该流量报文基于UDP协议, 为MP3编码格式, 数据流大小恒定为128kbps, 数据流对延迟、抖动和丢包都敏感。由于网络解码适配器播放接收到的数据流会缓冲3个报文 (12个MP3帧) 大概400ms左右数据, 因此该数据流可容忍的抖动应小于400ms。由于一台分控服务器只能接一路麦克风, 本系统中共有8个分控服务器, 每个分控服务器可对自己分管的两个楼层播音, 因此在极限情况下, 各分控服务器都对本服务器分管楼层播音, 则进入主控服务器的流量为128kbps×8=1024kbps=1Mbps;主控服务器将各分控服务器产生的播音业务流量复制并转发到相应楼层, 全网分控服务器产生的通常播音与通告业务流最大为128kbps×16=2048kbps=2Mbps。流量路径如图8所示。
(4) 分控服务器与主控服务器之间的交互信令报文流。分控服务器与主控服务器之间的交互信令报文流是双向流量, 用于实现主控服务器对分控发起的业务请求识别、鉴权及建立、维护和终止主控与分控服务器之间的通常播音与通告业务流量。数据流完全由信令报文组成, 报文基于UDP协议, 流量小, 对延迟、抖动不敏感, 但对丢包率有一定要求。流量路径如图9所示。
3.2.3 组播流量分析
在本系统中使用组播替代单播向多个分区的网络解码适配器发送同一路播音时, 主控服务器会选择一个组播地址, 并将播音流的目的地址填写为该组播地址发送到TCP/IP网络上。主控服务器与网络解码适配器 (网络解码功放) 进行信令交互时, 会将该组播地址告诉网络解码适配器 (网络解码功放) , 随后网络解码适配器 (网络解码功放) 主动发起IGMP加入报文, 加入该组播组并接收播音数据流。因此引起以下数据流发生变化:
(1) 主控服务器执行通常播音与通告业务流 (组播) 。主控服务器通常播音与通告业务流 (组播) 是单向流, 从主控服务器发送到网络中, 报文基于UDP协议, 为MP3编码格式, 与单播流量的特征完全相同, 仅目的地址是组播地址, 因此对其特征不再赘述。
(2) 分控服务器执行通常播音与通告业务流 (组播) 。分控服务器通常播音与通告业务流是单向流, 从分控服务器流向主控服务器, 在主控服务器上将目的地址转变为组播地址后转发到TCP/IP网络上。与单播流相比, 流特征完全相同, 仅目的地址是组播地址, 因此对其特征不再赘述。
3.3 消防联动广播业务流量
3.3.1 工作流程
当产生消防报警时, 消防信号从干线传入设备“IP消防智能接口T-6723”, 该设备将消防信号转换成计算机可以识别的RS232串口信号后, 通过主控服务器的RS232串口发送到主控服务器上。主控服务器识别该信号, 并解码产生该信号的分区, 然后对特定的N-1、N、N+1三个分区发送消防联动广播流。消防联动广播的原理与背景音乐播音完全相同, 都是播放主控服务器上本地存储的MP3文件。
3.3.2 单播流量分析
(1) 消防联动广播业务流。消防联动广播业务流是单向流, 从主控服务器到网络解码适配器或网络解码功放, 报文基于UDP协议, 为MP3编码格式, 数据流带宽等于所播放的MP3文件的码率, 数据流对延迟、抖动和丢包都敏感。由于网络解码适配器播放接收到的数据流时会缓冲3个报文 (12个MP3帧) 大概400ms左右数据, 因此该数据流可容忍的抖动应小于400ms。由于系统中需要同时对相邻的3个分区播放消防联动广播, 系统中的业务流所占带宽应该为128kbps×3=384kbps。若同时有多个分区发生火灾, 则业务流量相应增加。流量路径如图10所示。
(2) 主控服务器与网络解码适配器 (网络解码功放) 之间的交互信令报文流。信令报文流是双向流量, 用于主控服务器与网络解码适配器 (网络解码功放) 之间建立、维护和终止消防联动广播业务流。报文基于UDP协议, 数据流流量小, 对延迟、抖动不敏感, 但对丢包率有一定要求。流量路径如图11所示。
3.3.3 组播流量分析
在本系统中使用组播替代单播向多个分区的网络解码适配器发送消防联动广播时, 主控服务器会选择一个组播地址, 并将消防联动广播流的目的地址填写为该组播地址发送到TCP/IP网络上。主控服务器与网络解码适配器 (网络解码功放) 进行信令交互时, 会将该组播地址告诉网络解码适配器 (网络解码功放) , 随后网络解码适配器 (网络解码功放) 主动发起IGMP加入报文, 加入该组播组并接收消防联动广播数据流。因此引起以下数据流发生变化:
主控服务器消防联动广播业务流 (组播) 。主控服务器消防联动广播业务流 (组播) 是单向流, 从主控服务器发送到网络中, 报文基于UDP协议, 为MP3编码格式, 与单播流量的特征完全相同, 仅目的地址是组播地址, 因此对其特征不再赘述。
4 业务流量总结及其对承载网络的要求
4.1 IP广播系统业务流量分析总结
基于前文分析, 总结IP公共广播系统业务生成原理、流量特征及带宽如下:
主控服务器播放背景音乐、播音通告生成的业务流量特征相同, 主控服务器从本机硬盘上读取MP3文件或从声卡采集音源信号, 按照MP3文件自身的码流速率 (通常为128kbps) 或按照128kbps的采样速率, 将音频数据流发送到指定分区的网络解码适配器或网络解码功放, 由网络解码适配器/网络解码功放将音频数据流解码并驱动喇叭发声, 实现播放过程。产生的业务流是从主控服务器到网络解码适配器或网络解码功放的单向流, 基于UDP协议, 数据流大小为128kbps或等于MP3文件的码率。实测数据流所占带宽略大于128kbps, 以系数1.1予以修正, 流量计算时以128kbps×1.1=140.8kbps计算, 数据流对延迟、抖动和丢包都敏感, 可容忍的抖动应小于400ms。当前应用场景中, 广播分区总共36个 (网络解码适配器/解码器共37个) , 极限情况下所占带宽最大为140.8kbps×37=5209.6kbps≈5.1Mbps (单流带宽140.8kbps情况下) 。若MP3文件码率大于128kbps, 则网络上业务流量所占带宽也会相应增大。
从分控服务器上点播主控服务器本地存储背景音乐时, 首先需要一个认证授权过程, 得到授权后的工作流程与1相同, 业务流也相同。
分控服务器播放其本地存储的背景音乐、播音通告时, 分控服务器先在主控服务器上完成授权验证工作, 然后从本机硬盘上读取MP3文件或从声卡采集音源信号, 按照MP3文件自身的码流速率 (通常为128kbps) 或按照128kbps的采样速率发送到主控服务器上, 由主控服务器转发给相应的网络解码适配器进行解码播放。产生的业务流是单向流, 从分控服务器流向主控服务器, 由主控服务器转发到网络解码适配器 (网络解码功放) 。业务流基于UDP协议, 数据流大小为128kbps或等于MP3文件的码率。实测数据流所占带宽略大于128kbps, 以系数1.1予以修正, 流量计算时以128kbps×1.1=140.8kbps计算, 数据流对延迟、抖动和丢包都敏感, 可容忍的抖动小于400ms。当前应用场景中共8个分控服务器, 每个服务器管理两个分区, 极限情况下分控服务器发送给主控服务器的流量最大为140.8kbps×16=2252.8kbps=2.2Mbps (单流带宽140.8Kbps情况下) ;主控服务器转发所占带宽最大为140.8kbps×16=2252.8kbps=2.2Mbps。若MP3文件码率大于128kbps, 则网络上业务流量所占带宽也会相应增大。
当产生消防报警时, 消防信号从干线传入设备“IP消防智能接口T-6723”, 该设备将消防信号转换成计算机可以识别的RS232串口信号后, 通过主控服务器的RS232串口发送到主控服务器上。主控服务器识别该信号, 并解码出产生该信号的分区, 然后对特定的N-1、N、N+1三个分区发送消防联动广播流。消防联动广播的原理与背景音乐播音完全相同, 都是播放主控服务器上本地存储的MP3文件。业务流所占带宽应该为140.8kbps×3=422.4kbps。若同时有多个分区发生火灾, 则业务流量相应增加。
4.2 IP广播系统对承载网络的要求
公共楼宇 篇3
楼宇自动化系统也叫建筑设备自动化系统(Buiding Automation System简称BAS)，是智能建筑不可缺少的一部分，其任务是对建筑物内的能源使用、环境、交通及安全设施进行监测、控制等，以提供一个既安全可靠，又节约能源，而且舒适宜人的工作或居住环境。
2 KMC楼宇自控系统
楼控系统采用的是基于现代控制理论的集散型计算机控制系统，也称分布式控制系统(Distributed controlsystems简称DCS)。它的特征是“集中管理分散控制”，即用分布在现场被控设备处的计算机控制装置(DDC)完成对被控设备的实时检测和控制任务，克服了计算机集中控制带来的危险性高度集中的不足和常规仪表控制功能单一的局限性。安装于中央控制室的中央管理计算机具有CRT显示、打印输出、丰富的软件管理和很强的数字通信功能，能完成集中操作、显示、报警、打印与优化控制等任务，避免了常规仪表控制分散后人机联系困难、无法统一管理的缺点，保证设备在最佳状态下运行。
3 候机楼设备运行要求的特殊性
由于候机楼不同与一般大厦，在设备控制上有着很多的不同点，简单的朝九晚五模式在这里根本行不通。宁波机场分国内、国际的旅客区域，要随时根据飞机的起降的航空计划调整特定的灯光，空调等相关设备。采用传统的控制方式已经完全不适应这种多变的需求，采用楼宇控制是势在必行的。
4 宁波栎社国际机场楼宇系统简介
宁波栎社国际机场(以下简称：宁波机场)的候机楼地面有两个楼层，总建筑面积4.35万平方米，按年旅客吞吐量380万人次、高峰小时1700人次的要求建设。候机楼楼宇系统采用开放式集散系统，随着现场总线技术的发展，DDC分站连接传感器、执行器的输人输出模块，应用LON现场总线，从分内部走向设备现场，形成分布式输入输出现场网络层，从而使系统的配置更加灵活，由于Lon Works技术的开放性，使分站具有了一定程度的开放规模。BAS控制网络就形成了三层结构，分别是管理层(中央站)、自动化层(DDC分站)和现场网络层。宁波机场采用KMC公司的KMD5210为主控模块，下挂两个子网，根据不同的要求，各挂有70个和96个DDC。每个DDC控制采用RS-485网络与主模块相连，同时各DDC也能独立工作。数据的传输速率为9600bps已能满足日常工作的需要。
5 对公共区域灯光系统的控制
尽管已经采用了透明的玻璃幕墙，利用充足的阳光也节省了照明费用，但候机楼大厅的灯光照明仍然是耗电最多的照明系统。宁波机场通过对所控制的灯光进行详细的点位核对、登记，掌握了第一手的资料，通过对候机楼现场的实际效果的观察，把灯光按不同地点的不同要求进行分类，在照明时采用轮换照明，对航班间隙比较大的地方，通过监控镜头进行观察，按实际使用的需求，及时启停相关的灯光，例如：对值机柜台的灯光控制采用分三级光照强度控制，分别对应不同的光照需求。KMC公司提供Win Control软件进行不同的组合，如：阴雨天气补充照明，傍晚时分照明，值机柜台轮换照明、夜晚照明、特殊情况照明、节假日照明等通俗易懂的组合方式，给值班人员提供简便的操作。
对国际厅的照明按照航班计划制定周计划表，预先在现场的DDC中设置好启停时间，最多每日可以欲设四个时间段，并通过动态航显系统和现场监控镜头进行及时的调整，为避免在操作过程中出现纰漏，宁波机场还制定了操作规程及相应的声音提醒软件。通过三年的运行，确实达到了即节约了电能又延迟了灯具的使用寿命目的，同时还满足了候机楼照明的需求。
6 对空调系统的控制
宁波机场对锅炉、冷冻机组实行只监不控，检测热水的供水温度、流量等信息。设定中央空调的风机可以根据供水温度和流量达到一定值时自动启动，避免了人为差错造成的能量浪费。
根据候机楼建筑的特点，利用冷空气会沉降及热空气会上升的特点，把候机楼的10个自动扶梯作为空气流动的通道，在夏天适当停止一楼大厅的空调风机，在冬天则适当停止二楼大厅的空调风机，基本上仅开启半数的空调风机就能达到了控制温度的目的，经过三年的运行仅此一项就为机场节约了大量的电能。
由于空调风机箱都采用变频控制技术，当实际温度与设定温度的差距减小，循环风的需要量也随之减少，这时通过系统降低变频器的输出频率，从而降低循环风机转速进而减少送风量，节省了电能。
根据由流体力学可知P(功率)=Q(流量)×H(压力)，流量Q与转速N的一次方成正比，压力H与转速N的平方成正比，所以功率P与转速N的立方成正比。
如果风机的效率一定，当要求调节流量下降时，转速N可成比例的下降，而此时轴输出功率P成立方关系下降。32台循环风机功率为15kW×32=480kW，系统稳定后宁波机场设定转速平均下降到原转速的60%，可实现省电78.4%。
7 闭环控制方式使设备更容易被控制
由于对中央空调的风机箱实施了闭环控制，宁波机场利用安装在风机箱上的温度传感器、压差开关、风阀执行器、水阀执行器及变频器轻松实现现场温度的控制，由于KMC公司的DDC(例如：KMD5831、KMD5802、KMD7301)都带有PDI (Proportional Integral Derivative, 比例积分微分控制)使温度的控制变得简单。它们可独立运行，也可通过Peer-to-Peer方式连成网络。断电后还能保持72小时数据不丢失。还可以通过这些反馈回来的数据，轻松判断出一般的风机箱故障，例如：滤网堵住、皮带断裂、水阀执行器故障等故障，为及时排除故障提供了技术支持。且每个输出端口可以通过软件设置成数字量输出口或模拟量输出口，使维修工作变得更加的轻松和方便。尤其是在更换输出端口时，显得十分便利。
8 结束语