基于路况和天气的天窗/车窗控制方法、系统和车机与流程

本发明涉及车机中的功能组件，尤其涉及通过车机和云端服务器的配合，基于路况和天气的判断对天窗或者车窗实行开启或关闭的控制的方法和系统。

背景技术：

在传统车辆制造中，车窗或者天窗的开启或是关闭都是由用户手动操控的，而自动化操控通常只限于车辆熄火后，车窗和天窗在收到车主钥匙上的锁车信号后自动关闭。但实际上车窗或天窗的开关是需要根据不同的场景而进行频繁操作的。

技术实现要素：

以下给出一个或多个方面的简要概述以提供对这些方面的基本理解。此概述不是所有构想到的方面的详尽综览，并且既非旨在指认出所有方面的关键性或决定性要素亦非试图界定任何或所有方面的范围。其唯一的目的是要以简化形式给出一个或多个方面的一些概念以为稍后给出的更加详细的描述之序。

本发明的目的在于解决上述问题，提供了一种基于路况和天气的天窗/车窗控制方法、系统和车机，基于当前路况和天气的各种数据信息判断是否需要对天窗或车窗进行操控，提高了行车体验，提升了行车安全。

本发明的技术方案为：本发明揭示了一种基于路况和天气的天窗/车窗控制方法，包括：

车机实时采集包括当前车辆位置在内的信息；

车机被触发启动判断是否操控天窗/车窗的控制逻辑；

车机从云端服务器获取包括实时路况和天气状况在内的信息；

车机根据从云端服务器获取到的信息执行控制逻辑，基于控制逻辑的结果执行对天窗/车窗开启或关闭动作。

根据本发明的基于路况和天气的天窗/车窗控制方法的一实施例，控制逻辑的触发启动包括车机定期轮询自动触发或者云端服务器中信息变化时通知车机触发。

根据本发明的基于路况和天气的天窗/车窗控制方法的一实施例，在车机定期轮询时，轮询周期和车机检测到的当前车辆时速相关，车辆时速越大轮询周期越短。

根据本发明的基于路况和天气的天窗/车窗控制方法的一实施例，云端服务器上存储的实时路况信息包括道路拥堵情况，存储的天气状况包括天气预报信息、天气指数数据，车机上还存储道路等级信息。

根据本发明的基于路况和天气的天窗/车窗控制方法的一实施例，车机执行的控制逻辑包括：按照天气预报信息、天气指数数据、道路拥堵情况、道路等级信息的顺序依次判断，只有在前一条件符合的前提下才做下一条件的判断，若不符合则直接终止运行当前的控制逻辑。

根据本发明的基于路况和天气的天窗/车窗控制方法的一实施例，车机对天窗/车窗执行的动作进一步包括：

询问用户是否需要打开或关闭天窗/车窗，根据用户的反馈执行相应的动作；或者

根据预设自动执行对天窗/车窗的打开或关闭。

本发明还揭示了一种基于路况和天气的天窗/车窗控制系统，包括：

云端服务器，存有包括实时路况和天气状况在内的信息；

车机，包括：

车辆位置获取模块，获取当前车辆所在的位置信息；

智能控制服务模块，被触发启动判断是否操控天窗/车窗的控制逻辑；

网络服务模块，从云端服务器获取包括实时路况和天气状况在内的信息；

控制逻辑运行模块，根据从云端服务器获取到的信息执行控制逻辑，基于控制逻辑的结果执行对天窗/车窗开启或关闭动作。

根据本发明的基于路况和天气的天窗/车窗控制系统的一实施例，智能控制服务模块的触发启动机制包括车机定期轮询自动触发或者云端服务器中信息变化时通知车机触发。

根据本发明的基于路况和天气的天窗/车窗控制系统的一实施例，在车机定期轮询触发启动机制中，轮询周期和车机检测到的当前车辆时速相关，车辆时速越大轮询周期越短。

根据本发明的基于路况和天气的天窗/车窗控制系统的一实施例，云端服务器上存储的实时路况信息包括道路拥堵情况，存储的天气状况包括天气预报信息、天气指数数据。

根据本发明的基于路况和天气的天窗/车窗控制系统的一实施例，控制逻辑运行模块执行的控制逻辑包括：按照天气预报信息、天气指数数据、道路拥堵情况、道路等级信息的顺序依次判断，只有在前一条件符合的前提下才做下一条件的判断，若不符合则直接终止运行当前的控制逻辑。

根据本发明的基于路况和天气的天窗/车窗控制系统的一实施例，车机对天窗/车窗执行的动作进一步包括：询问用户是否需要打开或关闭天窗/车窗，根据用户的反馈执行相应的动作；或者根据预设自动执行对天窗/车窗的打开或关闭。

本发明还揭示了一种用于控制天窗/车窗开闭的车机，其特征在于，包括：

车辆位置获取模块，获取当前车辆所在的位置信息；

智能控制服务模块，被触发启动判断是否操控天窗/车窗的控制逻辑；

网络服务模块，从云端服务器获取包括实时路况和天气状况在内的信息；

控制逻辑运行模块，根据从云端服务器获取到的信息执行控制逻辑，基于控制逻辑的结果执行对天窗/车窗开启或关闭动作。

根据本发明的用于控制天窗/车窗开闭的车机的一实施例，智能控制服务模块的触发启动机制包括车机定期轮询自动触发或者云端服务器中信息变化时通知车机触发。

根据本发明的用于控制天窗/车窗开闭的车机的一实施例，在车机定期轮询触发启动机制中，轮询周期和车机检测到的当前车辆时速相关，车辆时速越大轮询周期越短。

根据本发明的用于控制天窗/车窗开闭的车机的一实施例，云端服务器上存储的实时路况信息包括道路拥堵情况，存储的天气状况包括天气预报信息、天气指数数据，控制逻辑运行模块执行的控制逻辑包括：按照天气预报信息、天气指数数据、道路拥堵情况、道路等级信息的顺序依次判断，只有在前一条件符合的前提下才做下一条件的判断，若不符合则直接终止运行当前的控制逻辑。

根据本发明的用于控制天窗/车窗开闭的车机的一实施例，车机对天窗/车窗执行的动作进一步包括：询问用户是否需要打开或关闭天窗/车窗，根据用户的反馈执行相应的动作；或者根据预设自动执行对天窗/车窗的打开或关闭。

本发明对比现有技术有如下的有益效果：本发明基于路况信息和天气信息检测是否有打开或关闭天窗/车窗的需要，并询问驾驶员或者自动执行对应操作。相较于现有技术，本发明提高了行车体验，提升了行车安全。

附图说明

图1示出了本发明的基于路况和天气的天窗/车窗控制方法的实施例的流程图。

图2示出了本发明的基于路况和天气的天窗/车窗控制系统的实施例的原理图。

图3示出了本发明的用于控制天窗/车窗开闭的车机的实施例的原理图。

图4示出了在车辆上实现本发明的组件图。

具体实施方式

在结合以下附图阅读本公开的实施例的详细描述之后，能够更好地理解本发明的上述特征和优点。在附图中，各组件不一定是按比例绘制，并且具有类似的相关特性或特征的组件可能具有相同或相近的附图标记。

