Vehicle-mounted low-power-consumption dormancy method and system and computer readable storage medium

Abstract

The invention discloses a vehicle-mounted low-power-consumption dormancy method and system and a computer readable storage medium. The method comprises the steps that high and low level changes of a GPIO pin are operated through a vehicle MCU; when the Tbox process detects the high level change of the GPIO pin, the IVI power management is notified to enter dormancy, and the vehicle dormancy operation is executed; after IVI dormancy is detected to be completed, the MCU is notified to trigger self dormancy; when the Tbox process detects the low level change of the GPIO pin, the MCU is notified to wake up, the IVI power management is notified to wake up, and the vehicle wake-up operation is executed; when a concurrent scene exists in the sleep / wake-up process, it is ensured that execution of the sleep / wake-up process is not interrupted in a serial mode. The sleep success rate can be improved, and the vehicle sleep power consumption is reduced.

Description

Technical Field

[0001] The present invention relates to the technical field of intelligent vehicles, and in particular, to a vehicle-mounted low-power sleep method, system, and computer-readable storage medium. Background Art

[0002] At present, more and more automobile manufacturers hope that the in-vehicle computer / dashboard can quickly turn on the screen and display after the vehicle is powered on in order to improve the user's driving experience. It is required that the vehicle does not shut down when the engine is turned off and the driver gets out of the car, but enters the low-power STR mode (suspend to ram), that is, the whole vehicle is in a Suspend state (the vehicle and the SoC are powered off, no code is executed, and the SoC RAM is still powered on). When the user unlocks, the whole vehicle can be quickly awakened, and the user can observe and operate the central control screen when opening the car door and getting into the car.

[0003] The prior art relies on the Kernel Suspend / Resume architecture, and the deep sleep / sleep function (suspending Android to RAM / disk) is implemented in the kernel. When no one in the system holds the Lock, the Suspend() of each HWDriver will be called when entering Suspend; when the system is awakened, the Resume() of each HW Driver will also be called when entering Resume; the HW Driver implements its own Suspend / Resume function to control its own power on / power off. When sleeping, the upper-layer services also need to adapt to the sleep / wake-up mode and release the system resources held by the resources, with poor constraints. There is a situation where the Suspend mode cannot be entered due to business exceptions, resulting in power consumption of the whole vehicle.

[0004] Because of the differences in the kernels between different chip manufacturers and the large increase in the built-in vehicle device TBox, the wake-up frequency has increased significantly. The differences in the dual-system management and scheduling have made it impossible for vehicle manufacturers to adapt to the existing solutions. The sleep fails frequently because the APP holds peripherals such as WIFI, Bluetooth, GPS, etc. and does not release and close them.

[0005] Therefore, it is urgent to design a vehicle-mounted low-power sleep method to overcome the above problems. Summary of the Invention

[0006] The technical problem to be solved by the present invention is to provide a vehicle-mounted low-power sleep method, system, and computer-readable storage medium for the defects in the prior art.

[0007] The technical solution adopted by the present invention to solve its technical problems is as follows:

[0008] The present invention provides a vehicle-mounted low-power sleep method, including:

[0009] Operating the high and low levels of the GPIO pin through the vehicle MCU;

[0010] When the Tbox process detects a change in the high level of the GPIO pin, it notifies the IVI power management to enter the sleep state and performs the vehicle sleep operation; after detecting that the IVI sleep is completed, it notifies the MCU to trigger its own sleep.

[0011] When the Tbox process detects a change in the low level of the GPIO pin, it notifies the MCU to wake up and notifies the IVI power management to wake up, and performs the vehicle wake-up operation.

[0012] Furthermore, when there is a concurrent scenario during the vehicle sleep / wake-up operation process of the present invention, the vehicle sleep / wake-up operation is performed in a serial and non-interruptible manner.

[0013] Furthermore, the concurrent scenario described in the present invention includes triggering a wake-up when the sleep is not completed or requesting a sleep when the wake-up is not completed.

