呼叫中心平台基础通用性软件技术架构

呼叫中心平台基础通用性软件技术架构（精选5篇）

呼叫中心平台基础通用性软件技术架构 篇1

呼叫中心平台基础通用性软件技术架构

12328电话系统由呼叫中心平台和电话管理系统平台组成。呼叫中心平台包括电话服务系统、短信服务系统、微信服务系统、服务监督网站、移动终端服务系统、邮件服务系统、转办受理系统、交办受理系统；电话管理系统平台包括业务处理系统、知识库系统、决策分析系统、运行管理系统。

（一）呼叫中心平台 1．电话服务系统

电话服务系统通过排队、接入、保持、录音、三方通话、外呼、转接等功能，为投诉举报、信息咨询、意见受理等业务提供电话受理渠道，并实现呼入弹屏、历史呼叫自动检索、数据项录入、知识库检索等功能。

博域通讯一体化呼叫中心平台产品BYICC2.0采用上表所述型号的呼叫中心行业主流品牌硬件作为本产品出厂时的呼叫中心系统硬件平台，从而为保障呼叫中心系统平台的电信运营商级稳定性奠定了坚实的硬件基础。采用博域通讯一体化呼叫中心平台产品BYICC2.0的呼叫中心系统硬件(专业部分)通常包括：[1]一体化CTI通讯服务器，模拟语音卡{包括通用底板，板载的功能模块如外线模块、坐席模块、内外线联合模块等，以及坐席铃流馈电电源}，数字中继语音卡{支持ISDN PRI[30B+D]信令以及中国7号信令[TUP、ISUP]以及中国1号信令的呼叫接续，支持75Ω E1同轴线、100Ω T1双绞线及120Ω E1双绞线等多种阻抗的数字中继线}，VoIP语音网关(VOIP语音卡){支持SIP/SDP/H.323协议}，CT-BUS总线电缆等；或[2]多媒体(语音)交换机{包括交换机机架、交换机中央主控板与后出线板、交换机功能板如模拟功能板/数字中继板/VoIP功能板/Asterisk功能板以及与功能板对应的后出线板、板载模块等}。作为一站式呼叫中心解决方案与开放式的标准的呼叫中心(联络中心)系统平台，博域通讯一体化呼叫中心平台产品BYICC2.0在一台CTI通讯服务器(多媒体语音交换机)上融合了呼叫中心系统的所有常用功能，这对于降低呼叫中心系统的建设和维护成本具有重要意义；博域通讯一体化呼叫中心平台产品BYICC2.0高度的集成性和整合性极大地回避了非集成系统普遍遇到的软硬件冲突以及不同厂家的系统接口的连接和配置难题，为企业/政府机关免去了昂贵的成本、复杂的网络连接以及众多服务器和程控交换机设备，大大地降低了呼叫中心系统的建设成本。博域通讯一体化呼叫中心平台产品BYICC2.0(也称为一体化呼叫中心系统产品BYICC2.0)致力于面向广大企业和政府机构普及呼叫中心系统(Call Center)。经过大连广播电视台、深圳地铁四号线、佛山水业集团、郴州市桂东县人民政府、岳阳市公安局交通警察支队、泉州市老龄办、招远市公安局、广东江门海关、黑龙江省人民政府采购管理办公室、大理广电、威海第二热电集团、丽江数字电视、滨州市博兴县教育局、深圳华强电子世界网、广西环江电力、中青旅山水时尚酒店、广州白天鹅宾馆、盘锦市司法局、南宁海方燃气、清远市劳动和社会保障局、贵州四方鼎立、长安铃木汽车、新疆特力电信、长沙三诺生物、昭通广电、广西出入境检验检疫局、巴彦淖尔市商务局、无锡生活在线、黑龙江省柴河林业局、淄博市淄川区城市管理行政执法局、西宁市财政局、文山广电、保山广电、西双版纳广电、大同市纪委监察局、无锡市民政局、恩施自来水、寻甸县第一人民医院、深圳市司法局、荆门市农业局、大宝化工、乌兰察布市住房公积金管理中心、云南省大理市第二人民医院、福建省莆田市老龄工作委员会、辽宁省数字证书认证中心、香港昌机集团等众多企业/政府机关呼叫中心成功案例验证的博域通讯一体化呼叫中心平台产品BYICC2.0作为CTI软硬件一体化平台开机即可使用，硬件平台采用呼叫中心行业主流硬件厂商(如杭州三汇、深圳东进、广州毅航通信、上海迅时通信等)的多媒体交换机和语音板卡以及VOIP语音网关，以ALL-IN-ONE/嵌入式的方式集成并固化了PBX/ACD/IVR/CTI/数字录音/语音信箱/VOIP[支持完全分布式、远程中继和远程IP座席方式的混合应用]/TTS/电子传真/来电弹屏（Screen PopUp）/人工座席软件/短信/统计报表软件/维护管理工具软件/智能自动外拨（也称为智能自动外呼或自动批量外呼）软件/客户关系管理(CRM)/工作流(派工单流转/电子工单流转)管理/与已有计算机技术支持系统的数据接口/易学易用的软件二次开发环境以及软件二次开发的模板程序源代码(呼叫中心系统第三方开发接口)/运营管理等核心的呼叫中心功能模块，同时提供定制化软件开发技术服务。博域通讯一体化呼叫中心平台产品BYICC2.0中的交互式语音应答(IVR)流程软件BYICCIVR2.0和座席软件BYICCAgent2.0以及统计报表软件BYICCReport2.0已经内置了经过规模商用验证的通用客户关系管理(CRM)功能，通常能满足大部分最终使用部门的业务功能需求。这里提到的通用客户关系管理(CRM)功能包括客户档案信息管理，投诉建议记录管理，业务受理记录管理，业务咨询记录管理，业务查询记录管理，客户回访记录管理，电话营销管理，派工单/工作流管理，销售业务管理，和与已有计算机技术支持系统(如MIS系统/GIS系统/OA系统/ERP系统/BOSS系统等)的数据接口等。作为易于建设/部署实施、易于管理/维护、易于二次开发的高度集成的呼叫中心系统平台成熟产品，对于CRM个性化业务功能需求较少的呼叫中心系统/客户服务中心系统项目(不论系统采用SS1/ISDN PRI/SS7的数字中继线路还是模拟电话线路，不论系统配置4个座席还是64个座席或120个座席)，采用博域通讯一体化呼叫中心平台产品BYICC2.0(也称为一体化呼叫中心系统产品BYICC2.0)的贵单位呼叫中心系统即装即用，在1个工作日内即可直接投入正式的商业运行。呼叫中心平台是指对各行各业的用户都适用的呼叫中心系统的通用部分，往往由专业的呼叫中心厂商提供。对于个性化应用较少的企业/政府部门，只需在呼叫中心平台上做个性化配置，呼叫中心系统就可以投入运营。对于个性化应用功能需求较多的企业/政府部门，则需要在呼叫中心平台上做二次开发，二次开发可以由系统集成商(SI)来完成，对于开发力量较强的企业/政府部门也可以自己进行二次开发。对于那些呼叫中心应用软件功能做得比较完善的高级呼叫中心平台，只需进行软件的个性化配置，而无须做二次开发。如果用户需要行业化的客户服务流程，则需外购专业的CRM(客户关系管理)软件。呼叫中心平台通过二次开发接口与专业CRM软件集成。因此，呼叫中心平台，就象房子的地基，支撑起呼叫中心系统的业务和系统负荷。呼叫中心系统的内核是以通信为基础的企业[政府机关]对内对外沟通联络系统，最具技术含量的核心部分是交换机系统PBX(Private Branch Exchange)以及CTI(计算机电信集成)系统；呼叫中心系统制造商需要依靠对通信技术的深刻理解，才能提供高稳定、高可用、高可靠的PBX系统以及CTI系统，灵活可靠地满足企业[政府机关]对于通信不断增长和变化的需求。呼叫中心中间件(即通常所讲的CTI中间件)产品是呼叫中心系统中的各种计算机系统与通信系统之间的桥梁，屏蔽了呼叫中心系统的底层通信的复杂性，为软件开发人员提供了一个简单而统一的易学易用的软件二次开发环境，减少了呼叫中心系统的程序设计的复杂性，在实施呼叫中心系统项目时将软件开发人员的注意力集中到最终用户的个性化CRM业务流程(如客户档案管理、业务咨询管理、业务查询管理、业务受理管理、投诉建议管理、客户回访与市场调查管理、工作流/工单管理、销售业务管理、与已有计算机技术支持系统[如MIS/ERP]的数据接口等)的定制开发上，从而大大减少了软件开发人员在技术上的负担。采用CTI中间件产品建设呼叫中心系统项目的显著优势包括：(1)减少呼叫中心系统项目的建设成本；(2)降低呼叫中心系统开发/实施的失败率；(3)缩短呼叫中心系统的开发周期；(4)节约呼叫中心系统的开发成本；(5)简化呼叫中心系统与已有计算机技术支持系统的集成/整合；(6)减少呼叫中心系统的维护费用；(7)提高呼叫中心系统的开发质量；(8)保证呼叫中心系统技术进步的连续性；(9)增强呼叫中心系统的生命力；(10)保护已有的投资。

