智能交通云控制系统的制作方法

文档序号:11138779阅读:414来源:国知局
智能交通云控制系统的制造方法与工艺

本申请涉及信号与信息处理技术领域,尤其涉及智能交通云控制系统。



背景技术:

随着社会经济的飞速发展,各类交通工具得到了越来越广泛的应用,极大的方便了人们的出行;但是,也使城市交通管理系统的任务越来越重。

目前,城市交通管理系统主要涉及疏通拥堵道路、违法监控、缉查布控、信号灯调控等应用。如图1所示,交通管理系统包括控制中心控制系统101、交通信号机102、视频检测器103、车流量检测器104和车速检测器105、交通信号灯106以及其他设备107。

相关技术中,一般在每个路口设置一个交通信号机。交通信号机用于接收现场设备采集的数据,并将数据发送给中心控制系统。中心控制系统用于接收交通信号机发送的数据,根据该数据生成控制指令,并将控制指令下发给交通信号机。进一步地,交通信号机还用于接收中心控制系统下发的控制指令,并将该控制指令下发给现场设备,实现对现场设备的控制;其中,交通信号机与现场设备通常采用串行总线通信。

由于相关技术中的中心控制系统需要完成数据处理和控制功能,而整个城市或城区所有路口的交通数据十分庞大,至使中心控制系统的负担过重,导致数据处理效率低,控制指令下发延迟等问题;又由于交通信号机与现场设备采用串行总线通信,而串行总线传输数据的速度相对较慢,导致数据传输效率低。



技术实现要素:

本申请实施例提供的智能交通云控制系统,用以解决相关技术中的中心控制系统需要完成数据的运算、处理和控制功能,而整个城市或城区所有路口的交通数据十分庞大,至使中心控制系统的负担过重,导致数据处理效率低,控制指令下发延迟等问题;又由于交通信号机与现场设备采用串行总线通信,而串行总线传输数据的速度相对较慢,导致数据传输效率低等的问题。

本申请实施例提供智能交通云控制系统,包括:设置于每个路口的控制服务器、与控制服务器通过基于IP(Internet Protocol,网络之间互连的协议)地址的宽带总线通信的多个IP化现场设备,其中:

IP化现场设备用于采集交通路口数据;

控制服务器用于集中处理IP化现场设备采集的数据,并通过边缘计算实现对本地区域交通的控制,和/或,

控制服务器用于确定满足预设触发条件时,在该控制服务器所属的预先组建的自定义区域中,若该控制服务器为主控制服务器,则主控制服务器通过自我学习和边缘计算生成协同控制策略实现对自定义区域的协同控制;若该控制服务器为从控制服务器,则从控制服务器通过云计算从主控制服务器获得协同控制策略。

进一步地,一个通行方向具有一条宽带总线,针对每个通行方向,控制服务器采用该通行方向上的宽带总线与该通行方向上的IP化现场设备通信;或者,

一个路口的所有通行方向共用一条宽带总线,控制服务器采用该条共用的宽带总线与其所处路口的IP化现场设备通信。

进一步地,自定义区域由位置相邻的多个控制服务器的本地区域组成;协同控制,包括:交通执法、轨迹追踪、交通控制、定位待定位对象。

进一步地,所述系统还包括:中心系统,用于与多个控制服务器通过网络实现数据交互,共享与其连接的控制服务器存储的数据,并通过对共享的数据进行分析、处理,得到分析结果;根据分析结果,生成协同控制策略,并将协同控制策略发送给相应的控制服务器;

控制服务器还用于通过云计算从中心系统获得协同控制策略,并根据协同控制策略执行相应的操作。

进一步地,所述通过边缘计算实现对本地交通的控制,包括:控制服务器将采集的数据进行分析和存储,生成对IP化现场设备的控制指令,并通过所述宽带总线发送给IP化现场设备执行。

进一步地,自定义区域包括控制服务器的本地区域、以及除该控制服务器之外的指定控制服务器的本地区域;