[0014] Furthermore, in the method of the present invention, the vehicle sleep operation includes: turning off peripherals, notifying the application to enter the sleep mode and killing processes not within the whitelist; the vehicle wake-up operation includes: turning on peripherals, notifying the application to enter the wake-up mode, suspending to the RAM recovery state; the SOC is powered on and executes the running instruction, and the process resumes the running state.

[0015] Furthermore, in the method of the present invention, the method of notifying the IVI power management to enter the sleep state includes:

[0016] Notifying the in-vehicle computer and the instrument to sleep by setting the high level of the GPIO pin, detecting the high level and performing the pre-processing operation for the instrument sleep and the vehicle sleep operation; perceiving the IVI sleep through the monitoring interface and setting the IVI to the sleep state;

[0017] Periodically querying the IVI sleep state through the monitoring interface, and if both the in-vehicle computer and the instrument systems have completed sleep, notifying the MCU to sleep.

[0018] Furthermore, the method of the present invention also includes setting a signal that can query sleep / wake-up through the GPIO pin. When the IVI fails to sleep, it restarts the SOC of the MCU, and after restarting, it queries the sleep / wake-up state of the MCU again and performs the sleep again.

[0019] Furthermore, the sleep in the method of the present invention is all in the low-power STR mode of sleep, that is, the standby preparation mode.

[0020] Furthermore, in the method of the present invention, the data of the current working state is saved before performing the vehicle sleep operation; the saved data of the current working state is quickly restored before performing the vehicle wake-up operation.

[0021] The present invention provides an in-vehicle low-power sleep system, including:

[0022] A memory for storing an executable computer program;

[0023] A processor, when executing the executable computer program stored in the memory, implements the above-mentioned vehicle-mounted low-power sleep method.

[0024] The present invention provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the above-mentioned vehicle-mounted low-power sleep method.

[0025] The beneficial effects produced by the present invention are as follows:

[0026] 1. The method of the present invention uses hardware GPIO pins to replace the communication of the upper-layer protocol, improves the interaction stability, is compatible with the differences between different chip manufacturers, and the built-in TBox of the manufacturer can wake up the kernel through the modem.

[0027] 2. The method of the present invention can effectively reduce the problem that the native solution often fails to sleep due to the peripherals such as WIFI, Bluetooth, GPS, etc. not being turned off. The method of the present invention ensures that these are forcibly turned off and can forcibly kill the corresponding processes; a new sleep / wake signal is added to increase the coverage of the dual-system and multi-scene applications of the in-vehicle instrument, so as to improve the sleep success rate.

[0028] 3. Through the sleep method of the present invention, the problem of relying on the Kernel Suspend / Resume architecture in the existing method can be effectively avoided, and it has good constraints, and can overcome the problem that the vehicle is powered off due to the inability to enter the Suspend mode caused by business exceptions.

[0029] 4. The method of the present invention adds a serial method to ensure that a single process is not interrupted before completion, and avoids abnormal black screens caused by concurrency. Description of the Drawings

[0030] The present invention will be further described below in conjunction with the drawings and embodiments. In the drawings:

[0031] Figure 1 is the flowchart of the vehicle-mounted low-power sleep method according to the embodiment of the present invention.

[0032] Figure 2 is the overall framework of sleep / wake according to the embodiment of the present invention;

[0033] Figure 3 is the overall process of sleep / wake according to the embodiment of the present invention;

[0034] Figure 4 is the serial process of the sleep / wake process according to the embodiment of the present invention;

[0035] Figure 5 is the flowchart of the controller sleep according to the embodiment of the present invention;

[0036] Figure 6 It is a block diagram of the device according to an embodiment of the present invention. Detailed implementation manners

[0037] In order to make the objectives, technical solutions and advantages of the present invention more clearly understood, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention. In addition, the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0038] In the description of the present invention, it should be understood that the terms "center", "longitudinal", "lateral", "length", "width", "thickness", "upper", "lower", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", "clockwise", "counterclockwise", "axial", "radial", "circumferential", etc. indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings. They are only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and thus should not be construed as limiting the present invention.

