Remote information terminal control method, device and equipment

Abstract

The invention provides a remote information terminal control method, device and equipment, and relates to the technical field of Internet of Vehicles. The method comprises the following steps: running first software in a first memory partition of a system-on-chip, running second software in a second memory partition of the system-on-chip, meanwhile, running third software in the system-on-chip, and distributing first data related to an emergency call function to the first software through the third software, and distributing second data related to the Internet of Vehicles function to the second software, so that the first software can realize the eCALL function based on the first data, and the second software can realize the Internet of Vehicles function based on the second data. According to the method provided by the invention, decoupling between the first software and the second software can be realized through the memory partition, so that the second software can be independently upgraded, tedious and long-time authentication in the software upgrading process can be avoided, and the hardware cost of the vehicle can be reduced.

Description

Technical Field

[0001] The present application relates to the field of vehicle networking technology, and more specifically, to a control method, device and equipment for a remote information terminal in network technology. Background Art

[0002] With the rapid development of the automotive industry, more and more vehicles are integrating emergency call (eCall) functionality. When a vehicle is involved in an accident, the eCall function is automatically triggered, sending emergency information such as vehicle location, identification, accident type, and occupant information. Rescue personnel can use this information to quickly determine the accident scene and type, and prepare the appropriate rescue equipment in advance.

[0003] The software required to implement eCALL functionality requires rigorous certification, a complex, lengthy, and expensive process. For these reasons, the common practice is to install separate hardware in the vehicle for eCALL, which then runs the software. Obviously, this separate hardware for eCALL increases vehicle hardware costs. Summary of the Invention

[0004] The present application provides a control method, device and equipment for a remote information terminal, which can reduce the hardware cost of a vehicle.

[0005] In a first aspect, a control method for a remote information terminal is provided, which is applied to a system-on-chip in the remote information terminal, the method comprising:

[0006] Running first software in a first memory partition of a system-on-chip and running second software in a second memory partition of the system-on-chip, wherein a priority of the first software is higher than a priority of the second software, the first software is used to implement an emergency call function of the vehicle, and the second software is used to implement an Internet of Vehicles function of the vehicle;

[0007] A third software is run in the system-on-chip to divert first data related to the emergency call function to the first software through the third software, and to divert second data related to the Internet of Vehicles function to the second software, so that the first software implements the emergency call function based on the first data, and the second software implements the Internet of Vehicles function based on the second data.

[0008] In an embodiment of the present application, a first software is run in a first memory partition of the system-level chip, a second software is run in a second memory partition of the system-level chip, and a third software is run in the system-level chip at the same time. The third software is used to divert first data related to the emergency call function to the first software, and second data related to the vehicle networking function to the second software, so that the first software can implement the eCALL function based on the first data, and the second software can implement the vehicle networking function based on the second data. The memory partitioning can achieve decoupling between the first software and the second software, so that the second software can be upgraded separately, avoiding the need to authenticate the first software when the second software is upgraded. When the first software and the second software are integrated into the TBox, the tedious and time-consuming authentication process during the software upgrade can be avoided. Compared with the method of setting up hardware for the eCALL function separately, the hardware cost of the vehicle can be reduced.

[0009] Moreover, when the priority of the first software is higher than that of the second software, it can ensure that the first software can obtain the resources in the SOC in time, ensuring that the first software can run quickly and stably, thereby enabling the response delay of the vehicle's emergency events to meet the requirements.

[0010] Optionally, the system-level chip is connected to a micro control unit, and running the third software in the system-level chip includes: running the first sub-software included in the third software in the first memory partition, so as to divert the first data included in the first part of the data to the first software through the first sub-software, and divert the second data included in the first part of the data to the second software, wherein the first part of the data includes the data obtained by the first sub-software from the micro control unit; running the second sub-software included in the third software in the first memory partition, so as to divert the first data included in the second part of the data to the first software through the second sub-software, and divert the second data included in the second part of the data to the second software, wherein the second part of the data includes the data obtained by the second sub-software from other hardware modules integrated in the remote information terminal.

[0011] In an embodiment of the present application, running the third software related to the eCALL function in the first memory partition can ensure that the first software and the third software related to the eCALL function both run in the first memory partition, which can reduce the coupling between the software related to the eCALL function and the software related to the vehicle network function, and reduce the adverse effects of the software related to the vehicle network function on the eCALL function.

[0012] Optionally, the method further includes: running fourth software in the second memory partition to receive the second data split by the first sub-software and the second sub-software through the fourth software; and passing the received second data to the second software through the fourth software.

[0013] In an embodiment of the present application, a fourth software is set in the second memory partition, and the second data sent by the third software of the first memory partition is received by the fourth software, so that data sharing between the first memory partition and the second memory partition can be achieved, and the first memory partition and the second memory partition can be isolated at the same time.

[0014] Optionally, the method further includes: creating a shared memory partition; and synchronizing the state information of the emergency call function between the first software and the second software via the shared memory partition.

[0015] In an embodiment of the present application, a shared memory partition is set up, and the first software in the first memory partition and the second software in the second memory partition can synchronize the status information of the emergency call function through the shared memory partition, thereby ensuring smooth communication between the first software and the second software.

[0016] Optionally, the system-level chip has multiple cores, and running the first software in the first memory partition of the system-level chip and running the second software in the second memory partition of the system-level chip include: running the first software in the first memory partition through the first core among the multiple cores; and running the second software in the second memory partition through the second core among the multiple cores.