所述通过自我学习和边缘计算实现对自定义区域交通的协同控制,包括:

共享指定控制服务器的数据,并根据共享的指定控制服务器的数据,生成协同控制策略,根据协同控制策略,对自定义区域交通进行控制;其中,自定义区域内的控制服务器采用分布式存储方式存储数据。

进一步地,所述IP化现场设备包括第一IP化现场设备和/或第二IP化现场设备,其中:第一IP化现场设备为支持IP协议的智能现场设备;第二IP化现场设备包括支持IP协议的驱动设备、以及与该驱动设备相连的不支持IP协议的非智能现场设备。

进一步地,控制服务器还用于:为与其通信的IP化现场设备分配唯一的IP地址。

进一步地,中心系统与多个控制服务器通过网络实现数据交互,包括:中心系统实时接收控制服务器的状态数据,非实时接收控制服务器的统计与查询数据,和按需订阅控制服务器的存储数据。

进一步地,控制服务器还用于,对与其连接的控制服务器的数据备份、故障接管。

本申请有益效果如下:本申请实施例提供的系统中,控制服务器用于集中处理IP化现场设备采集的数据,并通过边缘计算实现对本地区域交通的控制,和/或,控制服务器用于确定满足预设触发条件时,在该控制服务器所属的预先组建的自定义区域中,若该控制服务器为主控制服务器,则主控制服务器通过自我学习和边缘计算生成协同控制策略实现对自定义区域的协同控制;若该控制服务器为从控制服务器,则从控制服务器通过云计算从主控制服务器获得协同控制策略。由于控制服务器具备了数据处理和对本地区域交通的控制以及对自定义区域交通的协同控制的功能。这样,就能够减轻中心系统的负担,甚至不需要中心系统。而且,每个路口一个控制服务器,一个控制服务器仅对本地区域或者自定义区域进行交通控制,处理的数据量少,提高了数据处理的效率,解决了指令下发延迟的问题。

附图说明

为了更清楚地说明本申请实施例中的技术方案,下面将对实施例描述中所需要使用的附图作简要介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域的普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。

图1所示为背景技术中交通管理系统的示意图;

图2所示为智能交通云控制系统的示意图一;

图3所示为驱动设备的示意图;

图4所示为智能交通云控制系统的示意图二;

图5所示为两线制工业以太网的结构示意图一;

图6所示为两线制工业以太网的结构示意图二。

具体实施方式

为了使本申请的目的、技术方案和优点更加清楚,下面将结合附图对本申请作进一步地详细描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例,都属于本申请保护的范围。

如图2所示,为本申请提供的智能交通云控制系统的示意图,该智能交通云控制系统,包括设置于每个路口的控制服务器201、与控制服务器通过基于IP地址的宽带总线通信的多个IP化现场设备202,其中:

IP化现场设备202,用于采集交通路口数据;

控制服务器201,用于集中处理IP化现场设备采集的数据,并通过边缘计算实现对本地区域交通的控制,和/或,

控制服务器用于确定满足预设触发条件时,在该控制服务器所属的预先组建的自定义区域中,若该控制服务器为主控制服务器,则主控制服务器通过自我学习和边缘计算生成协同控制策略实现对自定义区域的协同控制;若该控制服务器为从控制服务器,则从控制服务器通过云计算从主控制服务器获得协同控制策略。

其中,在一个实施例中,每个本地区域包含一个控制服务器,为了便于控制本地区域的交通,通过边缘计算实现对本地交通的控制,包括:控制服务器将采集的数据进行分析和存储,生成对IP化现场设备的控制指令,并通过所述宽带总线发送给IP化现场设备执行。这样,实现了对本地区域交通的控制。

其中,在一个实施例中,预设触发条件,例如是:控制服务器在处理数据的过程中,由于数据量过大,导致无法对全部数据进行处理。还例如交通拥堵,需要多个控制服务器协同进行交通管理,还例如,查询一个待查询对象在自定义区域内的信息。例如查询待查询对象在自定义区域内的运动轨迹。