[0039] In addition, the terms "first" and "second" are only used for descriptive purposes and cannot be understood as indicating or implying relative importance or implicitly specifying the quantity of the indicated technical features. Thus, the features defined with "first" and "second" may explicitly or implicitly include at least one of such features. In the description of the present invention, "a plurality of" means at least two, such as two, three, etc., unless otherwise specifically defined.

[0040] In the present invention, unless otherwise clearly defined and limited, the terms "mounted", "connected", "coupled", "fixed", etc. shall be construed in a broad sense. For example, it may be a fixed connection, a detachable connection, or integrated; it may be a mechanical connection or an electrical connection; it may be directly connected or indirectly connected through an intermediate medium, and it may be the internal communication of two elements or the interaction relationship between two elements, unless otherwise clearly limited. For those of ordinary skill in the art, the specific meanings of the above terms in the present invention can be understood according to specific circumstances.

[0041] In the present invention, unless otherwise clearly specified or limited, the first feature being "on" or "under" the second feature may mean that the first and second features are in direct contact, or the first and second features are in indirect contact through an intermediate medium. Moreover, the first feature being "above", "over" and "on top of" the second feature may mean that the first feature is directly above or obliquely above the second feature, or merely indicates that the horizontal height of the first feature is higher than that of the second feature. The first feature being "under", "beneath" and "underneath" the second feature may mean that the first feature is directly below or obliquely below the second feature, or merely indicates that the horizontal height of the first feature is less than that of the second feature.

[0042] It should be understood that the magnitudes of the sequence numbers of the steps in the above embodiments do not imply the order of execution. The order of execution of each process should be determined according to its function and internal logic, and should not constitute any limitation to the implementation process of the embodiments of the present application.

[0043] The English abbreviation interpretations involved in the embodiments of the present invention are as follows:

[0044] Microcontroller Unit (abbreviation: MCU)

[0045] In-Vehicle Infotainment (abbreviation: IVI)

[0046] General-purpose input / output (abbreviation: GPIO)

[0047] System on Chip (abbreviation: SoC)

[0048] Telematics BOX (abbreviation: Tbox)

[0049] hypervisor

[0050] Embodiment 1

[0051] As Figures 1-5 shown, the embodiments of the present invention provide a vehicle-mounted low-power sleep method, and the method includes the following:

[0052] By operating the high and low levels of the GPIO pin state through the vehicle MCU, the power management is notified to enter sleep / wake-up; and the power management can query the MCU sleep / wake-up state at any time. When there is a difference between the MCU sleep wake-up and the in-vehicle IVI, the IVI can quickly respond to sleep / wake-up to ensure synchronization.

[0053] The process of requesting sleep and wake-up through the Tbox is as follows:

[0054] When the Tbox process detects a high-level change in the GPIO pin, it notifies the IVI power management to enter the sleep state and performs the vehicle sleep operation.

[0055] In a preferred embodiment of the present invention, performing the vehicle sleep operation specifically includes the following:

[0056] The vehicle sleep operation includes: turning off peripherals, notifying the application to enter the sleep mode and killing processes not in the whitelist, turning off WIFI, turning off Bluetooth, turning off USB peripherals and removing the peripheral usage scenario, preventing application processes from pulling up or restoring some peripherals such as Bluetooth and wifi through keep-alive, and ensuring that no peripheral-related resource locks are held when the kernel triggers sleep.

[0057] After the above vehicle sleep operation process is completed, it will notify the kernel to sleep. After the SOC detects that the IVI and instrument are in the sleep state, it sets the GPIO pin high level to notify the MCU to trigger its own sleep.

[0058] The MCU notifies the MCU to wake up by setting the GPIO pin change to low level. When the Tbox process detects a low-level change in the GPIO pin, it notifies the MCU to wake up and notifies the IVI power management to wake up, and performs the vehicle wake-up operation.

[0059] In a preferred embodiment of the present invention, performing the vehicle wake-up operation specifically includes the following:

[0060] The in-vehicle IVI performs turning on peripherals, lighting up the screen, notifying the application to enter the wake-up mode, and suspending to the RAM recovery state; the SOC is powered on and executes the running instruction, and the process resumes the running state.

[0061] In the case of a concurrent scenario during the sleep / wake-up process, the serial method is used to ensure that the sleep / wake-up process is not interrupted.