[0017] In an embodiment of the present application, by running the first software in the first memory partition through the first core among the multiple cores and running the second software in the second memory partition through the second core among the multiple cores, the first software and the second software can be prevented from preempting CPU resources during operation, so as to avoid a certain software from being stuck when it cannot preempt CPU resources, thereby improving the reliability of the first software and the second software.

[0018] Optionally, before running the first software in the first memory partition through the first core among the multiple cores, the method further includes: when the first software is in an inactivated state, determining a first number of the first cores from the multiple cores, or, when the first software is in an activated state, determining a second number of the first cores from the multiple cores, the second number being greater than the first number; and determining the other cores among the multiple cores except the first core as the second cores.

[0019] In an embodiment of the present application, when the first software is in an activated state, allocating more cores to the first software can provide the first software with sufficient core resources to ensure the smooth operation of the first software after the first software enters the activated state. When the first software is in an inactivated state, allocating fewer cores to the first software can avoid idle kernel resources and improve the utilization rate of kernel resources.

[0020] Optionally, the system-level chip has multiple cores, and running the first software in the first memory partition of the system-level chip and running the second software in the second memory partition of the system-level chip include: when the first software enters an activated state, running the first software in the first memory partition through the first core among the multiple cores; and running the second software in the second memory partition through the second core among the multiple cores except the first core.

[0021] In an embodiment of the present application, after the first software enters the activated state, a fixed core is allocated to the first software. While ensuring the smooth implementation of the eCALL function, the idle rate of the core resources can be reduced and the resource utilization of the system-level chip can be improved.

[0022] Optionally, the method further includes: when the first software enters an activated state, expanding the first memory partition to obtain an expanded first memory partition; and running the first software in the expanded first memory partition.

[0023] In an embodiment of the present application, when the first software enters an activated state, the first memory partition is expanded to obtain an expanded first memory partition, and the first software is run in the expanded first memory partition. This allows the first software to have larger memory resources after activation, and the first software can occupy fewer memory resources when not activated, thereby improving the utilization of memory resources.

[0024] In a second aspect, a control device for a remote information terminal is provided, which is applied to a system-on-chip in the remote information terminal, and the device includes:

[0025] an operating module, configured to operate a first software in a first memory partition of a system-on-chip and to operate a second software in a second memory partition of the system-on-chip, wherein a priority of the first software is higher than a priority of the second software, the first software is configured to implement an emergency call function of the vehicle, and the second software is configured to implement an Internet of Vehicles function of the vehicle;

[0026] A diversion module is used to run a third software in the system-level chip to divert first data related to the emergency call function to the first software through the third software, and to divert second data related to the vehicle networking function to the second software, so that the first software implements the emergency call function based on the first data, and the second software implements the vehicle networking function based on the second data.

[0027] According to a third aspect, an electronic device is provided, the device comprising:

[0028] a memory for storing executable program code;

[0029] A processor is used to call and run the executable program code from the memory, so that the electronic device executes the method in any possible implementation manner of the first aspect above.

[0030] In a fourth aspect, a program product is provided, comprising: a program code, which, when executed on an electronic device, causes the electronic device to execute the method in any possible implementation of the first aspect.

[0031] In a fifth aspect, a readable storage medium is provided, which stores a program code. When the program code is run on an electronic device, the electronic device executes the method in any possible implementation manner of the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] Figure 1 This is a schematic diagram of the composition of a TBox provided in an embodiment of the present application;

[0033] Figure 2 This is a schematic diagram of the steps of a control method for a remote information terminal provided by an embodiment of the present application;

[0034] Figure 3 This is a data diversion diagram provided by an embodiment of the present application;

[0035] Figure 4 This is a schematic structural diagram of a control device for a remote information terminal provided in an embodiment of the present application;

[0036] Figure 5 It is a structural diagram of a device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0037] The following will clearly and thoroughly describe the technical solutions in this application in conjunction with the accompanying drawings. In the description of the embodiments of this application, unless otherwise specified, " / " means or, for example, A / B can mean A or B: "and / or" in the text is only a description of the association relationship of associated objects, indicating that there can be three relationships, for example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more than two.

[0038] In the following, the terms "first" and "second" are used for descriptive purposes only and should not be understood to imply or suggest relative importance or implicitly indicate the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the features.

[0039] In vehicles, the software that implements the eCALL function (hereinafter referred to as the first software) must undergo rigorous certification, a complex, lengthy, and expensive process. The certification process for other software, such as the software that implements the Internet of Vehicles (IoV) function (hereinafter referred to as the second software), is typically simpler and less expensive. The second software is the Network Access Device (NAD) application running in the Telematics Box (TBox). When the first software and other software are integrated into the same hardware, the first software and other software installed in the same hardware module are coupled. When upgrading, both the first software and other software need to be upgraded simultaneously, requiring certification of the first software, which adds additional certification time and cost.

[0040] Therefore, a common practice is to install separate hardware for the eCALL function in the vehicle, such as an electronic control unit (ECU), and use this separate ECU to run the first software. This decouples the first software from other software, allowing other software to be upgraded independently without the need for tedious and lengthy certification of the first software. However, installing a separate ECU for the eCALL function increases the vehicle's hardware costs.

