一种车载终端与智能手机的互联方法
【专利摘要】一种车载终端与智能手机的互联方法，实现手机和车载终端互联，透过数据线或WiFi把导航画面映射到车载终端上，把导航声音传递到车载终端利用车载终端喇叭进行播放，同时,实现手机与车载终端双屏幕的双向操控；在车载屏幕上形成简单、明了的导航界面，通过车载终端上的物理按键或屏幕上的软按键就可以进行相应的菜单操作；互联方案完全靠软件实现；互联成功后车载设备和手机显示相同的导航界面；并且车载终端和手机端均能操作导航系统。本发明的优点：实现手机的小屏幕换到车机大屏上显示，更符合车上的用户使用习惯，不仅全面提升了驾乘的便利性，车内的驾驶体验亦得到了发烧级的拓展。
【专利说明】一种车载终端与智能手机的互联方法
【技术领域】
[0001]本发明涉及智能移动终端为核心的车载终端导航领域，特别涉及了一种车载终端与智能手机的互联方法。
【背景技术】
[0002]随着汽车电子行业的兴起，汽车导航系统开始走入人们的视线。目前主要有车载终端、手持设备、智能手机等运行平台。
[0003]车载终端屏幕比较大，操作起来比较方便，但也存在不少缺点:
[0004]随着互联网快速发展，单一的车载终端总滞后于消费者的需要。最突出的一个问题是，硬件发展永远跟不上时代发展的脚步。在手机市场，苹果手机系统1s 7.X，安卓手机系统Android 4.成为主流的时候，车机仍旧在WINCE平台上爬行。手机、电脑内存2G以上已成标配，车机内存512M就已经很了不起。
[0005]第二是联网能力有限，目前中国移动终端网络传输还是有问题，再加上车载终端的数据传输速率比较高、流量大，影响了联网能力。
[0006]第三，具备定制了车载信息服务的终端需要支付额外的费用，且费用很贵。
[0007]第四，用户无法选择车载终端的服务内容，也没办法进行扩展。
[0008]第五，传统车载终端服务非常封闭。
[0009]第六，车载移动终端服务更新升级很繁琐，很多车载导航地图买了之后几年都不会升级，升级比较麻烦而且费用高。
【发明内容】
[0010]本发明的目的是为了把智能手机的优点和车载终端的优点结合起来，满足消费者的需求，特提供了一种车载终端与智能手机的互联方法。
[0011]本发明提供了一种车载终端与智能手机的互联方法，其特征在于:所述的车载终端与智能手机的互联方法，实现手机和车载终端互联，透过数据线或WiFi把导航画面映射到车载终端上，把导航声音传递到车载终端利用车载终端喇叭进行播放，同时，实现手机与车载终端双屏幕的双向操控。在车载屏幕上形成简单、明了的导航界面，通过车载终端上的物理按键或屏幕上的软按键就可以进行相应的菜单操作。
[0012]车载终端，可以通过数据线进行连接，也可以通过Wifi热点进行连接。互联方案完全靠软件实现。
[0013]并且，在手机与车载终端互联之后，不影响手机的正常使用，可随时接收、拨打电话，收发短信，操作手机上其他APP等。
[0014]智能手机作为互联的服务端，负责处理原本导航所有相关的内部运作，包括数据读写、逻辑运算、处理用户操作、算路、引导、检索、描画等功能。另外还要负责在适当的时机将图片、声音发送出去；并将车载终端发送过来的用户操作信息应用到导航中，就像用户操作的是手机一样。
[0015]车载终端作为互联的客户端，相对简单。不需要参与导航的具体职能。描画、算路、引导、检索等都与车载终端无关。车载终端只需要接收智能手机传来的图片，进行显示；声音进行播报。并将用户操作按顺序无遗漏的发送出去。
[0016]智能手机和车载终端在连接到一个局域网之后能互相发现对方；并能按照协议互相交互信息，交互需要是双向畅通的。一旦互联条件发生变更，例如网络阻塞、Wifi断开、数据线拔除等，车载终端此时无法继续表现导航，但智能手机仍能继续导航，不受影响。
[0017]互联成功后车载设备和手机显示相同的导航界面。并且车载终端和手机端均能操作导航系统。
[0018]目前主流的智能手机都集中在1S和Android两种操作系统，互联系统需要考虑用户感受，不能限制用户使用的是何种手机设备，均能与同一车载终端上的同车载终端软件进行互联，中途不需要任何额外切换操作。
[0019]互联后不能影响手机的接打电话等功能。
[0020]为了使用户操作便捷，避免连接到一个局域网，通过数据线或Wifi成功后，输入局域网内IP地址的麻烦操作，互联系统需要有自动获取对方IP地址的功能。地址获取成功后还要有商务校验的过程，只有批准配对互联的设备才能进行互联，保护各方利益及产权。
[0021]同一个智能手机可与一个或多个车载设备端互联。只求要这些设备都联接在同一个局域网内。
[0022]互联成功后，需要及时将画面和声音从手机端发送到车载设备端，导航的特殊性，不能缓冲否则就无时效性可言，所以要求传输性能、解码速度能跟上导航系统的要求。同时车载设备端也需要及时将操作一个不落的按顺序传送给手机端，保证用户操作正确、流畅。
[0023]当关闭手机端或关闭手机端Wifi时，所有连接的车载设备端都需要断开连接，进入等待模式，等待手机端重新启动或重新连接Wifi后，自动再次互联。最后一个连接在系统中的车载设备端关闭或关闭Wifi时，手机端断开连接，但仍能在手机端继续导航。等有新的车载设备端启动或开启Wifi时,再次自动连接。
[0024]车载终端有已经预装车载导航软件的状态，互联系统不能影响预装的车载导航的正常工作，用户可在两个导航间自由选择，随时切换。
[0025]技术解决方案:
[0026]智能手机作为互联的服务端，车载设备作为互联的车载终端。
[0027]智能手机在导航系统中加入MayLink模块。对内，与画面更新、声音播报、处理操作的三个模块有接口进行交互；对外负责处理与车载终端的通信，根据协议，发送图片和声音，接收车载终端发回的触屏控制消息。
[0028]车载终端与导航业务无关，只负责接收图片、声音。并将屏幕消息按照格式要求发回给智能手机。
[0029]使用Wifi进行互联的模式通常智能手机即能建立热点，也能接收热点。根据不同的车载终端硬件，如果车载终端可建立Wifi热点，那么使用车载终端作为热点，手机接收热点即可。如果车载终端只能接收热点，那么使用智能手机建立Wifi热点，车载终端接收热点。
[0030]如果使用USB数据线进行互联，那么将数据线两端分别连接在车载终端与手机上即可。
[0031]无论使用以上哪种方案，最终的目的是将智能手机与车载终端连接到一个局域网内。
[0032]通过UDP广播的方式使设备互相发现，1S和Android设备需要分别实现。并进行各方面的校验，并需要考虑不同版本的兼容性。智能手机要有能力管理所有联接在一套系统内的所有车载终端。
[0033]时效性也是要导航设备要考虑的另一个重要因素，Wifi联接受带宽影响，在发送画面前，图片要经过放缩、颜色转换、压缩等步骤，并只有在更新后才发送。智能手机需要记录最新的画面，这样可以只传送更新区域的新图片。声音也要在智能手机进行堆积的删减处理，保证不发过期的引导。
[0034]车载终端需要截获所有屏幕操作，包括点击、滑动、多点触控等，并按顺序将其发送给智能手机。智能手机需要将MLink模块收到的操作按照本身接到的屏幕消息一样处理，保证智能手机和车载终端都能操作导航。
[0035]车载终端是一个独立于导航之外的独立的应用，与车载导航使用完全不同的资源，互不影响。当然也可以根据特殊的定制需求，进行切换处理
[0036]互联过程主要分为以下两个阶段，为完成不同的功能，两个阶段分别使用不同协议。
[0037](一)使用UDP协议发送、接收广播包的过程。其步骤如下:
[0038]Cl:初始化客户端广播“套接字”。
[0039]C2:向“套接字”设置广播属性。
[0040]C3:发送数据包，其中包括自身IP地址和用于校验的字符串。
[0041]C4:等待接收数据
[0042]S1:初始化服务端广播“套接字”。
[0043]S2:绑定服务端监听的端口号
[0044]S3:接收发向端口号的广播信息。
[0045]S4:检测此信息是否为当前所需要的，例如判断字符串是否匹配。
[0046]S5:若检测结果为此条消息为正在等待的信息，从广播信息中分离出客户端的IP地址，将自身的IP地址加入到信息中发回。
[0047]Ml:客户端发出的寻找服务端的广播消息。
[0048]M2:服务端回复的带有自身IP地址的消息。客户端收到此消息后，可与消息中的IP地址进行真正的TCP联接。
[0049]自此，服务端与客户端完成自动寻找的过程，并自动进行联接。
[0050]注意事项如下:
[0051]接收方一定要知道广播方的端口号，然后绑定此端口号才能正确接收。
[0052]接收方的Socket不需要设置成广播属性。
[0053]绑定的IP不可以使用127.0.0.1，可以使用真实IP地址或者INADDR_ANY。否则接收失败。
[0054](二)使用TCP协议，“套接字”网络发出请求或者应答网络请求，具体步骤如下:
[0055]S1:创建服务端TCP协议“套接字”需要区别于广播使用的套接字。
[0056]S2:服务端绑定端口号，这个端口号也要区别于广播的端口号。
[0057]S3:服务端接收信息，接到消息后，需要根据不同类型进行后续操作。
[0058]S4:服务端发送消息，包括画面、声音更新等消息。
[0059]S5:关闭套接字，断开联接。
[0060]Cl:创建客户端TCP协议“套接字”，需要区别于广播使用的套接字。
[0061]C2:客户端绑定端口号，这个端口号也要区别于广播的端口号。
[0062]C3:客户端发送消息，触控消息需要及时按顺序全部发送。
[0063]C4:客户端接收消息，接收到画面更新消息，需要按格式解压缩数据，并显示在屏幕上；接收到声音播报消息，需要立即播报。
[0064]C5:关闭套接字，断开联接。
[0065]Ml:客户端发出的消息，包括请求画面更新、触屏按下、抬起、移动、多点触控等等。
[0066]M2:服务端发出的消息，包括画面更新数据、声音更新数据。
[0067]SLl:服务端接收发送的循环过程。
[0068]CLl:客户端接收发送的循环过程。
[0069]依照以上流程可呈现出互联的效果:车机端能显示手机端同样的导航，也能通过车机端控制手机端的导航。
[0070]注意事项:
[0071]为保证传输效率，应尽量减少传输的数据。要求客户端要保留上一帧的画面数据，这样，服务只需要将更新的区域发送给客户端，客户端就能显示出完整、正确的导航地图。
[0072]服务端需要有对声音控制的能力，当待发声音多余一个时，及声音发生了堆积，需要有一定的规则来对声音惊醒删减，只保留那些必须要发送的声音给客户端，保证时效性。
[0073]客户端及时描画机制:某些情况下，客户端需要立即响应客户操作，显示相关内容，等待互相传送来不及，以手写功能为例，如果每次更新画面都等待服务端传画面数据，客户端的反应就会延迟很严重，给操作者没有写上的感觉。需要客户端采取立即响应描画的机制，即将用户操作传送给服务端的同时，将用户划过的轨迹用线条描画出来。同时还要保证服务端不会传更新画面过来覆盖刚刚画好的手写区域。需要服务端和客户端在手写开始和结束的时候互通额外的协议，来表明状态。所以互联模块还需要提供机制满足这种服务端和客户端之间交互的这类额外的控制状态的协议，这类额外的协议需要按照实际情况及时发送。
[0074]本发明的优点:
[0075]本发明所述的车载终端与智能手机的互联方法，实现手机的小屏幕换到车机大屏上显示，更符合车上的用户使用习惯，不仅全面提升了驾乘的便利性，车内的驾驶体验亦得到了发烧级的拓展。手机车机映射不仅降低了整车厂开发车联网的成本，而且对车主来说，未来车载应用和手机应用协同应该是一种完美的服务体验。车载导航与智能手机联通的实施方案不仅可以降低车机的硬件成本，在车机里面可省去导航地图，而且因所支持的应用均通过手机流量实现，所以系统本身并没有产生任何上网使用费用。
【专利附图】
【附图说明】
[0076]下面结合附图及实施方式对本发明作进一步详细的说明:
[0077]图1为智能手机服务端与车载终端客户端互联示意图；
[0078]图2为UDP协议发送、接收广播包示意图；
[0079]图3为使用TCP协议，“套接字”网络发出请求或者应答网络请求示意图。
【具体实施方式】
[0080]实施例1
[0081]本实施例提供了一种车载终端与智能手机的互联方法，其特征在于:所述的车载终端与智能手机的互联方法，实现手机和车载终端互联，透过数据线或WiFi把导航画面映射到车载终端上，把导航声音传递到车载终端利用车载终端喇叭进行播放，同时，实现手机与车载终端双屏幕的双向操控。在车载屏幕上形成简单、明了的导航界面，通过车载终端上的物理按键或屏幕上的软按键就可以进行相应的菜单操作。
[0082]车载终端，可以通过数据线进行连接，也可以通过wifi热点进行连接。互联方案完全靠软件实现。
[0083]并且，在手机与车载终端互联之后，不影响手机的正常使用，可随时接收、拨打电话，收发短信，操作手机上其他APP等。
[0084]手机作为互联的服务端，负责处理原本导航所有相关的内部运作，包括数据读写、逻辑运算、处理用户操作、算路、引导、检索、描画等功能。另外还要负责在适当的时机将图片、声音发送出去；并将车载终端发送过来的用户操作信息应用到导航中，就像用户操作的是手机一样。
[0085]车载终端作为互联的客户端，相对简单。不需要参与导航的具体职能。描画、算路、引导、检索等都与车载终端无关。车载终端只需要接收智能手机传来的图片，进行显示；声音进行播报。并将用户操作按顺序无遗漏的发送出去。
[0086]智能手机和车载终端在连接到一个局域网之后能互相发现对方；并能按照协议互相交互信息，交互需要是双向畅通的。一旦互联条件发生变更，例如网络阻塞、Wifi断开、数据线拔除等，车载终端此时无法继续表现导航，但智能手机仍能继续导航，不受影响。
[0087]互联成功后车载设备和手机显示相同的导航界面。并且车载终端和手机端均能操作导航系统。
[0088]目前主流的智能手机都集中在1S和Android两种操作系统，互联系统需要考虑用户感受，不能限制用户使用的是何种手机设备，均能与同一车载终端上的同车载终端软件进行互联，中途不需要任何额外切换操作。
[0089]互联后不能影响手机的接打电话等功能。
[0090]为了使用户操作便捷，避免连接到一个局域网，通过数据线或Wifi成功后，输入局域网内IP地址的麻烦操作，互联系统需要有自动获取对方IP地址的功能。地址获取成功后还要有商务校验的过程，只有批准配对互联的设备才能进行互联，保护各方利益及产权。
[0091]同一个智能手机可与一个或多个车载设备端互联。只求要这些设备都联接在同一个局域网内。
[0092]互联成功后，需要及时将画面和声音从手机端发送到车载设备端，导航的特殊性，不能缓冲否则就无时效性可言，所以要求传输性能、解码速度能跟上导航系统的要求。同时车载设备端也需要及时将操作一个不落的按顺序传送给手机端，保证用户操作正确、流畅。
[0093]当关闭手机端或关闭手机端Wifi时，所有连接的车载设备端都需要断开连接，进入等待模式，等待手机端重新启动或重新连接Wifi后，自动再次互联。最后一个连接在系统中的车载设备端关闭或关闭Wifi时，手机端断开连接，但仍能在手机端继续导航。等有新的车载设备端启动或开启Wifi时,再次自动连接。
[0094]车载终端有已经预装车载导航软件的状态，互联系统不能影响预装的车载导航的正常工作，用户可在两个导航间自由选择，随时切换。
[0095]技术解决方案:
[0096]智能手机作为互联的服务端，车载设备作为互联的车载终端。
[0097]智能手机在导航系统中加入MayLink模块。对内，与画面更新、声音播报、处理操作的三个模块有接口进行交互；对外负责处理与车载终端的通信，根据协议，发送图片和声音，接收车载终端发回的触屏控制消息。
[0098]车载终端与导航业务无关，只负责接收图片、声音。并将屏幕消息按照格式要求发回给智能手机。
[0099]使用Wifi进行互联的模式通常智能手机即能建立热点，也能接收热点。根据不同的车载终端硬件，如果车载终端可建立Wifi热点，那么使用车载终端作为热点，手机接收热点即可。如果车载终端只能接收热点，那么使用智能手机建立Wifi热点，车载终端接收热点。
[0100]如果使用USB数据线进行互联，那么将数据线两端分别连接在车载终端与手机上即可。
[0101]无论使用以上哪种方案，最终的目的是将智能手机与车载终端连接到一个局域网内。
[0102]通过UDP广播的方式使设备互相发现，1S和Android设备需要分别实现。并进行各方面的校验，并需要考虑不同版本的兼容性。智能手机要有能力管理所有联接在一套系统内的所有车载终端。
[0103]时效性也是要导航设备要考虑的另一个重要因素，Wifi联接受带宽影响，在发送画面前，图片要经过放缩、颜色转换、压缩等步骤，并只有在更新后才发送。智能手机需要记录最新的画面，这样可以只传送更新区域的新图片。声音也要在智能手机进行堆积的删减处理，保证不发过期的引导。
[0104]车载终端需要截获所有屏幕操作，包括点击、滑动、多点触控等，并按顺序将其发送给智能手机。智能手机需要将MLink模块收到的操作按照本身接到的屏幕消息一样处理，保证智能手机和车载终端都能操作导航。
[0105]车载终端是一个独立于导航之外的独立的应用，与车载导航使用完全不同的资源，互不影响。当然也可以根据特殊的定制需求，进行切换处理
[0106]互联过程主要分为以下两个阶段，为完成不同的功能，两个阶段分别使用不同协议。
[0107](一)使用UDP协议发送、接收广播包的过程。其步骤如下:
[0108]Cl:初始化客户端广播“套接字”。
[0109]C2:向“套接字”设置广播属性。
[0110]C3:发送数据包，其中包括自身IP地址和用于校验的字符串。
[0111]C4:等待接收数据
[0112]S1:初始化服务端广播“套接字”。
[0113]S2:绑定服务端监听的端口号
[0114]S3:接收发向端口号的广播信息。
[0115]S4:检测此信息是否为当前所需要的，例如判断字符串是否匹配。
[0116]S5:若检测结果为此条消息为正在等待的信息，从广播信息中分离出客户端的IP地址，将自身的IP地址加入到信息中发回。
[0117]Ml:客户端发出的寻找服务端的广播消息。
[0118]M2:服务端回复的带有自身IP地址的消息。客户端收到此消息后，可与消息中的IP地址进行真正的TCP联接。
[0119]自此，服务端与客户端完成自动寻找的过程，并自动进行联接。
[0120]注意事项如下:
[0121 ] 接收方一定要知道广播方的端口号，然后绑定此端口号才能正确接收。
[0122]接收方的Socket不需要设置成广播属性。
[0123]绑定的IP不可以使用127.0.0.1，可以使用真实IP地址或者INADDR_ANY。否则接收失败。
[0124](二)使用TCP协议，“套接字”网络发出请求或者应答网络请求，具体步骤如下:
[0125]S1:创建服务端TCP协议“套接字”需要区别于广播使用的套接字。
[0126]S2:服务端绑定端口号，这个端口号也要区别于广播的端口号。
[0127]S3:服务端接收信息，接到消息后，需要根据不同类型进行后续操作。
[0128]S4:服务端发送消息，包括画面、声音更新等消息。
[0129]S5:关闭套接字，断开联接。
[0130]Cl:创建客户端TCP协议“套接字”，需要区别于广播使用的套接字。
[0131]C2:客户端绑定端口号，这个端口号也要区别于广播的端口号。
[0132]C3:客户端发送消息，触控消息需要及时按顺序全部发送。
[0133]C4:客户端接收消息，接收到画面更新消息，需要按格式解压缩数据，并显示在屏幕上；接收到声音播报消息，需要立即播报。
[0134]C5:关闭套接字，断开联接。
[0135]Ml:客户端发出的消息，包括请求画面更新、触屏按下、抬起、移动、多点触控等等。
[0136]M2:服务端发出的消息，包括画面更新数据、声音更新数据。
[0137]SLl:服务端接收发送的循环过程。
[0138]CLl:客户端接收发送的循环过程。
[0139]依照以上流程可呈现出互联的效果:车机端能显示手机端同样的导航，也能通过车机端控制手机端的导航。
[0140]注意事项:
[0141]为保证传输效率，应尽量减少传输的数据。要求客户端要保留上一帧的画面数据，这样，服务只需要将更新的区域发送给客户端，客户端就能显示出完整、正确的导航地图。
[0142]服务端需要有对声音控制的能力，当待发声音多余一个时，及声音发生了堆积，需要有一定的规则来对声音惊醒删减，只保留那些必须要发送的声音给客户端，保证时效性。
[0143]客户端及时描画机制:某些情况下，客户端需要立即响应客户操作，显示相关内容，等待互相传送来不及，以手写功能为例，如果每次更新画面都等待服务端传画面数据，客户端的反应就会延迟很严重，给操作者没有写上的感觉。需要客户端采取立即响应描画的机制，即将用户操作传送给服务端的同时，将用户划过的轨迹用线条描画出来。同时还要保证服务端不会传更新画面过来覆盖刚刚画好的手写区域。需要服务端和客户端在手写开始和结束的时候互通额外的协议，来表明状态。所以互联模块还需要提供机制满足这种服务端和客户端之间交互的这类额外的控制状态的协议，这类额外的协议需要按照实际情况及时发送。
【权利要求】
1.一种车载终端与智能手机的互联方法，其特征在于:所述的车载终端与智能手机的互联方法，实现手机和车载终端互联，透过数据线或WiFi把导航画面映射到车载终端上，把导航声音传递到车载终端利用车载终端喇叭进行播放，同时，实现手机与车载终端双屏幕的双向操控；在车载屏幕上形成简单、明了的导航界面，通过车载终端上的物理按键或屏幕上的软按键就可以进行相应的菜单操作； 车载终端，可以通过数据线进行连接，也可以通过wifi热点进行连接；互联方案完全靠软件实现； 并且，在手机与车载终端互联之后，不影响手机的正常使用，可随时接收、拨打电话，收发短信，操作手机上其他APP; 手机作为互联的服务端，负责处理原本导航所有相关的内部运作，包括数据读写、逻辑运算、处理用户操作、算路、引导、检索、描画等功能；另外还要负责在适当的时机将图片、声音发送出去；并将车载终端发送过来的用户操作信息应用到导航中，就像用户操作的是手机一样； 车载终端作为互联的客户端，相对简单；不需要参与导航的具体职能；描画、算路、弓丨导、检索等都与车载终端无关；车载终端只需要接收智能手机传来的图片，进行显示；声音进行播报；并将用户操作按顺序无遗漏的发送出去； 智能手机和车载终端在连接到一个局域网之后能互相发现对方；并能按照协议互相交互信息，交互需要是双向畅通的；一旦互联条件发生变更，例如网络阻塞、Wifi断开、数据线拔除等，车载终端此时无法继续表现导航，但智能手机仍能继续导航，不受影响； 互联成功后车载设备和手机显示相同的导航界面；并且车载终端和手机端均能操作导航系统； 目前主流的智能手机都集中在1S和Android两种操作系统，互联系统需要考虑用户感受，不能限制用户使用的是何种手机设备，均能与同一车载终端上的同车载终端软件进行互联，中途不需要任何额外切换操作； 互联后不能影响手机的接打电话等功能； 为了使用户操作便捷，避免连接到一个局域网，通过数据线或Wifi成功后，输入局域网内IP地址的麻烦操作，互联系统需要有自动获取对方IP地址的功能；地址获取成功后还要有商务校验的过程，只有批准配对互联的设备才能进行互联，保护各方利益及产权； 同一个智能手机可与一个或多个车载设备端互联；只求要这些设备都联接在同一个局域网内； 互联成功后，需要及时将画面和声音从手机端发送到车载设备端，导航的特殊性，不能缓冲否则就无时效性可言，所以要求传输性能、解码速度能跟上导航系统的要求；同时车载设备端也需要及时将操作一个不落的按顺序传送给手机端，保证用户操作正确、流畅；当关闭手机端或关闭手机端Wifi时，所有连接的车载设备端都需要断开连接，进入等待模式，等待手机端重新启动或重新连接Wifi后，自动再次互联；最后一个连接在系统中的车载设备端关闭或关闭Wifi时，手机端断开连接，但仍能在手机端继续导航；等有新的车载设备端启动或开启Wifi时,再次自动连接； 车载终端有已经预装车载导航软件的状态，互联系统不能影响预装的车载导航的正常工作，用户可在两个导航间自由选择，随时切换； 技术解决方案: 智能手机作为互联的服务端，车载设备作为互联的车载终端； 智能手机在导航系统中加入MayLink模块；对内，与画面更新、声音播报、处理操作的三个模块有接口进行交互；对外负责处理与车载终端的通信，根据协议，发送图片和声音，接收车载终端发回的触屏控制消息； 车载终端与导航业务无关，只负责接收图片、声音；并将屏幕消息按照格式要求发回给智能手机； 使用Wifi进行互联的模式通常智能手机即能建立热点，也能接收热点；根据不同的车载终端硬件，如果车载终端可建立Wifi热点，那么使用车载终端作为热点，手机接收热点即可；如果车载终端只能接收热点，那么使用智能手机建立Wifi热点，车载终端接收热点； 如果使用USB数据线进行互联，那么将数据线两端分别连接在车载终端与手机上即可； 无论使用以上哪种方案，最终的目的是将智能手机与车载终端连接到一个局域网内；通过UDP广播的方式使设备互相发现，1S和Android设备需要分别实现；并进行各方面的校验，并需要考虑不同版本的兼容性；智能手机要有能力管理所有联接在一套系统内的所有车载终端； 时效性也是要导航设备要考虑的另一个重要因素，Wifi联接受带宽影响，在发送画面前，图片要经过放缩、颜色转换、压缩等步骤，并只有在更新后才发送；智能手机需要记录最新的画面，这样可以只传送更新区域的新图片；声音也要在智能手机进行堆积的删减处理，保证不发过期的引导。
2.按照权利要求1所述的车载终端与智能手机的互联方法，其特征在于:车载终端需要截获所有屏幕操作，包括点击、滑动、多点触控等，并按顺序将其发送给智能手机；智能手机需要将MLink模块收到的操作按照本身接到的屏幕消息一样处理，保证智能手机和车载终端都能操作导航； 车载终端是一个独立于导航之外的独立的应用，与车载导航使用完全不同的资源，互不影响；当然也可以根据特殊的定制需求，进行切换处理。
3.按照权利要求1所述的车载终端与智能手机的互联方法，其特征在于:互联过程主要分为以下两个阶段，为完成不同的功能，两个阶段分别使用不同协议； (一)使用UDP协议发送、接收广播包的过程；其步骤如下: Cl:初始化客户端广播“套接字”； C2:向“套接字”设置广播属性； C3:发送数据包，其中包括自身IP地址和用于校验的字符串； C4:等待接收数据 51:初始化服务端广播“套接字”； 52:绑定服务端监听的端口号 53:接收发向端口号的广播信息； 54:检测此信息是否为当前所需要的，例如判断字符串是否匹配； 55:若检测结果为此条消息为正在等待的信息，从广播信息中分离出客户端的IP地址，将自身的IP地址加入到信息中发回； Ml:客户端发出的寻找服务端的广播消息； M2:服务端回复的带有自身IP地址的消息；客户端收到此消息后，可与消息中的IP地址进行真正的TCP联接； 自此，服务端与客户端完成自动寻找的过程，并自动进行联接； 注意事项如下: 接收方一定要知道广播方的端口号，然后绑定此端口号才能正确接收； 接收方的Socket不需要设置成广播属性； 绑定的IP不可以使用127.0.0.1，可以使用真实IP地址或者INADDR_ANY ;否则接收失败； (二)使用TCP协议，“套接字”网络发出请求或者应答网络请求，具体步骤如下: S1:创建服务端TCP协议“套接字”需要区别于广播使用的套接字； 52:服务端绑定端口号，这个端口号也要区别于广播的端口号； 53:服务端接收信息，接到消息后，需要根据不同类型进行后续操作； 54:服务端发送消息，包括画面、声音更新等消息； S5:关闭套接字，断开联接； Cl:创建客户端TCP协议“套接字”，需要区别于广播使用的套接字； C2:客户端绑定端口号，这个端口号也要区别于广播的端口号； C3:客户端发送消息，触控消息需要及时按顺序全部发送； C4:客户端接收消息，接收到画面更新消息，需要按格式解压缩数据，并显示在屏幕上；接收到声音播报消息，需要立即播报； C5:关闭套接字，断开联接； Ml:客户端发出的消息，包括请求画面更新、触屏按下、抬起、移动、多点触控等等； M2:服务端发出的消息，包括画面更新数据、声音更新数据； SLl:服务端接收发送的循环过程； CLl:客户端接收发送的循环过程； 依照以上流程可呈现出互联的效果:车机端能显示手机端同样的导航，也能通过车机端控制手机端的导航； 注意事项: 为保证传输效率，应尽量减少传输的数据；要求客户端要保留上一帧的画面数据，这样，服务只需要将更新的区域发送给客户端，客户端就能显示出完整、正确的导航地图；服务端需要有对声音控制的能力，当待发声音多余一个时，及声音发生了堆积，需要有一定的规则来对声音惊醒删减，只保留那些必须要发送的声音给客户端，保证时效性；客户端及时描画机制:某些情况下，客户端需要立即响应客户操作，显示相关内容，等待互相传送来不及，以手写功能为例，如果每次更新画面都等待服务端传画面数据，客户端的反应就会延迟很严重，给操作者没有写上的感觉；需要客户端采取立即响应描画的机制，即将用户操作传送给服务端的同时，将用户划过的轨迹用线条描画出来；同时还要保证服务端不会传更新画面过来覆盖刚刚画好的手写区域；需要服务端和客户端在手写开始和结束的时候互通额外的协议，来表明状态；所以互联模块还需要提供机制满足这种服务端和客户端之间交互的这类额外的控制状态的协议，这类额外的协议需要按照实际情况及时发
。鄉同寸A 0.玲 狀 r-ψ V寸寸οοεεε寸οι Zo
【文档编号】H04M1/725GK104333844SQ201410636824
【公开日】2015年2月4日 申请日期:2014年11月12日 优先权日:2014年11月12日
【发明者】宁宇, 高延冰, 李滨, 朱小莹, 王海世, 张丹, 王思思 申请人:沈阳美行科技有限公司