其中,在一个实施例中,自定义区域包括一个主控制服务器和多个从控制服务器。预先组建的自定义区域,可以是在控制服务器处理IP化现场设备采集的数据之前,人为组建好的,例如是:将十个相邻的控制服务器所在的本地区域组建成一个自定义区域。也可以是在控制服务器处理IP化现场设备采集的数据的过程中,根据需求,自动组建的自定义区域。例如,满足组建自定义区域的触发条件时,向相邻控制服务器发送组建自定义区域的请求,若相邻控制服务器同意该请求则完成自定义区域的组建。当然,当相邻控制服务器接收到组建自定义区域的请求后,还可以请求其周边的相邻控制服务器组建自定义区域,这样自定义区域可以不断扩展。

其中,在一个实施例中,为便于对自定义区域进行控制,自定义区域由位置相邻的多个控制服务器的本地区域组成;

其中,在一个实施例中,协同控制,包括:交通执法、轨迹追踪、交通控制、定位待定位对象。

其中,交通执法,例如是控制服务器接收IP化现场设备采集的用于交通执法数据,对数据进行分析,得出自定义区域内有无违反交通法的事件,例如是闯红灯事件。

其中,轨迹追踪,例如是控制服务器接收IP化现场设备采集的用于轨迹追踪的数据,对数据进行分析,得到被追踪对象的轨迹。

其中,交通控制,例如是控制服务器接收IP化现场设备采集的用于交通控制的数据,对数据进行分析,生成控制指令,控制IP化现场设备进行相应的操作;例如是,控制自定义区域内的交通信号灯的红、绿、黄三颜色变换的间隔时间。还例如是控制自定义区域内的闯红灯拍照设备间隔多久拍一次照等。

其中,定位待定位对象,例如是控制服务器接收IP化现场设备采集的用于定位待定位对象的数据,对数据进行分析,根据分析结果得到被定位对象的定位结果。该定位结果可以是待定位对象的历史数据,也可以是当前位置,本申请实施例对此不作限定。

其中,若该控制服务器为主控制服务器,则主控制服务器可以共享从控制服务器的数据,然后对自身的数据和共享的数据进行分析处理,生成协同控制策略,并将协同控制策略发送给从控制服务器执行。这样从控制服务器可以根据协同控制策略,控制自身的IP化现场设备。也就是说,主控制服务器和从控制服务器协同完成了对自定义区域的控制。

其中,若该控制服务器为从控制服务器,则从控制服务器将IP化现场设备采集的数据(该数据可以是IP化现场设备采集的全部数据,也可以是其中的指定数据)发送给主控制服务器,使主控制服务器根据该数据生成协同控制策略。其中,指定数据可以按照需要协同控制的内容不同而不同,例如,若协同控制为轨迹追踪,则发送给主控制服务器的可以是待确定运动轨迹的对象的轨迹数据;若协同控制为交通控制,则发送给主控制服务器的为当前的交通拥堵状况数据。具体实施时,可以根据实际需要确定,本申请实施例对此不作限定。

本申请实施例提供的系统中,控制服务器用于集中处理IP化现场设备采集的数据,并通过边缘计算实现对本地区域交通的控制,和/或,控制服务器用于确定满足预设触发条件时,在该控制服务器所属的预先组建的自定义区域中,若该控制服务器为主控制服务器,则主控制服务器通过自我学习和边缘计算生成协同控制策略实现对自定义区域的协同控制;若该控制服务器为从控制服务器,则从控制服务器通过云计算从主控制服务器获得协同控制策略。由于控制服务器具备了数据处理和对本地区域交通的控制以及对自定义区域交通的协同控制的功能。这样,就能够减轻中心系统的负担,甚至不需要中心系统。而且,每个路口一个控制服务器,一个控制服务器仅对本地区域或者自定义区域进行交通控制,处理的数据量少,提高了数据处理的效率,解决了指令下发延迟的问题。