[0041] In order to solve the above technical problems, the present application provides a control method for a remote information terminal, in which the first software for implementing the eCALL function is run in the first memory partition in the system on chip (SOC) of the TBox, and the second software for implementing the Internet of Vehicles function is run in the second memory partition in the SOC. At the same time, the third software is run in the SOC, and the first data related to the emergency call function is diverted to the first software through the third software, and the second data related to the Internet of Vehicles function is diverted to the second software. The decoupling between the first software and the second software can be achieved through memory partitioning, so that the second software can be upgraded separately, avoiding the authentication of the first software when the second software is upgraded. When the first software and the second software are integrated in the TBox, the tedious and time-consuming authentication process during the software upgrade can be avoided. Compared with the method of setting up hardware for the eCALL function separately, the hardware cost of the vehicle can be reduced.

[0042] Moreover, when the priority of the first software is higher than that of the second software, it can ensure that the first software can obtain the resources in the SOC in time, ensuring that the first software can run quickly and stably, thereby enabling the response delay of the vehicle's emergency events to meet the requirements.

[0043] It should be noted that the first software may be one or more and the second software may also be one or more.

[0044] See also Figure 1 , Figure 1 This is a schematic diagram of the composition of a TBox provided in an embodiment of the present application. Figure 1As shown, the TBox includes a SOC, a microcontroller unit (MCU), a positioning module and a fault diagnosis module, as well as other hardware modules not shown. The SOC has a central processing unit (CPU) and memory, as well as other components not shown. The SOC is installed with an operating system (such as a Linux system), and the first and second software in the above examples, as well as other software, can be installed in the operating system. The MCU and the SOC can be connected to each other through interfaces such as a universal asynchronous receiver / transmitter (UART) interface and a serial peripheral interface (SPI). The MCU is responsible for receiving and processing data from various ECUs of the vehicle, such as the vehicle's speed, engine status, battery charge, etc., and sending this data to the SOC. The SOC is connected to the positioning module, and the positioning module can be used to determine the vehicle's positioning information. The SOC is connected to the fault diagnosis module, and the fault diagnosis module can be used to diagnose the vehicle when a vehicle fault occurs and obtain a diagnostic trouble code (DTC). It should be understood that the SOC also integrates other hardware modules in addition to the positioning module and the fault diagnosis module, and obtains other relevant parameters of the vehicle through other modules, which are not described in detail in this embodiment.

[0045] See also Figure 2 , Figure 2 This is a schematic diagram of the steps of a control method for a remote information terminal provided by an embodiment of the present application. The execution subject of the method can be the SOC in the above example, and can include the following steps:

[0046] Step 201: Run first software in a first memory partition of a system-on-chip, and run second software in a second memory partition of the system-on-chip.

[0047] The priority of the first software is higher than the priority of the second software. The first software is used to implement the vehicle's emergency call function, and the second software is used to implement the vehicle's Internet of Vehicles function. The priority of the first software is higher than the priority of the second software. This means that the priority of the first software's thread is higher than the priority of the second software's thread, and the priority of the first software's task is higher than the priority of the second software's task. In this way, when the first software and the second software compete for various resources in the SOC, the first software can obtain the resources before the second software.

[0048] For example, during the development of the SOC, the size and address range of the memory required by the first software and the second software can be determined based on the memory requirements of the first software and the second software, respectively. For example, assuming that the first software requires 1 megabyte (MB) of memory and the second software requires 2MB of memory, the address range of the first memory partition in the SOC's memory can be determined to be: from address 0x00000000 to 0x000FFFFF (1MB), and the address range of the second memory partition in the SOC's memory can be determined to be: from address 0x00100000 to 0x002FFFFF (2MB). Through hardware description language or related configuration files, the first software can be mapped to the first memory partition, and the second software can be mapped to the second memory partition.

[0049] In order to prevent the first software from accessing the second memory partition, and to prevent the second software from accessing the first memory partition, access permissions can be set. For example, the setting of access permissions can be implemented through a memory management unit (MMU). Specifically, in the configuration of the MMU, independent page tables or access permission control tables can be set for the first software and the second software respectively. The page table or access permission control table stipulates that the first software only accesses the first memory partition, and access to the second memory partition is prohibited, and stipulates that the second software only accesses the second memory partition, and access to the first memory partition is prohibited. Alternatively, a memory protection unit (MPU) can be configured for the SOC to only authorize the first software to access the first memory partition and only authorize the second software to access the second memory partition, and to isolate unauthorized access through the MPU.

[0050] After the SOC is started or reset, the boot program in the SOC first loads the binary code and data of the first software into the first memory partition according to the address range of the first memory partition, and loads the binary code and data of the second software into the second memory partition according to the address range of the second memory partition. Afterwards, the boot program will initialize and start the two software in a predetermined order (for example, start the first software first, or start the second software first, or start the first software and the second software at the same time). During the initialization process, various hardware resources (such as interrupt controllers, timers, etc.) are configured to ensure that the first software and the second software can run normally. During the operation of the first software and the second software, the first software runs in the first memory partition and the second software runs in the second memory partition.

[0051] At the same time, for the first software and the second software, the priority of the process and task of the first software can be configured to be higher than the priority of the process and task of the second software, and a preemptive scheduling strategy can be used to allocate resources to the first software and the second software. For example, during the operation of the first software and the second software, the scheduler in the operating system of the SOC allocates CPU resources according to the priority of the thread. When the thread of the first software and the thread of the second software are in the ready state at the same time, the scheduler can allocate CPU resources to the thread of the first software first to ensure that the thread of the first software obtains the CPU resources first, thereby ensuring that emergency events occurring in the vehicle can be handled with priority. In addition, when the thread of the second software is occupying CPU resources, when the first software needs to use CPU resources, the occupation of CPU resources by the thread of the second software can be interrupted, and the CPU resources can be reallocated to the first software to ensure that the first software can obtain CPU resources in a timely manner, so that emergency events occurring in the vehicle can be handled with priority.