基于路况和天气的天窗/车窗控制方法的第一实施例

图1示出了本发明的基于路况和天气的天窗/车窗控制方法的实施例的流程。请参见图1，本实施例的天窗/车窗控制方法的具体实施步骤详述如下。

步骤s1：车机实时采集包括当前车辆位置在内的信息。

通常车机是通过车机上的gps来获取车辆当前位置。

步骤s2：车机被触发启动判断是否操控天窗/车窗的控制逻辑。

在本实施例中，触发启动控制逻辑的机制是通过车机定期轮询自动触发的，轮询周期可以是一个预设的固定值，也可以是一个和当前行驶状态相关的值。比如，可以将轮询周期长短和当前实时车速相关联，一般来说车辆时速越大轮询周期应该越短，比如设置车辆时速高于60km/h则每10分钟启动执行控制逻辑，低于60km/h则每30分钟启动执行控制逻辑。实时车速可以由车机通过gps获得。

步骤s3：车机从云端服务器获取包括实时路况和天气状况在内的信息。

云端服务器的实时路况包括道路拥堵状况，例如分为极其拥堵、拥堵、通畅等，还有拥堵距离、预计通行时间、通行时速、车流量等数据，这一信息来源于行车地图上的实时路况，或者其他第三方提供的数据。天气状况包括天气预报信息(比如晴天、阴天、雨天、多云、下雪等、风力大小、气温)、天气指数数据。天气预报信息可以是指定位置指定时间段的精准天气服务，包括当前时间以及未来多天。天气指数包括紫外线指数、雾霾指数、pm2.5指数、空气质量指数、人体穿衣舒适度指数等。这些指数数据来源于第三方的专业天气数据提供商。此外，车机的导航地图中存储了道路等级信息，将道路分为国道、省道、县道、城市道路、乡村道路等。

步骤s4：车机根据从云端服务器获取到的信息执行控制逻辑，基于控制逻辑的结果执行对天窗/车窗开启或关闭动作。

简单而言，车机根据从云端服务器获得的道路拥堵状况、天气预报信息、天气指数数据，再结合车机上的道路等级信息，执行控制逻辑。当然车机也会检测当前车窗/天窗所处的状态(开启或关闭)。

在控制逻辑的具体执行过程中，较佳的可以根据一定的顺序依次判断相对独立的各条件，只有在前一条件判断符合的情况下才进行下一条件的判断。若遇到不符合的条件则直接终止运行当前的控制逻辑，这样就节省了多余的判断时间，提升了判断的效率。举例而言，可以按照天气预报信息、天气指数数据、道路拥堵情况、道路等级信息的顺序依次做判断。在天气预报信息的判断中，若遇到恶劣天气(比如下雨、下雪、雾霾、冰雹、大风等)，则终止后续的控制逻辑的运行，等待下一次的控制逻辑的启动。随后，在天气指数数据的判断中，若pm2.5指数或者紫外线指数特别高，则终止后续的控制逻辑的运行，等待下一次的控制逻辑的启动。接着，在道路拥堵情况的判断中，若当前道路状况十分拥堵，则终止后续的控制逻辑的运行，等待下一次的控制逻辑的启动。最后，在道路等级信息的判断中，若当前为乡村道路、县道等两边环境比较优美的道路则执行控制逻辑。

综上可见，当遇到天气舒适、pm2.5和紫外线指数不高、风力不大、道路通畅、道路环境优美，则执行对天窗/车窗的开启，反之则执行对天窗/车窗的关闭。

在本实施例中，若需要执行对天窗/车窗的开启/关闭，则会询问用户是否需要打开天窗/车窗的开启/关闭，在收到用户对此询问的反馈后执行相应的动作。

基于路况和天气的天窗/车窗控制方法的第二实施例

图1示出了本发明的基于路况和天气的天窗/车窗控制方法的实施例的流程。请参见图1，本实施例的天窗/车窗控制方法的具体实施步骤详述如下。

步骤s1：车机实时采集包括当前车辆位置在内的信息。

通常车机是通过车机上的gps来获取车辆当前位置。

步骤s2：车机被触发启动判断是否操控天窗/车窗的控制逻辑。

在本实施例中，触发启动控制逻辑的机制是通过车机定期轮询自动触发的，轮询周期可以是一个预设的固定值，也可以是一个和当前行驶状态相关的值。比如，可以将轮询周期长短和当前实时车速相关联，一般来说车辆时速越大轮询周期应该越短，比如设置车辆时速高于60km/h则每10分钟启动执行控制逻辑，低于60km/h则每30分钟启动执行控制逻辑。实时车速可以由车机通过gps获得。

步骤s3：车机从云端服务器获取包括实时路况和天气状况在内的信息。

云端服务器的实时路况包括道路拥堵状况，例如分为极其拥堵、拥堵、通畅等，还有拥堵距离、预计通行时间、通行时速、车流量等数据，这一信息来源于行车地图上的实时路况，或者其他第三方提供的数据。天气状况包括天气预报信息(比如晴天、阴天、雨天、多云、下雪等、风力大小、气温)、天气指数数据。天气预报信息可以是指定位置指定时间段的精准天气服务，包括当前时间以及未来多天。天气指数包括紫外线指数、雾霾指数、pm2.5指数、空气质量指数、人体穿衣舒适度指数等。这些指数数据来源于第三方的专业天气数据提供商。此外，车机的导航地图中存储了道路等级信息，将道路分为国道、省道、县道、城市道路、乡村道路等。

步骤s4：车机根据从云端服务器获取到的信息执行控制逻辑，基于控制逻辑的结果执行对天窗/车窗开启或关闭动作。

简单而言，车机根据从云端服务器获得的道路拥堵状况、天气预报信息、天气指数数据，再结合车机上的道路等级信息，执行控制逻辑。当然车机也会检测当前车窗/天窗所处的状态(开启或关闭)。

在控制逻辑的具体执行过程中，较佳的可以根据一定的顺序依次判断相对独立的各条件，只有在前一条件判断符合的情况下才进行下一条件的判断。若遇到不符合的条件则直接终止运行当前的控制逻辑，这样就节省了多余的判断时间，提升了判断的效率。举例而言，可以按照天气预报信息、天气指数数据、道路拥堵情况、道路等级信息的顺序依次做判断。在天气预报信息的判断中，若遇到恶劣天气(比如下雨、下雪、雾霾、冰雹、大风等)，则终止后续的控制逻辑的运行，等待下一次的控制逻辑的启动。随后，在天气指数数据的判断中，若pm2.5指数或者紫外线指数特别高，则终止后续的控制逻辑的运行，等待下一次的控制逻辑的启动。接着，在道路拥堵情况的判断中，若当前道路状况十分拥堵，则终止后续的控制逻辑的运行，等待下一次的控制逻辑的启动。最后，在道路等级信息的判断中，若当前为乡村道路、县道等两边环境比较优美的道路则执行控制逻辑。

综上可见，当遇到天气舒适、pm2.5和紫外线指数不高、风力不大、道路通畅、道路环境优美，则执行对天窗/车窗的开启，反之则执行对天窗/车窗的关闭。

