您所在位置： &
&nbsp&&nbsp&nbsp&&nbsp
基于6LoWPAN技术的智能家居系统设计与实现.pdf 94页
本文档一共被下载：
次 ,您可全文免费在线阅读后下载本文档。
下载提示
1.本站不保证该用户上传的文档完整性，不预览、不比对内容而直接下载产生的反悔问题本站不予受理。
2.该文档所得收入(下载+内容+预览三)归上传者、原创者。
3.登录后可充值，立即自动返金币，充值渠道很便利
你可能关注的文档：
··········
··········
硕士学位论文
（工程硕士）
基于6LoWPAN 技术的智能家居系统设计与
DESIGN AND IMPLEMENTATION OF THE
SMART HOUSE SYSTEM BASED ON 6LOWPAN
哈尔滨工业大学
2013 年7 月
国内图书分类号：TN915
学校代码：10213
国际图书分类号：621.3
密级：公开
工程硕士学位论文
基于6LoWPAN 技术的智能家居系统设计与
硕 士研究生：王伟超
师：马永奎副教授
申 请 学 位：工程硕士
科：电子与通信工程
所 在 单 位：电子与信息工程学院
答 辩 日 期：20 13 年7 月
授予学位单位：哈尔滨工业大学
Classified Index: TN915
U.D.C: 621.3
Dissertation for the Master Degree in Engineering
DESIGN AND IMPLEMENTATION OF THE
SMART HOUSE SYSTEM BASED ON 6LOWPAN
Candidate ：
Wang Weichao
Supervisor ：
A.Prof.Ma Yongkui
Academic Degree Applied for ： Master of Engineering
Speciality ：
Electronics
Communication
Engineering
Affiliation ：
School of Electronics and Information
Technology
Date of Defence ：
July, 2013
Degree-Conferring-Institution ： Harbin Institute of Technology
智能家居行业拥有广阔的发展前景，但是由于IPv4 地址资源的枯竭、各厂商
协议不统一等问题，智能家居无法实现大规模的推广。6LoWPAN
技术可以解决
网络上传输IPv6 数据报文的问题，但是目前对6LoWPAN 协议
的研究还处在发展初期，本文的研究重点是设计并实现一种基于 6LoWPAN
的智能家居系统，将 6LoWPAN
技术应用到智能家居行业，为行业提供应用示
本设计在实现上采用C/S 结构，服务器端由监控终端、6LoWPAN 星型网络和
系统网关组成，客户端主要是在 Android
手机平台开发应用程序，同时也提供对
浏览器网站访问的支持。
首先，本系统成功完成了服务器的设计。监控终
正在加载中，请稍后...浅谈应急信息系统的功能需求和规划
浅谈应急信息系统的功能需求和规划
10-01-20 &匿名提问
一、前言   经过SARS等一系列公共卫生突发事件后，应急信息系统的建设受到了空前的重视。我国各级政府、各部门都把应急信息系统或应急指挥中心的建设提上了议事日程。例如，北京市公共卫生信息应用系统的建设，就是在以往的经验教训基础上，把应对公共卫生突发事件作为一个主要建设目标；卫生部应急指挥中心向社会公开招标，征集建设方案，等等。在政府推动下，应急信息系统建设已经进入一个高峰期。   应急信息系统的建设受到全社会范围的重视，这是一件好事。但同时也带来了问题：系统建设的目标到底是什么？多个相关项目如何统筹？怎样处理应急信息系统建设与业务处理系统的关系？应急信息系统的功能边界应该如何划分？等等。对这些问题如果没有一个正确的思路，应急信息系统建设的大规模投入就难以收到应有的社会效益，甚至象以前办公自动化和门户网站一样，变为一场“运动”。   本文试图对应急信息系统给出一个目标，描述“理想”情况下的系统模型和需求；在此基础上给出对整个应急信息系统规划的看法。二、应急信息系统的目标和功能需求分析   应急信息系统的目标，就是配合危机管理的全过程，应用信息技术，实现大面积的、跨专业和部门的信息资源、处理资源和通讯资源的实时调度，使应急指挥过程更加科学化和可视化。   这里用到了一个超越“应急”的概念——危机管理，我们把支持危机管理作为应急信息系统的目标。这是因为，要最大限度减少各种突发或紧急事件带来的损失，不仅仅要求我们在事件发生后做出迅速、准确的应对和处理，还要求我们在事件前期进行预警和辨识、在后期进行常态恢复。“危机管理”的三阶段理论更能指导我们运用信息技术对突发或紧急事件全面、全程的支持。   显然，这一目标，不是一个单纯的信息系统可以达到的。它要依赖基础性的网络和多个专业化的应用系统，要依赖多种技术的支持。但是，越是复杂，我们就越应该分析清楚，那些是核心、哪些是基础、哪些是锦上添花；哪些应该先建，哪些可以后建。否则眉毛胡子一把抓，不利于复杂系统的建设和统一的规划。   我们用如下的三层逻辑模型表示应急信息系统及其支持系统的关系。……应急信息系统信息处理系统通讯调度系统信息采集信息调度资源调度信息表现基本网络和通讯系统辅助决策应用支持层集成应用层基础设施层GIS应急信息系统的三层逻辑模型   各层的关系如下：最高层即是应急信息系统的核心功能，它是一种集成式应用；专业化的信息处理系统和各种相对成熟的技术系统（如GIS和Call Center系统）是构建应急信息系统的支撑性应用，我们称之为应用支撑层；而基本网络和通信系统是以上所有应用的基础。相邻层次之间有着双向的信息供求关系。   我们从对信息的处理角度来分解应急信息系统的功能目标。任何类型和目的的应急指挥系统，都具有以下功能特性：   1、信息汇聚：从应急事件现场或监测网络采集到的各种信息，将被传输到信息汇聚点（应急指挥中心）。这些信息可能是直接事件现场的视音频信息，也可能是来自传感设备、监控设备的信息或信号，还可能是来自相关的专业化信息处理系统的数字化信息。   2、信息表现：应急信息系统应该有直观而准确的信息表现形式，为指挥员进行指挥调度和辅助决策提供最大的帮助。GIS是一项广泛使用的技术，可以将危机管理所涉及的信息（如危机态势、应急指挥相关资源分布、应急方案等）在基础的空间地理图形上形象地表现出来，便于指挥和决策人员直观地进行形式判断、形成决策或进行资源调度；各种信息还可能要借助一定的显示设备和显示控制系统表现出来。   3、信息调度：所有信息在汇聚点被组合和集中呈现，供指挥中心的指挥决策人员作为决策和调度依据；有时还要将信息分发下级指挥中心（或分中心）的不同的专业化处理系统进行处理，或从这些系统收集处理结果。   4、通讯和物资资源调度：应急指挥最终都表现为通过一定的通讯手段，完成一定的人力、物力资源调度。例如警力的调度、救灾物资和设施调度、对事件现场的疏导和部署，等等。   5、辅助分析决策：在应急指挥过程中，提供一些逻辑分析模型、统计模型或预案，以及案例库中的参考案例，帮助指挥员进行理性决策；同时，应急信息系统还应记录下整个指挥调度的过程，形成完整案例，丰富案例库，为实现知识化、智能化的危机管理作积累。   以上是一个较为抽象的逻辑功能模型，它有助于我们把握应急信息系统的核心建设目标，合理运用各种技术和各种“物理的”系统。三、应急信息系统与其它信息系统的周边关系   1、技术型应用系统与应急信息系统的关系   在应急信息系统建设领域的最大误区，在于信息系统功能需求分析的缺失——从需求的陈述（实质上是一种需求定义）直接跳到技术方案，甚至成为技术方案或产品的简单堆砌。以技术方案代替功能需求，这似乎已经成为了一种应急信息系统建设中的普遍现象。   例如，我们经常能在招标书或所谓规划中看到这样的做法：即直接把“数字录音系统”、“大屏幕显示系统”、“地理信息系统”等作为“需求”本身的内容，对具体的技术实施方案和产品型号进行招标，甚至还有的招标书把“数据库系统”也作为应急信息系统需求的一部份提出来。这里面缺少了对应急信息系统的实质内容和目标的把握，缺少了一个理性的论证和分析过程。这样的“需求”拿出来招标，多半会造成建设的混乱和失控。   并不是说以上的技术系统不能作为应急信息系统的一部分，相反，逻辑的功能最终都会落实为一系列“物理”的技术子系统。但是我们在进行技术子系统的划分和分包之前，有必要对有机信息系统的“原始”功能需求作一定义和陈述，为技术方案的展开提供理性的约束，而不会被技术牵着鼻子走。   例如，GIS是一种广泛使用的、成熟的技术，也已经形成相对独立运行的系统。独立运行的GIS甚至可能成为整个应急信息系统中最主要的操作平台。这也是一些项目直接把GIS作为一种“默认”的“需求”的原因。但是，应急信息系统是否要采纳GIS，还要看具体的应用领域是否具备了应用GIS的数据条件和环境。而且，即使有必要和有条件使用GIS，也要从整个应急信息系统的总体目标出发进行分析，提出技术应用需求： 第一，   要实现应急信息系统与GIS的双向联动。GIS虽然可以独立运行，但在应急信息系统环境下，应该可以实现应急信息系统与GIS的多种联动方式——包括双向的相互驱动和基于数据共享的独立操作，等等；   第二，   要实现应急信息系统与GIS的底层整合。GIS系统与应急信息系统应共同遵循一定的数据标准，产生和传递一致的数据；底层应实现数据库共享或公用。   第三，   GIS与其他系统的数据整合。GIS的基础数据来自测绘部门，而应急指挥所需的“活”的应用数据往往来自其他业务部门，如建设、交通、气象、卫生，等等。为让信息系统能够运行起来而“一劳永逸”地导入数据的做法是不可取的。应该充分利用这些“活”的地理数据，建立与数据源进行同步更新的完整机制，贯彻专用属性数据“谁使用、谁负责”和合理共享的原则，避免产生新的信息孤岛。   以上是应急信息系统中对GIS的需求分析应该考虑的内容。只有对这些问题都分析清楚了，才可能对应急信息系统中GIS的必要性、可行性和技术方案和造价作一正确判断。而这种全局的、客观的、中立的分析，恐怕要在请GIS厂商提供技术方案之前完成。   在应急信息系统领域，类似的成熟技术系统还有Call Center、知识管理系统、视频会议和视频监控系统等。对这些相对成熟、“自成一体”的技术应用系统，都要作类似的分析，才能保证最后的应急信息系统是一个有机的、完整的、体现建设初衷的系统，而不是一组不分主次、繁复、独立的技术系统。   忽视需求分析或缺乏正确的需求分析方法，是存在于信息化建设的通病。对于应急信息系统建设而言，这种只有方案，没有需求分析的现象尤其有害。因为应急信息系统的建设几乎成了一种潮流，而且它同时承载着政府危机管理和电子政务信息资源整合的双重重任。缺乏对需求的分析和规划，会使应急信息系统建设失去理性，导致盲目建设和重复建设，与信息资源整合的精神背道而驰。   2、专业化信息处理系统与应急信息系统的关系   我们对应急信息系统的需求认识往往是始于“混沌”的。尤其是当因为信息系统缺位造成重大损失的时候，更是希望通过一个项目、甚至一个系统的建设毕其功于一役。但是，应急信息系统的主要目标是实现危机管理中的决策支持，离开了专业领域的知识和专业化的信息处理系统的支持，应急信息系统对科学决策的支持就会落空。另一方面，应急信息系统往往是跨管理部门、跨专业领域的系统，涉及多个专业系统。处理这种兼具“宽度”和“深度”的复杂需求的合理做法，是把项目进行分解，把应急信息系统建设与专业化信息处理系统进行合理划分。   一般来说，专业化信息系统负责专业化的信息监测和预警、信息处理；应急信息系统则负责信息的汇聚、分析，以及对会商、决策和资源调度的支持；二种系统之间通过共同认可的标准来实现信息传递和工作协同。应急信息系统从专业化信息处理系统中收集预警监测的结果；应急信息系统则向专业化信息处理系统提交信息加工请求并收集信息处理结果。   检验是否较好划分了专业化信息处理系统和应急信息系统界限的直接办法，是看二者之间是否有足够的独立性。一个好的规划和设计应该是这样的情形：应急信息系统本身不一定很“专业”，但它能与很专业化的信息处理系统高效地协同工作。应急信息系统的核心价值，在于它对跨专业的、公用资源的调度能力；专业的判断和业务流程应该留给专业化的信息处理系统。从这点上来说，应急信息系统其实需要有一定的“通用性”。通用性越好，它动态“接入”不同专业信息系统的能力就越强，整个大系统的“应急”能力也就越好。   举个例子，假设我们针对SARS的预防和控制建设了一个公共卫生应急信息系统，如果它不能百分之八十、九十，甚至更高比例地应用到其它公共卫生突发事件的处理上，那么它的规划和需求定义就是失败的。相反，如果我们在进行需求分析的时候，能把专业化事件处理的差异性需求尽可能地体现在“应用支持层”的专业化信息处理系统中，那么无论是作为通用应急指挥平台的公共卫生应急信息系统，还是专业化的传染病管理信息系统、医院管理信息系统、以及各种科研信息系统，等等，都能沿着相对稳固的需求轨迹发展。四、应急信息系统的规划与标准化   现在我们跳出单个应急信息系统的需求分析，来看看多个系统——或者说整个城市级别的应急信息系统——的需求，或者说一种规划。   根据上面的分析可知，我们如果采用一个相对通用的“应急信息系统”和一系列专业化信息处理系统，可以构成一个完整的、面向各种突发事件的应急信息系统 “两层”构架。也即从理论上说，可以构建城市级别的唯一的、集中的、公用的应急信息系统平台。但在实际操作中，有两个因素制约这种“两层架构”模式。一是系统的规模和负载问题；二是现有的行政管理体制的制约。   根据系统论的原理和系统工程实践经验，每个系统下辖的子系统个数是有限的，超出这一限度，不仅系统的业务负载和复杂度会难以承受，为保障系统运行可靠性所付出的代价也会十分巨大。我们通常采用系统分级的办法来解决这一问题。在应急信息系统建设中，就是通过建立一些区域的或“领域”分中心来分担“总中心” 的负载和复杂性。   但是，采用分中心的“三层”构架，应该满足两个先决条件。否则，就有可能使整个城市的应急信息系统更加混乱和难于管理，操作起来无所适从，甚至变成一盘散沙，为信息资源综合增加新的负担。   第一个条件，还是比较、分析和论证。在具体的城市危机管理环境中采用三层构架，一定要有与两层构架的对比分析。三层系统的优势在于其上的业务操作流程通常可以更好吻合现有管理体制；劣势是分级处理带来了额外的信息分配和汇总的效率开销，甚至为一些导致低效的“门槛”创造了条件。我们对架构进行分析的结果，应该不仅仅是一个构架的模式，而且有具体的构架实施方案，包括对弱点的分析，以及弥补的方法，作为系统后续建设的前提条件。这是应该在决定建分中心之前完成的。   在实际建设过程中，对于城市应急信息系统的构架模式选择，盲目模仿或是“拍脑袋”的情况还是很多的。构架的选择往往不是对流程科学性、系统运行效率、系统建设周期和投入、系统的可操作性等因素进行分析比较的结果，而是避开业务整合的深层困难、对现有管理体制过分迁就和妥协的结果。这对于整个城市的危机管理和信息化建设都是非常不利的。   第二个条件，无论是二层还是三层构架，都离不开标准化基础。统一的数据标准制定应该在应急信息系统的总体规划层面，而不是某个具体的应急信息系统建设的层面来进行。在某个具体应用系统中谈统一标准的意义是十分有限的。即使每个系统都实现了“内部”的统一标准，也可能导致多个系统之间无法沟通。   对于标准化的认识，也是信息化建设中误区多多的一个领域。如把统一数据规划甚至统一数据库设计等同为数据标准化，把标准化局限于管理标准化而无视应用标准化，把应急信息系统的标准化局限于应急事件的分级，等等。应用标准化是我国信息化建设的一个弱点和紧迫点，也是应急信息系统建设的一项基础性工作。如果能在国家层面整合专业化研究资源，组织面向应急指挥和危机管理的统一的标准化研究，则能有效促进整个国家的应急信息系统的建设；反之，如果我们不抓住应急信息系统这一建设背景，则不仅应急信息系统的建设不能进入有序状态，标准化建设本身也将摆脱不了滞后于信息系统建设的状况。（参考《把标准做“实”》）。参考文献：1.       《把标准做“实”》 黄以宽，《信息化建设》2.       《浅论应急指挥系统的基础性研究》，黄以宽，第一届中国政府电子政务论坛交流论文，2004-103.       《应急联动系统的需求“升级”》 黄以宽，《上海信息化》2005-1
请登录后再发表评论!
路灯 ( 景观 ) 智能化监控管理系统简介一、系统概况 　　 天津市经济开发区路灯 ( 景观 ) 智能监控管理系统项目于 2003 年立项，当年公开招标，由山东地天泰科技有限公司中标， 2004 年 5 月竣工验收。该系统项目含有一个中央监控室、 154 个路灯和景观灯监控点、 10 个视频图象监控点、 8000 个单灯控制器，总投资 600 万元。 该系统是由 GPS 卫星数据接收系统、 NOTER 网卫星通讯平台、数字微波视频传输 / 控制系统、 GIS 地理信息系统、多媒体背投屏幕电视墙、前置后备冗余工作站、 GSM(SMS) 短信报警系统、电话语音自动查询系统、载波方式节能点控系统等组成。可以对全区范围内实现对路灯照明及景观照明的遥控、遥信、遥测、遥调、遥视。 1 、中央监控室 　　 中央监控室建筑面积约 160m2 ，是整个系统的核心。中心配有 120 英寸丹麦 SVS 硬质背式投影屏幕两面及日本松下 29 英寸纯平监视器 6 台组成电视墙，用以显示各种图文信息；中心还配备视频工作站、数据服务器、前置工作站、后置工作站和 GIS 工作站五个值班位，同时配置 19 英寸标准机柜两台，分别安装 NOTER 网络卫星数据收发设备、 10 路微波发射接收及控制设备、美国山特 32AH 在线式 UPS 不间断电源、 GSM(SMS) 短信息报警发射模块、卫星数据收发器、 UHF 维修调度通讯设备等。 2 、摄像机终端控制设备 　　 一期工程设定 10 个摄像机位，分为三组分别设立在 : 泰达中心酒店大楼楼顶平台，安装摄像头 5 个，距地面高度约 90m ；金色阳光大厦楼顶平台，安装摄像头 3 个，距地面高度约 50m ；克瑞思大厦楼顶平台，安装摄像头 2 个，距地面高度约 80m 。 3 、路灯监控分站 (RTU) 　　 全区一期工程完成 RTU 站点 86 个，基本覆盖全区。所有的站点均设为 “ 点控 ” 站，安装于各箱式变压器的空闲位置，和箱变内原二次控制线路连接，溶为一体。安装 RTU 后，均能对该站点路灯实现遥控、遥测、遥信和遥调。 4 、景观照明监控分站 (RTU) 　　 一期工程共安装景观 RTU 站点 68 个，对景观照明站点实现遥控、遥信、遥测。遥视系统采用数字微波发送接收方式，工作频段为 2.4G 和 5.8G( 中继 ) 的公共频段，采用 MPEG4 数字压缩技术传输 / 解调。该系统具有占用频段窄，保密性好，抗干扰性强，易扩展，造价低等特点，是目前城市图像传输的第一选择，通常在无遮挡的情况下可以传输 30km 。 5 、调压灯控器 　　 一期工程安装灯控器共 8000 个，分别安装在各路灯杆维修孔内，系统完成后可对单灯实现点控、检测和调压。 二、系统原理及功能 1 、遥信 　　 系统对路灯、景观站点的运行状态进行实时检测。在 0.1 秒内 RTU 可主动并优先向主站报警下列情况：电压欠限、电压超限、电流欠限、电流超限、熔断器熔断、接触器应吸未吸或应分未分、空开跳闸、供电网络掉电。主站收到报警后，将自动弹出警示窗并有提示语音告知值班员，值班员可根据故障报警的内容及时采取应急措施。同时， GSM(SMS) 短信息模块自动将该信息发到预先设定的手机上。计算机把以上报警信息自动记录并存入数据库供日后查阅和打印。 电话查询：在全球任何一部电话机上，可通过技术中心查询热线，根据提示音输入密码，方便查询系统运行情况。 2 、遥测 　　 系统对路灯景观箱变 RTU 以每小时 N 次 (N≤6) 间隔，自动查询各站点运行数据，并将此数据存入数据库，自动绘出该站点本年、本月亮灯率曲线彩图、三相电压、电流曲线彩图，必要时可打印。值班员还可以手动对全区或某一站点运行数据即时查询。采用 POLLING 通讯方式，全区查询一遍需要 5 分钟左右。 3 、遥控 　　 系统根据 GPS 卫星接收系统单元接收到的本城市所在地球经纬度，自动将一年内日出日落的晨光昏影的格林威治时间，自动生成每日开关灯的北京时间序列表。然后将该时间序列表由主站下发到各分站，分站准确按照该时间表自运行。系统还可以根据天气情况或突发事件（如出现大风雷雨天气、交通事故、现场检修、防空警报等情况）的需要，手动或切换到光控开关灯方式，对一个灯位、一条路段、一个区域或全区进行即时开关灯控制。 控制的方式一般可分为 : 预编程控制 ( 设为不同的亮灯方式 ) 、分组控制、单灯控制。 4 、遥调 ( 经济运行方式 ) 　　 调压的执行终端由安装的每盏灯杆中的灯控器完成。灯控器由电源供给电路、灯电流检测电路、电子开关电路、降压自耦变压器、中央处理器等单元组成。经过电力线载波，受控于分站 RTU 。当 RTU 接收到来自主站的调压指令时，通过点控数据收发器，控制单个、部分或所有的灯控器进入经济运行方式。另外，灯控器根据路灯的工作电流，判断该灯是否正常工作。有故障时，将故障信息反向传输给中央控制室，利用大屏幕显示来。同时，将数据自动存入数据库，必要时可打印故障灯位址号、数量、时间等清单，供维修人员使用。路灯在经济运行方式工作时，节能率设计在 25%-33% 。 5 、遥视 　　 在数字微波监控中心，图像接收采用一对一接收前端图像，首先将接收天线安装在制高点上，分别对准前端三个数字微波监控点和一个中继点的天线发射过来的方向。从接收天线接收到的图像信号，通过放大器、接收机就可以还原出前端数字微波监控的图像，用户可以直接接入监视器进行监看。 　　 对中心控制主机 ( 如视频主机，控制键盘 ) 发出的控制指令，可利用数字图象微波的透明双向传输通道来传输，直接接入到接收机，通过 RS232 或 RS422/485 传输接口自适应 ( 支持任何云台，镜头串行协议 ) ，将数字微波传输到前端的发射机，再将发射机出来的总线信号接到摄像机，这样就可对远端的镜头的光圈、焦距、变倍以及云台的上、下、左、右进行自动控制。摄像机选择索尼高速一体化球机 , 可实现 360° 水平无极旋转， 180° 垂直方向转动，像素高、图像清晰，并可根据光照的变化自动进行光圈调整。 三、系统的经济和社会现实意义 1. 可观的经济效益 (1) 延长灯泡寿命 　　 午夜以后，供往路灯的电压一般能升高到 245V 以上甚至 270V ，这样高的电压使灯泡急剧缩短使用寿命，实际使用不到 4000 小时就坏掉了，比理论寿命 6000 小时少 2000 小时左右。采用该系统后，灯泡在任何时候都不会出现过压运行，还相应节省因更换灯泡的各项维护费用。 (2) 节约电力资源和费用支出 　　 由于本系统可以任意组态，既保证合理的光照度，又利于市民生活、交通、社会治安，还可大大降低电费支出。若将路灯电压降低额定电压 10% ，这至少节省 20% 电量，设全区有 250W 钠灯 10000 盏，每 KWH 电费 0.6 元，每天开灯时间按 11 小时计算，全年可节省 120 万元。 　　 同时由于实现了管理的自动化，可以节约大量人力、车辆巡检费用、人工加班费用，大大降低灯泡损坏率和灯泡拆换费用。 　　 据测算，采用本系统一次性投资，节约费用带来的经济效益回报期为 2 ～ 3 年。 2 、深远的社会效益 　　 道路照明和节约费用是相互矛盾的，解决这种矛盾的本身就是发展。本系统一改传统落后的路灯控制方式，使城市路灯管理进入网络化、智能化、现代化的轨道。在向科技要经济效益的同时，还有深远的社会效益，主要体现在以下几个方面： (1) 推动了道路照明事业的发展 　　 城市道路、景观照明是城市一道不可缺少的亮丽风景线。一个现代化的城市，路灯就好比是这座城市的眼睛。多少年来，路灯行业的工作者们常年劳作于寒暑风雨之中。本系统的出现是广大路灯工作者们的殷切希望，传统落后的控制手段已不适应信息化、网络化高速发展的时代要求。 (2) 有利于社会治安和交通安全 　　 由于大部分城市用 “ 半夜灯 ” 方式节能，从而带来午夜后整个城市一片漆黑，给人们的夜间出行带来不便，且影响城市的形象。采用 “ 全夜灯 ” 方式照明将明显减少夜晚案发率。 (3) 提高路灯的服务质量 传统的控制手段不能保证路灯无误的正常运行，因故障或其他原因造成的大片灭灯现象时有发生，群众对此意见很大。安装系统后，出现重大事故时，可以及时组织抢修，保证了路灯的服务质量。城市道路照明中的场景控制策略及其实现作者: 照明工程师社区 来源:照明工程师社区 时间:01月08日 13:15 摘要：城市道路照明控制系统可以通过场景控制达到提高照明质量和节约电能的双重效果。文章分析了智能化道路照明控制系统的几种主要场景控制策略，包括时间表控制、组群控制和环境参数辅助控制，并给出了具体的实现方法。引 言道路照明是城市绿色照明工程的重要组成部分。随着计算机技术、无线数据传输技术和现代电力电子技术的飞速发展，传统的道路照明也开始向着智能化的方向前进，尤其是已经可以实现单灯控制和故障检测。智能化的城市道路照明控制系统在提高照明质量、美化城市夜景的同时，还可以获得明显的节能效果，提高市政管理水平。智能化已经成为城市道路照明发展的必然趋势。智能化道路照明系统概述智能化的道路照明控制系统的一个重要特征就是系统能够根据不同区域的不同功能需求，在每天的不同时段、不同自然光照度或者不同交通流量情况下，按照特定的设置，实现对道路照明的动态智能化管理，即TPO(Time/Place/Occasion)管理。这些设置就是用户根据经验和需要设定的场景，智能化的道路照明系统正是通过场景控制获得了提高照明质量和节约电能的双重效果。一种典型智能化道路照明系统的组成示意图，如图1所示。该系统由照明管理中心平台、线路级智能监控终端和单灯智能控制器（或智能化数字镇流器）组成。照明管理中心平台负责整个系统的集中管理，进行远程实时控制、系统运行信息采集和监测。线路级智能监控终端负责所辖路段的智能化照明控制、解析执行管理中心指令和采集上报运行数据。单灯智能控制器（或智能化数字镇流器）负责单个路灯的控制和状态检测。线路级智能监控终端和照明管理中心之间可以采用无线通信（如GPRS）或以太网进行数据传输，单灯控制器（或智能化数字镇流器）和线路级智能监控终端之间采用窄带电力线载波通信方式进行数据传输。场景控制的概念所谓场景控制就是通过综合考虑和分析与道路照明密切相关的时间、路段、环境照度和交通流量等因素，按照预设的控制策略，对道路照明进行动态智能化管理，控制路灯在不同情况下工作在不同状态，实现多样化的道路照明场景，从而在提高照明质量的同时获得最佳的节能效果。按照影响道路照明控制的主要因素可以将场景控制策略分为时间表控制、组群控制和环境参数辅助控制。利用场景控制可以实现多种情景模式控制，例如，在单杆单灯情况下，可以实现隔灯点亮；在单杆多灯情况下，可以实现一杆亮一盏灯／两盏灯／三盏灯／四盏灯等多种组合情况。时间表控制时间控制主要包括每天的及时开关灯控制和夜间按照道路交通流量分时段进行的组群控制或调光控制。这些控制操作不仅应该能够取得明显的节电效果，还应该能够提高道路照明质量。1 开关灯时间的确定尽管对于某一城市来说，完全可以根据当地的日照曲线确定出每个月份大致的开关灯时间，但是由于地球上每一点的地理位置不同，其对应的日出日落时间也不相同；并且由于地球的自转轴相对于地球和太阳的平面剧倾斜的，再加上地球的公转作用，因此即使是同一地区其每天的日出日落时间也不是完全相同的。所以为了实现精确的开关灯控制，更为合理的方法应该是根据城市所处的经纬度计算出当地每天的开关灯时间。文献[2]给出了一种较好的日出日落时间计算方法。2 夜间分时段控制夜间的道路照明控制主要是根据道路夜间交通流量变化规律进行分时段控制，尽管在一条道路上每天夜间不同时刻的交通流量会略有差异，但就一段时间（一个月或几个月）的统计规律来看，这种变化的波动并不很大，所以完全可以按照平均交通流量变化规律把一年的照明周期划分成若干照明季节。表1给出的是某路段一年内的照明季节划分情况。表中各划分点既是本季节的起始日期，也是上个季节的终止日期。在每个照明季节内每天都按照同样的时段划分进行自动的照明控制。照明季节内的控制时段主要是根据对特定路段在该照明季节内每天不同时段的交通流量统计规律进行划分。表2给出的是某路段在照明季节三内的夜间控制时段划分情况。表中各划分点既是本时段的起始时间，也是上个时段的终止日期。场景的具体内容可以是调光、部分开关灯或者全部开关灯，用户可以根据每个线路级智能监控终端所辖路段的实际情况设定合理的场景模式。尽管每天的开关灯时间不同，但夜间的控制时段一定是介于开灯和关灯时间之间的，因此，加上开灯和关灯，一天实际上就被分成了五个控制时段，如图2所示。3 时段控制策略的软件实现在主循环内程序首先应该能够根据当前日期，选择合适的照明季节，读取相应的时段划分表以便进行时段控制。照明季节选择流程如图3所示。图中寄存器Month1、Month2、Month3、Month4、Month5和Month6中存放照明季节划分表中各划分点中的月份信息。寄存器Date1、Date2、Date3、Date4、Dates和Date6中存放照明季节划分表中各划分点中的日期信息。寄存器Month和Date中分别存放当前月份和当前日期信息。此流程在照明季节划分上，要求一个照明季节至少包含一个月，并且最多不超过四个月。由于每天的开关灯时间不同，所以必须在每天执行完关灯操作之后计算出新的一天的开关灯时间。在主循环内程序不断读取当前时间，和当前的时间策略表比较，决定是否执行控制操作或者执行何种控制操作。为了保证系统任何时刻上电都能立即恢复到正确的场景，在程序设计上就不能采用简单的时间点判断(即判断当前时刻是否到达某个设定的控制时段划分点)方法，而应该使用时间段判断(即判断当前时刻应该处于哪个设定的控制时段)方法。时间段判断的流程如图4所示。图中寄存器Hour1、Hour2、Hour3、Hour4和Hour5分别存放各时段划分点的小时信息。寄存器Minu1、Minu2、Minu3、Minu4和Minu5分别存放各时段划分点的分钟信息。寄存器Hour和Minu中存放当前时间信息。此流程在照明时段的划分上，要求中间时段的划分点必须介于正常的开关灯时间点之间。采用时段判断的方法，使得系统不论在何时上电，都能够立即进入正确的控制场景，从而保证了照明质量。组群控制低压电力线载波通信技术的发展使得低成本的单灯控制和检测成为可能，从而也使路灯的控制变得更加灵活。同一路段的不同路灯，由于其所处位置的不同，对其照明控制的要求可能也不相同。比如某个路段处于十字路口的路灯，由于其位置的重要特殊性，就不能和其他路灯同时进行相同的场景控制。再就是对于一杆多灯的情况，需要考虑在交通流量减小时部分关闭以节约电能和减少光污染，这些都属于组群控制。组群控制可以通过配置控制系统底层(线路级智能控制终端和单灯智能控制器)之间的通信协议实现。对应于组群控制的通信协议数据包格式如图5所示。控制类型声明单灯智能控制器应该执行何种控制操作，起始地址、终止地址和作用范围一起声明了对受控路灯节点的地址编号要求，这样就相当于将符合相同条件的路灯节点绑定在一起，从而可以实现群组控制。作用范围根据单灯智能控制器地址编号的数学特征可以分为奇数有效、偶数有效等多种情况，因此可以实现多样化的组群控制组合。环境参数辅助控制智能化的道路照明控制系统还应该能够根据天气、交通流量等实际的环境参数调整照明控制措施，以获得更好的照明质量和节电效果。1 照度辅助控制考虑到天气异常变化的影响，比如在阴雨天气，实际的天黑时间将比正常情况提前，天亮时间将会推迟，这样就必须提前开灯或者推迟关灯。所以在这种情况下要提高照明质量就不能再单纯按照时段划分中的开关灯时间进行控制，而必须综合考虑自然环境照度和当前时间，执行相应的开灯或关灯操作。需要注意的是，为了保证系统的稳定性，在进行环境照度采集时必须采取延时或者软件滤波等措施消除环境照度尖峰干扰(如闪电)。此外，还应该限定根据照度进行控制的作用时间段或者采用模糊控制手段区分干扰和正常情况，避免因突变持续性干扰造成的误动作。依据环境照度进行辅助开灯控制只是在控制时段5内且距离正常开灯时间1h内的时间段内有效。同样，依据环境照度进行辅助的延迟关灯控制只是在控制时段5内且在正常关灯时间之后的1h内的时间段内有效，超出这段时间将不再考虑环境照度因素。2 交通流量辅助控制在智能化的照明控制系统中要实现人性化的照明控制，还必须考虑同一照明季节内交通流量变化规律的异常情况，尤其是在一些比较重要的节假日，人们的作息习惯会和平时出现差异，因此道路交通流量曲线与平时相比会出现较大波动，这时就不能再按照正常的时间段划分进行控制，而必须借助于交通流量辅助控制。考虑到这种波动主要集中在控制时段2和控制时段3内，因此限定交通流量辅助控制也只是在控制时段2和控制时段3内有效。在进行交通流量数据采集时，为了保证照度采集的准确性，应该合理安排数据采集的周期。结束语为了达到更好的效果，还可以进一步细化照明季节划分和控制时段划分，其算法和流程可能会更加复杂，但在原理上与本文中的划分是相同的。现场的实际应用表明，本文提出的城市道路照明系统场景控制策略较好地实现了对路灯的智能化控制，能够在提高照明质量的同时获得明显的节电效果，所提出的算法流程也是切实可行、稳定可靠的。
请登录后再发表评论!