[0052] It should be noted that the specific process of running the first software and the second software in the first memory partition and the second memory partition respectively includes other contents in addition to the various implementation details in the above examples. Those skilled in the art can make specific settings according to needs, and this embodiment will not go into details here.

[0053] Step 202 : Run third software in the system-on-chip to divert first data related to the emergency call function to the first software through the third software, and divert second data related to the Internet of Vehicles function to the second software.

[0054] Among them, the first software realizes the emergency call function based on the first data, and the second software realizes the vehicle networking function based on the second data.

[0055] For example, when the operating system of the SOC is a Linux system, a third software can be deployed in the application layer of the Linux system. The third software is responsible for receiving data obtained by the hardware abstraction layer (HAL) in the Linux system from various hardware modules, and determining the first data required by the first software from the received data, passing the first data to the first software, and determining the second data required by the second software from the received data, and passing the second data to the first software.

[0056] like Figure 1As shown, when the eCALL function supports airbag triggering, the MCU communicates with the airbag controller. Upon detecting airbag deployment, the airbag controller can send an activation signal to the MCU. This activation signal is used to activate the first software, which is the first data. The MCU also communicates with other ECUs in the vehicle and can obtain first data related to the eCALL function, such as vehicle direction, vehicle fuel type, accident time, and estimated number of occupants, from these ECUs. It also obtains second data related to the connected vehicle function, such as remote control commands, driving trajectory records, engine status data, and energy consumption data, sent by these ECUs.

[0057] It should be noted that the first data and the second data may include but are not limited to the above examples. Some of the above data belong to the first data, some belong to the second data, and some belong to both the first data and the second data.

[0058] Taking the communication between the MCU and the SOC via the SPI protocol as an example, different data identifiers can be set in advance for the first data and the second data in the MCU. When the MCU sends data to the HAL layer in the SOC, if a certain data belongs to the first data, when sending the data to the HAL layer, the data identifier of the first data is added to the message header of the SPI message. If a certain data belongs to the second data, when sending the data to the HAL layer, the data identifier of the second data is added to the message header of the SPI message. If a certain data belongs to both the first data and the second data, when sending the data to the HAL layer, the data identifier of the first data and the data identifier of the second data are added to the message header of the SPI message.

[0059] After receiving the data sent by the MCU, the HAL layer transmits the data to the third software. When the message header includes the data identifier of the first data, the third software sends the data to the first software; when the message header includes the data identifier of the second data, the third software sends the data to the second software; when the message header includes the data identifiers of the first data and the second data at the same time, the third software sends the data to the first software and the second software at the same time.

[0060] like Figure 1 As shown, the SOC also includes other hardware modules such as the positioning module and the fault diagnosis module. The HAL layer can collect the vehicle's positioning information through the positioning module, obtain the vehicle's diagnostic fault code after a fault through the fault diagnosis module, and send the positioning information and DTC to the third software.

[0061] Similarly, the third software marks the received data in advance. After receiving a piece of data, if it is determined that the data belongs to the first data based on the mark, the first data is sent to the first software; if it is determined that the data belongs to the second data, the second data is sent to the second software; if it is determined that the data belongs to both the first data and the second data, the data is sent to the first software and the second software respectively.

[0062] Correspondingly, after receiving the first data, the first software runs based on the first data, enabling the TBox to function. For example, before receiving the activation signal, the first software is in an inactive state. After receiving the activation signal, it enters an active state. After entering the active state, the first software calls the MCU and other hardware modules through the HAL layer. After receiving data from the MCU and other hardware modules, the HAL layer sends the data to the third software. The third software sends the first data included in the received data to the first software. The first software runs based on the first data, enabling the TBox to implement the eCALL function.

[0063] Similarly, during the operation of the second software, the MCU and other hardware modules can be called through the HAL layer. After receiving the data sent by the MCU and other hardware, the HAL layer sends the data to the third software. The third software sends the second data included in the received data to the second software. The second software runs based on the second data, enabling the TBox to realize the Internet of Vehicles function.

[0064] In an embodiment of the present application, a first software is run in a first memory partition of the system-level chip, a second software is run in a second memory partition of the system-level chip, and a third software is run in the system-level chip at the same time. The third software is used to divert first data related to the emergency call function to the first software, and second data related to the vehicle networking function to the second software, so that the first software can implement the eCALL function based on the first data, and the second software can implement the vehicle networking function based on the second data. The memory partitioning can achieve decoupling between the first software and the second software, so that the second software can be upgraded separately, avoiding the need to authenticate the first software when the second software is upgraded. When the first software and the second software are integrated into the TBox, the tedious and time-consuming authentication process during the software upgrade can be avoided. Compared with the method of setting up hardware for the eCALL function separately, the hardware cost of the vehicle can be reduced.

[0065] Moreover, when the priority of the first software is higher than that of the second software, it can ensure that the first software can obtain the resources in the SOC in time, ensuring that the first software can run quickly and stably, thereby enabling the response delay of the vehicle's emergency events to meet the requirements.

[0066] Optionally, the system-on-chip is connected to the microcontroller unit, and third software is run in the system-on-chip, including:

[0067] Running a first sub-software included in the third software in the first memory partition, so as to divert first data included in the first portion of data to the first software through the first sub-software, and to divert second data included in the first portion of data to the second software, wherein the first portion of data includes data obtained by the first sub-software from the micro-control unit;