在本实施例中，是根据预设自动执行对对天窗/车窗的开启/关闭。这个预设可以是用户预先对天窗/车窗操控模式的场景条件进行配置，也可以是先前询问并由用户确认操控后系统自动对场景条件的配置所进行的存储。

基于路况和天气的天窗/车窗控制方法的第三实施例

图1示出了本发明的基于路况和天气的天窗/车窗控制方法的实施例的流程。请参见图1，本实施例的天窗/车窗控制方法的具体实施步骤详述如下。

步骤s1：车机实时采集包括当前车辆位置在内的信息。

通常车机是通过车机上的gps来获取车辆当前位置。

步骤s2：车机被触发启动判断是否操控天窗/车窗的控制逻辑。

在本实施例中，触发启动控制逻辑的机制是云端服务器中的信息发生变化时通知车机触发的。比如，云端服务器中的实时路况从拥堵变为通畅，或者天气信息从下雨变成晴天等，重大信息的变化会让云端服务器向车机发送执行控制逻辑的触发信号。

步骤s3：车机从云端服务器获取包括实时路况和天气状况在内的信息。

云端服务器的实时路况包括道路拥堵状况，例如分为极其拥堵、拥堵、通畅等，还有拥堵距离、预计通行时间、通行时速、车流量等数据，这一信息来源于行车地图上的实时路况，或者其他第三方提供的数据。天气状况包括天气预报信息(比如晴天、阴天、雨天、多云、下雪等、风力大小、气温)、天气指数数据。天气预报信息可以是指定位置指定时间段的精准天气服务，包括当前时间以及未来多天。天气指数包括紫外线指数、雾霾指数、pm2.5指数、空气质量指数、人体穿衣舒适度指数等。这些指数数据来源于第三方的专业天气数据提供商。此外，车机的导航地图中存储了道路等级信息，将道路分为国道、省道、县道、城市道路、乡村道路等。

步骤s4：车机根据从云端服务器获取到的信息执行控制逻辑，基于控制逻辑的结果执行对天窗/车窗开启或关闭动作。

简单而言，车机根据从云端服务器获得的道路拥堵状况、天气预报信息、天气指数数据，再结合车机上的道路等级信息，执行控制逻辑。当然车机也会检测当前车窗/天窗所处的状态(开启或关闭)。

在控制逻辑的具体执行过程中，较佳的可以根据一定的顺序依次判断相对独立的各条件，只有在前一条件判断符合的情况下才进行下一条件的判断。若遇到不符合的条件则直接终止运行当前的控制逻辑，这样就节省了多余的判断时间，提升了判断的效率。举例而言，可以按照天气预报信息、天气指数数据、道路拥堵情况、道路等级信息的顺序依次做判断。在天气预报信息的判断中，若遇到恶劣天气(比如下雨、下雪、雾霾、冰雹、大风等)，则终止后续的控制逻辑的运行，等待下一次的控制逻辑的启动。随后，在天气指数数据的判断中，若pm2.5指数或者紫外线指数特别高，则终止后续的控制逻辑的运行，等待下一次的控制逻辑的启动。接着，在道路拥堵情况的判断中，若当前道路状况十分拥堵，则终止后续的控制逻辑的运行，等待下一次的控制逻辑的启动。最后，在道路等级信息的判断中，若当前为乡村道路、县道等两边环境比较优美的道路则执行控制逻辑。

综上可见，当遇到天气舒适、pm2.5和紫外线指数不高、风力不大、道路通畅、道路环境优美，则执行对天窗/车窗的开启，反之则执行对天窗/车窗的关闭。

在本实施例中，若需要执行对天窗/车窗的开启/关闭，则会询问用户是否需要打开天窗/车窗的开启/关闭，在收到用户对此询问的反馈后执行相应的动作。

基于路况和天气的天窗/车窗控制方法的第四实施例

图1示出了本发明的基于路况和天气的天窗/车窗控制方法的实施例的流程。请参见图1，本实施例的天窗/车窗控制方法的具体实施步骤详述如下。

步骤s1：车机实时采集包括当前车辆位置在内的信息。

通常车机是通过车机上的gps来获取车辆当前位置。

步骤s2：车机被触发启动判断是否操控天窗/车窗的控制逻辑。

在本实施例中，触发启动控制逻辑的机制是云端服务器中的信息发生变化时通知车机触发的。比如，云端服务器中的实时路况从拥堵变为通畅，或者天气信息从下雨变成晴天等，重大信息的变化会让云端服务器向车机发送执行控制逻辑的触发信号。

步骤s3：车机从云端服务器获取包括实时路况和天气状况在内的信息。

云端服务器的实时路况包括道路拥堵状况，例如分为极其拥堵、拥堵、通畅等，还有拥堵距离、预计通行时间、通行时速、车流量等数据，这一信息来源于行车地图上的实时路况，或者其他第三方提供的数据。天气状况包括天气预报信息(比如晴天、阴天、雨天、多云、下雪等、风力大小、气温)、天气指数数据。天气预报信息可以是指定位置指定时间段的精准天气服务，包括当前时间以及未来多天。天气指数包括紫外线指数、雾霾指数、pm2.5指数、空气质量指数、人体穿衣舒适度指数等。这些指数数据来源于第三方的专业天气数据提供商。此外，车机的导航地图中存储了道路等级信息，将道路分为国道、省道、县道、城市道路、乡村道路等。

步骤s4：车机根据从云端服务器获取到的信息执行控制逻辑，基于控制逻辑的结果执行对天窗/车窗开启或关闭动作。

简单而言，车机根据从云端服务器获得的道路拥堵状况、天气预报信息、天气指数数据，再结合车机上的道路等级信息，执行控制逻辑。当然车机也会检测当前车窗/天窗所处的状态(开启或关闭)。

在控制逻辑的具体执行过程中，较佳的可以根据一定的顺序依次判断相对独立的各条件，只有在前一条件判断符合的情况下才进行下一条件的判断。若遇到不符合的条件则直接终止运行当前的控制逻辑，这样就节省了多余的判断时间，提升了判断的效率。举例而言，可以按照天气预报信息、天气指数数据、道路拥堵情况、道路等级信息的顺序依次做判断。在天气预报信息的判断中，若遇到恶劣天气(比如下雨、下雪、雾霾、冰雹、大风等)，则终止后续的控制逻辑的运行，等待下一次的控制逻辑的启动。随后，在天气指数数据的判断中，若pm2.5指数或者紫外线指数特别高，则终止后续的控制逻辑的运行，等待下一次的控制逻辑的启动。接着，在道路拥堵情况的判断中，若当前道路状况十分拥堵，则终止后续的控制逻辑的运行，等待下一次的控制逻辑的启动。最后，在道路等级信息的判断中，若当前为乡村道路、县道等两边环境比较优美的道路则执行控制逻辑。

综上可见，当遇到天气舒适、pm2.5和紫外线指数不高、风力不大、道路通畅、道路环境优美，则执行对天窗/车窗的开启，反之则执行对天窗/车窗的关闭。