[0062] Preferably, the signal of the MCU sleep / wake-up is queried through the GPIO pin status. When the in-vehicle IVI fails to sleep, it restarts the SOC of the MCU, and queries the sleep / wake-up status of the MCU again after the restart, and performs the sleep again.

[0063] The embodiment of the present invention proposes an innovative control process and method for the vehicle IVI power management system. Through the precise regulation of the GPIO pin status, the efficient switching between the system sleep and wake-up states is realized. This method abandons the traditional upper-layer protocol communication method and instead uses the hardware GPIO pin for signal transmission. This hardware-level method greatly improves the stability and reliability of the interaction, effectively avoids problems such as signal interference and data loss that may occur during the upper-layer protocol communication process, and ensures the accurate transmission of control signals.

[0064] In the specific implementation process, the present invention precisely triggers the sleep and wake-up mechanisms of the IVI power management system through real-time monitoring and precise control of the GPIO pin states. When the system needs to enter the sleep state, through specific GPIO pin state settings, it can reasonably allocate and turn off various resources within a short period of time, enter the low-power sleep mode, thereby effectively reducing the system power consumption of the vehicle. When the system needs to be woken up, similarly by changing the GPIO pin states, the power management system is quickly activated to rapidly resume the normal working state, enabling it to promptly respond to the operation requirements of users and achieve seamless switching.

[0065] Embodiment 2

[0066] As Figures 1-5 shown, based on Embodiment 1, the embodiment of the present invention provides a method for querying the sleep / wake-up status signal at any time on the basis of the in-vehicle low-power sleep method.

[0067] Signal multiplexing natively in the overall power management solution ensures that the sleep / wake-up progress and status of the IVI power management are synchronized to the MCU; the IVI power management registers a callback, receives the callback of the corresponding status before STR, and switches its own power state to STR, turns off various peripherals, and notifies the application of the corresponding power state. The application makes preparations before sleep and notifies the kernel to sleep. The hypervisor system notifies the MCU of the current SOC sleep result.

[0068] The main function of the Tbox is to monitor the high and low levels of the GPIO pins corresponding to the MCU. A high level state notifies the IVI to sleep, and a low level state notifies the IVI to wake up. The IVI power management receives the sleep / wake-up signal sent by the Tbox, switches its own power state to STR, turns off various peripherals, notifies the application layer to release system resources, and then notifies the kernel to sleep.

[0069] As Figure 5 shown, in the embodiment of the present invention, a signal for querying sleep / wake-up is newly added. When the IVI fails to sleep, the MCU will restart the SOC, and after restarting, it can query the sleep / wake-up status of the MCU. The IVI power management will execute the sleep process again. Before the IVI system successfully sleeps, it will also pull up the GPIO high level to notify the hypervisor that the IVI has successfully slept.

[0070] Among them, the instrument IC itself detects and monitors the state of the GPIO pins. After its own successful sleep, it will also notify the hypervisor IC of the successful sleep. After the hypervisor detects that both the instrument and the IVI have successfully slept, it notifies the MCU to sleep.

[0071] When entering the wake-up process, the wake-up objects include: Wake-up source B + power-on, ACC wake-up, CAN wake-up, IMU wake-up, SOC wake-up, RTC wake-up, BLE wake-up, and Ethernet.

[0072] There are no conditional restrictions for the MCU to trigger sleep and wake-up, and there is a great deal of randomness; the sleep and wake-up processes are based on the stability of the system and the CASERVICE process, and for the stability of the system, the CASERVICE process will query the sleep and wake-up status of the MCU during initialization to avoid problems such as power consumption due to abnormal process failure to enter sleep or black screen due to abnormal wake-up. Based on the stability of each layer of processes in the sleep / wake-up process and concurrent scenarios such as requests for sleep, a new serial method is added to ensure that the process is not interrupted before completion, ensuring that the corresponding Suspend and Resume operations of the kernel layer services are executed in an orderly manner.