[0068] The second sub-software included in the third software is run in the first memory partition to divert the first data included in the second part of the data to the first software through the second sub-software, and to divert the second data included in the second part of the data to the second software, wherein the second part of the data includes data obtained by the second sub-software from other hardware modules integrated in the remote information terminal.

[0069] In one embodiment, the third software includes a first sub-software and a second sub-software, both of which run in the first memory partition, and both the first software and the second software can implement data reuse in different memory partitions.

[0070] Exemplarily, the first sub-software may be a System Interrupt Controller Dispatcher (SIC-Dispatcher) in a Linux system. The first sub-software interacts with the MCU and may obtain data from the MCU, the data obtained from the MCU being the first portion of data. After obtaining the first portion of data, the first portion of data may be shunted, the first data included in the first portion of data may be sent to the first software, and the second data included in the first portion of data may be sent to the second software. It should be understood that the specific implementation of the first sub-software may include but is not limited to an interrupt dispatcher, and other software modules that may implement the above functions may all serve as the first sub-software.

[0071] Exemplarily, the second sub-software can be an interface module running in the HAL layer of the Linux system. The interface module can call the interface of the HAL layer and obtain data from other hardware modules integrated in the SOC except the MCU through the interface of the HAL layer. The data obtained by the interface module is the second part of the data. After obtaining the second part of the data, the second part of the data can be diverted, and the first data included in the second part of the data can be sent to the first software, and the second data included in the second part of the data can be sent to the second software. It should be understood that the specific implementation of the second sub-software can include but is not limited to the interface module in the HAL layer, and other software modules that can implement the above functions can serve as the second sub-software.

[0072] In an embodiment of the present application, running the third software related to the eCALL function in the first memory partition can ensure that the first software and the third software related to the eCALL function both run in the first memory partition, which can reduce the coupling between the software related to the eCALL function and the software related to the vehicle network function, and reduce the adverse effects of the software related to the vehicle network function on the eCALL function.

[0073] Optionally, the method may further include:

[0074] Running the fourth software in the second memory partition to receive the second data split by the first sub-software and the second sub-software through the fourth software;

[0075] And, the received second data is transmitted to the second software through the fourth software.

[0076] like Figure 3 As shown, Figure 3 This is a data diversion diagram provided by an embodiment of the present application, and the fourth software includes a data service layer and a parsing / encapsulation module running in the second memory partition. The parsing / encapsulation module is used to receive the second data sent by the first sub-software, parse and encapsulate the second data, and send it to the second software. The data service layer is used to receive the second data sent by the second sub-software, and send the second data to the second software. In combination with the above example, the MCU and the SOC communicate through the SPI protocol, and there are multiple second software. After the first sub-software obtains the SPI message from the MCU, it sends the SPI message belonging to the second data to the parsing / encapsulation module. The parsing / encapsulation module can parse the SPI message, obtain the second data from the SPI message, and then encapsulate the obtained second data using the encapsulation format required by each second software, and send the encapsulated second data to each second software.

[0077] Furthermore, the second sub-software is an interface module in the HAL layer, which can call the HAL layer interface to obtain data from other hardware modules integrated in the SOC, except for the MCU, and send the second data included in the obtained data to the data service layer. Accordingly, after receiving the second data, the data service layer forwards the second data to the second software.

[0078] In an embodiment of the present application, a fourth software is set in the second memory partition, and the second data sent by the third software of the first memory partition is received by the fourth software, so that data sharing between the first memory partition and the second memory partition can be achieved, and the first memory partition and the second memory partition can be isolated at the same time.

[0079] Optionally, the method may further include:

[0080] Create a shared memory partition;

[0081] State information of the emergency call function is synchronized between the first software and the second software via the shared memory partition.

[0082] In one embodiment, a shared memory partition in addition to the first and second memory partitions can be set in the memory of the SOC. The first and second software can share eCALL status information via the shared memory partition. For example, when the first software is in an inactive state, status information indicating that the first software is inactive can be written to the shared memory partition. Furthermore, when the first software is in an inactive state, hardware modules implementing the eCALL function, such as the speaker, microphone, and antenna, can be controlled to hibernate, and the status information of each hardware module can be updated to the shared memory partition.

[0083] Similarly, after entering the active state, the first software can write status information indicating that the first software is in the active state to the shared memory partition. Furthermore, after entering the active state, the first software can activate hardware modules such as the speaker, microphone, and antenna that implement the eCALL function, and update the status information of each hardware module to the shared memory partition.

[0084] Accordingly, the second software can read the aforementioned status information from the shared memory partition and perform corresponding operations based on the status information. For example, if the second software determines that hardware modules such as speakers, microphones, and antennas related to the eCALL function are activated based on the status information read from the shared memory partition, it can disable other hardware modules such as speakers, microphones, and antennas in the vehicle to prevent other hardware from interfering with the implementation of the eCALL function.

[0085] The first software and the second software can communicate using a publish-subscribe model. The first software can trigger an interrupt signal to notify the second software that the eCALL function status information has been updated in the shared memory partition. After receiving the interrupt signal, the second software can read the shared memory partition and obtain the status information from the shared memory partition.

[0086] Alternatively, the first software and the second software can communicate using a message queue mechanism. The first software can update the status information of the eCALL function in real time to the message queue (such as the ZMQ message queue) set in the shared memory partition, and the second software periodically reads the status information of the eCALL function from the message queue.