在本实施例中，是根据预设自动执行对对天窗/车窗的开启/关闭。这个预设可以是用户预先对天窗/车窗操控模式的场景条件进行配置，也可以是先前询问并由用户确认操控后系统自动对场景条件的配置所进行的存储。

基于路况和天气的天窗/车窗控制系统的第一实施例

图2示出了本发明的基于路况和天气的天窗/车窗控制系统的实施例的原理。请参见图2，本实施例的天窗/车窗控制系统包括云端服务器和车机。云端服务器中存有包括实时路况和天气状况在内的信息。车机包括车辆位置获取模块、智能控制服务模块、网络服务模块、控制逻辑运行模块。

车辆位置获取模块采集包括当前车辆位置在内的信息。通常车机是通过车机上的gps来获取车辆当前位置。

智能控制服务模块被触发启动判断是否操控天窗/车窗的控制逻辑。在本实施例中，触发启动控制逻辑的机制是通过车机定期轮询自动触发的，轮询周期可以是一个预设的固定值，也可以是一个和当前行驶状态相关的值。比如，可以将轮询周期长短和当前实时车速相关联，一般来说车辆时速越大轮询周期应该越短，比如设置车辆时速高于60km/h则每10分钟启动执行控制逻辑，低于60km/h则每30分钟启动执行控制逻辑。实时车速可以由车机通过gps获得。

网络服务模块从云端服务器获取包括实时路况和天气状况在内的信息。

云端服务器的实时路况包括道路拥堵状况，例如分为极其拥堵、拥堵、通畅等，还有拥堵距离、预计通行时间、通行时速、车流量等数据，这一信息来源于行车地图上的实时路况，或者其他第三方提供的数据。天气状况包括天气预报信息(比如晴天、阴天、雨天、多云、下雪等、风力大小、气温)、天气指数数据。天气预报信息可以是指定位置指定时间段的精准天气服务，包括当前时间以及未来多天。天气指数包括紫外线指数、雾霾指数、pm2.5指数、空气质量指数、人体穿衣舒适度指数等。这些指数数据来源于第三方的专业天气数据提供商。此外，车机的导航地图中存储了道路等级信息，将道路分为国道、省道、县道、城市道路、乡村道路等。

控制逻辑运行模块根据从云端服务器获取到的信息执行控制逻辑，基于控制逻辑的结果执行对天窗/车窗开启或关闭动作。

简单而言，车机根据从云端服务器获得的道路拥堵状况、天气预报信息、天气指数数据，再结合车机上的道路等级信息，执行控制逻辑。当然车机也会检测当前车窗/天窗所处的状态(开启或关闭)。

在控制逻辑的具体执行过程中，较佳的可以根据一定的顺序依次判断相对独立的各条件，只有在前一条件判断符合的情况下才进行下一条件的判断。若遇到不符合的条件则直接终止运行当前的控制逻辑，这样就节省了多余的判断时间，提升了判断的效率。举例而言，可以按照天气预报信息、天气指数数据、道路拥堵情况、道路等级信息的顺序依次做判断。在天气预报信息的判断中，若遇到恶劣天气(比如下雨、下雪、雾霾、冰雹、大风等)，则终止后续的控制逻辑的运行，等待下一次的控制逻辑的启动。随后，在天气指数数据的判断中，若pm2.5指数或者紫外线指数特别高，则终止后续的控制逻辑的运行，等待下一次的控制逻辑的启动。接着，在道路拥堵情况的判断中，若当前道路状况十分拥堵，则终止后续的控制逻辑的运行，等待下一次的控制逻辑的启动。最后，在道路等级信息的判断中，若当前为乡村道路、县道等两边环境比较优美的道路则执行控制逻辑。

综上可见，当遇到天气舒适、pm2.5和紫外线指数不高、风力不大、道路通畅、道路环境优美，则执行对天窗/车窗的开启，反之则执行对天窗/车窗的关闭。

在本实施例中，若需要执行对天窗/车窗的开启/关闭，则会询问用户是否需要打开天窗/车窗的开启/关闭，在收到用户对此询问的反馈后执行相应的动作。

基于路况和天气的天窗/车窗控制系统的第二实施例

图2示出了本发明的基于路况和天气的天窗/车窗控制系统的实施例的原理。请参见图2，本实施例的天窗/车窗控制系统包括云端服务器和车机。云端服务器中存有包括实时路况和天气状况在内的信息。车机包括车辆位置获取模块、智能控制服务模块、网络服务模块、控制逻辑运行模块。

车辆位置获取模块采集包括当前车辆位置在内的信息。通常车机是通过车机上的gps来获取车辆当前位置。

智能控制服务模块被触发启动判断是否操控天窗/车窗的控制逻辑。在本实施例中，触发启动控制逻辑的机制是通过车机定期轮询自动触发的，轮询周期可以是一个预设的固定值，也可以是一个和当前行驶状态相关的值。比如，可以将轮询周期长短和当前实时车速相关联，一般来说车辆时速越大轮询周期应该越短，比如设置车辆时速高于60km/h则每10分钟启动执行控制逻辑，低于60km/h则每30分钟启动执行控制逻辑。实时车速可以由车机通过gps获得。

网络服务模块从云端服务器获取包括实时路况和天气状况在内的信息。

云端服务器的实时路况包括道路拥堵状况，例如分为极其拥堵、拥堵、通畅等，还有拥堵距离、预计通行时间、通行时速、车流量等数据，这一信息来源于行车地图上的实时路况，或者其他第三方提供的数据。天气状况包括天气预报信息(比如晴天、阴天、雨天、多云、下雪等、风力大小、气温)、天气指数数据。天气预报信息可以是指定位置指定时间段的精准天气服务，包括当前时间以及未来多天。天气指数包括紫外线指数、雾霾指数、pm2.5指数、空气质量指数、人体穿衣舒适度指数等。这些指数数据来源于第三方的专业天气数据提供商。此外，车机的导航地图中存储了道路等级信息，将道路分为国道、省道、县道、城市道路、乡村道路等。

控制逻辑运行模块根据从云端服务器获取到的信息执行控制逻辑，基于控制逻辑的结果执行对天窗/车窗开启或关闭动作。

简单而言，车机根据从云端服务器获得的道路拥堵状况、天气预报信息、天气指数数据，再结合车机上的道路等级信息，执行控制逻辑。当然车机也会检测当前车窗/天窗所处的状态(开启或关闭)。

在控制逻辑的具体执行过程中，较佳的可以根据一定的顺序依次判断相对独立的各条件，只有在前一条件判断符合的情况下才进行下一条件的判断。若遇到不符合的条件则直接终止运行当前的控制逻辑，这样就节省了多余的判断时间，提升了判断的效率。举例而言，可以按照天气预报信息、天气指数数据、道路拥堵情况、道路等级信息的顺序依次做判断。在天气预报信息的判断中，若遇到恶劣天气(比如下雨、下雪、雾霾、冰雹、大风等)，则终止后续的控制逻辑的运行，等待下一次的控制逻辑的启动。随后，在天气指数数据的判断中，若pm2.5指数或者紫外线指数特别高，则终止后续的控制逻辑的运行，等待下一次的控制逻辑的启动。接着，在道路拥堵情况的判断中，若当前道路状况十分拥堵，则终止后续的控制逻辑的运行，等待下一次的控制逻辑的启动。最后，在道路等级信息的判断中，若当前为乡村道路、县道等两边环境比较优美的道路则执行控制逻辑。