2．服务监督网站

部级12328网站主要实现省级子网站导航和部级服务监督综合信息政务公开。地市级12328网站实现投诉举报业务受理、业务信息查询、政务信息公开等功能。省级不受理呼叫业务的，实现地市级子网站导航和省级服务监督综合信息政务公开；省级受理呼叫业务的，在提供地市级子网站导航和省级服务监督综合信息政务公开的同时，还需实现投诉举报业务受理、业务信息查询、政务信息公开等功能。

3．短信服务系统 12328短信平台实现投诉举报、信息咨询等业务受理和公众出行等公益信息发布，以及投诉举报处理结果告知等功能。

4．微信服务系统

实现投诉举报、信息咨询等业务受理，业务处理进展查询和结果反馈，公众出行等公益信息发布功能。

5．移动终端服务系统

移动终端APP实现投诉举报、信息咨询等业务受理，业务处理进展查询和结果反馈，公众出行等公益信息发布功能。

6．邮件服务系统

通过12328邮箱方式受理投诉举报、信息咨询等业务，自动形成业务受理工单，并通过邮件回复进行业务处理结果反馈。

7．转办受理系统

受理外单位或外部门转送的交通运输服务监督业务，实现工单生成、业务处理及结果反馈功能。

8．交办受理系统

受理上级部门交办的交通运输服务监督业务，实现工单生成、业务处理及结果反馈功能。