[0087] In an embodiment of the present application, a shared memory partition is set up, and the first software in the first memory partition and the second software in the second memory partition can synchronize the status information of the emergency call function through the shared memory partition, thereby ensuring smooth communication between the first software and the second software.

[0088] Optionally, the system-on-chip has multiple cores, and the first software is run in a first memory partition of the system-on-chip, and the second software is run in a second memory partition of the system-on-chip, including:

[0089] running the first software in the first memory partition through a first core among the multiple cores;

[0090] And, running the second software in the second memory partition through a second core among the multiple cores.

[0091] In one embodiment, the CPU in the SOC can be a multi-core CPU. During the execution of the first software and the second software, different cores can be allocated to the first software and the second software so that the first software and the second software respectively execute based on different cores. For example, the CPU includes cores A, B, C, and D. When creating a thread for the first software, the thread can be bound to core A (i.e., the first core). When creating a thread for the second software, the thread can be bound to cores B, C, and D (i.e., the second core), thereby binding the first software to core A and the second software to cores B, C, and D. Afterwards, during execution, the first software only accesses the resources of core A and executes the first software through core A in the first memory partition. During execution, the second software only accesses the resources of cores B, C, and D and executes the second software through cores B, C, and D in the second memory partition.

[0092] It should be noted that the method of allocating cores between the first software and the second software includes but is not limited to the above examples. More cores can be allocated to the first software and fewer cores can be allocated to the second software. The same number of cores can also be allocated to the first software and the second software. The core data allocated to each software can be specifically configured according to actual needs.

[0093] In an embodiment of the present application, by running the first software in the first memory partition through the first core among the multiple cores and running the second software in the second memory partition through the second core among the multiple cores, the first software and the second software can be prevented from preempting CPU resources during operation, so as to avoid a certain software from being stuck when it cannot preempt CPU resources, thereby improving the reliability of the first software and the second software.

[0094] Optionally, before running the first software in the first memory partition through the first kernel among the multiple kernels, the method may further include:

[0095] When the first software is in an inactive state, determining a first number of first cores from the plurality of cores, or when the first software is in an activated state, determining a second number of first cores from the plurality of cores, the second number being greater than the first number;

[0096] The other cores among the plurality of cores except the first core are determined as second cores.

[0097] In one embodiment, when the CPU in the SOC is a multi-core CPU, the CPU cores can be dynamically allocated between the first software and the second software based on the status of the first software. In conjunction with the above example, the CPU includes core A, core B, core C, and core D, the first number is 1, and the second number is 2. When the first software is started, the first software is in an inactive state. At this time, the first number can be determined to be 1, and one core can be selected from cores A, B, C, and D as the first core. The first thread is bound to the first core, and the first software is run in the first memory partition through the first core. At the same time, the other three cores can be determined as the second core, and the second software can be bound to the second core, and the second software can be run in the second memory partition through the second core.

[0098] After receiving the trigger signal, the first software enters an active state. At this point, two cores can be selected from cores A, B, C, and D as first cores. The first thread is bound to the first core, and the first software runs in the first memory partition via the first core. Simultaneously, the other two cores can be identified as second cores, and the second software can be bound to the second core, and the second software runs in the second memory partition via the second core.

[0099] Afterwards, when the first software switches from the activated state to the inactivated state, one core can be selected from cores A, B, C, and D as the first core again, and the other three cores can be determined as the second cores. The first software can be run through the first core, and the second software can be run through the second core.

[0100] When the first software is in an inactive state, the CPU resources required by the first software are relatively small. If more CPU resources are allocated to the first software at this time, the CPU resources will be idle. When the first software is in an active state, the CPU resources required by the first software are relatively large. If the CPU resources are relatively small at this time, the first software may not run smoothly.

[0101] In an embodiment of the present application, when the first software is in an activated state, allocating more cores to the first software can provide the first software with sufficient core resources to ensure the smooth operation of the first software after the first software enters the activated state. When the first software is in an inactivated state, allocating fewer cores to the first software can avoid idle kernel resources and improve the utilization rate of kernel resources.

[0102] Optionally, the system-on-chip has multiple cores, and the method may further include:

[0103] When the first software enters an activated state, running the first software in the first memory partition through a first core among the multiple cores;

[0104] And, running the second software in the second memory partition through a second core other than the first core among the plurality of cores.

[0105] In one embodiment, when the CPU in the SOC is a multi-core CPU, after the first software enters the active state, it can be assigned a fixed core (i.e., the first core) so that the first software runs on the first core after entering the active state. For example, the CPU includes cores A, B, C, and D. When the first software does not receive a trigger signal and is in the inactive state, a process (hereinafter referred to as the first process) can be created to listen for the trigger signal. This process can be bound to cores A, B, C, and D. After receiving the trigger signal, the first software switches to the active state. At this time, one or more cores from cores A, B, C, and D can be selected as the first core, the process currently running on the first core can be shut down, and then another process of the first software (hereinafter referred to as the second process) can be created and bound to the first core. The second process can access the resources of the first core and run, thus implementing the eCALL function. Simultaneously, a second software process can be bound to a core other than the first core (i.e., the second core) among cores A, B, C, and D, allowing the second software to access the resources of the second core and run.

[0106] In this way, when the eCALL function is not activated, the first and second software programs share multiple cores in the CPU, maximizing the utilization of CPU core resources and reducing the idle rate of core resources. Furthermore, after the eCALL function is activated, the first software program is fixed to run on the first core, while the second software program is fixed to run on another core, thus preventing the first and second software programs from competing for core resources during operation.