综上可见，当遇到天气舒适、pm2.5和紫外线指数不高、风力不大、道路通畅、道路环境优美，则执行对天窗/车窗的开启，反之则执行对天窗/车窗的关闭。

在本实施例中，是根据预设自动执行对对天窗/车窗的开启/关闭。这个预设可以是用户预先对天窗/车窗操控模式的场景条件进行配置，也可以是先前询问并由用户确认操控后系统自动对场景条件的配置所进行的存储。

基于路况和天气的天窗/车窗控制系统的第三实施例

图2示出了本发明的基于路况和天气的天窗/车窗控制系统的实施例的原理。请参见图2，本实施例的天窗/车窗控制系统包括云端服务器和车机。云端服务器中存有包括实时路况和天气状况在内的信息。车机包括车辆位置获取模块、智能控制服务模块、网络服务模块、控制逻辑运行模块。

车辆位置获取模块采集包括当前车辆位置在内的信息。通常车机是通过车机上的gps来获取车辆当前位置。

智能控制服务模块被触发启动判断是否操控天窗/车窗的控制逻辑。在本实施例中，触发启动控制逻辑的机制是云端服务器中的信息发生变化时通知车机触发的。比如，云端服务器中的实时路况从拥堵变为通畅，或者天气信息从下雨变成晴天等，重大信息的变化会让云端服务器向车机发送执行控制逻辑的触发信号。

网络服务模块从云端服务器获取包括实时路况和天气状况在内的信息。

云端服务器的实时路况包括道路拥堵状况，例如分为极其拥堵、拥堵、通畅等，还有拥堵距离、预计通行时间、通行时速、车流量等数据，这一信息来源于行车地图上的实时路况，或者其他第三方提供的数据。天气状况包括天气预报信息(比如晴天、阴天、雨天、多云、下雪等、风力大小、气温)、天气指数数据。天气预报信息可以是指定位置指定时间段的精准天气服务，包括当前时间以及未来多天。天气指数包括紫外线指数、雾霾指数、pm2.5指数、空气质量指数、人体穿衣舒适度指数等。这些指数数据来源于第三方的专业天气数据提供商。此外，车机的导航地图中存储了道路等级信息，将道路分为国道、省道、县道、城市道路、乡村道路等。

控制逻辑运行模块根据从云端服务器获取到的信息执行控制逻辑，基于控制逻辑的结果执行对天窗/车窗开启或关闭动作。

简单而言，车机根据从云端服务器获得的道路拥堵状况、天气预报信息、天气指数数据，再结合车机上的道路等级信息，执行控制逻辑。当然车机也会检测当前车窗/天窗所处的状态(开启或关闭)。

在控制逻辑的具体执行过程中，较佳的可以根据一定的顺序依次判断相对独立的各条件，只有在前一条件判断符合的情况下才进行下一条件的判断。若遇到不符合的条件则直接终止运行当前的控制逻辑，这样就节省了多余的判断时间，提升了判断的效率。举例而言，可以按照天气预报信息、天气指数数据、道路拥堵情况、道路等级信息的顺序依次做判断。在天气预报信息的判断中，若遇到恶劣天气(比如下雨、下雪、雾霾、冰雹、大风等)，则终止后续的控制逻辑的运行，等待下一次的控制逻辑的启动。随后，在天气指数数据的判断中，若pm2.5指数或者紫外线指数特别高，则终止后续的控制逻辑的运行，等待下一次的控制逻辑的启动。接着，在道路拥堵情况的判断中，若当前道路状况十分拥堵，则终止后续的控制逻辑的运行，等待下一次的控制逻辑的启动。最后，在道路等级信息的判断中，若当前为乡村道路、县道等两边环境比较优美的道路则执行控制逻辑。

综上可见，当遇到天气舒适、pm2.5和紫外线指数不高、风力不大、道路通畅、道路环境优美，则执行对天窗/车窗的开启，反之则执行对天窗/车窗的关闭。

在本实施例中，若需要执行对天窗/车窗的开启/关闭，则会询问用户是否需要打开天窗/车窗的开启/关闭，在收到用户对此询问的反馈后执行相应的动作。

基于路况和天气的天窗/车窗控制系统的第四实施例

图2示出了本发明的基于路况和天气的天窗/车窗控制系统的实施例的原理。请参见图2，本实施例的天窗/车窗控制系统包括云端服务器和车机。云端服务器中存有包括实时路况和天气状况在内的信息。车机包括车辆位置获取模块、智能控制服务模块、网络服务模块、控制逻辑运行模块。

车辆位置获取模块采集包括当前车辆位置在内的信息。通常车机是通过车机上的gps来获取车辆当前位置。

智能控制服务模块被触发启动判断是否操控天窗/车窗的控制逻辑。在本实施例中，触发启动控制逻辑的机制是云端服务器中的信息发生变化时通知车机触发的。比如，云端服务器中的实时路况从拥堵变为通畅，或者天气信息从下雨变成晴天等，重大信息的变化会让云端服务器向车机发送执行控制逻辑的触发信号。

网络服务模块从云端服务器获取包括实时路况和天气状况在内的信息。

云端服务器的实时路况包括道路拥堵状况，例如分为极其拥堵、拥堵、通畅等，还有拥堵距离、预计通行时间、通行时速、车流量等数据，这一信息来源于行车地图上的实时路况，或者其他第三方提供的数据。天气状况包括天气预报信息(比如晴天、阴天、雨天、多云、下雪等、风力大小、气温)、天气指数数据。天气预报信息可以是指定位置指定时间段的精准天气服务，包括当前时间以及未来多天。天气指数包括紫外线指数、雾霾指数、pm2.5指数、空气质量指数、人体穿衣舒适度指数等。这些指数数据来源于第三方的专业天气数据提供商。此外，车机的导航地图中存储了道路等级信息，将道路分为国道、省道、县道、城市道路、乡村道路等。

控制逻辑运行模块根据从云端服务器获取到的信息执行控制逻辑，基于控制逻辑的结果执行对天窗/车窗开启或关闭动作。

简单而言，车机根据从云端服务器获得的道路拥堵状况、天气预报信息、天气指数数据，再结合车机上的道路等级信息，执行控制逻辑。当然车机也会检测当前车窗/天窗所处的状态(开启或关闭)。

在控制逻辑的具体执行过程中，较佳的可以根据一定的顺序依次判断相对独立的各条件，只有在前一条件判断符合的情况下才进行下一条件的判断。若遇到不符合的条件则直接终止运行当前的控制逻辑，这样就节省了多余的判断时间，提升了判断的效率。举例而言，可以按照天气预报信息、天气指数数据、道路拥堵情况、道路等级信息的顺序依次做判断。在天气预报信息的判断中，若遇到恶劣天气(比如下雨、下雪、雾霾、冰雹、大风等)，则终止后续的控制逻辑的运行，等待下一次的控制逻辑的启动。随后，在天气指数数据的判断中，若pm2.5指数或者紫外线指数特别高，则终止后续的控制逻辑的运行，等待下一次的控制逻辑的启动。接着，在道路拥堵情况的判断中，若当前道路状况十分拥堵，则终止后续的控制逻辑的运行，等待下一次的控制逻辑的启动。最后，在道路等级信息的判断中，若当前为乡村道路、县道等两边环境比较优美的道路则执行控制逻辑。