（二）电话管理系统平台 1．业务受理系统

业务受理系统接收电话、短信、网站、邮件、移动终端、微信等渠道受理的服务监督信息。工作人员通过业务受理系统对信息内容进行整理与记录后，按照《12328电话系统业务流程规范》填写电子表格，形成业务处理工单。

2．业务处理系统

与业务处理工作流程紧密结合，实现工单流转、催办督办、查询反馈、企业直通车、多渠道工单查重及并案处理、重大投诉举报处理等功能。

3．统计分析系统

结合对12328电话业务统计数据的挖掘整理，实现相关类型数据的同比分析、环比分析，结合管理决策的需要实现行业热点分析、行业动态预警、行业专题分析、趋势分析等功能。

4．知识库系统

知识库系统具备知识生命周期管理、多库管理、文档锁定、知识版本控制、知识导入导出、知识维护流程管理、编码管理、配置管理、系统管理等功能，能结合结构化数据和非结构化数据对图文、表格等多种类型数据知识进行采编、查询和管理。知识库系统一方面可作为一个独立系统提供信息查询服务，另一方面可通过与电话管理系统整合，结合具体业务运行数据的积累，实现相关知识信息的动态更新。

5．运行管理系统

运行管理系统实现初始化、工作流配置和权限设置等系统管理维护功能，实现电话业务系统运行监控、工作人员考试管理与绩效考核功能。

呼叫中心平台基础通用性软件技术架构 篇2

1.1 SDI方式的发展方向

若在媒体融合时代背景下, 电视中心的基础架构技术始终按照传统架构方向发展, 那么其所具备的优势可以表现为技术的不断成熟, 可靠性有所提高并被广泛应用, 在此基础上, 信号实际传输延迟率低, 在直播中的应用效果最佳[1]。同时, 信号与线缆的对象相对比较简单, 并且逻辑关系十分清晰, 方便进行维护, 对于出现的故障很容易进行定位与排查。但是, 同样具有一定的劣势:在电视中心SDI基础架构信源量快速增加的基础上, 使得SDI/HD-SDI/3G-SDI信号调度矩阵自身的规模不断扩大, 并且布线与信号处理链路变得更加复杂, 所以, 就必须要整合不同信号、线缆以及网络。这样一来, 系统集成的实施成本就会提高, 而且结构并不支持灵活拓展, 很难利用软件来实现系统流程的再造。

1.2 电视中心基础架构的IP化发展方向

电视中心基础架构技术的另外发展方向就是对通用的共享/ 双向IP化架构充分利用, 然而, 只能针对AV数据信息的传输来使用专用协议。与此同时, 根据所使用的协议, 可以将IP化划分成两部分, 即以太网音视频桥接技术与时间码概念, 可以用AVB和SMPTE来表示[2]。而在SMPTE中, 又可以划分成专用IP交换机与通用IP交换机两种。

电视中心IP化的基础设施可以将电视、广播以及报纸等媒体同移动互联网及互联网间的通信边界有效消解, 并且积极地推动传统媒体和新兴媒体的融合发展, 进而不断满足媒体融合时代的业务需求。其中, IP网络架构十分简洁, 而且布线相对简单, 仅仅需要一根网线就能够将数据、控制以及同步等问题进行有效地解决, 并根据不同业务的特点来更灵活配置网络。同时, 系统流程与业务流程也能够利用软件进行动态的定制, 其实际的生产能力更容易实现平滑拓展与升级。

2 视音频信号IP化分析

2.1 视音频信号IP化应用前提

IP网络本身所具备的特点就是端到端时延不可控与尽力转发等, 但是, 电视中心的音视频数据量十分巨大, 所以, 音视频的应用对于延时与同步具有极强的敏感性, 对抖动的要求也比较高。而且, 音视频的码率并不能自动进行调整, 所以, 要想实现电视中心的IP化, 其中最重要的前提就是网络的可用宽带超出其所能够承载数据的码率。要想在电视中心台内实现基带无压缩IP视频数据路由交换, 其最低的要求就是10GE以太网[3]。

