[0001] 本发明涉及路侧应用技术领域，尤其涉及一种基于开源鸿蒙系统的车道交易方法及路侧系统。

[0002] 随着智能交通系统的快速发展，高速ETC(电子不停车收费)RSU(路边单元)技术已成为现代高速公路收费系统的核心组件。该技术以其高效、便捷的特点，得到了广泛应用。然而，在实际应用中，高速ETC RSU技术也面临着一些技术问题：

[0003] 1.信号干扰：在高速公路环境中，RSU设备可能会受到来自周围环境的信号干扰，如无线电信号、电磁干扰等。这些干扰可能导致RSU设备无法准确识别车辆标签，从而影响收费操作的正常进行。

[0004] 2.数据安全：高速ETC RSU系统涉及到车主的个人信息和支付数据，因此数据安全问题至关重要。在实际应用中，需要加强数据加密、身份认证等安全措施，以防止数据泄露和非法访问。

[0005] 系统兼容：随着ETC系统的不断发展，不同地区、不同厂家之间的RSU设备可能会存在兼容性问题。这可能导致在不同地区使用ETC时出现无法识别标签、交易失败等问题。因此，提高系统兼容性是高速ETC RSU技术面临的重要挑战之一。

[0043] 为了对本发明的技术特征、目的和效果有更加清楚的理解，现对照附图详细说明本发明的具体实施方式。

[0044] 以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本发明实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本发明。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本发明的描述。

[0045] 本发明实施例提供的一种基于开源鸿蒙系统的车道交易方法，车道交易方法基于Stage模型设计，如图1所示，车道交易方法包括：

[0046] 通过开源鸿蒙系统的ArkUI框架和ArkTS语言绘制RSU的用户界面，并利用ArkUI框架下发启动交易指令。

[0047] 需要说明的是，ArkUI架构主要围绕开发效率、性能体验、多平台支持进行设计。开发效率：能够兼顾两种开发范式，方便不同经验的开发者进行选择，并结合工具链的能力，提升开发和调试的效率。性能体验：结合方舟编译器和Runtime，提升语言的执行效率；另外，使用C++开发的声明保证了UI后端渲染引擎能够拥有较高的性能。因此，本发明通过使用ArkUI框架和ArkTS语言能够为车道交易方法提供用户页面，简化了用户页面的开发，加快了迭代效率。

[0048] 在其他一些可执行的实施例中，还可以为车道交易方法提供操作界面。具体的，根据车道交易的要求可以设计不同的用户界面。

[0049] 接收启动交易指令，启动交易服务，并将交易服务的执行结果反馈至用户界面。

[0050] ArkTS提供了多维度的状态管理机制。在ArkUI框架中，与用户界面相关联的数据可以在组件内使用，也可以在不同组件层级间传递，比如父子组件之间、爷孙组件之间，还可以在应用全局范围内传递或跨设备传递。另外，从数据的传递形式来看，可分为只读的单向传递和可变更的双向传递。可以灵活地利用这些能力来实现交易服务的数据和用户界面的联动。

[0051] 本发明通过ArkUI框架和ArkTS语言用不同的组件完成车道交易方法。因Stage模型具有严格的安全机制和隐私保护措施，保障用户数据的安全可靠，所以本发明能够提高数据交互时的安全性，防止数据泄露和非法访问。同时，由于鸿蒙开源系统具有统一的接口规范，使得即便是不同厂家开发的基于鸿蒙开源系统的路侧应用与具备本交易车道方法的路侧系统交互也不会出现兼容性的问题，从而减少无法识别标签、交易失败等问题的几率。ArkTS提供了类型检查和静态分析等功能，可以提高代码的可靠性和可维护性，从而保障了交易的稳定性。同时，它还能够与JavaScript代码无缝集成，方便开发者进行迁移和扩展。

[0052] 在一个可执行的实际例中，通过开源鸿蒙系统的ArkUI框架和ArkTS语言绘制RSU的用户界面，并利用ArkUI框架下发启动交易指令，包括：

[0053] 生成用户界面。

[0054] 通过ArkUI框架的Napi子框架的接口下发启动交易指令。

[0055] 具体的，OpenHarmony适配后的RSU应用提供了用户界面，提供更多的信息，这跟原来的RSU应用是有区别的(原有的RSU应用不提供UI展示)，所以RSU设备上电后，启动系统，会自动启动RSU应用，应用在用户界面完成初始化后，会回调消息响应函数，在消息响应函数中，会调用NAPI层提供的接口下发启动交易指令。