综上可见，当遇到天气舒适、pm2.5和紫外线指数不高、风力不大、道路通畅、道路环境优美，则执行对天窗/车窗的开启，反之则执行对天窗/车窗的关闭。

在本实施例中，是根据预设自动执行对对天窗/车窗的开启/关闭。这个预设可以是用户预先对天窗/车窗操控模式的场景条件进行配置，也可以是先前询问并由用户确认操控后系统自动对场景条件的配置所进行的存储。

用于控制天窗/车窗开闭的车机的第一实施例

图3示出了本发明的用于控制天窗/车窗开闭的车机的实施例的原理。请参见图3，本实施例的车机包括车辆位置获取模块、智能控制服务模块、网络服务模块、控制逻辑运行模块。

车辆位置获取模块采集包括当前车辆位置在内的信息。通常车机是通过车机上的gps来获取车辆当前位置。

智能控制服务模块被触发启动判断是否操控天窗/车窗的控制逻辑。在本实施例中，触发启动控制逻辑的机制是通过车机定期轮询自动触发的，轮询周期可以是一个预设的固定值，也可以是一个和当前行驶状态相关的值。比如，可以将轮询周期长短和当前实时车速相关联，一般来说车辆时速越大轮询周期应该越短，比如设置车辆时速高于60km/h则每10分钟启动执行控制逻辑，低于60km/h则每30分钟启动执行控制逻辑。实时车速可以由车机通过gps获得。

网络服务模块从云端服务器获取包括实时路况和天气状况在内的信息。

云端服务器的实时路况包括道路拥堵状况，例如分为极其拥堵、拥堵、通畅等，还有拥堵距离、预计通行时间、通行时速、车流量等数据，这一信息来源于行车地图上的实时路况，或者其他第三方提供的数据。天气状况包括天气预报信息(比如晴天、阴天、雨天、多云、下雪等、风力大小、气温)、天气指数数据。天气预报信息可以是指定位置指定时间段的精准天气服务，包括当前时间以及未来多天。天气指数包括紫外线指数、雾霾指数、pm2.5指数、空气质量指数、人体穿衣舒适度指数等。这些指数数据来源于第三方的专业天气数据提供商。此外，车机的导航地图中存储了道路等级信息，将道路分为国道、省道、县道、城市道路、乡村道路等。

控制逻辑运行模块根据从云端服务器获取到的信息执行控制逻辑，基于控制逻辑的结果执行对天窗/车窗开启或关闭动作。

简单而言，车机根据从云端服务器获得的道路拥堵状况、天气预报信息、天气指数数据，再结合车机上的道路等级信息，执行控制逻辑。当然车机也会检测当前车窗/天窗所处的状态(开启或关闭)。

在控制逻辑的具体执行过程中，较佳的可以根据一定的顺序依次判断相对独立的各条件，只有在前一条件判断符合的情况下才进行下一条件的判断。若遇到不符合的条件则直接终止运行当前的控制逻辑，这样就节省了多余的判断时间，提升了判断的效率。举例而言，可以按照天气预报信息、天气指数数据、道路拥堵情况、道路等级信息的顺序依次做判断。在天气预报信息的判断中，若遇到恶劣天气(比如下雨、下雪、雾霾、冰雹、大风等)，则终止后续的控制逻辑的运行，等待下一次的控制逻辑的启动。随后，在天气指数数据的判断中，若pm2.5指数或者紫外线指数特别高，则终止后续的控制逻辑的运行，等待下一次的控制逻辑的启动。接着，在道路拥堵情况的判断中，若当前道路状况十分拥堵，则终止后续的控制逻辑的运行，等待下一次的控制逻辑的启动。最后，在道路等级信息的判断中，若当前为乡村道路、县道等两边环境比较优美的道路则执行控制逻辑。

综上可见，当遇到天气舒适、pm2.5和紫外线指数不高、风力不大、道路通畅、道路环境优美，则执行对天窗/车窗的开启，反之则执行对天窗/车窗的关闭。

在本实施例中，若需要执行对天窗/车窗的开启/关闭，则会询问用户是否需要打开天窗/车窗的开启/关闭，在收到用户对此询问的反馈后执行相应的动作。

用于控制天窗/车窗开闭的车机的第二实施例

图3示出了本发明的用于控制天窗/车窗开闭的车机的实施例的原理。请参见图3，本实施例的车机包括车辆位置获取模块、智能控制服务模块、网络服务模块、控制逻辑运行模块。

车辆位置获取模块采集包括当前车辆位置在内的信息。通常车机是通过车机上的gps来获取车辆当前位置。

智能控制服务模块被触发启动判断是否操控天窗/车窗的控制逻辑。在本实施例中，触发启动控制逻辑的机制是通过车机定期轮询自动触发的，轮询周期可以是一个预设的固定值，也可以是一个和当前行驶状态相关的值。比如，可以将轮询周期长短和当前实时车速相关联，一般来说车辆时速越大轮询周期应该越短，比如设置车辆时速高于60km/h则每10分钟启动执行控制逻辑，低于60km/h则每30分钟启动执行控制逻辑。实时车速可以由车机通过gps获得。

网络服务模块从云端服务器获取包括实时路况和天气状况在内的信息。

云端服务器的实时路况包括道路拥堵状况，例如分为极其拥堵、拥堵、通畅等，还有拥堵距离、预计通行时间、通行时速、车流量等数据，这一信息来源于行车地图上的实时路况，或者其他第三方提供的数据。天气状况包括天气预报信息(比如晴天、阴天、雨天、多云、下雪等、风力大小、气温)、天气指数数据。天气预报信息可以是指定位置指定时间段的精准天气服务，包括当前时间以及未来多天。天气指数包括紫外线指数、雾霾指数、pm2.5指数、空气质量指数、人体穿衣舒适度指数等。这些指数数据来源于第三方的专业天气数据提供商。此外，车机的导航地图中存储了道路等级信息，将道路分为国道、省道、县道、城市道路、乡村道路等。

控制逻辑运行模块根据从云端服务器获取到的信息执行控制逻辑，基于控制逻辑的结果执行对天窗/车窗开启或关闭动作。

简单而言，车机根据从云端服务器获得的道路拥堵状况、天气预报信息、天气指数数据，再结合车机上的道路等级信息，执行控制逻辑。当然车机也会检测当前车窗/天窗所处的状态(开启或关闭)。