在电视中心的IP化接口转换处应使用IP通用协议, 并且保证信号的交叉点切换转变成基于包的路由交换。与此同时, 为了对SDI over IP传输以及交换与分发网络实时数据的共享宽带传输的过程中, 实际面临的延时与丢包问题进行解决, 并保证传输的可靠性, 可以通过以下几种方法来实现:第一, 视音频的信号数据应根据IP具体规范内容进行分组并打包传输;第二, 应积极引进RTP/RTCP/RTSP的实时传输协议;第三, 将区分服务与RTVP引入其中;第四, 充分利用延时包转发等相关技术;第五, 利用FEC技术。

2.2 压缩编码视音频流IP化

所谓的TS over IP, 就是压缩编码音视频流与业务控制流等IP化。在目前阶段, 使用最广泛的视音频处理设备都已经配置了标准性的以太网接口, 并且同样支持TS over IP码流的实际输出。

2.3 SDI基带信号IP化

SDI over IP就是无压缩视音频SDI基带信号IP化, 而实时处理与传输以及交换的最核心设备, 在现阶段主要包括IP Gateway板卡等, 能够使得实时IP视频的无缝切换、分包以及路由精准到帧。但是, 当前的SDI over IP实际应用始终存在链路宽带不充足且系统交换能力不高等多种类型的问题。

2.4 IP化矩阵

第一, SDN。文中所讲的SDN, 就是软件定义网络, 在IP化基础架构中占据核心位置, 而SDN则是硬件软化的软件, 属于控制和管理类型的软件。在其管理与控制下, 通用IP交换机与专业IP交换机都能够有效地实现传统的SDI矩阵功能。把网络设备的控制层和数据层进行分离, SDN就可以对网络流量进行控制, 并实现宽带管理, 同时也支持冗余备份的功能。在此基础上, SDN也可以通过使用传统的操作方式或者是IT化的操作方式进行信号的管理与分配, 并有效地提供接口/ 界面的设置与管理以及操作, 实现混合性的操作, 进而完成AV与网络设备、矩阵的配置与交叉点的切换。除此之外, 还可以提供外部控制所需要的SDK, 能够实现同远程维护系统的通讯, 并积极支持远程固件的升级。

第二, SDVN。由Evertz公司所研发的SDN, 在IPX的基础上能够有效地实现对SDI信号路由的管理, 并对宽带进行管理。同时, 操作人员也可以根据传统的方式来进行管理系统的相关操作。

第三, IP交换机+SDN。在IP网络基础上所形成的SDI矩阵被称为SDI over IP路由矩阵。这种IP化的矩阵, 本质就是IP交换机+SDN, 并且是在SDN的控制和管理背景下, 通过IP交换机来完成矩阵的一种功能。其中, 路由控制功能类似于传统矩阵, 对无阻塞智能级联予以一定的支持, 可以通过独立局域网来进行控制。IP化的矩阵所具备的输入与输出板能够对无压缩的YUV基带SDI信号进行实时的打包操作, 并且使其转变为IP数据包, 这样一来, 就可以在10GE以太网中进行相应的传输[4]。而IP矩阵则能够保证所有的信号通过所有的交叉点来实现输入输出路由, 进而更好地切换精度。而图一所表示的与60×60HD-SDI矩阵相似, 其中基带HD-SDI的数据流是1.5Gbps, 并且每万兆的端口都能够承受住六路未经压缩的HD-SDI信号路由并实现切换。

3 结论

综上所述, 目前阶段, 传统媒体同新兴媒体的融合速度不断加快, 而在此背景下, 积极实现电视中心基础架构的IP化已经成为当下最重要的工作内容。而在电视中心基础架构IP化的实际应用中却始终存在一定的需求, 在基础层面的阻碍并不多, 仅仅需要对电视中心基础架构IP化的相关技术标准进行完善即可。与此同时, 各级的电视台制播技术工作人员则应该对电视中心基础架构的IP化技术发展趋势及进展进行实时的跟踪, 并且根据媒体融合时代下的业务平台来建设, 科学合理地引进IP化的解决方案, 进而使得传统媒体与新兴媒体之间能够更快地实现融合发展, 进而不断满足媒体融合时代背景下的各种业务需求。文章对电视中心基础架构技术全IP化的发展背景进行了分析, 并重点阐述了视音频信号的IP化, 最主要的目的就是不断加快传统媒体同新兴媒体融合发展的速度, 最终使我国的电视广播行业在媒体融合时代背景下更好地发展与进步。

参考文献

[1]徐俭, 马春, 徐有聪, 等.媒体融合时代电视中心IP化基础架构技术初探[J].广播电视信息, 2015 (3) :64-67, 74.

[2]韦安明.电视中心基础架构IP化探讨[J].广播与电视技术, 2015, 42 (4) :18-21.