[0056] 在一个可执行的实际例中，接收启动交易指令，启动交易服务，并将交易服务的执行结果反馈至用户界面，包括：

[0057] 利用业务模块接收启动交易指令，启动交易服务，获取执行结果。

[0058] 具体的，业务模块位于开源鸿蒙系统的框架层，通过Ark框架中的子框架调用业务模块中的函数，启动交易服务，获取执行结果。

[0059] 通过ArkUI框架将执行结果反馈至用户界面。

[0060] 具体的，业务模块获取到执行结果后，判断根据执行结果判断是否有进行交易，若进行了交易则将交易结果反馈至用户界面。例如，如果交易成功，可以显示一个成功的消息；如果失败，则显示错误信息。ArkUI框架提供了实时界面更新的机制，使得用户界面的变化能够及时反映给用户。

[0061] 通过Ark框架将前后端进行分离，能够使用ArkUI提供的一系列现成的UI组件。可以直接使用这些组件来构建应用的界面，简化了开发过程，提高应用开发和迭代的效率。同时，ArkUI还支持自定义组件，开发者可以根据自己的需求扩展和定制UI组件，使得用户界面更加流畅，易于使用，提高界面信息的可读性，保障交易的可追溯性。

[0062] 在一个可执行的实际例中，启动交易服务，获取执行结果，包括：

[0063] 创建网络服务端，执行监听客户端指令以及搜索OBU指令。

[0064] 创建Socket服务端，通过TCP/IP接收PC车道上位机的连接，通过5.8GHz DSRC与OBU通信，实时检测OBU，搜索到OBU则向PC车道上位机发起ETC交易请求。

[0065] 搜索OBU指令搜索到OBU设备后，执行ETC交易流程，获取执行结果。

[0066] 具体的，NAPI层调用业务模块(TradeModule)定义的启动方法(start_service)，启动ETC交易服务。启动方法将创建网络服务端(TCP Socket服务端)，并创建用于监听客户端的连接线程(Accept_Client_Thread)和用于ETC交易的交易线程(ETC_Trade_Thread)。连接线程线程负责执行监听客户端指令，处理PC车道软件客户端连接。交易线程用于执行搜索OBU指令，并执行ETC交易流程，获取执行结果。

[0067] 在一个可执行的实际例中，监听客户端指令，包括：

[0068] 循环判断客户端连接状态是否正常。

[0069] 在一个可执行的实际例中，搜索OBU指令，包括：

[0070] 循环搜索OBU设备是否存在。

[0071] 通过ETC交易模块发送BST协议帧，当搜索到OBU后，返回VST协议帧。如果收到VST协议帧，则说明搜索到OBU。在一些其他的可执行的实施例中，收到VST协议帧，并且预设标记为B2，才说明搜索到OBU。

[0072] 在一个可执行的实际例中，循环搜索OBU设备是否存在，包括：

[0073] 利用业务模块循环下发OBU搜索指令至ETC交易模块。

[0074] 具体的，业务模块利用交易线程循环下发OBU搜索指令至ETC交易模块。

[0075] ETC交易模块接收OBU搜索指令，通过ETC交易模块搜索OBU设备，判断是否存在待连接的OBU设备。

[0076] 具体的，通过ETC交易模块发送BST协议帧，当搜索到OBU后，返回VST协议帧。

[0077] 在一个可执行的实际例中，搜索OBU指令搜索到OBU设备后，执行ETC交易流程，获取执行结果，包括：

[0078] 利用ETC交易模块与OBU设备进行交互，获取OBU设备的车载单元信息。

[0079] 如果收到VST，并且预设标记为B2，则说明搜索到OBU，则将VST携带的OBU系统信息组装为B2帧(车载单元信息)，发送到PC端车道软件(客户端的一种)，记录预设标记为B3。

[0080] 根据车载单元信息获取车道交易指令。

[0081] 具体的，循环(Loop2)接收PC端数据，并进行协议帧解析，此时车道软件将返回如下车道交易指令：C1帧(继续交易)、C2帧(停止交易)、C6帧(执行消费)。

[0082] 执行车道交易指令，得到车道交易指令的交易结果。

[0083] 根据车道交易指令的信息，与PC段车道软件、OBU进行数据交互，得到不同指令的交易结果。