[0073] The embodiments of the present invention add a signal for querying the sleep / wake-up status. The introduction of this signal enables the IVI system to obtain the sleep and wake-up status information of itself and related components in real time and accurately. In the case of sleep failure, the IVI system can quickly respond and automatically restart the SOC. After restarting, the sleep / wake-up status of the MCU is queried in detail through the newly added query signal. This enables the IVI system to accurately grasp the actual status of the MCU, thereby providing an accurate reference basis for subsequent sleep processes. After confirming the status of the MCU, the IVI system will execute the sleep process again, which improves the success rate of the sleep operation and the stability of the system.

[0074] This query mechanism in the embodiments of the present invention enables the power management system to monitor the status changes of the MCU in real time and promptly detect the status differences between the MCU and the in-vehicle IVI. When it is detected that the sleep and wake-up status of the MCU is inconsistent with the in-vehicle IVI, the IVI system can quickly respond and rapidly adjust its own sleep / wake-up status to achieve high synchronization with the MCU.

[0075] The embodiments of the present invention comprehensively improve the sleep and wake-up performance of the IVI power management system, enhance the stability and reliability of the system, and provide a solid guarantee for the efficient operation of the intelligent in-vehicle system by adding a sleep / wake-up status query signal, optimizing the restart and query processes after sleep failure, and endowing the power management with the ability to query the status at any time and quickly synchronize.

[0076] Embodiment 3

[0077] As Figures 1-5As shown, based on Embodiment 1 and Embodiment 2, the embodiment of the present invention adopts a way of serial execution of sleep / wake-up to solve the concurrent scenario and avoid vehicle power failure caused by sleep failure. When there is a concurrent scenario during the vehicle sleep / wake-up operation, the present invention executes the vehicle sleep / wake-up operation in a serial and uninterrupted manner. The concurrent scenario includes triggering wake-up when sleep is not completed or requesting sleep when wake-up is not completed.

[0078] In a preferred embodiment of the present invention, during the sleep / wake-up process of the IVI power management system, there are some concurrent scenarios, such as triggering wake-up when sleep is not completed or requesting sleep when wake-up is not completed. These scenarios may cause system anomalies, such as black screens. To solve this problem, the embodiment of the present invention introduces a new serial method to ensure that it is not interrupted before the process execution is completed, so as to ensure that the kernel layer services can orderly execute the corresponding Suspend and Resume operations.

[0079] In this way, the embodiment of the present invention effectively avoids problems such as abnormal black screens that may be caused in the concurrent scenario, and improves the stability and reliability of the system. At the same time, this serial mechanism also provides convenience for system maintenance and debugging, enabling developers to more clearly track each step in the sleep / wake-up process and timely discover and solve problems.

[0080] Embodiment 4

[0081] As Figure 6 shown is a schematic structural diagram of a computer device provided by an embodiment of the present invention, such as a smart phone, a tablet computer, a notebook computer, a desktop computer, a rack server, a blade server, a tower server or a cabinet server (including an independent server, or a server cluster composed of multiple servers) that can execute programs. The computer device 20 of this embodiment at least includes, but is not limited to: a memory 21 and a processor 22 that can communicate with each other through a system bus, as Figure 6 shown. It should be noted that Figure 6 only the computer device 20 with components 21-22 is shown, but it should be understood that it is not required to implement all the shown components, and more or fewer components can be alternatively implemented.

[0082] In this embodiment, the memory 21 (i.e., the readable storage medium) includes flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory, etc.), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM). The memory 21 can also be an external storage device of the computer device 20, such as a plug-in hard disk equipped on the computer device 20, a Smart Media Card (SMC), a Secure Digital (SD) card, a Flash Card, etc. Of course, the memory 21 can also include both the internal storage unit of the computer device 20 and its external storage device. In this embodiment, the memory 21 is generally used to store the operating system installed on the computer device 20 and various application software, such as the program code of the vehicle-mounted low-power sleep method in the method embodiment. In addition, the memory 21 can also be used to temporarily store various data that have been output or will be output.

[0083] In some embodiments, the processor 22 can be a central processing unit (CPU), a controller, a microcontroller, a microprocessor, or other data processing chips. The processor 22 is generally used to control the overall operation of the computer device 20. In this embodiment, the processor 22 is used to run the program code stored in the memory 21 or process data, such as running the vehicle-mounted low-power sleep method.