为便于进一步理解本申请实施例提供的智能交通云控制系统,下面做进一步说明:

其中,在一个实施例中,由于城市中各区域交通路况十分复杂,有时需要综合分析各路口的交通情况,进而对各个路口进行协同控制,其中各个路口可以是相邻的至少两个路口,或不相邻的至少两个路口。为此,本申请实施例中,自定义区域包括控制服务器的本地区域、以及除该控制服务器之外的指定控制服务器的本地区域;所述通过自我学习和边缘计算实现对自定义区域交通的协同控制,包括:共享指定控制服务器的数据,并根据共享的指定控制服务器的数据,生成协同控制策略,根据协同控制策略,对自定义区域交通进行控制;其中,自定义区域内的控制服务器采用分布式存储方式存储数据。采用分布式存储,就无需专用的存储设备集中存储数据,可以节约硬件资源。同时,控制服务器也便于根据自身的历史数据进行相应的操作,例如,查询数据等。

例如:位于北京海淀区的A路口的控制服务器A,与位于北京昌平区的B路口的控制服务器B之间共享彼此的数据。当A路口拥堵,B路口通畅时,控制服务器A根据控制服务器B共享的数据,以及自身的数据,综合分析处理,生成针对于位于A路口的IP化现场设备的第一控制指令,同时生成针对于位于B路口的IP化现场设备的第二控制指令,并将第二控制指令传输给控制服务器B,从而使位于两路口的IP化现场设备,根据相应的控制指令,进行相应的操作,进而达到疏通A路口的目的。

其中,在一个实施例中,在一个自定义区域内有多个控制服务器,可从该多个控制服务器中选择一个控制服务器作为主控制服务器,来控制该自定义区域内的交通。例如:一个自定义区域有A、B、C、D、E五个控制服务器,某时,B路口交通通畅,控制服务器B需要处理的IP化现场设备采集的数据少,而其他四个路口拥堵,相应的控制服务器需要处理的数据多,那么,此时选择控制服务器B作为主控制服务器。也就是说将自定义区域内负载最低的控制服务器选为主控制服务器。其中,主控制服务器的选择可根据实际情况任意转换。例如主控制服务器还可以由自定义区域内的控制服务器协商确定。其中,在一个实施例中,具体实施时,主控制服务器也可以通过竞选的方式确定。例如,自定义区域内的各控制服务器可以竞争同一把锁,如果谁先获得该锁,谁就为主控制服务器,则其他的控制服务器自动成为从控制服务器。

其中,在一个实施例中,IP化现场设备包括第一IP化现场设备和/或第二IP化现场设备,其中:第一IP化现场设备为支持IP协议的智能现场设备;第二IP化现场设备包括支持IP协议的驱动设备、以及与该驱动设备相连的不支持IP协议的非智能现场设备。其中,驱动设备用于接收控制服务器发送的控制指令,并根据该指令控制相应的非智能现场设备,以及将非智能现场设备采集的数据发送给控制服务器。这样,有了驱动设备,即使现场设备不支持IP,控制服务器也能够实现对其进行控制。

其中,在一个实施例中,为提高智能交通云控制系统的数据处理速度,本申请实施例中控制服务器采用双CPU(Central Processing Unitrotocol,中央处理器)。

其中,在一个实施例中,整个城市或城区的交通路网十分庞大,各道路上的现场设备(例如信号灯)数量很多,各路口的交通情况非常复杂,有时需要根据整个城市或城区内的交通情况做出相应的操作;所以,本申请实施例中,智能交通云控制系统还包括,中心系统,用于与多个控制服务器通过网络实现数据交互,共享与其连接的控制服务器存储的数据,并通过对共享的数据进行分析、处理,得到分析结果;根据分析结果,生成协同控制策略,并将协同控制策略发送给相应的控制服务器;