[0084] 根据交易结果，获取执行结果。

[0085] 在其它一些可执行的实施例中，如图2所示，ETC交易流程包括：

[0086] ETC交易模块将B2帧到PC端。将获取车辆信息的指令发送至OBU。将接收到的车辆信息组合成B2帧发送至PC端。接收PC端指令，判断预设标志是否为C1，如果不是，则直接返回交易异常。

[0087] 如果是没见过获取卡片信息的指令传输至OBU。将卡片信息组合成B4帧发送至PC端。接收PC端指令，判断是否为C6帧，如果不是则判断是否为C8帧，若不是C8帧则直接返回交易异常。

[0088] 若为C6帧则下发消防操作的指令至OBU；若为C8帧则下发获取TAC码指令至OBU。将消费信息或TAC码组合成B5帧传输至PC端。再次判断是否接受到C1帧，若接收到C1帧，则返回交易完成，若收到的不是C1帧则返回交易异常。

[0089] 在一个可执行的实际例中，根据车载单元信息获取车道交易指令，包括：

[0090] 通过ETC交易模块将车载单元信息发送至PC端；

[0091] 进一步的，如果收到C1帧，并且预设标记为B3，则调用ETCModule获取车辆信息；ETC交易模块通过发送GetSecure.request协议帧与OBU通讯，接收OBU返回的GetSecure.response协议帧，获取到OBU车辆信息密文，调用PSAM进行3DES算法或者SM4算法解密车辆信息；获取车辆信息明文后，发送B3帧(车辆信息)到PC端车道软件，记录预设标记为B4；

[0092] 如果收到C1帧，并且预设标记为B4，则调用ETC交易模块获取CPU卡用户信息，包括0015文件、0019文件、EF04文件等；获取CPU卡用户信息后，发送B4帧(用户卡信息)到PC端车道软件，记录预设标记为B5。

[0093] 接收PC端下发的车道交易指令。

[0094] 本发明还提供一种基于开源鸿蒙系统的路侧系统，路侧系统基于Stage模型搭建。

[0095] 需要说明的是，Stage模型提供面向对象的开发方式，规范化了进程创建的方式，提供组件化开发机制，将组件抽象为UIAbility和ExtensionAbility两大类。UIAbility组件的生命周期包含创建、销毁、前台、后台状态，将与界面强相关的获焦、失焦状态都放在窗口管理对象中，从而实现UIAbility与窗口之间的弱耦合；在服务侧,窗口管理服务依赖于组件管理服务，前者通知后者前后台变化，这样组件管理服务仅感知前后台变化，不感知焦点变化。ExtensionAbility组件提供场景化的服务扩展机制，不提供自定义服务的能力。

[0096] 原有的路侧系统划分了6个模块，在移植到OpenHarmony后，根据OpenHarmony程序框架的特点，为了更好的适配OpenHarmony系统框架，进一步优化程序功能，模块进行了重新调整，业务主程序、web应用、日志管理划分到了用户级业务程序中，有些模块需要在后台运行，需要以系统级服务方式呈现，比如升级管理，守护进程，远程调试等模块，在OpenHarmony中，后台服务需要特定的系统权限和API，所以将部分模块功能统一划分到了系统级服务。

[0097] 路侧系统包括：用户界面模块，用于通过开源鸿蒙系统的ArkUI框架和ArkTS语言绘制RSU的用户界面，并利用ArkUI框架下发启动交易指令。

[0098] 具体的，用户界面模块可以单独为一个模块，还可以作为用户级业务程序下业务主程序下的一个子模块存在。

[0099] 扩展功能模块，用于接收启动交易指令，启动交易服务，并将交易服务的执行结果反馈至用户界面。

[0100] 在一些可执行的实施例中，如图3所示，路侧系统的架构包括：

[0101] 界面层，用于展示用户界面。业务逻辑层，包括NAPI接口和业务程序的不同功能模块。通讯层，包括业务程序的ETC交易模块，用于启动交易服务，并与OBU交互，底层依赖开源鸿蒙系统的HDF框架。

[0102] 以上实施例仅表达了本发明的优选实施方式，其描述较为具体和详细，但并不能因此而理解为对本发明专利范围的限制；应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，可以对上述技术特点进行自由组合，还可以做出若干变形和改进，这些都属于本发明的保护范围；因此，凡跟本发明权利要求范围所做的等同变换与修饰，均应属于本发明权利要求的涵盖范围。