[0107] In an embodiment of the present application, after the first software enters the activated state, a fixed core is allocated to the first software. While ensuring the smooth implementation of the eCALL function, the idle rate of the core resources can be reduced and the resource utilization of the system-level chip can be improved.

[0108] Optionally, the method may further include:

[0109] When the first software enters an activated state, expanding the first memory partition to obtain an expanded first memory partition;

[0110] The first software is run in the expanded first memory partition.

[0111] In one embodiment, a dynamic memory management strategy can be employed to dynamically adjust the size of the first memory partition based on the state of the first software. When the first software is launched, a smaller first memory partition is allocated to the first software. At this time, the eCALL function is inactive and runs in the smaller first memory partition. Upon receiving a trigger signal, the first software is activated and enters an active state. After the first software is activated, the first memory partition can be expanded to increase the size of the first memory partition, so that the activated first software runs in the increased size.

[0112] For example, when dividing the first memory partition into the second memory partition, the first memory partition is the initial first memory partition, and the second memory partition is the initial second memory partition. The initial first memory partition is smaller, but can meet the requirements of the smooth operation of the first software in an unactivated state. The initial second memory partition is larger and can meet the requirements of the smooth operation of the second software. After receiving a trigger signal, part of the memory partition can be recovered from the initial second memory partition and merged into the first memory partition to achieve expansion of the first memory partition, so that the activated first software runs in the expanded first memory partition.

[0113] When the first software switches from the active state to the inactive state, the first software releases the merged portion of the memory partition, allowing the first software to run again in the original first memory partition. The portion of the memory partition released by the first software is merged into the second memory partition, and the second software continues to run in the original second memory partition.

[0114] In an embodiment of the present application, when the first software enters an activated state, the first memory partition is expanded to obtain an expanded first memory partition, and the first software is run in the expanded first memory partition. This allows the first software to have larger memory resources after activation, and the first software can occupy fewer memory resources when not activated, thereby improving the utilization of memory resources.

[0115] See also Figure 4 , Figure 4 This is a schematic diagram of the structure of a control device for a remote information terminal provided by an embodiment of the present application. Figure 4 As shown, the control device 400 of the remote information terminal may include:

[0116] an operating module 401 configured to operate a first software in a first memory partition of a system-on-chip and to operate a second software in a second memory partition of the system-on-chip, wherein a priority of the first software is higher than a priority of the second software, the first software being configured to implement an emergency call function of the vehicle, and the second software being configured to implement an Internet of Vehicles function of the vehicle;

[0117] The diversion module 402 is used to run a third software in the system-level chip to divert the first data related to the emergency call function to the first software through the third software, and to divert the second data related to the vehicle networking function to the second software, so that the first software implements the emergency call function based on the first data, and the second software implements the vehicle networking function based on the second data.

[0118] Optionally, the system-level chip is connected to a micro control unit, and the running module 401 is specifically used to run the first sub-software included in the third software in the first memory partition, so as to divert the first data included in the first part of the data to the first software through the first sub-software, and to divert the second data included in the first part of the data to the second software, wherein the first part of the data includes the data obtained by the first sub-software from the micro control unit; and run the second sub-software included in the third software in the first memory partition, so as to divert the first data included in the second part of the data to the first software through the second sub-software, and to divert the second data included in the second part of the data to the second software, wherein the second part of the data includes the data obtained by the second sub-software from other hardware modules integrated in the remote information terminal.

[0119] Optionally, the running module 401 is also used to run the fourth software in the second memory partition to receive the second data diverted by the first sub-software and the second sub-software through the fourth software; and to pass the received second data to the second software through the fourth software.

[0120] Optionally, the device further includes: a synchronization module, configured to create a shared memory partition; and synchronize the state information of the emergency call function between the first software and the second software via the shared memory partition.

[0121] Optionally, the system-level chip has multiple cores, and the running module 401 is specifically used to run the first software in the first memory partition through a first core among the multiple cores; and to run the second software in the second memory partition through a second core among the multiple cores.

[0122] Optionally, the running module 401 is further used to determine a first number of the first cores from the multiple cores when the first software is in an inactivated state, or to determine a second number of the first cores from the multiple cores when the first software is in an activated state, the second number being greater than the first number; and determine the other cores among the multiple cores except the first core as the second cores.

[0123] Optionally, the system-level chip has multiple cores, and the running module 401 is specifically used to run the first software in the first memory partition through the first core among the multiple cores when the first software enters the activation state; and run the second software in the second memory partition through the second core among the multiple cores except the first core.

[0124] Optionally, the running module 401 is further configured to, when the first software enters an activated state, expand the first memory partition to obtain an expanded first memory partition; and run the first software in the expanded first memory partition.

[0125] See also Figure 5 , Figure 5 This is a schematic diagram of the structure of a device provided in an embodiment of the present application. Figure 5 As shown, the device 500 includes: a memory 501 and a processor 502, wherein the memory 501 stores an executable program code 5011, and the processor 502 is used to call and execute the executable program code 5011 to perform a control method for a remote information terminal.

[0126] In addition, an embodiment of the present application also protects a control device for a remote information terminal, which may include a memory and a processor, wherein the memory stores executable program code, and the processor is used to call and execute the executable program code to execute a control method for a remote information terminal provided in an embodiment of the present application.

[0127] In this embodiment, the device can be divided into functional modules based on the above-described method examples. For example, each functional module can be mapped to a specific functional module, or two or more functions can be integrated into a single processing module. The integrated module can be implemented in hardware. It should be noted that the module division in this embodiment is illustrative and represents only a logical functional division. In actual implementation, other division methods may be used.