[3]王献冠, 倪宏, 朱明, 等.有线电视网络IP数据封装方法的分析与改进[J].小型微型计算机系统, 2013, 34 (4) :721-726.

用软件定义基础架构重塑数据中心 篇3

以我国为例，我国现在大约拥有8.38亿中国互联网用户、7.19亿中国博客用户、4.68亿微信活跃用户，有超过4亿台智能手机，还有超过2000万新的PC和平板电脑。支撑如此巨大的用户群体需要强大而且灵活的数据中心（大约每400台智能手机设备或者100台可穿戴设备就需要1台服务器），而传统的数据中心是很难满足需求的。比如，传统数据中心提供一项新服务平均需要2～3周，但市场的瞬息万变需要尽快将服务推出。

“在一个SMAC（‘S’指社交、‘M’指移动、‘A’指分析、‘C’指云计算）主导的时代，建设开放、高效、按需提供、弹性的数据中心势在必行，英特尔提出的软件定义基础架构（Software-defined Infrastructure，SDI）正是在这个背景下提出的。它的目标就是通过重构数据中心，使数据中心能够敏捷、自动和高效。”英特尔（中国）有限公司行业合作与解决方案部高级经理、行业资深架构师龚毅敏告诉本报记者。

龚毅敏介绍说，基于软件定义基础设施构建的数据中心应该是动态的、高度自动化和软件定义的，这和传统的数据中心有很大不同，传统数据中心是一种静态、手动和硬件定义的，这样的传统数据中心根本无法满足云时代不断变化的需求。在按照软件定义基础架构构建的数据中心中，软件主导硬件，硬件只提供重要的基础架构属性，用软件来实现实时、智能和完全自动化。

具体而言，软件定义基础架构包含三个方面的内容，即计算、存储和网络。在这三个方面，英特尔分别都有相对应的产品。比如，在计算方面英特尔推出了名为RSA（Rack Scale Arch）的架构来重新定义服务器，RSA采用分离的部件和预定义的机架， 各个部件单独集成，可扩展，且便于构建基于机架的资源池。

龚毅敏表示，RSA架构可以很好地支持当下流行的模块化数据中心概念。在模块化数据中心，计算、网络和存储都可以和配电、制冷等设备集合成一个个独立的可插拔模块，方便扩展，也方便维护。

而在网络方面，英特尔也是软件定义网络（SDN）的大力推动者和实践者，同时在网络功能虚拟化（NVF）和虚拟化网络方面都推出了自己的产品。同样，在存储方面英特尔也是软件定义存储的领导者，英特尔有高速缓存加速（iCAS）、下一代NVM以及英特尔存储加速库等相关技术。

龚毅敏强调说，英特尔的SDI是一个开放的架构，英特尔正在为之构建一个广泛的生态系统。“不管是开源的OpenStack还是VMware、微软等，SDI都可以很好地支持其产品。”龚毅敏说，“简化、弹性、互操作性以及基于开放的工业标准建设正是SDI的主要特点。”

物联网校园平台的基础架构 篇4

目前, 物联网已有部分应用进入了高校的信息平台, 如“一卡通”、智能电表、校园安防系统等, 但是这些应用都是一个个孤独的、分散的信息孤岛, 没有形成一个有效的整体, 而相互之间的数据也没有完整的结合在一起, 没有构建一个完整的物联网整体系统[2]。

针对物联网的技术特点和现在校园信息化网络存在的不足, 物联网平台的搭建是非常有必要的, 本文通过对校园物联网的研究, 设计了一种基于物联网的信息平台架构, 希望可以为校园物联网平台运行和管理提供更好的模式和体系架构的探索性研究, 同时可以带动物联网技术的研究及其在其它重要领域的广泛应用。

1 平台搭建环境

整个环境力求高效简洁开源, 所以选择LAMP组合。即是用Linux作为操作系统, Apache作为Web服务器, MySQL作为数据库, PHP (部分站点也使用Perl或Python) 作为服务器端脚本解释器。由于这四个软件都是开放源代码软件, 因此使用这种方式不用花一分钱就可以创建起一个稳定、免费的站点系统。MySQL加PHP的配对在互联网上的应用相比LAMP来说更为常见。

服务器上选择Ubuntu Server 12.04 LTS 64bit。Web服务器选择Apache的原因是它的源代码开放、有一支开放的开发队伍、支持跨平台的应用 (可以运行在几乎所有的Unix、Windows、Linux系统平台上) 以及它的可移植性等方面。数据选择MySql开源数据库。MySQL是一种关联数据库管理系统, 关联数据库将数据保存在不同的表中, 而不是将所有数据放在一个大仓库内, 这样就增加了速度并提高了灵活性。MySQL的SQL语言是用于访问数据库的最常用标准化语言。PHP是一个应用范围很广的语言, 特别是在网络程序开发方面。一般来说PHP大多在服务器端运行, 通过运行PHP的代码来产生网页提供浏览器读取, 此外也可以用来开发命令行脚本程序和用户端的GUI应用程序。PHP可以在许多不同种的服务器、操作系统、平台上运行, 也可以和许多数据库系统结合。最重要的是PHP可以用C、C++进行程序的扩展[3]。

