WO2023138001A1 - 一种新型界面换肤系统及其方法 - Google Patents

一种新型界面换肤系统及其方法 Download PDF

Info

Publication number
WO2023138001A1
WO2023138001A1 PCT/CN2022/103655 CN2022103655W WO2023138001A1 WO 2023138001 A1 WO2023138001 A1 WO 2023138001A1 CN 2022103655 W CN2022103655 W CN 2022103655W WO 2023138001 A1 WO2023138001 A1 WO 2023138001A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
hmi
layer
api layer
subunit
Prior art date
Application number
PCT/CN2022/103655
Other languages
English (en)
French (fr)
Inventor
贾梓鑫
景猛
赵颖慧
Original Assignee
中国第一汽车股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 中国第一汽车股份有限公司 filed Critical 中国第一汽车股份有限公司
Publication of WO2023138001A1 publication Critical patent/WO2023138001A1/zh

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/30Creation or generation of source code
    • G06F8/38Creation or generation of source code for implementing user interfaces
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/451Execution arrangements for user interfaces
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/542Event management; Broadcasting; Multicasting; Notifications
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/546Message passing systems or structures, e.g. queues
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00Indexing scheme relating to G06F9/00
    • G06F2209/54Indexing scheme relating to G06F9/54
    • G06F2209/545Gui
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00Indexing scheme relating to G06F9/00
    • G06F2209/54Indexing scheme relating to G06F9/54
    • G06F2209/547Messaging middleware
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02PCLIMATE CHANGE MITIGATION TECHNOLOGIES IN THE PRODUCTION OR PROCESSING OF GOODS
    • Y02P90/00Enabling technologies with a potential contribution to greenhouse gas [GHG] emissions mitigation
    • Y02P90/02Total factory control, e.g. smart factories, flexible manufacturing systems [FMS] or integrated manufacturing systems [IMS]