[0128] In the case of dividing each functional module into corresponding functional modules, the device may further include a determination module, a replacement module, a control module, etc. It should be noted that all relevant contents of each step involved in the above method embodiment can be referred to the functional description of the corresponding functional module and will not be repeated here.

[0129] It should be understood that the device provided in this embodiment is used to execute the above-mentioned control method of a remote information terminal, and thus can achieve the same effect as the above-mentioned implementation method.

[0130] In the case of an integrated unit, the device may include a determination module and a control module. When the device is applied to a device, the processing module may be used to control and manage the device's actions. The storage module may be used to support the device in executing relevant program codes, etc.

[0131] The processing module may be a processor or a vehicle body configuration module, which may implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure herein. The processor may also be a combination of devices that implement computing functions, such as a combination of one or more microprocessors, a combination of a digital signal processing system (DSP) and a microprocessor, and the storage module may be a memory.

[0132] This embodiment also provides a readable storage medium, which stores program code. When the program code runs on an electronic device, the electronic device executes the above-mentioned related method steps to implement a control method for a remote information terminal provided by the above embodiment.

[0133] This embodiment further provides a program product. When the program product is run on an electronic device, the electronic device executes the above-mentioned related steps to implement a remote information terminal control method provided by the above embodiment.

[0134] Among them, the device, readable storage medium, program product or chip provided in this embodiment is used to execute the corresponding method provided above. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects in the corresponding method provided above, and will not be repeated here.

[0135] Through the description of the above implementation methods, technical personnel in the relevant field can understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0136] In the embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of modules or units is only a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0137] The above content is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.

Claims

1. A control method for a remote information terminal, characterized in that: A system-on-chip (SoC) used in a telematics terminal, the method comprising: Running first software in a first memory partition of a system-on-chip and running second software in a second memory partition of the system-on-chip, wherein a priority of the first software is higher than a priority of the second software, the first software is used to implement an emergency call function of the vehicle, and the second software is used to implement an Internet of Vehicles function of the vehicle; A third software is run in the system-on-chip to divert first data related to the emergency call function to the first software through the third software, and to divert second data related to the Internet of Vehicles function to the second software, so that the first software implements the emergency call function based on the first data, and the second software implements the Internet of Vehicles function based on the second data.

2. The method according to claim 1, wherein The system-on-chip is connected to a microcontroller unit, and the third software is run in the system-on-chip, including: Running a first sub-software included in the third software in the first memory partition, so as to divert the first data included in the first portion of data to the first software through the first sub-software, and to divert the second data included in the first portion of data to the second software, wherein the first portion of data includes data obtained by the first sub-software from the micro control unit; The second sub-software included in the third software is run in the first memory partition to divert the first data included in the second part of data to the first software through the second sub-software, and to divert the second data included in the second part of data to the second software, wherein the second part of data includes data obtained by the second sub-software from other hardware modules integrated in the remote information terminal.

3. The method according to claim 2, wherein The method further comprises: Running fourth software in the second memory partition to receive, through the fourth software, the second data split between the first sub-software and the second sub-software; And, the received second data is transmitted to the second software through the fourth software.

4. The method according to claim 1, wherein The method further comprises: Create a shared memory partition; The state information of the emergency call function is synchronized between the first software and the second software via the shared memory partition.

5. The method according to claim 1, wherein The system-on-chip has multiple cores, and the first software is run in a first memory partition of the system-on-chip, and the second software is run in a second memory partition of the system-on-chip, including: running the first software in the first memory partition through a first core among the multiple cores; And, running the second software in the second memory partition through a second core among the multiple cores.

6. The method according to claim 5, wherein Before running the first software in the first memory partition through the first core among the multiple cores, the method further includes: When the first software is in an inactive state, determining a first number of the first cores from the multiple cores, or when the first software is in an activated state, determining a second number of the first cores from the multiple cores, the second number being greater than the first number; The other cores among the plurality of cores except the first core are determined to be the second core.

7. The method according to claim 1, wherein The system-on-chip has multiple cores, and the first software is run in a first memory partition of the system-on-chip, and the second software is run in a second memory partition of the system-on-chip, including: When the first software enters an activated state, running the first software in the first memory partition through a first core among the multiple cores; And, running the second software in the second memory partition through a second core among the multiple cores except the first core.

8. The method according to any one of claims 1 to 7, wherein The method further comprises: When the first software enters an activated state, expanding the first memory partition to obtain an expanded first memory partition; The first software is run in the expanded first memory partition.

9. A control device for a remote information terminal, characterized in that: A system-on-chip (SoC) for use in a remote information terminal, comprising: an operating module, configured to operate a first software in a first memory partition of a system-on-chip and to operate a second software in a second memory partition of the system-on-chip, wherein a priority of the first software is higher than a priority of the second software, the first software is configured to implement an emergency call function of the vehicle, and the second software is configured to implement an Internet of Vehicles function of the vehicle; A diversion module is used to run a third software in the system-level chip to divert first data related to the emergency call function to the first software through the third software, and to divert second data related to the vehicle networking function to the second software, so that the first software implements the emergency call function based on the first data, and the second software implements the vehicle networking function based on the second data.

10. An electronic device, characterized in that: The device comprises: a memory for storing executable program code; A processor is configured to call and run the executable program code from the memory, so that the electronic device executes the method according to any one of claims 1 to 8.

Images