2 平台模块构成

整个平台分为3大部分:基础信息、设备信息和校园管理。如图1所示。

2.1 基础信息

基础信息是整个平台的基础, 它包含了地址信息、用户信息、系统安全等部分。

地址信息包括了学校的校区、教学楼、教室、寝室楼、寝室等信息, 里面的主要信息是学校的基本环境情况, 便于确定设备安装地址以及管理范围。如:教室信息里面就应该包括教室大小、教室容纳学生人数、教室课程安排情况等。

用户信息包括了学生信息和教师信息, 里面的主要信息是学生和教师的基本信息情况, 用来确定用户身份及权限。并且通过专用接口和校园网对现有学工、学籍等系统实现数据交换, 保持数据一致性。

系统安全主要是针对平台安全认证授权有着详细的设置, 根据不同角色赋予不同权限。

2.2 设备信息

设备是整个平台正常工作的基石, 在设备信息部分中, 主要是包括设备安装及设备查询两部分。

设备安装主要包括所有具有物联网工作设备的安装情况, 用于统计校内物联网点数及物联网设备正常工作情况。

设备查询主要是包括具体物联网设备的工作情况, 用来对某一个物联网设备的工作状况、使用情况的查询。

2.3 校园管理

校园管理部分是平台的实际操作部分也是平台的核心部分。在这部分中, 通关物联网的技术。我们可以具体对某一个物联网应用设备进行管理。如灯光管理, 在教室里面的灯, 我们可以在平台终端根据不同的季节来调整它自动开灯和关灯的时间。

3 用户界面及数据库设计

本层是直接展示给最终用户的进行操作的接口, 设计原则是简单易用, 不会造成使用上的困惑, 尽量减少误操作的可能性。在前端构架上采用HTML5+jQuery+Twitter Bootstrap CSS的组合, 充分利用现有最新技术, 提高响应速度以及多设备的不同屏幕大小适应性。

数据库是服务器端的核心, 数据库设计的合理与否对系统的制作有着至关重要的影响。系统的一大基本功能就是检索, 主要包括用户信息检索、教师课表检索、教室课表检索、空闲教室检索、设备状况检索等。

本系统使用MySQL数据库, 与Apache服务器和PHP语言形成黄金组合, 在该作品网站建设中充分体现了其体积小、速度快、总体成本低, 尤其是开放源码这一特点。

将采集到的信息存放在数据库中, 对数据进行处理并用于查询, 得到用户最终满意的结果。数据库的详细设计如图2所示。

4 自动处理系统与信息采集网关

自动处理系统设计用于紧急事件以及突发情况, 可以根据预先设定的紧急预案流程, 自动处理事件。例如收到火警信息:一旦系统侦测到某火警点报警, 立即告警并发送所处大楼疏散信号, 启动疏散引导系统, 提示关闭防火隔离门。

在底层构建实时信息采集系统, 通过通讯网关, 连接至Internet上的各个设备 (无线3G或者有线方式) , 采用TCP/IP协议, 稳定可靠。

实时信息采集系统在后台定时自动请求各个设备状态, 如果设备无响应, 或者返回错误状态, 系统主动上报, 反映至管理平台, 有助于快速排错, 使系统稳定运行。也可以在管理平台手动直接采集设备实时信息, 提高诊断准确率, 以及了解设备运行状态。

5 处理流程

下面通过监测控制校园路灯为例, 介绍平台对终端的控制流程。

在实际工作中, 当路灯突然出现故障不能亮启的时候, 传感器接收到电流的异常变化, 这时候它就发出一个异常变化的信号并且连同自己的网络地址通过校园网送达学校的物联网平台。

而在平台中, 平台判断异常变化的情况给出结论显现出来, 这时操作员根据给出的结论来对路灯进行处理。

登陆平台之后, 进入[校园管理]=〉[路灯管理]界面。校园网内所有路灯都显示在页面。第一列是路灯编号;第二列是路灯的地址, 便于发现问题之后找到问题路灯, 进行维护;第三列是当前路灯状态, 表示正常工作, 而则表示路灯需要维护;第四列可以对正常的路灯进行开关控制, 而异常的路灯则给出诊断按钮, 用于诊断异常信息。

5.1 开关控制

当需要控制路灯开关的时候, 点击控制栏的开或关按钮, 平台找到所需控制设备的ID号, 确定网络地址, 根据协议往目标地址发出控制指令。目标设备获得指令之后做出相应控制, 成功之后返回成功信息。平台获得成功信息之后刷新界面, 显示控制成功提示信息。