在控制逻辑的具体执行过程中，较佳的可以根据一定的顺序依次判断相对独立的各条件，只有在前一条件判断符合的情况下才进行下一条件的判断。若遇到不符合的条件则直接终止运行当前的控制逻辑，这样就节省了多余的判断时间，提升了判断的效率。举例而言，可以按照天气预报信息、天气指数数据、道路拥堵情况、道路等级信息的顺序依次做判断。在天气预报信息的判断中，若遇到恶劣天气(比如下雨、下雪、雾霾、冰雹、大风等)，则终止后续的控制逻辑的运行，等待下一次的控制逻辑的启动。随后，在天气指数数据的判断中，若pm2.5指数或者紫外线指数特别高，则终止后续的控制逻辑的运行，等待下一次的控制逻辑的启动。接着，在道路拥堵情况的判断中，若当前道路状况十分拥堵，则终止后续的控制逻辑的运行，等待下一次的控制逻辑的启动。最后，在道路等级信息的判断中，若当前为乡村道路、县道等两边环境比较优美的道路则执行控制逻辑。

综上可见，当遇到天气舒适、pm2.5和紫外线指数不高、风力不大、道路通畅、道路环境优美，则执行对天窗/车窗的开启，反之则执行对天窗/车窗的关闭。

在本实施例中，是根据预设自动执行对对天窗/车窗的开启/关闭。这个预设可以是用户预先对天窗/车窗操控模式的场景条件进行配置，也可以是先前询问并由用户确认操控后系统自动对场景条件的配置所进行的存储。

用于控制天窗/车窗开闭的车机的第三实施例

图3示出了本发明的用于控制天窗/车窗开闭的车机的实施例的原理。请参见图3，本实施例的车机包括车辆位置获取模块、智能控制服务模块、网络服务模块、控制逻辑运行模块。

车辆位置获取模块采集包括当前车辆位置在内的信息。通常车机是通过车机上的gps来获取车辆当前位置。

智能控制服务模块被触发启动判断是否操控天窗/车窗的控制逻辑。在本实施例中，触发启动控制逻辑的机制是云端服务器中的信息发生变化时通知车机触发的。比如，云端服务器中的实时路况从拥堵变为通畅，或者天气信息从下雨变成晴天等，重大信息的变化会让云端服务器向车机发送执行控制逻辑的触发信号。

网络服务模块从云端服务器获取包括实时路况和天气状况在内的信息。

云端服务器的实时路况包括道路拥堵状况，例如分为极其拥堵、拥堵、通畅等，还有拥堵距离、预计通行时间、通行时速、车流量等数据，这一信息来源于行车地图上的实时路况，或者其他第三方提供的数据。天气状况包括天气预报信息(比如晴天、阴天、雨天、多云、下雪等、风力大小、气温)、天气指数数据。天气预报信息可以是指定位置指定时间段的精准天气服务，包括当前时间以及未来多天。天气指数包括紫外线指数、雾霾指数、pm2.5指数、空气质量指数、人体穿衣舒适度指数等。这些指数数据来源于第三方的专业天气数据提供商。此外，车机的导航地图中存储了道路等级信息，将道路分为国道、省道、县道、城市道路、乡村道路等。

控制逻辑运行模块根据从云端服务器获取到的信息执行控制逻辑，基于控制逻辑的结果执行对天窗/车窗开启或关闭动作。

简单而言，车机根据从云端服务器获得的道路拥堵状况、天气预报信息、天气指数数据，再结合车机上的道路等级信息，执行控制逻辑。当然车机也会检测当前车窗/天窗所处的状态(开启或关闭)。

在控制逻辑的具体执行过程中，较佳的可以根据一定的顺序依次判断相对独立的各条件，只有在前一条件判断符合的情况下才进行下一条件的判断。若遇到不符合的条件则直接终止运行当前的控制逻辑，这样就节省了多余的判断时间，提升了判断的效率。举例而言，可以按照天气预报信息、天气指数数据、道路拥堵情况、道路等级信息的顺序依次做判断。在天气预报信息的判断中，若遇到恶劣天气(比如下雨、下雪、雾霾、冰雹、大风等)，则终止后续的控制逻辑的运行，等待下一次的控制逻辑的启动。随后，在天气指数数据的判断中，若pm2.5指数或者紫外线指数特别高，则终止后续的控制逻辑的运行，等待下一次的控制逻辑的启动。接着，在道路拥堵情况的判断中，若当前道路状况十分拥堵，则终止后续的控制逻辑的运行，等待下一次的控制逻辑的启动。最后，在道路等级信息的判断中，若当前为乡村道路、县道等两边环境比较优美的道路则执行控制逻辑。

综上可见，当遇到天气舒适、pm2.5和紫外线指数不高、风力不大、道路通畅、道路环境优美，则执行对天窗/车窗的开启，反之则执行对天窗/车窗的关闭。

在本实施例中，若需要执行对天窗/车窗的开启/关闭，则会询问用户是否需要打开天窗/车窗的开启/关闭，在收到用户对此询问的反馈后执行相应的动作。

用于控制天窗/车窗开闭的车机的第四实施例

图3示出了本发明的用于控制天窗/车窗开闭的车机的实施例的原理。请参见图3，本实施例的车机包括车辆位置获取模块、智能控制服务模块、网络服务模块、控制逻辑运行模块。

车辆位置获取模块采集包括当前车辆位置在内的信息。通常车机是通过车机上的gps来获取车辆当前位置。

智能控制服务模块被触发启动判断是否操控天窗/车窗的控制逻辑。在本实施例中，触发启动控制逻辑的机制是云端服务器中的信息发生变化时通知车机触发的。比如，云端服务器中的实时路况从拥堵变为通畅，或者天气信息从下雨变成晴天等，重大信息的变化会让云端服务器向车机发送执行控制逻辑的触发信号。

网络服务模块从云端服务器获取包括实时路况和天气状况在内的信息。

云端服务器的实时路况包括道路拥堵状况，例如分为极其拥堵、拥堵、通畅等，还有拥堵距离、预计通行时间、通行时速、车流量等数据，这一信息来源于行车地图上的实时路况，或者其他第三方提供的数据。天气状况包括天气预报信息(比如晴天、阴天、雨天、多云、下雪等、风力大小、气温)、天气指数数据。天气预报信息可以是指定位置指定时间段的精准天气服务，包括当前时间以及未来多天。天气指数包括紫外线指数、雾霾指数、pm2.5指数、空气质量指数、人体穿衣舒适度指数等。这些指数数据来源于第三方的专业天气数据提供商。此外，车机的导航地图中存储了道路等级信息，将道路分为国道、省道、县道、城市道路、乡村道路等。

控制逻辑运行模块根据从云端服务器获取到的信息执行控制逻辑，基于控制逻辑的结果执行对天窗/车窗开启或关闭动作。

简单而言，车机根据从云端服务器获得的道路拥堵状况、天气预报信息、天气指数数据，再结合车机上的道路等级信息，执行控制逻辑。当然车机也会检测当前车窗/天窗所处的状态(开启或关闭)。