控制服务器还用于通过云计算从中心系统获得协同控制策略,并根据协同控制策略执行相应的操作。

其中,中心系统能够通过与多个自定义区域内的主控制服务器通信,将协同控制策略下发给主控制服务器,由主控制服务器将协同控制策略下发给从控制服务器来控制各自定义区域内的IP化现场设备执行相应的操作;还可以是中心系统直接和各自定义区域内的各控制服务器通信(包括主控制服务器和从控制服务器),将协同控制策略下发给从控制服务器来控制IP化现场设备执行相应的操作,进而达到控制多个自定义区域交通的目的。

例如:中心系统通过从与其通信的多个控制服务器中获取预设用于交通执法的第一数据,并对第一数据进行分析,根据分析结果生成交通执法策略,并将交通执法策略发送给相应的控制服务器执行。

又如:中心系统通过从与其通信的多个控制服务器中获取预设用于轨迹追踪的第二数据,并对第二数据进行分析,得到被追踪对象的轨迹。

又如:中心系统通过从与其通信的多个控制服务器中获取预设用于交通协同控制的第三数据,并对第三数据进行分析,根据分析结果生成广义协同控制策略,并将该广义协同控制策略发送给相应的控制服务器执行。如中心系统可以对整个城市或城区进行广义协同控制,其中,广义协同控制可以对任何等级的行政区域,例如一个城市、一个市区(如海淀区)等,当然具体实施时可以根据实际需要确定控制的地理范围,本申请实施例对此不作限定。如,北京市海淀区交通拥堵,中心系统可以根据海淀区的指定控制服务器发送的数据,分析出这两个城区的路况,进而根据数据分析结果,将相应的控制指令传输给位于这两个城区的相应控制服务器。通过控制服务器下发控制指令给位于这两个城区的相应的IP化现场设备,使IP化现场设备进行相应的操作,达到疏散海淀区的人流和车流的目的,从而降低海淀区的交通拥堵程度。

又如:中心系统通过从与其通信的多个控制服务器中获取预设用于定位的第四数据,并对第四数据进行分析,根据分析结果得到被定位对象的定位结果。

其中,中心系统将协同控制策略送给相应的控制服务器,该控制服务器通过所述宽带总线把协同控制策略发送给IP化现场设备,实现对IP化现场设备的控制。

其中,中心系统用于大区域的协同控制,自定义区域中的控制服务器用于自定义区域内的协同控制;其中,大区域的范围大于自定义区域。例如:大区域为整个北京市,而自定义区域为北京市内的海淀区或是昌平区等。

其中,当中心系统有至少两个时,可以将一个中心系统作为其他中心系统的备份中心系统,用于备份其它中心系统的数据。当然,也可以选择多个中心系统作为备份中心系统。

其中,在一个实施例中,中心系统实时接收控制服务器的状态数据,非实时接收控制服务器的统计与查询数据,和按需订阅控制服务器的存储数据。其中,为了便于中心系统控制控制服务器,进而控制相应的IP化现场设备,中心系统实时接收控制服务器的状态数据。统计与查询数据对实时性要求不高,例如用于查询车流量的数据并不要求实时传输给中心系统,故此,实时性要求不高的数据,可以通过非实时接收的方式接收。其中,中心系统还可以将用于订阅消息的订阅指令发送给控制服务器,该订阅指令中可包括订阅的消息类型;中心系统还用于根据从控制服务器接收到的已订阅的数据进行数据分析,并根据数据分析结果进行相应操作。该相应操作,例如是存储数据,例如是生成控制IP化现场设备的控制指令。当中心系统管辖多个控制服务器时,生成的控制指令能够实现对辖区内交通的全局控制。

其中,在一个实施例中,中心系统用于通过云计算对数据进行分析、处理、生成协同控制策略,从而节省了成本,提高了数据处理能力,降低了能源消耗。