5.2 异常诊断

针对异常备我们提供了诊断功能, 点击控制栏诊断按钮, 平台找到所需控制设备的ID号, 确定网络地址, 根据协议往目标地址发出诊断指令。目标设备获得诊断指令之后开始探测设备状态, 完成之后返回设备状态信息。平台获得信息之后刷新界面, 显示设备诊断信息。

6 结束语

传统的校园网络平台只是单纯的平台来访问学校的应用系统和资源。而基于物联网技术的智能平台, 除了传统意义上的平台访问更具有了智能管理模式, 人们使用平台通过网络对终端设备进行控制。终端设备也可以通过网络发终端数据发送给平台。这样就达到了物与物、物与人、人与人通过网络管理的功能。

参考文献

[1]钱志鸿, 王义君, 等.物联网技术与应用研究[J].电子学报, 2012年第5期.

[2]李卢一, 郑燕林, 等.物联网在教育中的应用[J].现代教育技术, 2010年第2期.

呼叫中心平台基础通用性软件技术架构 篇5

教育部关于建设“三通两平台”的发展战略中, 对建设教育资源和管理两大公共服务平台的阐述也明确了应按照“两级建设、五级应用”的模式来推进。基于此背景, 苏州工业园区教育信息中心借鉴新加坡“智慧教育”的成熟经验, 提出了“复用政务数据资源, 架构区域性教育基础数据平台”的发展思路, 以此为教育行政管理决策提供高效、准确的基础数据, 为园区教育软件平台枢纽提供底层支撑, 满足教育参与者对教育资源的使用需求, 这一创新理念解决了信息沟通壁垒问题, 实现了政教双赢。

云模式下的整合需求

2012年开始, 苏州工业园区教育局已逐步实现园区直属学校全面接入园区教育城域网。基于复用政务云资源的创新链路模式, 实现了网络资源与带宽共融、集约管理, 教育城域网将拥有20G的主干交换, 并实现了千兆光纤到校, 园区区域整体推进数字化建设取得了初步成效。然而, 在基础线路搭建完成后, 基于城域网的区域性应用系统的开发与完善若不及时规划和实施, 区域性教育管理与教育应用信息化绩效受到影响, 仍然会造成各中小学应用平台的重复投资、资源浪费。园区教育系统专门为此申请立项了《园区教育信息枢纽平台的可行性研究》课题, 对此进行了深入调研。

苏州工业园区提倡的“智慧教育云”工程打破了传统的教育信息化边界, 推出了全新的教育信息化概念, 集教学、管理、学习、交流于一体。教育部门、学校、教师、学生、家长及其他教育参与者, 可以在同一个平台上, 根据权限去完成不同的工作。

教育信息枢纽平台应是以教育管理的各类数据和教学应用的诸多资源等为基础, 按照统一的数据接口规范, 定制开发的满足各种教育管理与应用需要的平台的集合体, 涵盖了面向管理人员的教育管理, 如学籍、成绩、教务、校产、办公等内容;涵盖了面向教师的资源库和备课、授课、教研、师资培训等应用平台;涵盖了面向学生的学习资源和方式, 如自主学习、协作学习、探究学习;以及面向家长的家校互联等应用子系统, 可以满足教育管理、教育教学、家校联系等多功能、多途径、高效快捷的云计算服务。

区域教育基础数据库是教育信息枢纽平台的底层支撑, 园区教育城域网上所有应用均由本数据平台提供统一身份认证。涵盖教育单位、教师、学生三大基础数据库, 每个数据库具备可扩充性, 并及时更新完善数据, 对接各大应用平台, 所有用户可按不同权限检索、交换想要的数据, 减少重复录入和重复统计, 极大地提高了教育行政管理效率。

政教互联的创新理念

目前, 园区人口库能基本满足园区政府各部门对涉及人口信息的一般性查询和统计的需求, 并为园区社区、医疗、教育平台提供了基础的信息服务, 人口信息资源利用初显成效。法人库入库企业数据累计约3万家, 其中就包括教育系统内部的法人、经营、年检、证照等相关信息, 初步形成了较为统一、规范、丰富的信息库。并提供跨部门查询、横向资源比对和数据统计分析等业务功能。地理信息库, 在电脑中真实展现土地、规划、房产以及地下管线等信息, 实现了土地、规划、房产、市政等相关部门的高效运作与长效管理。

苏州工业园区政务数据资源既是战略性、全局性的信息资源共享库, 又起到政府各部门业务应用系统构建的基础纽带作用。作为园区推行的“三库九枢纽”的信息化建设架构中的重要一环, “智慧教育”必须与整个政务云融通, 共享数据。为此园区专门成立了政务数据 (园区三库) 推进工作组, 研究如何将各机关局办的数据壁垒打通。