在控制逻辑的具体执行过程中，较佳的可以根据一定的顺序依次判断相对独立的各条件，只有在前一条件判断符合的情况下才进行下一条件的判断。若遇到不符合的条件则直接终止运行当前的控制逻辑，这样就节省了多余的判断时间，提升了判断的效率。举例而言，可以按照天气预报信息、天气指数数据、道路拥堵情况、道路等级信息的顺序依次做判断。在天气预报信息的判断中，若遇到恶劣天气(比如下雨、下雪、雾霾、冰雹、大风等)，则终止后续的控制逻辑的运行，等待下一次的控制逻辑的启动。随后，在天气指数数据的判断中，若pm2.5指数或者紫外线指数特别高，则终止后续的控制逻辑的运行，等待下一次的控制逻辑的启动。接着，在道路拥堵情况的判断中，若当前道路状况十分拥堵，则终止后续的控制逻辑的运行，等待下一次的控制逻辑的启动。最后，在道路等级信息的判断中，若当前为乡村道路、县道等两边环境比较优美的道路则执行控制逻辑。

综上可见，当遇到天气舒适、pm2.5和紫外线指数不高、风力不大、道路通畅、道路环境优美，则执行对天窗/车窗的开启，反之则执行对天窗/车窗的关闭。

在本实施例中，是根据预设自动执行对对天窗/车窗的开启/关闭。这个预设可以是用户预先对天窗/车窗操控模式的场景条件进行配置，也可以是先前询问并由用户确认操控后系统自动对场景条件的配置所进行的存储。

图4示出了在车辆上实现本发明的组件。如图4所示，云端服务器主要提供系统所需要的实时数据服务，包括实时路况服务和天气服务，其中实时路况服务主要提供指定位置道路是否拥堵的数据查询服务，包括通畅、拥堵、严重拥堵、拥堵距离、预计通行时间、通行时速、车流量等信息，天气服务主要提供指定位置指定时间段的精确天气服务，包括当前时间和未来3天的天气信息(晴朗、多云、雨雪等，风力大小)、温度信息、空气质量指数、pm2.5指数、紫外线指数、人体穿衣舒适度指数。

车机是整个系统的执行和控制端，采用但不限于android系统，包括智能控制服务、网络服务(networkservice)、can总线服务(canbusservice)、位置服务和地图引擎。

智能控制服务为一个后台服务，开机启动运行，主要为根据车辆的运行状态(如时速)来一定频率检测及执行是否打开天窗的服务。

networkservice封装了访问云端的实时路况，天气等服务，提供方便快捷的接口让智能控制服务模块获取相应的网络信息，主要通过https从云端各服务提供商获取相应数据服务，如查询当前位置实时路口，查询当前位置当前时间天气信息、空气质量指数。

canbusservice主要是封装发送can协议帧的模块，通过该模块可以像车辆发送打开/关闭天窗的相应can指令，以及打开天窗一级等更精确的控制can指令，同时可获取车辆相应的can指令响应反馈，以明确操作是否成功，也可以查询当前天窗的状态，如是否已经打开，同时，也可以通过该模块获取车辆相关的其它can信息，如当前车速、can状态等。

位置服务通过gps系统获取当前车机所处的实时位置、时速等信息。

地图引擎提供相关的地图服务，可获取当前位置的道路级别信息，如国道、省道、县道、乡村道路、城市道路、道路宽度等具体信息。

mcu主要是单片机，运行实时系统，可实时接收解析车辆的can总线信息，同时发送相应的can协议给车辆的bcm模块。

天窗通过bcm模块来执行天窗或车窗的打开、关闭等操作。

尽管为使解释简单化将上述方法图示并描述为一系列动作，但是应理解并领会，这些方法不受动作的次序所限，因为根据一个或多个实施例，一些动作可按不同次序发生和/或与来自本文中图示和描述或本文中未图示和描述但本领域技术人员可以理解的其他动作并发地发生。

本领域技术人员将进一步领会，结合本文中所公开的实施例来描述的各种解说性逻辑板块、模块、电路、和算法步骤可实现为电子硬件、计算机软件、或这两者的组合。为清楚地解说硬件与软件的这一可互换性，各种解说性组件、框、模块、电路、和步骤在上面是以其功能性的形式作一般化描述的。此类功能性是被实现为硬件还是软件取决于具体应用和施加于整体系统的设计约束。技术人员对于每种特定应用可用不同的方式来实现所描述的功能性，但这样的实现决策不应被解读成导致脱离了本发明的范围。

结合本文所公开的实施例描述的各种解说性逻辑板块、模块、和电路可用通用处理器、数字信号处理器(dsp)、专用集成电路(asic)、现场可编程门阵列(fpga)或其它可编程逻辑器件、分立的门或晶体管逻辑、分立的硬件组件、或其设计成执行本文所描述功能的任何组合来实现或执行。通用处理器可以是微处理器，但在替换方案中，该处理器可以是任何常规的处理器、控制器、微控制器、或状态机。处理器还可以被实现为计算设备的组合，例如dsp与微处理器的组合、多个微处理器、与dsp核心协作的一个或多个微处理器、或任何其他此类配置。

结合本文中公开的实施例描述的方法或算法的步骤可直接在硬件中、在由处理器执行的软件模块中、或在这两者的组合中体现。软件模块可驻留在ram存储器、闪存、rom存储器、eprom存储器、eeprom存储器、寄存器、硬盘、可移动盘、cd-rom、或本领域中所知的任何其他形式的存储介质中。示例性存储介质耦合到处理器以使得该处理器能从/向该存储介质读取和写入信息。在替换方案中，存储介质可以被整合到处理器。处理器和存储介质可驻留在asic中。asic可驻留在用户终端中。在替换方案中，处理器和存储介质可作为分立组件驻留在用户终端中。

在一个或多个示例性实施例中，所描述的功能可在硬件、软件、固件或其任何组合中实现。如果在软件中实现为计算机程序产品，则各功能可以作为一条或更多条指令或代码存储在计算机可读介质上或藉其进行传送。计算机可读介质包括计算机存储介质和通信介质两者，其包括促成计算机程序从一地向另一地转移的任何介质。存储介质可以是能被计算机访问的任何可用介质。作为示例而非限定，这样的计算机可读介质可包括ram、rom、eeprom、cd-rom或其它光盘存储、磁盘存储或其它磁存储设备、或能被用来携带或存储指令或数据结构形式的合意程序代码且能被计算机访问的任何其它介质。任何连接也被正当地称为计算机可读介质。例如，如果软件是使用同轴电缆、光纤电缆、双绞线、数字订户线(dsl)、或诸如红外、无线电、以及微波之类的无线技术从web网站、服务器、或其它远程源传送而来，则该同轴电缆、光纤电缆、双绞线、dsl、或诸如红外、无线电、以及微波之类的无线技术就被包括在介质的定义之中。如本文中所使用的盘(disk)和碟(disc)包括压缩碟(cd)、激光碟、光碟、数字多用碟(dvd)、软盘和蓝光碟，其中盘(disk)往往以磁的方式再现数据，而碟(disc)用激光以光学方式再现数据。上述的组合也应被包括在计算机可读介质的范围内。

提供对本公开的先前描述是为使得本领域任何技术人员皆能够制作或使用本公开。对本公开的各种修改对本领域技术人员来说都将是显而易见的，且本文中所定义的普适原理可被应用到其他变体而不会脱离本公开的精神或范围。由此，本公开并非旨在被限定于本文中所描述的示例和设计，而是应被授予与本文中所公开的原理和新颖性特征相一致的最广范围。