其中,在一个实施例中,一个通行方向具有一条宽带总线,针对每个通行方向,控制服务器采用该通行方向上的宽带总线与该通行方向上的IP化现场设备通信;例如,有四个通行方向,分别为A、B、C、D,有四根网线分别为A1、B1、C1、D1,则具体实施时,可A方向使用网线A1、B方向使用网线B1、C方向使用网线C1、D方向使用网线D1。这样,可以便于布线。

或者,一个路口的所有通行方向共用一条宽带总线,控制服务器采用该条共用的宽带总线与其所处路口的IP化现场设备通信。例如,有四个通行方向,分别为A、B、C、D,则这四个通行方向共采用一根网线A1。

其中,在一个实施例中,城市交通路网十分复杂,各道路上的现场设备,有时需要根据相应区域内其他道路的交通情况做出相应的操作;并且,当控制服务器出现故障时,需要有其他控制服务器对其进行故障接管;故,本申请实施例中,控制服务器还用于,对与其连接的控制服务器的数据备份、故障接管。

为便于理解,这里进行举例说明;例如,控制服务器A是位于A道路路口处的控制服务器,控制服务器B是位于B道路路口处的控制服务器;控制服务器A与B通过网络相连,且互相进行数据备份。某时,A道路拥堵,而相邻的B道路十分通畅,这时,控制服务器A就可以根据备份的控制服务器B的B道路的数据分析出B道路通畅;而控制服务器B也可以根据备份的控制服务器A的A道路的数据分析出A道路拥堵;从而控制服务器A和B根据分析出的结果,控制相应的现场设备进行相应的操作。如果控制服务器A出现了故障,由于控制服务器B具有控制服务器A的所有数据,所以控制服务器B可以接管控制服务器A的工作,实现对控制服务器A下连的IP化现场设备的控制。

其中,在一个实施例中,具体实施时,各IP化现场设备的IP地址可以由中心系统分配,也可以由管理员统一设置。当然,为了便于控制现场设备,本申请实施例中,控制服务器还用于为与其通信的IP化现场设备分配唯一的IP地址。另,为了提高系统的安全性,控制服务器还用于进行网络安全检测。

其中,在一个实施例中,为了保证中心系统接收控制服务器的数据;和将控制指令发送给控制服务器的时效性,进而准确地控制IP化现场设备进行相应的操作;控制服务器与中心系统采用时钟同步机制。这样,提高了广义协同控制的准确性。

其中,在一个实施例中,为了便于管理各个路口的交通,每个路口处一个控制服务器,且各控制服务器与对应的指定控制服务器通过网络连接,所述指定控制服务器为相邻路口处的控制服务器,和/或用户下发的配置指定控制服务器的指令中包括的控制服务器。这样,具体实施时,可以根据实际需求,实现不同控制服务器之间的通信。控制服务器之间可以实现通信,便于进行交通管理和交通数据的管理,以便于建设智慧城市的智能交通。

其中,在一个实施例中,控制服务器采用IP地址寻址的方式与IP化现场设备通信,其中,数据通过IP地址在链路底层寻址。

其中,在一个实施例中,控制服务器将传统单一功能的信号控制器提升为融合安全网络、交通信息感知、高性能数据处理、存储、控制功能于一体的交通云控制服务器,通过视频监测实现了实时智能交通检测,避免了布线复杂、结构庞大、处理缓慢、功能单一的缺陷。控制服务器包括两个功能不同的PowerPC四核工业级CPU(Central Processing Unit,中央处理器),分别为第一CPU和第二CPU;

其中,第二CPU,用于接收IP化现场设备提供的交通数据,传输给第一CPU;以及接收所述第一CPU生成的第一控制指令,并且基于该第一控制指令对IP化现场设备进行控制管理。

可选地,第一CPU还用于:

基于对从第二CPU接收的数据进行分析处理的结果生成提供给中心系统的待处理数据,并发送给中心系统;

第二CPU还用于:

接收中心系统下发的第二控制指令,基于该第二控制指令对IP化现场设备进行控制管理。

可选地,控制服务器还包括:

网络交换模块,用于获取IP化现场设备传输的数据,传输给第二CPU,还用于接收第二CPU下发的第一控制指令或者第二控制指令,并传输给IP化现场设备。

可选地,控制服务器还包括:

网络安全模块,用于将第一CPU生成的待处理数据发送给中心系统,还用于接收中心系统下发给第二CPU的第二控制指令。

可选地,第二CPU包括:信号控制模块,用于检测IP化现场设备的信号控制状态,传输给第一CPU的信号优化模块;交通检测模块,用于检测IP化现场设备采集的车辆信息,传输给第一CPU的信号优化模块;

第一CPU包括:信号优化模块,用于基于信号控制模块传输的信号控制状态和交通检测模块传输的车辆信息,对IP化现场设备的控制状态进行优化处理,并生成第一控制指令。

可选地,第一CPU还包括:

交通数据处理模块,用于结合信号控制模块传输的信号控制状态和交通检测模块传输的车辆数据,进行分析处理,生成提供给中心系统的待处理数据,并发送给中心系统;

信号控制模块,还用于接收中心系统下发的第二控制指令,基于该第二控制指令对IP化现场设备进行控制管理。

可选地,第一CPU还包括:

视频流处理模块,用于基于交通检测模块传输的车辆视频数据进行视频分析处理,生成提供给中心系统的待处理视频数据,并发送给中心系统。

可选地,第一CPU还包括:

违法数据处理模块,用于基于交通检测模块传输的车辆数据进行违法行为分析处理,生成提供给中心系统的待处理违法数据,并发送给中心系统。

可选地,控制服务器还包括:

节点交互模块,用于通过网络连接,与其它控制服务器进行交互,实现协同控制和/或故障接管。

这样,控制服务器通过网络与现场设备采用IP化方式实现数据通讯,并完成图像监测,数据采集,云计算、云存储、云控制等功能,使系统体积大幅度降低、数据处理速度加快、控制指令实时性提高。同时,中心系统实现了高性能的协同指挥调度、运行维护管理、数据综合分析功能。由此实现更加智能化的交通控制系统。

其中,在一个实施例中,由于城市交通路网十分庞大,现场设备数量巨大,整个交通数据量十分巨大。这就使当用户想要查询某个路口的某个设备和/或某个控制服务器的信息时,十分困难。为了方便用户操作,本申请实施例中,每个IP化现场设备均具有用户自定义名称;和/或,每个控制服务器均具有用户自定义名称。具体的,中心系统和/或控制服务器用于提供数据检索服务。其中,中心系统可以将接收到的数据与发送该数据的设备(包括IP化现场设备和/或控制服务器)的用户自定义名称对应存储;并,在根据用户的检索操作得到检索数据后,将该检索数据以及对应的用户自定义名称显示给用户。控制服务器也可以将接收到的数据与发送该数据的IP化现场设备的用户自定义名称对应存储;并,在根据用户的检索操作得到检索数据后,将该检索数据以及对应的用户自定义名称显示给用户。这样,当用户检索某一IP化现场设备或控制服务器时,中心系统或控制服务器就会将相应设备的自定义名称以及相应数据显示给用户,以便于用户能够了解显示的是哪个设备的数据,例如:

用户可以定义信号灯的名称为海淀区成府路1号信号灯。这样,显示数据时,用户自定义名称就能使用户与实际地理位置的信号灯对应起来,便于用户了解数据。

用户可以定义控制服务器的名称为海淀区成府路。这样,显示数据时,用户自定义名称就能使用户与实际地理位置的控制服务器对应起来,便于用户了解。

其中,在一个实施例中,为了便于施工,控制服务器还包括,电源,用于通过电源线给驱动设备和智能现场设备供电。

如图3所示,为本申请实施例提供的驱动设备的结构示意图,包括:

第一接口301,用于连接宽带总线,例如二线制工业以太网;则该第一接口例如是用于接入二线制工业以太网的二线制工业以太网接口;

第二接口302,用于连接非智能现场设备;该第二接口例如是水晶插头网络接口。

处理器303,用于处理非智能现场设备发送的数据和控制服务器发送的指令;

非智能现场设备驱动电路304。

其中,在一个实施例中,驱动设备还可以包括信号安全检测与保护逻辑单元305。其中,信号安全检测例如是对采集的信号进行安全检测,保障采集的信号是安全的。保护逻辑单元可用于在确定出现事故或异常时,能够为驱动设备和/或非智能现场设备提供安全保障。

具体实施时,驱动设备可以包括以下中的至少一种:灯组驱动、检测装置的检测驱动、除灯组驱动和检测驱动之外其它的非智能现场设备的驱动。

具体实施时,智能现场设备可以包括:视频监测设备,违法监测设备、专用短程通信技术设备。

为便于进一步理解本申请实施例提供的智能交通云控制系统,这里以一个具体的实例对该系统的结构进行说明,如图4所示:本发明实施例中,中心系统通过控制服务器进行广义协同控制,每个路口处的控制服务器在所处路口的每个通行方向上,采用一条宽带总线与相应通行方向上的智能现场设备和驱动设备通信,所述网线可以是两线制工业以太网或者其它任何可以实现IP协议通信的网络;控制服务器通过电源线给驱动设备和智能现场设备供电。

其中,在一个实施例中,上述两线制工业以太网的结构示意图可以如图5所示,包括:。

第一以太网转换器501:用于将5类双绞线传来的标准以太网信号转换为以太网帧信号;

数模转换模块502,用于将以太网帧信号经过数模转换为电力传输的数字格式信号;

处理模块503,用于将数字格式信号进行整流滤波放大,得到符合宽带电力线规范的信号;

其中,在一个实施例中,宽带电力线例如是Homeplug AV电力线。

二线线缆504,用于传输符合宽带电力线规范的信号进行传输。

其中,在一个实施例中,二线线缆例如是Profibus、CAN、Modbus、485总线、HART(模拟)、FSK、FF等常用的二线线缆。

其中,二线线缆504上连接有各个设备(包括驱动设备和智能现场设备),故此,二线线缆504可以将信号传输给其连接的至少一个设备。

图5所示的两线制工业以太网的结构用于将信号发送给下连的设备,如图6所示,为该两线制工业以太网的另一结构示意图,该结构用于接收下连设备发送的信号,具体的包括:

电力线耦合电路601,用于将二线线缆上的低压高频的可编程逻辑控制器波形传给可编程逻辑控制器模拟前端;

可编程逻辑控制器模拟前端602,用于将接收到的信号通过带通滤波器滤掉PLC以外的信号后传给放大滤波器;

放大滤波器603,用于对信号进行放大、滤波后传给ADC(模数转换器);

ADC604,用于将接收的信号转换为数字信号并传给以太网转换器;

第二以太网转换器605,用于将接收的信号转换为以太网帧信号,并将以太网帧信号转换为适合5类双绞线传输的标准以太网信号。

这样,二线线缆可以认为是CAN总线类的线缆,由此两线制工业以太网可以利用如图1所示的交通控制系统中的总线。这样,为了无需对传统的交通控制系统进行大的改造,例如无需改造通信用的二线线缆,即可将其升级为本申请实施例提供的智能交通云控制系统。

当然,具体实施时,任何支持二线制工业以太网的二线线缆均适用于本申请实施例,对此不作限定。

本领域技术人员应明白,本申请的实施例可提供为方法、装置(设备)、或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、装置(设备)和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请的优选实施例,但本领域内的技术人员一旦得知了基本创造性概念,则可对这些实施例作出另外的变更和修改。所以,所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

显然,本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样,倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内,则本申请也意图包含这些改动和变型在内。

当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1