园区教育局在制定信息化发展战略时, 清楚地认识到构建符合标准规范的基础数据库的重要作用, 积极与政府进行深入沟通磋商, 了解园区信息化建设进展并提出自己的数据共享请求。初期已经将人事管理、财务申报、校园地理等信息与政务相容互通。未来还将在督导评估、师生成长档案、校园安全、终生学习生态系统等领域全面实现无边界融合。

共享扩展的数据架构

根据国家、省、市的数据结构标准和《教育信息化建设指南》指导思想, 经过不断的研究论证, 园区区域教育基础数据库将分为学校、教师和学生三个基础表。学校 (含教育机构、社区教育中心) 库表里包含学校名称、建制、建筑面积、法人、班级、师生规模、财务、地理、联系方式等相关信息;教师库表里包含姓名、年龄、性别、学历、专业、工作经历、荣誉奖惩等相关信息;学生库表里包含姓名、年龄、性别、学习经历、荣誉奖惩、家庭、社区等相关信息。

在建设初期, 很多数据在园区政府数据中已经存在, 如法人库已经包括联系人、经营、年检、证照等相关信息, 人口已经包含了园区籍学生的信息, 地理信息库中已经可以检索查询学校的位置、规模、施教区域等信息。我们只需向园区政务数据资源发起请求, 经过审核通过后, 便可检索并共享到教育数据库内, 不需要另外再收集汇总和整理, 节省了大量的采集时间和人力。

与此同时, 其他兄弟局办也会向教育基础数据平台请求数据资源共享, 如医疗卫生机构会定期收集适龄儿童的疫苗接种情况, 社会事业局会在学年度开始时收集各类办学机构的审批、登记注册等信息。公积金中心也会检索在编教师的信息做适时调整。

这些信息都会随着时间的推移不断产生更新, 也会因为上级的平台需求增设更多的数据字段, 信息中心为此制定了《园区教育信息化建设管理意见》来制度化地规范, 确保数据的规范性、准确性和及时性。

问题与困惑

在数据库架构的同时, 要涉及外部数据的请求和同步, 牵涉很多单一数据始料未及的问题及困惑。这些问题得不到彻底解决, 会严重影响整个“智慧教育”的推进。

1.数据库缺乏统一标准

目前全国、省、市各级机构对于教育信息化平台的建设还处于试验阶段, 各级平台的数据库建设情况不一, 数据标准各异, 教育系统本身还缺乏一套完整的、有实际操作价值的教育管理信息数据标准。各平台采集数据的字段也是想到什么收集什么, 缺乏长期规划和扩展性。上级主管部门应考虑尽快建立统一的教育数据库标准, 并可与其他外部数据库实现无缝对接。

2.更新缺乏长效机制

园区政务云的数据建设需要20余个局办通力合作, 将基础信息资源共享与整合。异步数据请求往往带来这样的情况:我们请求的数据可能是前一年的过期数据, 而新的数据还没有来得及更新;或者因为许多单位信息共享的决定权取决于管理机制、保密条例、法律法规等外部制约, 具体工作支持乏力。

如何开发针对政务云数据的应用服务支撑体系, 如何确认外部数据的真实性和实效性;如何建立安全、长效的运营维护机制, 这些都是我们在实践中产生的困惑。

3.数据共享途径要权衡

“数据共享”的通行办法是“使用统一数据库”和建立“统一数据接口标准”, 那么在什么情况下利用接口融通数据?在什么情况下推行统一后台, 集约管理?教育局内部有关教师和学生的私密信息如何做到有条件的检索和交换, 遵循什么原则?基于基础数据库应用系统是B/S还是C/S的结构?

应该在建构数据库前, 就考虑制定并发布《教育基础信息使用规范》、《用户身份信息获取与认证接口规范》、《单点登录服务接口规范》、《消息中心消息发送接口规范》、《应用系统接入规范》等相关政策文件。

教育系统借力政务数据平台, 复用政务私有云的数据来实现政教共赢的新局面, 已经成为苏州工业园区教育信息化建设三年行动计划的重点工作。如何借鉴北美和新加坡的教育信息化先进经验, 量身开发符合“智慧教育”基本理念的数据交换平台和基于政务云上的教育应用, 从而为“三通两平台”建设打下坚实的基础, 服务区域教育信息化, 值得我们认真思考和实践。

参考文献

[1]陈慧.我国教育信息化基础数据库平台原型的设计与开发[D].华中师范大学, 2012.

[2]许哲.我国教育信息化基础数据库平台的设计与开发[D].华中师范大学, 2011.

[3]汪珺, 冯有文.美国国家教育统计中心对我国教育基础信息数据库建设的启示[D]北京邮电大学国际学院, 2011.

[4]陈庆贵, 申屠祖斌.教育基础数据库建设的探索与应用[J].中国信息技术教育, 2009 (23) .

[5]江苏省扬州市电化教育馆;建好基础数据库服务区域教育信息化[J].中国信息技术教育, 2009 (23) .