[0084] Embodiment 5

[0085] This application also provides a computer-readable storage medium, such as flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory, etc.), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, disk, optical disc, server, App application mall, etc. A computer program is stored thereon, and when the program is executed by a processor, corresponding functions are implemented. The computer-readable storage medium of this embodiment is used to store the vehicle-mounted low-power sleep device, and when executed by a processor, it implements the vehicle-mounted low-power sleep method of the method embodiment.

[0086] It should be noted that according to the needs of implementation, the various steps / components described in this application can be split into more steps / components, or two or more steps / components or partial operations of steps / components can be combined into new steps / components to achieve the purpose of the present invention.

[0087] Those skilled in the art can easily understand that the above are only the preferred embodiments of the present invention and are not intended to limit the present invention. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present invention shall be included within the protection scope of the present invention.

Claims

1. A vehicle-mounted low-power sleep method, characterized in that, Including: Operating the high and low levels of GPIO pins through the vehicle MCU; When the Tbox process detects a high-level change of the GPIO pin, it notifies the IVI power management to enter the sleep state and performs the vehicle sleep operation; after detecting that the IVI sleep is completed, it notifies the MCU to trigger its own sleep; When the Tbox process detects a low-level change of the GPIO pin, it notifies the MCU to wake up and notifies the IVI power management to wake up, and performs the vehicle wake-up operation.

2. The in-vehicle low-power sleep method according to claim 1, characterized in that When there is a concurrent scenario during the vehicle sleep / wake-up operation, the vehicle sleep / wake-up operation is performed in a serial and non-interruptible manner.

3. The in-vehicle low-power sleep method according to claim 2, wherein The concurrent scenario includes triggering wake-up when sleep is not completed or requesting sleep when wake-up is not completed.

4. The vehicle-mounted low-power sleep method according to claim 1, wherein, The vehicle sleep operation in this method includes: turning off peripherals, notifying the application to enter the sleep mode and killing processes not in the whitelist; the vehicle wake-up operation includes: turning on peripherals, notifying the application to enter the wake-up mode, suspending to the RAM restore state; the SOC is powered on and runs the operation instructions, and the process resumes the running state.

5. The in-vehicle low-power sleep method according to claim 1, wherein The method for notifying the IVI power management to enter the sleep state includes: Notifying the in-vehicle computer and instrument to sleep by setting the high level of the GPIO pin, and detecting the high level to perform the pre-processing operation for instrument sleep and the vehicle sleep operation; perceiving the IVI sleep through the monitoring interface and setting the IVI to the sleep state; Periodically querying the IVI sleep state through the monitoring interface, and if both the in-vehicle computer and instrument systems have completed sleep, notifying the MCU to sleep.

6. The in-vehicle low-power sleep method according to claim 1, characterized in that This method also includes setting a signal for querying sleep / wake-up through the GPIO pin. When the IVI fails to sleep, it restarts the SOC of the MCU, and after restarting, it queries the sleep / wake-up state of the MCU again and performs sleep again.

7. The in-vehicle low-power sleep method according to claim 1, wherein The sleep in this method is all in the low-power STR mode of sleep, that is, the standby preparation mode.

8. The in-vehicle low-power sleep method according to claim 1, wherein In this method, the data of the current working state is saved before performing the vehicle sleep operation; the saved data of the current working state is quickly restored before performing the vehicle wake-up operation.

9. A vehicle-mounted low-power sleep system, characterized in that, Including: A memory for storing an executable computer program; A processor for implementing the in-vehicle low-power sleep method described in any one of claims 1 to 8 when executing the executable computer program stored in the memory.

10. A computer-readable storage medium, characterized in that [[ID=?]]A computer program is stored and used to implement the in-vehicle low-power sleep method described in any one of claims 1 to 8 when executed by a processor. It should be noted that there seems to be a problem with the numbering in [[ID=?]]. It should probably be to be consistent with the original text's numbering logic. I've translated it as is based on the provided content.

Images