Definitions

  • This specification relates to the technical field of automobiles, in particular to a novel interface skinning system and method thereof.
  • the vehicle-machine system As a component of the vehicle, the vehicle-machine system is constantly updated and improved with the rapid development of information technology. Among them, the improvement of the functionality and experience of the vehicle increasingly relies on the vehicle-machine system.
  • the car-machine system has been greatly improved and progressed, there are still some problems in the current car-machine system: the car-machine system needs to design a variety of themes before it goes on the market, and the interface and interactive scene themes are updated from time to time after the car goes on the market, so as to promote users to have a better experience. And related themes are often applied in different models and different platforms.
  • the existing skinning method needs to receive different signals from the bottom layer according to different platforms, and then directly notify the HMI layer. Every time the platform is changed, the framework layer and the HMI layer need to be re-corresponded. Such a method is time-consuming, laborious, inefficient, and unable to respond to user concerns and needs in a timely manner, and such a method leads to poor portability of the designed theme.
  • the purpose of one or more embodiments of this specification is to propose a new interface skinning system and method thereof, so as to solve the problems of time-consuming, laborious, inefficient and poor portability of current skinning methods.
  • one or more embodiments of this specification provide a new interface skinning system:
  • a novel interface skinning system includes: HMI API layer, the level of the HMI API layer connection includes Common API layer and Kanzi DataSource layer;
  • the Common API layer includes the upper layer communication unit and the framework communication unit;
  • the Kanzi DataSource layer includes the general communication unit, the kanzi HMI communication unit and the internal data distribution unit.
  • the upper layer communication unit includes a first information receiving subunit and a first information sending subunit;
  • the framework communication unit includes Vehicle Service data communication subunit, State Manager data communication subunit and IVI Interaction data communication subunit.
  • the general communication unit includes a second information receiving subunit and a second information sending subunit;
  • the kanziHMI communication unit includes the Datasource XML definition subunit;
  • the internal data distribution unit includes a functional classification subunit and a logic processing display unit.
  • the system also includes a self-selection function module, and the self-selection function module includes a self-selection function unit.
  • the optional function module includes an optional functional unit, which is a power state unit.
  • a method specifically comprising: an uplink data transmission section and a downlink data transmission section, wherein the uplink data transmission section is used to transmit data transmitted from the Framework communication unit to the HMI API layer, and the downlink data transmission section is used to transmit data from the HMI API layer to the Framework communication unit;
  • the steps of the uplink data transmission segment include:
  • Step 1 when the MCU has a status update, the Vehicle Service data communication subunit writes the data into the PPS, and passes the data to the Common API layer through the Client;
  • Step 2 After the Common API layer receives the data from the Vehicle Service data communication subunit, it updates the data to the Vehicle Service data communication subunit after being processed by the DataSource layer;
  • Step 3 when the instrument system has a status update, the State Manager data communication subunit writes the data into the PPS, and the monitoring thread of the Common API layer obtains the PPS data;
  • Step 4 After the Common API layer receives the data from the State Manager data communication subunit, it updates the data to the HMI API layer after being processed by the DataSource layer;
  • Step 5 when the central control has a status update, the IVI Interaction data communication subunit writes the data into the PPS and sends it to the Common API layer through the Client;
  • Step 6 After the Common API layer receives the data from the IVI Interaction data communication subunit, it updates the data to the HMI API layer after being processed by the DataSource layer;
  • Step 7 When there is data update on the HMI API layer screen, send the data to the DataSource layer;
  • Step 8 the DataSource layer sends the data to the Common API layer
  • Step 9 After the Common API layer receives the data, it sends the data to the Vehicle Service data communication subunit, the IVI Interaction data communication subunit or the State Manager data communication subunit according to the data type.
  • the steps of receiving uplink data link are as follows:
  • Step ten the Vehicle Service data communication subunit will write the data signal through the PPS;
  • Step 11 the client end is passed to the HMILogic module
  • Step 12 the HMILogic module passes the onMessage signal again.
  • the link of receiving downlink data is initiated by Kanzi HMI, and the steps are as follows:
  • Step 13 HMI API layer heads up display
  • Step 14 the HMI API layer will upload the button information to the kanzi HMI communication unit
  • Step 15 the kanzi HMI communication unit judges by itself whether it is in the head-up display interface at this time, and whether the key information is valid. If it is determined to be valid, the kanzi HMI communication unit will send relevant information to the DataSource layer;
  • Step 16 the DataSource layer will send the SendData signal to the HMI API layer, the parameters are: CSID_Setting_HUD and OPEN;
  • Step seventeen the data is transmitted to the HMILogic module.
  • Step eighteen start the man-machine interface and start receiving information
  • Step nineteen check whether the Vehicle Service data communication subunit has a message update and obtain change data, check whether the State Manager data communication subunit has a message and obtain change data, check whether the IVI Interaction data communication subunit has a message update and obtain change data, if there is no change, continue to execute this step, and if there is a change, execute the next step;
  • Step 20 analyze the information at this time
  • Step 21 write the parsing result of the previous step to the Datasource XML definition subunit.
  • This process includes the main thread and information sending thread, the steps of information transmission are as follows
  • the main thread steps are:
  • Step 22 Datasource XML defines sub-unit setting data, and information transfer starts;
  • Step 23 receiving the Action of the Datasource XML definition subunit
  • Step 23 notify the message sending thread
  • Step 24 the main thread ends
  • the steps of the message sending thread are:
  • Step 26 wait for notification
  • Step 27 receive the information notification
  • Step twenty-eight analyze the data, and write the PPS file
  • Step 29 go back and wait for the notification.
  • Beneficial effects save the design workload of designers, improve work efficiency, establish a standard HMI API layer to separate the work below the APP and Framework layer, and establish a unified external interface. Different platforms are adapted by the HMI API layer, and differences between different platforms are absorbed by this layer.
  • the HMI API converts signals into signal and value types that are strongly related to functions, and decomposes the function signals.
  • the APP only receives the function type messageID and value, and transmits information by directly uploading the signal ID and value, which reduces the logical judgment of HMI, decouples unnecessary underlying correlations, and reduces the workload of HMI development. It can tend to modular development, allowing HMI development to focus more on the development of HMI effects and interfaces.
  • This set of architecture can realize the multiplexing of HMI and platform.
  • the multiplexing of HMI means that HMI is cross-platform. Under different hardware environments and different platform software suppliers, the available interactive interfaces of HMI are consistent.
  • the multiplexing of the platform means that the platform is reusable and scalable. Under different UI/UE designs, the data is consistent.
  • a standard Common API layer is defined. Every time the platform is updated, the Common API layer is adapted according to different platforms, and the upper HMI APP remains unchanged.
  • Fig. 1 is a schematic diagram of the composition of Embodiment 1 of a novel interface skin changing system in this specification;
  • Fig. 2 is a schematic diagram of the composition of the upper layer communication unit in Fig. 1;
  • FIG. 3 is a schematic diagram of the composition of the framework communication unit in FIG. 1;
  • Fig. 4 is a schematic diagram of the composition of the general communication unit in Fig. 1;
  • Figure 5 is a schematic diagram of the composition of the kanziHMI communication unit in Figure 1;
  • Fig. 6 is a schematic diagram of the composition of the internal data distribution unit in Fig. 1;
  • Fig. 7 is a second embodiment of a new interface skin changing system in this specification.
  • Fig. 8 is a working flow diagram of a method embodiment three in this specification.
  • FIG. 9 is a sequence diagram of receiving uplink data in Embodiment 4 of a method in this specification.
  • FIG. 10 is a sequence diagram of receiving downlink data in Embodiment 4 of a method in this specification.
  • Fig. 11 is the Commom API layer message receiving step figure in a kind of method embodiment five in this description;
  • Fig. 12 is the Commom API layer message sending step figure in a kind of method embodiment five in this description;
  • Embodiment 1 of a novel interface skinning system as shown in Fig. 1-Fig. 6:
  • HMI API layer the level that described HMI API layer connects comprises Common API layer and Kanzi DataSource layer;
  • the Common API layer includes the upper layer communication unit and the framework communication unit;
  • the Kanzi DataSource layer includes the general communication unit, kanzi HMI communication unit and internal data distribution unit.
  • the upper layer communication unit includes a first information receiving subunit and a first information sending subunit;
  • the framework communication unit includes Vehicle Service data communication subunit, State Manager data communication subunit and IVI Interaction data communication subunit.
  • the general communication unit includes a second information receiving subunit and a second information sending subunit;
  • the kanziHMI communication unit includes the Datasource XML definition subunit;
  • the internal data distribution unit includes a functional classification subunit and a logic processing display unit.
  • the functions of the HMI API layer include:
  • HMI can obtain uplink data through the HMIAPI:registerListener interface, and can send downlink data by calling the HMIAPI:sendData interface.
  • the type of data can be extended by updating the ClusterStateId id.
  • the HMI API layer communicates with each framework module, obtains messages by communicating with VehicleService, IVI Interaction, and StateManager, and encapsulates the interface for HMI to use.
  • the Data Source plug-in uses an extensible architecture, which can increase, decrease, and adjust logic processing sub-modules according to project requirements.
  • Logical processing modules can be divided according to needs, such as: power status, indicator lights, driving computer, etc.
  • modules can be divided according to the needs of the vehicle type.
  • electric cars the content related to fuel vehicles can be put into a functionmanager.
  • the module can be deleted directly, without affecting the overall structure, and without changing the API and underlying logic.
  • you need to add a tram-related module you can add a functionmanager module for logic processing, and add it directly without affecting the structure of other sub-modules. It is suitable for platform-based development and rapid iteration, and the adaptation of various models.
  • HMI API layer In order to save the design workload of designers and improve work efficiency, a standard HMI API layer is established to separate the work below the APP and Framework layer, and a unified external interface is established. Different platforms are adapted by the HMI API layer, and differences between different platforms are absorbed by this layer. At the same time, the HMI API converts signals into signal and value types that are strongly related to functions, and decomposes the function signals.
  • the APP only receives the function type messageID and value, and transmits information by directly uploading the signal ID and value, which reduces the logical judgment of HMI, decouples unnecessary underlying correlations, and reduces the workload of HMI development. It can tend to modular development, allowing HMI development to focus more on the development of HMI effects and interfaces.
  • This set of architecture can realize the multiplexing of HMI and platform.
  • the multiplexing of HMI means that HMI is cross-platform. Under different hardware environments and different platform software suppliers, the available interactive interfaces of HMI are consistent.
  • the multiplexing of the platform means that the platform is reusable and scalable. Under different UI/UE designs, the data is consistent.
  • a standard Common API layer is defined. Every time the platform is updated, the Common API layer is adapted according to different platforms, and the upper HMI APP remains unchanged.
  • Embodiment 2 of a novel interface skinning system as shown in Figure 7:
  • the system also includes a self-selection function module, and the self-selection function module includes a self-selection function unit.
  • the optional function module includes an optional functional unit, which is a power state unit.
  • a third embodiment of a method includes: an uplink data transmission section and a downlink data transmission section, wherein the uplink data transmission section is used to transmit data transmitted from the Framework communication unit to the HMI API layer, and the downlink data transmission section is used to transmit data from the HMI API layer to the Framework communication unit;
  • the steps of the uplink data transmission segment include
  • Step 1 when the MCU has a status update, the Vehicle Service data communication subunit writes the data into the PPS, and passes the data to the Common API layer through the Client;
  • Step 2 After the Common API layer receives the data from the Vehicle Service data communication subunit, it updates the data to the Vehicle Service data communication subunit after being processed by the DataSource layer;
  • Step 3 when the instrument system has a status update, the State Manager data communication subunit writes the data into the PPS, and the monitoring thread of the Common API layer obtains the PPS data;
  • Step 4 After the Common API layer receives the data from the State Manager data communication subunit, it updates the data to the HMI API layer after being processed by the DataSource layer;
  • Step 5 when the central control has a status update, the IVI Interaction data communication subunit writes the data into the PPS and sends it to the Common API layer through the Client;
  • Step 6 After the Common API layer receives the data from the IVI Interaction data communication subunit, it updates the data to the HMI API layer after being processed by the DataSource layer;
  • Step 7 When there is data update on the HMI API layer screen, send the data to the DataSource layer;
  • Step 8 the DataSource layer sends the data to the Common API layer
  • Step 9 After the Common API layer receives the data, it sends the data to the Vehicle Service data communication subunit, the IVI Interaction data communication subunit or the State Manager data communication subunit according to the data type.
  • Embodiment 4 of a method as shown in Fig. 9-Fig. 10:
  • the steps of receiving uplink data link are as follows:
  • Step ten the Vehicle Service data communication subunit will write the data signal through the PPS;
  • Step 11 the client end is passed to the HMILogic module
  • Step 12 the HMILogic module passes the onMessage signal again.
  • the link of receiving downlink data is initiated by Kanzi HMI, and the steps are as follows:
  • Step 13 HMI API layer heads up display
  • Step 14 the HMI API layer will upload the button information to the kanzi HMI communication unit;
  • Step 15 the kanzi HMI communication unit judges by itself whether it is in the head-up display interface at this time, and whether the key information is valid. If it is determined to be valid, the kanzi HMI communication unit will send relevant information to the DataSource layer;
  • Step 16 the DataSource layer will send the SendData signal to the HMI API layer, the parameters are: CSID_Setting_HUD and OPEN;
  • Step seventeen the data is transmitted to the HMILogic module.
  • Step eighteen start the man-machine interface and start receiving information
  • Step nineteen check whether the Vehicle Service data communication subunit has a message update and obtain change data, check whether the State Manager data communication subunit has a message and obtain change data, check whether the IVI Interaction data communication subunit has a message update and obtain change data, if there is no change, continue to execute this step, and if there is a change, execute the next step;
  • Step 20 analyze the information at this time
  • Step 21 write the parsing result of the previous step to the Datasource XML definition subunit.
  • This process includes the main thread and information sending thread, the steps of information transmission are as follows
  • the main thread steps are:
  • Step 22 Datasource XML defines sub-unit setting data, and information transfer starts;
  • Step 23 receiving the Action of the Datasource XML definition subunit
  • Step 23 notify the message sending thread
  • Step 24 the main thread ends
  • the steps of the message sending thread are:
  • Step 26 wait for notification
  • Step 27 receive the information notification
  • Step twenty-eight analyze the data, and write the PPS file
  • Step 29 go back and wait for the notification.
  • the write operation Since the write operation may be blocked, the write operation needs to be completed in a dedicated thread, which is divided into the main thread and the message sending thread.
  • the main thread When the main thread has a message to be passed down, it notifies the message sending thread and jumps to the message sending thread. Before that, the message sending thread has been waiting for the notification.
  • the message notification When the message notification is received, it starts to parse the data, writes the PPS file, and then returns to wait for the next notification.
  • Such a setting can make
  • step nine in embodiment three of a method and step ten in embodiment four of a method are not necessarily in sequence, but steps one to six in embodiment three of a method belong to a small internal process of a stage and have a sequence. Steps 7 to 9 belong to the flow within a small stage and have a sequence.
  • the technical carriers involved in the payment described in the embodiments of this specification may include, for example, Near Field Communication (NFC), WIFI, 3G/4G/5G, POS machine card swiping technology, QR code scanning technology, bar code scanning technology, Bluetooth, infrared, Short Message Service (SMS), Multimedia Message Service (MMS), etc.
  • NFC Near Field Communication
  • WIFI Wireless Fidelity
  • 3G/4G/5G 3G/4G/5G
  • POS machine card swiping technology QR code scanning technology
  • bar code scanning technology Bluetooth
  • infrared Short Message Service
  • SMS Short Message Service
  • MMS Multimedia Message Service
  • the method in one or more embodiments of this specification may be executed by a single device, such as a computer or server.
  • the method of this embodiment can also be applied in a distributed scenario, and is completed by cooperation of multiple devices.
  • one of the multiple devices may only execute one or more steps in the method of one or more embodiments of this specification, and the multiple devices will interact with each other to complete the method.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Multimedia (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本说明书提供一种新型界面换肤系统,该系统包括:HMI API层,HMI API层连接的层级包括Common API层和Kanzi DataSource层;Common API层包括上层通信单元、framework通信单元;Kanzi DataSource层包括通用通信单元、kanzi HMI通信单元以及内部数据分发单元。一种方法,包括上行数据传输段和下行数据传输段,上行数据传输段用于传输从Framework通信单元向HMI API层传递的数据,下行数据传输段用于从HMI API层向Framework通信单元传递的数据。节省了设计人员的设计工作量,提升工作效率,建立标准的HMI API层来分隔APP和Framework层以下的工作,建立统一的对外接口,不同的平台由HMI API层进行适配,不同平台的差异由本层吸收。对应不同平台,API层接口是统一的,上层的HMI APP不需要重新开发设计,不同平台进行适配节省了大量的设计。

Description

一种新型界面换肤系统及其方法 技术领域
本说明书涉及汽车技术领域,尤其涉及一种新型界面换肤系统及其方法。
背景技术
随着科技的迅猛发展,车辆的功能性越来越多样化。作为车辆组成部分的车机系统随着信息技术的迅猛发展,不断更新进步。其中,车辆的功能性和体验感的提高越来越依靠车机系统。车机系统虽然有了较大的提高和进步,但目前的车机系统仍然存在一定的问题:车机系统在上市前需要设计多种主题,在车辆上市后不定期的升级界面和交互场景主题,促进用户有更加良好的体验。且相关的主题,往往会在不同的车型、不同的平台进行应用。但是现有的换肤方法需要根据不同平台接收底层不同的信号,再直接通知HMI层,每一次更换平台都需要framework层、HMI层重新对应,既需要底层一起联动,又需要花费大量开发成本。这样的方式费时费力,效率低,无法及时相应用户的关切和需求,且这样的方法导致设计出的主题可移植性差。
因此为了解决该类问题,提出一种新型界面换肤系统及其方法。
发明内容
有鉴于此,本说明书一个或多个实施例的目的在于提出一种新型界面换肤系统及其方法,以解决目前换肤方法费时费力、低效且可移植性差的问题。
基于上述目的,本说明书一个或多个实施例提供了新型界面换肤系统:
一种新型界面换肤系统,该系统包括:HMI API层,所述的HMI API层连接的层级包括Common API层和Kanzi DataSource层;
其中,Common API层包括上层通信单元、framework通信单元;Kanzi DataSource层包括通用通信单元、kanzi HMI通信单元以及内部数据分发单元。
上层通信单元包括第一信息接收子单元和第一信息发送子单元;
framework通信单元包括Vehicle Service数据通信子单元、State Manager 数据通信子单元以及IVI Interaction数据通信子单元。
通用通信单元包括第二信息接收子单元和第二信息发送子单元;
其中,kanziHMI通信单元包括Datasource XML定义子单元;
其中,内部数据分发单元包括功能分类子单元和逻辑处理显示单元。
该系统还包括自选功能模块,所述的自选功能模块包括一个自选功能单元。
自选功能模块包括一个自选功能单元,该自选功能单元为电源状态单元。
一种方法,具体包括:上行数据传输段和下行数据传输段,其中上行数据传输段用于传输从Framework通信单元向HMI API层传递的数据,下行数据传输段用于从HMI API层向Framework通信单元传递的数据;
上行数据传输段的步骤包括:
步骤一,当MCU有状态更新时,Vehicle Service数据通信子单元将数据写入PPS,并通过Client端将数据传递给Common API层;
步骤二,当Common API层收到Vehicle Service数据通信子单元的数据后,将数据经由DataSource层处理后更新至Vehicle Service数据通信子单元;
步骤三,当仪表系统有状态更新时,State Manager数据通信子单元将数据写入PPS,Common API层的监听线程获取PPS数据;
步骤四,Common API层收到State Manager数据通信子单元的数据后,将数据经由DataSource层处理后更新至HMI API层;
步骤五,当中控有状态更新时,IVI Interaction数据通信子单元将数据写入PPS,并通过Client端发送给Common API层;
步骤六,Common API层收到IVI Interaction数据通信子单元的数据后,将数据经由DataSource层处理后更新至HMI API层;
下行数据传输段
步骤七:HMI API层画面有数据更新时,将数据发送给DataSource层;
步骤八,DataSource层将数据发送给Common API层;
步骤九,Common API层收到数据后,按照数据的类型将数据发送给Vehicle Service数据通信子单元、IVI Interaction数据通信子单元或者State  Manager数据通信子单元。
接收上行数据环节的步骤如下:
步骤十,Vehicle Service数据通信子单元会将数据信号通过PPS写入;
步骤十一,Client端传给HMILogic模块
步骤十二,HMILogic模块再通过onMessage信号。
接收下行数据环节由Kanzi HMI发起,步骤如下:
步骤十三,HMI API层抬头显示;
步骤十四,HMI API层会上传给kanzi HMI通信单元按键信息
步骤十五,kanzi HMI通信单元自行判断此时是否在抬头显示界面,以及按键信息是否有效,如果判定有效,kanzi HMI通信单元会向DataSource层发送相关信息;
步骤十六,DataSource层会向HMI API层发送SendData信号,参数为:CSID_Setting_HUD和OPEN;
步骤十七,数据传输至HMILogic模块。
Common API层信息接收环节的步骤:
步骤十八,人机界面启动,信息接收开始;
步骤十九,检查Vehicle Service数据通信子单元是否有消息更新并获取变化数据、检查State Manager数据通信子单元是否有消息并获取变化数据、检查IVI Interaction数据通信子单元是否有消息更新并获取变化数据,若无变化继续执行该步骤,若有变化则执行下一步;
步骤二十,此时解析信息;
步骤二十一,向Datasource XML定义子单元写入上一步的解析结果。
Common API层信息发送环节步骤:该过程包括主线程和信息发送线程,信息传递的步骤如下
主线程步骤为:
步骤二十二,Datasource XML定义子单元设置数据,信息传递开始;
步骤二十三,接收Datasource XML定义子单元的Action;
步骤二十三,通知信息发送线程;
步骤二十四,主线程结束;
信息发送线程的步骤为:
步骤二十五,开始;
步骤二十六,等待通知;
步骤二十七,收到信息通知;
步骤二十八,解析数据,写入PPS文件;
步骤二十九,返回继续等待通知。
有益效果:节省了设计人员的设计工作量,提升工作效率,通过建立标准的HMI API层来分隔APP和Framework层以下的工作,建立统一的对外接口,不同的平台由HMI API层进行适配,不同平台的差异由本层吸收,APP无论对应什么平台,对应的API层接口图示统一的,上层的HMI APP不需要重新开发设计,不同平台进行适配节省了大量的设计。同时,HMI API将信号转化为和功能强相关的信号和值类型,将功能信号分解,APP只接收功能类型messageID及value值,通过直接上传信号ID和值的方式传递信息,减少了HMI的逻辑判断,解耦了不必要的底层关联性,减少了HMI开发的工作量,可以趋向于模块化开发,可以让HMI的开发更专注于HMI效果、界面的开发。
该套架构可以实现HMI和平台的复用。HMI的复用指HMI是跨平台的,在不同的硬件环境下,不同的平台软件供应商下,HMI可用的交互接口是一致的。平台的复用是指:平台是可复用可扩展的,在不同的UI/UE设计下,数据是保持一致的,在HMI APP和Framework层中间,定义标准Common API层,每次更新更换平台,由Common API层根据不同平台进行适配,上层HMI APP不变。
附图说明
为了更清楚地说明本说明书一个或多个实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本说明书一个或多个实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为本说明书一种新型界面换肤系统的实施例一的组成示意图;
图2为图1中上层通信单元的组成示意图;
图3为图1中framework通信单元的组成示意图;
图4为图1中通用通信单元的组成示意图;
图5为图1中kanziHMI通信单元的组成示意图;
图6为图1中内部数据分发单元的组成示意图;
图7为本说明书的一种新型界面换肤系统的实施例二;
图8为本说明书中一种方法实施例三的工作流程图;
图9为本说明书中一种方法实施例四中接收上行数据时序图;
图10为本说明书中一种方法实施例四中接收下行数据时序图;
图11为本说明书中一种方法实施例五中的Commom API层消息接收步骤图;
图12为本说明书中一种方法实施例五中的Commom API层消息发送步骤图;
具体实施方式
为使本公开的目的、技术方案和优点更加清楚明白,以下结合具体实施例,并参照附图,对本公开进一步详细说明。
需要说明的是,除非另外定义,本说明书一个或多个实施例使用的技术术语或者科学术语应当为本公开所属领域内具有一般技能的人士所理解的通常意义。本说明书一个或多个实施例中使用的“第一”、“第二”以及类似的词语并不表示任何顺序、数量或者重要性,而只是用来区分不同的组成部分。“包括”或者“包含”等类似的词语意指出现该词前面的元件或者物件涵盖出现在该词后面列举的元件或者物件及其等同,而不排除其他元件或者物件。“连接”或者“相连”等类似的词语并非限定于物理的或者机械的连接,而是可以包括电性的连接,不管是直接的还是间接的。“上”、“下”、“左”、“右”等仅用于表示相对位置关系,当被描述对象的绝对位置改变后,则该相对位置关系也可能相应地改变。
一种新型界面换肤系统的实施例一,如图1—图6所示:
该系统包括:HMI API层,所述的HMI API层连接的层级包括Common API层和Kanzi DataSource层;
其中,Common API层包括上层通信单元、framework通信单元;Kanzi  DataSource层包括通用通信单元、kanz i HMI通信单元以及内部数据分发单元。
上层通信单元包括第一信息接收子单元和第一信息发送子单元;
framework通信单元包括Vehicle Service数据通信子单元、State Manager数据通信子单元以及IVI Interaction数据通信子单元。
通用通信单元包括第二信息接收子单元和第二信息发送子单元;
其中,kanziHMI通信单元包括Datasource XML定义子单元;
其中,内部数据分发单元包括功能分类子单元和逻辑处理显示单元。
其中,HMI API层的作用包括:
与上层通信,提供C++接口的API,可以适配各种HMI工具,这个接口的定义要覆盖全平台车型的要求。Common API提供了通用的C++接口来和HMI实现数据交互。HMI可以通过HMIAPI:registerListener接口来获取上行数据,并可以通过调用HMIAPI:sendData接口来下发下行数据。数据的类型可以通过CluterStateId id的更新来实现扩展。
HMI API层与Framework各模块通信,通过与VehicleService、IVI Interaction、StateManager通讯获取消息,并封装接口给HMI使用。
其与Common API通信。
与Kanzi HMI通信,提供Kanzi接口的API。按照画面需求处理上行数据。将上行数据更新到Kanzi HMI的节点。将下行数据传递给Cluster Common API。
内部分发数据,根据功能分发出数据,并处理现实逻辑,具备可扩展的能力,获取Common API传递的上行数据,可扩展的架构,Data Source插件使用可扩展架构,可以根据项目需求增减和调整逻辑处理子模块。
可以根据需要自行划分逻辑处理模块,比如:电源状态、指示灯、行车电脑相关等。
这样可以根据车型需要进行模块划分,例如电车:可以将燃油车相关的内容做到一个functionmanager中,不需要的时候,直接将模块删除,不影响整体架构,也不需要改变API和底层逻辑。如果需要增加电车相关模块,可以新增一个逻辑处理的functionmanager模块,直接加上,不影响其他子模块架构,适用于平台化开发及快速迭代,多种车型的适配工作。
有益效果:为了节省设计人员的设计工作量,提升工作效率,通过建立 标准的HMI API层来分隔APP和Framework层以下的工作,建立统一的对外接口,不同的平台由HMI API层进行适配,不同平台的差异由本层吸收,APP无论对应什么平台,对应的API层接口图示统一的,上层的HMI APP不需要重新开发设计,不同平台进行适配节省了大量的设计。同时,HMI API将信号转化为和功能强相关的信号和值类型,将功能信号分解,APP只接收功能类型messageID及value值,通过直接上传信号ID和值的方式传递信息,减少了HMI的逻辑判断,解耦了不必要的底层关联性,减少了HMI开发的工作量,可以趋向于模块化开发,可以让HMI的开发更专注于HMI效果、界面的开发。
该套架构可以实现HMI和平台的复用。HMI的复用指HMI是跨平台的,在不同的硬件环境下,不同的平台软件供应商下,HMI可用的交互接口是一致的。平台的复用是指:平台是可复用可扩展的,在不同的UI/UE设计下,数据是保持一致的,在HMI APP和Framework层中间,定义标准Common API层,每次更新更换平台,由Common API层根据不同平台进行适配,上层HMI APP不变。
一种新型界面换肤系统的实施例二,如图7所示:
该系统还包括自选功能模块,所述的自选功能模块包括一个自选功能单元。
自选功能模块包括一个自选功能单元,该自选功能单元为电源状态单元。
通过这样的设置,可以根据不同用户的需要进行相应功能单元的设置,从而多样化的满足客户需要。同时,不需要因为功能的缺少而重新设置,效率得到了提高,系统的适配性得到了很大的提高。
一种方法的实施例三,如图8所示,包括:上行数据传输段和下行数据传输段,其中上行数据传输段用于传输从Framework通信单元向HMI API层传递的数据,下行数据传输段用于从HMI API层向Framework通信单元传递的数据;
上行数据传输段的步骤包括
步骤一,当MCU有状态更新时,Vehicle Service数据通信子单元将数据写入PPS,并通过Client端将数据传递给Common API层;
步骤二,当Common API层收到Vehicle Service数据通信子单元的数据后,将数据经由DataSource层处理后更新至Vehicle Service数据通信子单元;
步骤三,当仪表系统有状态更新时,State Manager数据通信子单元将数据写入PPS,Common API层的监听线程获取PPS数据;
步骤四,Common API层收到State Manager数据通信子单元的数据后,将数据经由DataSource层处理后更新至HMI API层;
步骤五,当中控有状态更新时,IVI Interaction数据通信子单元将数据写入PPS,并通过Client端发送给Common API层;
步骤六,Common API层收到IVI Interaction数据通信子单元的数据后,将数据经由DataSource层处理后更新至HMI API层;
下行数据传输段
步骤七:HMI API层画面有数据更新时,将数据发送给DataSource层;
步骤八,DataSource层将数据发送给Common API层;
步骤九,Common API层收到数据后,按照数据的类型将数据发送给Vehicle Service数据通信子单元、IVI Interaction数据通信子单元或者State Manager数据通信子单元。
通过上述步骤,能够实现上行数据快速安全的传输。
一种方法的实施例四,如图9—图10所示:
接收上行数据环节的步骤如下:
步骤十,Vehicle Service数据通信子单元会将数据信号通过PPS写入;
步骤十一,Client端传给HMILogic模块
步骤十二,HMILogic模块再通过onMessage信号。
接收下行数据环节由Kanzi HMI发起,步骤如下:
步骤十三,HMI API层抬头显示;
步骤十四,HMI API层会上传给kanzi HMI通信单元按键信息;
步骤十五,kanzi HMI通信单元自行判断此时是否在抬头显示界面,以及按键信息是否有效,如果判定有效,kanzi HMI通信单元会向DataSource层发送相关信息;
步骤十六,DataSource层会向HMI API层发送SendData信号,参数为: CSID_Setting_HUD和OPEN;
步骤十七,数据传输至HMILogic模块。
一种方法的实施例五,如图11—图12所示:
Common API层信息接收环节的步骤:
步骤十八,人机界面启动,信息接收开始;
步骤十九,检查Vehicle Service数据通信子单元是否有消息更新并获取变化数据、检查State Manager数据通信子单元是否有消息并获取变化数据、检查IVI Interaction数据通信子单元是否有消息更新并获取变化数据,若无变化继续执行该步骤,若有变化则执行下一步;
步骤二十,此时解析信息;
步骤二十一,向Datasource XML定义子单元写入上一步的解析结果。
Common API层信息发送环节步骤:该过程包括主线程和信息发送线程,信息传递的步骤如下
主线程步骤为:
步骤二十二,Datasource XML定义子单元设置数据,信息传递开始;
步骤二十三,接收Datasource XML定义子单元的Action;
步骤二十三,通知信息发送线程;
步骤二十四,主线程结束;
信息发送线程的步骤为:
步骤二十五,开始;
步骤二十六,等待通知;
步骤二十七,收到信息通知;
步骤二十八,解析数据,写入PPS文件;
步骤二十九,返回继续等待通知。
由于写入操作可能会被Block,因此写入操作需要在专门的线程中完成,分为主线程和消息发送线程,主线程中有消息要向下传递的时候,通知到消息发送线程,跳转到消息发送线程,此前,消息发送线程一直在等待通知,当接收到消息通知,开始解析数据,写入PPS文件,然后返回继续等待下一个通知。这样的设置可以使得
需要说明的是,以上各个实施例中步骤的序号仅为方便描述,在不同阶 段之间并不必然表示顺序的先后。比如一种方法的实施例三中的步骤九与一种方法的实施例四中的步骤十并不必然的是先后顺序,但是在一种方法的实施例三中步骤一至六属于一个小的阶段内部的流程,具有先后顺序。而步骤七至步骤九属于一个小的阶段内部的流程,具有先后顺序。
本说明书实施例中所述支付涉及的技术载体,例如可以包括近场通信(Near Field Communication,NFC)、WIFI、3G/4G/5G、POS机刷卡技术、二维码扫码技术、条形码扫码技术、蓝牙、红外、短消息(Short Message Service,SMS)、多媒体消息(Multimedia Message Service,MMS)等。
需要说明的是,本说明书一个或多个实施例的方法可以由单个设备执行,例如一台计算机或服务器等。本实施例的方法也可以应用于分布式场景下,由多台设备相互配合来完成。在这种分布式场景的情况下,这多台设备中的一台设备可以只执行本说明书一个或多个实施例的方法中的某一个或多个步骤,这多台设备相互之间会进行交互以完成所述的方法。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下,在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外,在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中,多任务处理和并行处理也是可以的或者可能是有利的。
为了描述的方便,描述以上装置时以功能分为各种模块分别描述。当然,在实施本说明书一个或多个实施例时可以把各模块的功能在同一个或多个软件和/或硬件中实现。
上述实施例的装置用于实现前述实施例中相应的方法,并且具有相应的方法实施例的有益效果,在此不再赘述。
所属领域的普通技术人员应当理解:以上任何实施例的讨论仅为示例性的,并非旨在暗示本公开的范围(包括权利要求)被限于这些例子;在本公开的思路下,以上实施例或者不同实施例中的技术特征之间也可以进行组合,步骤可以以任意顺序实现,并存在如上所述的本说明书一个或多个实施例的不同方面的许多其它变化,为了简明它们没有在细节中提供。
另外,为简化说明和讨论,并且为了不会使本说明书一个或多个实施例难以理解,在所提供的附图中可以示出或可以不示出与集成电路(IC)芯片 和其它部件的公知的电源/接地连接。此外,可以以框图的形式示出装置,以便避免使本说明书一个或多个实施例难以理解,并且这也考虑了以下事实,即关于这些框图装置的实施方式的细节是高度取决于将要实施本说明书一个或多个实施例的平台的(即,这些细节应当完全处于本领域技术人员的理解范围内)。在阐述了具体细节(例如,电路)以描述本公开的示例性实施例的情况下,对本领域技术人员来说显而易见的是,可以在没有这些具体细节的情况下或者这些具体细节有变化的情况下实施本说明书一个或多个实施例。因此,这些描述应被认为是说明性的而不是限制性的。
尽管已经结合了本公开的具体实施例对本公开进行了描述,但是根据前面的描述,这些实施例的很多替换、修改和变型对本领域普通技术人员来说将是显而易见的。
本说明书一个或多个实施例旨在涵盖落入所附权利要求的宽泛范围之内的所有这样的替换、修改和变型。因此,凡在本说明书一个或多个实施例的精神和原则之内,所做的任何省略、修改、等同替换、改进等,均应包含在本公开的保护范围之内。

Claims (10)

  1. 一种新型界面换肤系统,其特征在于,该系统包括:HMI API层,所述的HMI API层连接的层级包括Common API层和Kanzi DataSource层;
    其中,Common API层包括上层通信单元、framework通信单元;Kanzi DataSource层包括通用通信单元、kanzi HMI通信单元以及内部数据分发单元。
  2. 根据权利要求1所述的新型界面换肤系统,其特征在于,所述的上层通信单元包括第一信息接收子单元和第一信息发送子单元;
    所述的framework通信单元包括Vehicle Service数据通信子单元、State Manager数据通信子单元以及IVI Interaction数据通信子单元。
  3. 根据权利要求2所述的新型界面换肤系统,其特征在于,所述的通用通信单元包括第二信息接收子单元和第二信息发送子单元;
    其中,所述的kanzi HMI通信单元包括Datasource XML定义子单元;
    其中,所述的内部数据分发单元包括功能分类子单元和逻辑处理显示单元。
  4. 根据权利要求3所述的新型界面换肤系统,其特征在于,该系统还包括自选功能模块,所述的自选功能模块包括至少一个自选功能单元。
  5. 根据权利要求4所述的新型界面换肤系统,其特征在于,所述的自选功能模块包括一个自选功能单元,该自选功能单元为电源状态单元。
  6. 一种如权利要求1—5任一项所述的新型界面换肤系统的方法,其特征在于,包括:上行数据传输段和下行数据传输段,其中上行数据传输段用于传输从Framework通信单元向HMI API层传递的数据,下行数据传输段用于从HMI API层向Framework通信单元传递的数据;
    上行数据传输段的步骤包括
    步骤一,当MCU有状态更新时,Vehicle Service数据通信子单元将数据写入PPS,并通过Client端将数据传递给Common API层;
    步骤二,当Common API层收到Vehicle Service数据通信子单元的数据后,将数据经由DataSource层处理后更新至Vehicle Service数据通信子单元;
    步骤三,当仪表系统有状态更新时,State Manager数据通信子单元将数 据写入PPS,Common API层的监听线程获取PPS数据;
    步骤四,Common API层收到State Manager数据通信子单元的数据后,将数据经由DataSource层处理后更新至HMI API层;
    步骤五,当中控有状态更新时,IVI Interaction数据通信子单元将数据写入PPS,并通过Client端发送给Common API层;
    步骤六,Common API层收到IVI Interaction数据通信子单元的数据后,将数据经由DataSource层处理后更新至HMI API层;
    下行数据传输段
    步骤七:HMI API层画面有数据更新时,将数据发送给DataSource层;
    步骤八,DataSource层将数据发送给Common API层;
    步骤九,Common API层收到数据后,按照数据的类型将数据发送给Vehicle Service数据通信子单元、IVI Interaction数据通信子单元或者State Manager数据通信子单元。
  7. 根据权利要求6所述的方法,其特征在于,接收上行数据环节的步骤如下:
    步骤十,Vehicle Service数据通信子单元会将数据信号通过PPS写入;
    步骤十一,Client端传给HMILogic模块;
    步骤十二,HMILogic模块再通过onMessage信号。
  8. 根据权利要求7所述的方法,其特征在于,接收下行数据环节由Kanzi HMI发起,步骤如下:
    步骤十三,HMI API层抬头显示;
    步骤十四,HMI API层会上传给kanzi HMI通信单元按键信息;
    步骤十五,kanzi HMI通信单元自行判断此时是否在抬头显示界面,以及按键信息是否有效,如果判定有效,kanzi HMI通信单元会向DataSource层发送相关信息;
    步骤十六,DataSource层会向HMI API层发送SendData信号,参数为:CSID_Setting_HUD和OPEN;
    步骤十七,数据传输至HMILogic模块。
  9. 根据权利要求8所述的方法,其特征在于,Common API层信息接收环节的步骤:
    步骤十八,人机界面启动,信息接收开始;
    步骤十九,检查Vehicle Service数据通信子单元是否有消息更新并获取变化数据、检查State Manager数据通信子单元是否有消息并获取变化数据、检查IVI Interaction数据通信子单元是否有消息更新并获取变化数据,若无变化继续执行该步骤,若有变化则执行下一步;
    步骤二十,此时解析信息;
    步骤二十一,向Datasource XML定义子单元写入上一步的解析结果。
  10. 根据权利要求9所述的方法,其特征在于,Common API层信息发送环节步骤:该过程包括主线程和信息发送线程,信息传递的步骤如下
    主线程步骤为:
    步骤二十二,Datasource XML定义子单元设置数据,信息传递开始;
    步骤二十三,接收Datasource XML定义子单元的Action;
    步骤二十三,通知信息发送线程;
    步骤二十四,主线程结束;
    信息发送线程的步骤为:
    步骤二十五,开始;
    步骤二十六,等待通知;
    步骤二十七,收到信息通知;
    步骤二十八,解析数据,写入PPS文件;
    步骤二十九,返回继续等待通知。
PCT/CN2022/103655 2022-01-24 2022-07-04 一种新型界面换肤系统及其方法 WO2023138001A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202210081202.8 2022-01-24
CN202210081202.8A CN114546379A (zh) 2022-01-24 2022-01-24 一种新型界面换肤系统及其方法

Publications (1)

Publication Number Publication Date
WO2023138001A1 true WO2023138001A1 (zh) 2023-07-27

Family

ID=81672362

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/103655 WO2023138001A1 (zh) 2022-01-24 2022-07-04 一种新型界面换肤系统及其方法

Country Status (2)

Country Link
CN (1) CN114546379A (zh)
WO (1) WO2023138001A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114546379A (zh) * 2022-01-24 2022-05-27 中国第一汽车股份有限公司 一种新型界面换肤系统及其方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190090097A1 (en) * 2017-09-21 2019-03-21 Ford Global Technologies, Llc Vehicle based communication of location data between external applications and devices
CN113673948A (zh) * 2021-08-02 2021-11-19 江苏杰瑞信息科技有限公司 一种基于工业互联网的数字孪生基础开发平台
CN114546379A (zh) * 2022-01-24 2022-05-27 中国第一汽车股份有限公司 一种新型界面换肤系统及其方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190090097A1 (en) * 2017-09-21 2019-03-21 Ford Global Technologies, Llc Vehicle based communication of location data between external applications and devices
CN113673948A (zh) * 2021-08-02 2021-11-19 江苏杰瑞信息科技有限公司 一种基于工业互联网的数字孪生基础开发平台
CN114546379A (zh) * 2022-01-24 2022-05-27 中国第一汽车股份有限公司 一种新型界面换肤系统及其方法

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"Master's Thesis", 1 June 2015, JILIN UNIVERSITY, CN, article BAI, JIE: "Design and Implementation of Vehicle Entertainment Information System", pages: 1 - 64, XP009547772 *
"Master's Thesis", 8 June 2014, DALIAN UNIVERSITY OF TECHNOLOGY, CN, article WANG, LEI: "Application of Telematics in Vehicle Navigation System", pages: 1 - 72, XP009547771 *

Also Published As

Publication number Publication date
CN114546379A (zh) 2022-05-27

Similar Documents

Publication Publication Date Title
CN104239132B (zh) 一种唤醒对齐的方法、装置及终端
US10467154B2 (en) Multi-port multi-sideband-GPIO consolidation technique over a multi-drop serial bus
CN107943458B (zh) 一种机器人开发系统
CN107291456B (zh) 一种多屏显示的控制方法及系统
CN102752369B (zh) 电视应用服务的提供方法及虚拟化内容服务平台
WO2023138001A1 (zh) 一种新型界面换肤系统及其方法
CN105975351A (zh) 一种用户行为消息上报方法和装置
EP3779690A1 (en) Processor core scheduling method and apparatus, terminal, and storage medium
WO2018133571A1 (zh) 一种基于移动智能终端的分布式pc系统
CN112332997A (zh) 终端设备的配网方法、终端设备及计算机可读存储介质
CN114296808B (zh) 一种引脚配置方法、装置、电子设备及存储介质
CN113253640B (zh) 飞控计算机及其通用硬件抽象层
CN108415785A (zh) 自助终端sp实现方法、终端设备以及可读存储介质
CN111552992A (zh) 一种不对称安全级别的双系统多模通信架构
CN103488598B (zh) 一种多模终端及其实现usb共用的方法
CN105988814A (zh) 界面生成方法及装置
CN111736792A (zh) 可编程逻辑器件及其控制方法、控制系统和视频处理器
CN106896956B (zh) 一种“道”系统下多点触控的实现方法
US10176133B2 (en) Smart device with no AP
CN110515662A (zh) 双系统设备的远程控制方法、系统、设备及可读存储介质
KR20130000045A (ko) 클라우드 컴퓨팅 환경하에서 멀티 단말 장치 간 서버-클라이언트 서비스 환경을 지원하는 앱 구동 체계
CN103150162B (zh) 提高嵌入式软件代码共享程度的方法
WO2021057351A1 (zh) 在glibc环境下控制安卓蓝牙的装置、方法及终端设备
CN101316420B (zh) 移动终端及通信方法
CN104572316A (zh) 游戏程序与运行平台交互的方法和系统

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22921432

Country of ref document: EP

Kind code of ref document: A1