Vehicle OTA program self-upgrading method and device and electronic equipment

Abstract

The invention relates to the technical field of automobiles, in particular to a vehicle OTA program self-upgrading method and device and electronic device.The method comprises the steps that after a system is started, a starting module and a guiding module in an OTA program are started in sequence; the boot module checks a system specific directory and calls the service master control module with the highest version; the service main control module writes the vehicle feature information into a configuration file; the starting module analyzes the configuration file and inquires and downloads an upgrading file of the service main control module from the OTA cloud platform when a condition is met; and then, when it is monitored that the system or the module is restarted, the guiding process is executed again, the downloaded new-version service master control module is started, and self-upgrading is completed. Through modular design and process control, reliable upgrading of the OTA program is realized, upgrading endless loop caused by abnormality of the main control program is effectively broken, and robustness and applicability of the OTA system are remarkably improved.

Description

Technical Field

[0001] This invention relates to the field of automotive technology, and in particular to a method, apparatus, and electronic device for vehicle OTA program self-upgrade. Background Technology

[0002] With the widespread adoption of intelligent connected vehicles, OTA (Over-The-Air) technology has become a core means of vehicle software maintenance and feature updates. A typical vehicle-side OTA system includes an OTA program (the main controller) and OTA objects (items to be upgraded). The OTA program manages all upgrade logic, and its stability is crucial. However, when the OTA program itself malfunctions or needs updating, traditional upgrade channels may fail, leading to a situation where the system "needs an upgrade but cannot."

[0003] Currently, improving the robustness of the OTA (Over-The-Air) controller is a common solution, but once the controller program crashes, it still requires physical intervention or redundant design, which is costly and inefficient. Therefore, there is an urgent need for a reliable method that enables OTA programs to self-repair and upgrade, ensuring that the OTA system maintains its upgradeability under any circumstances. Summary of the Invention

[0004] This invention provides a method, device, and electronic device for self-upgrading of vehicle OTA programs, which achieves reliable upgrades of the OTA program itself through modular design and process control.

[0005] This specification provides an embodiment of a vehicle OTA program self-upgrade system, deployed on an in-vehicle terminal. The system includes: a startup module, a guide module, and a business control module. The startup module is configured to start the boot module in response to a system startup event; and is configured to start the boot module in response to an exit event of the business master control module. The boot module is configured to, in response to being started by the startup module, access a system-preset storage directory to obtain version information of the business master control module, and call the target version of the business master control module based on a version comparison strategy; and is configured to, when restarted due to the exit of the business master control module, if a target module with a version higher than the exited business master control module is detected, load and execute the target module to complete the self-upgrade; wherein, the business master control module is configured to execute core OTA business logic, and when the business master control module finishes running, transmit an exit event to the startup module.

[0006] Optionally, the boot module is further configured to: After the business control module is called for the first time, the vehicle's characteristic attribute information is obtained through the system interface and written into a preset configuration file.

[0007] Optionally, the startup module is further configured to: After the boot module exits, the configuration file is read and parsed, and based on the parsing result and preset triggering conditions, a query request for the OTA program's own upgrade task is sent to the OTA cloud server.

[0008] Optionally, the startup module also integrates a keep-alive mechanism; The keep-alive mechanism is configured to monitor the running status of the startup module itself, and automatically restart the startup module when it is detected that the startup module has stopped running; wherein, the restarted startup module is configured to immediately perform the operation of starting the boot module. Optionally, the preset trigger condition is a system date change event.

[0009] Optionally, the version comparison strategy specifically involves comparing the version number values ​​and selecting the business control module with the largest version number value for invocation.

[0010] Optionally, the startup module can detect the exit event of the business master control module by monitoring the process status of the business master control module.

[0011] This specification also provides an OTA (Over-The-Air) program self-upgrade device for vehicles, applied to an in-vehicle terminal, comprising: In response to a system startup event, a boot module is started; or, in response to an exit event of a business control module, the boot module is restarted. When the boot module is started, it accesses the system's preset storage directory to obtain the version information of the business master control module; based on the version comparison strategy, it calls the target version of the business master control module; when the boot module is restarted due to the exit of the business master control module, if a target module with a version higher than the exited business master control module is detected, the target module is loaded and executed to complete the self-upgrade; wherein, the business master control module is configured to execute core OTA business logic, and when the business master control module finishes running, it transmits an exit event to the boot module.

[0012] An electronic device includes a memory and a processor, the memory storing computer instructions, and the processor being configured to execute the computer instructions to perform the method described above.

[0013] A storage medium, characterized in that the storage medium stores computer instructions, the computer instructions being configured to execute the method described above at runtime.

[0014] Its beneficial effects are as follows: This application links parameter acquisition, performance optimization, displacement calculation, and structural design into a complete and logically rigorous design process, reducing reliance on experience; through multidisciplinary joint optimization, it can accurately find stiffness parameters that simultaneously satisfy high decoupling rate, reasonable natural frequency, and displacement constraints, ensuring vibration isolation performance from the source; by determining the limiting distance through theoretical calculation rather than empirical estimation, it effectively avoids the risk of failure such as rubber body impact and tearing caused by insufficient displacement, improving the durability of the product. At the same time, this method can complete most of the design and verification work on a computer, shortening the development cycle and reducing the cost of physical trial and error. Attached Figure Description

[0015] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This specification provides a schematic diagram of a vehicle OTA (Over-The-Air) program self-upgrade system structure as an embodiment. Figure 2 This is a schematic diagram illustrating the principle of a vehicle OTA program self-upgrade method provided in the embodiments of this specification; Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this specification; Figure 4 This is a schematic diagram of a computer-readable medium provided for embodiments of this specification. Detailed Implementation

[0016] The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0017] It should be noted that, unless otherwise specifically stated, the relative arrangement, numerical expressions, and values ​​of the components and steps described in these embodiments do not limit the scope of the invention.

[0018] The following description of at least one exemplary embodiment is merely illustrative and is in no way intended to limit the invention or its application or use.

[0019] Techniques, methods, and equipment known to those skilled in the art may not be discussed in detail, but where appropriate, such techniques, methods, and equipment should be considered part of the specification.

[0020] In all the examples shown and discussed herein, any specific values ​​should be interpreted as merely exemplary and not as limitations. Therefore, other examples of exemplary embodiments may have different values.

[0021] It should be noted that similar labels and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be discussed further in subsequent figures.

[0022] Reference Figure 1 This is a schematic diagram of a vehicle OTA program self-upgrade system provided in an embodiment of this specification. The system is deployed on an in-vehicle terminal and includes: a startup module 101, a guide module 102, and a service master control module 103. The startup module 101 is configured to start the guide module 102 in response to a system startup event and to start the guide module 102 in response to an exit event of the service master control module 103. The guide module 102 is configured to, in response to being started by the startup module 101, access a system-preset storage directory to obtain the version information of the service master control module 103, and call the target version of the service master control module 103 based on a version comparison strategy; and is configured to, when restarted due to the exit of the service master control module 103, if a target module with a version higher than the exited service master control module 103 is detected, load and execute the target module to complete the self-upgrade. The service master control module 103 is configured to execute core OTA business logic and, when the service master control module 103 finishes running, transmit an exit event to the startup module 101.

[0023] In an optional embodiment, when the vehicle system is first started, the system actively starts the startup module 101; the startup module 101 then starts the boot module. The boot module is configured to access a preset storage directory (such as / OTA / versions) in the system's storage space through the system interaction interface, obtain the version information of all business master control modules 103 by parsing the version number file, and call the target version of the business master control module 103 (i.e., the target module) based on a version comparison strategy (such as selecting the business master control module 103 with the largest version number). The business master control module 103 is responsible for executing the core OTA business logic (such as downloading upgrade packages, verifying signatures, etc.), and integrates the UDS (Unified Diagnostic Services) protocol stack during execution for vehicle diagnostics and communication. For example, the business master control module accesses the vehicle's CAN bus through the UDS protocol stack, reads the status information of the ECU (Electronic Control Unit) or executes diagnostic routines to ensure that the OTA upgrade is compatible with the vehicle system. When the business master control module finishes running (normal exit or abnormal crash), it transmits an exit event to the startup module 101. The startup module 101 then responds to the exit event and restarts the boot module to achieve cyclic monitoring. Through modular design and cyclic monitoring mechanisms, the OTA program can be automatically recovered and upgraded in case of anomalies, breaking the vicious cycle of "OTA objects needing to be upgraded but unable to be upgraded", and enhancing the robustness of the entire OTA system.

[0024] In actual deployment, the modular deployment of startup module 101, guide module 102 and business control module 103 is suitable for OTA systems of different vehicle platforms, which facilitates integration and expansion.

[0025] When the boot module 102 is started for the first time, it will perform version comparison and module call; when the business master control module 103 is restarted after it exits, if a higher version of the business master control module 103 is detected in the storage directory (such as a newly downloaded upgrade package), the target module will be loaded directly to complete the self-upgrade and avoid relying on the original OTA channel.

[0026] Optionally, the guidance module 102 is further configured to: after the first call to the business control module 103, obtain the vehicle's feature attribute information through the system interface and write the feature attribute information into a preset configuration file.

[0027] The boot module 102 is also configured to, upon the initial call to the business control module 103, obtain vehicle characteristic attribute information (such as VIN code, serial number SN, etc.) through system interfaces (such as Linux's sysfs or vehicle-specific APIs) and write this information to a preset configuration file (such as / OTA / config / vehicle_info.conf). For example, after the business control module 103 starts without errors, the boot module 102 calls the get_vin() function to obtain the VIN code and formats it to write to the configuration file. The configuration file is created on the first run and updated in subsequent runs. Writing vehicle characteristic attribute information facilitates rapid reading by subsequent modules (such as the startup module 101), reduces the overhead of repeated acquisition, and improves efficiency. Based on vehicle information, the OTA cloud server can issue targeted upgrade tasks, improving the accuracy and security of upgrades.

[0028] Optionally, the startup module 101 is further configured to: after the boot module 102 exits, read and parse the configuration file, and based on the parsing result and preset triggering conditions, initiate a query request to the OTA cloud server for the OTA program's own upgrade task.

[0029] The startup module 101 is also configured to read and parse the aforementioned configuration file (such as parsing the VIN code and serial number SN in vehicle_info.conf) after the boot module 102 exits, and based on the parsing results and preset trigger conditions (such as system date changes), initiate a query request to the OTA cloud server for the OTA program's own upgrade task. For example, the startup module 101 monitors the system date through a timer. When a date change is detected (such as from October 1, 2023 to October 2, 2023), it constructs an HTTP request using the VIN code information in the configuration file and calls the OTA cloud server's RESTful API to query whether a new version of the OTA program is available. By automatically initiating queries based on trigger conditions (such as system date changes), manual intervention is reduced, ensuring the timeliness of upgrade tasks; by querying the cloud server only under specific conditions, frequent network requests are avoided, saving vehicle terminal resources.

[0030] Optionally, the startup module 101 also integrates a keep-alive mechanism; the keep-alive mechanism is configured to monitor the running status of the startup module 101 itself, and automatically restart the startup module 101 when it is detected that the startup module 101 has stopped running; wherein, the restarted startup module 101 is configured to immediately perform the operation of starting the boot module 102. The startup module 101 also integrates a keep-alive mechanism. This mechanism, implemented through a daemon process or watchdog timer, monitors the startup module 101's own running status (such as whether the process ID is alive). If the startup module 101 unexpectedly stops running (e.g., killed due to insufficient system resources), the keep-alive mechanism automatically restarts the startup module 101 (e.g., via the systemd service). Upon restarting, the startup module 101 immediately executes the operations of the bootloader 102, ensuring uninterrupted OTA program monitoring. For example, in an in-vehicle Linux system, the keep-alive mechanism periodically checks the process list via a cron job; if it finds a missing process for the startup module 101, it executes a restart script. The keep-alive mechanism prevents a single point of failure for the startup module 101, ensuring the OTA program's self-upgrade system is always active, improving system availability; simultaneously, it automatically restarts the startup module 101 without external intervention, meeting the high reliability requirements of vehicle electronic systems.

[0031] Optionally, the preset trigger condition is a system date change event.

[0032] Specifically, the startup module 101 registers a system date listener (e.g., via Linux's timedatectl). When a date change is detected (e.g., a system date update at midnight), it triggers a configuration file parsing and cloud server query process. For example, when the date changes, the startup module 101 reads vehicle information from the configuration file and sends a query request to the OTA cloud to check if there are any new upgrade tasks based on that date. This design avoids frequent queries, executing only when the date changes, which aligns with vehicle usage scenarios (e.g., the first startup each day). Triggering based on date changes reduces unnecessary network requests, lowers power consumption and bandwidth usage, while ensuring that upgrade tasks are associated with dates, facilitating the management of periodic upgrades (e.g., monthly security updates).

[0033] Optionally, the version comparison strategy specifically involves comparing the version number values ​​and selecting the business main control module 103 with the largest version number value for invocation.

[0034] Specifically, the guidance module 102 scans all business main control module 103 files (such as main_control_v1.0.bin and main_control_v2.0.bin) in the storage directory, parses the version number (such as semantic version numbers v1.0 and v2.0) in the filename or metadata, and selects the module with the largest version (such as v2.0) as the target module through numerical comparison (such as converting the version number to an integer). This simple and efficient version comparison strategy avoids accidentally calling older versions and ensures that the system always runs the latest optimized code; at the same time, the numerical comparison-based strategy has low computational overhead and is suitable for resource-constrained vehicle terminals.

[0035] Optionally, the startup module 101 can detect the exit event of the business master control module 103 by monitoring the process status of the business master control module 103.

[0036] Specifically, the startup module 101 uses inter-process communication (such as the Linux waitpid system call) or signal mechanisms (such as SIGCHLD) to monitor the process ID of the business control module 103. When the business control module 103 exits normally (returns an exit code) or crashes abnormally (the process disappears), the startup module 101 immediately captures the exit event and triggers the startup process of the bootstrap module 102. For example, the startup module 101 receives a signal when the child process (business control module 103) terminates, and then re-executes the startup logic of the bootstrap module 102. Process status monitoring ensures that exit events are detected in a timely manner, reducing upgrade delays; at the same time, it is implemented based on the system's native mechanisms, without introducing additional overhead, thus improving response speed.

[0037] Reference Figure 2This specification also provides a schematic diagram of a vehicle OTA program self-upgrade method, applied to an in-vehicle terminal, including: S201: In response to a system startup event, a boot module 102 is started; or, in response to an exit event of a service master control module 103, the boot module 102 is restarted; S202: When the boot module 102 is started, the system's preset storage directory is accessed to obtain the version information of the service master control module 103; based on a version comparison strategy, the target version of the service master control module 103 is called; when the boot module 102 is restarted due to the exit of the service master control module 103, if a target module with a version higher than the exited service master control module 103 is detected, the target module is loaded and executed to complete the self-upgrade; wherein, the service master control module 103 is configured to execute core OTA business logic, and when the service master control module 103 finishes running, it transmits an exit event to the startup module 101.

[0038] Regarding the methods in the above embodiments, the process of performing each step has been described in detail in the embodiments of the system, and will not be elaborated here.

[0039] Based on the same inventive concept, embodiments of this specification also provide an electronic device.

[0040] The following describes embodiments of the electronic device of the present invention, which can be considered as specific implementations of the methods and apparatus embodiments of the present invention described above. Details described in the embodiments of the electronic device of the present invention should be considered as supplements to the methods or apparatus embodiments described above; details not disclosed in the embodiments of the electronic device of the present invention can be implemented with reference to the methods or apparatus embodiments described above.

[0041] Reference Figure 3 This is a schematic diagram of an electronic device provided as an embodiment of this specification. Refer to the following... Figure 3 The electronic device 300 according to this embodiment of the present invention will be described. Figure 3 The electronic device 300 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0042] like Figure 3 As shown, the electronic device 300 is presented in the form of a general-purpose computing device. The components of the electronic device 300 may include, but are not limited to: at least one processing unit 310, at least one storage unit 320, a bus 330 connecting different device components (including storage unit 320 and processing unit 310), a display unit 340, etc.

[0043] The storage unit stores program code that can be executed by the processing unit 310, causing the processing unit 310 to perform the steps described in the processing method section of this specification according to various exemplary embodiments of the present invention. For example, the processing unit 310 can perform, for example... Figure 1 The steps are shown.

[0044] The storage unit 320 may include a readable medium in the form of a volatile storage unit, such as a random access memory unit (RAM) 3201 and / or a cache storage unit 3202, and may further include a read-only memory unit (ROM) 3203.

[0045] The storage unit 320 may also include a program / utility 3204 having a set (at least one) of program modules 3205, such program modules 3205 including but not limited to: operating devices, one or more application programs, other program modules and program data, each or some combination of these examples may include an implementation of a network environment.

[0046] Bus 330 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the various bus structures.

[0047] Electronic device 300 can also communicate with one or more external devices 400 (e.g., keyboard, pointing device, Bluetooth device, etc.), and with one or more devices that enable a user to interact with electronic device 300, and / or with any device that enables electronic device 300 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 350. Furthermore, electronic device 300 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 360. Network adapter 360 can communicate with other modules of electronic device 300 via bus 330. It should be understood that, although... Figure 3 As not shown, other hardware and / or software modules may be used in conjunction with electronic device 300, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID devices, tape drives, and data backup storage devices.

[0048] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described in this invention can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this invention can be embodied in the form of a software product, which can be stored in a computer-readable storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, or network device, etc.) to execute the method described above according to this invention. When the computer instructions are executed by a data processing device, the computer-readable medium is able to implement the method described above, i.e., as follows: Figure 1 The method shown.

[0049] Reference Figure 4 This is a schematic diagram of a computer-readable medium provided for embodiments of this specification.

[0050] accomplish Figure 1 The computer instructions of the method shown can be stored on one or more computer-readable media. A computer-readable medium can be a readable signal medium or a readable storage medium. A readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor device, or any combination thereof. More specific examples (a non-exhaustive list) of readable storage media include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof.

[0051] The computer-readable storage medium may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The readable storage medium may also be any readable medium other than a readable storage medium, capable of transmitting, propagating, or transmitting a program for use by or in connection with an instruction execution device, apparatus, or apparatus. The program code contained on the readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0052] Program code for performing the operations of this invention can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0053] In summary, the present invention can be implemented in hardware, or as software modules running on one or more processors, or a combination thereof. Those skilled in the art will understand that in practice, general-purpose data processing devices such as microprocessors or digital signal processors (DSPs) can be used to implement some or all of the functions of some or all of the components according to the embodiments of the present invention. The present invention can also be implemented as a device or apparatus program (e.g., a computer program and computer program product) for performing part or all of the methods described herein. Such programs implementing the present invention can be stored on a computer-readable medium or can be in the form of one or more signals. Such signals can be downloaded from an Internet website, provided on a carrier signal, or provided in any other form.

[0054] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the present invention is not inherently related to any specific computer, virtual device, or electronic device, and various general-purpose devices can also implement the present invention. The above descriptions are merely specific embodiments of the present invention and are not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

[0055] The various embodiments in this specification are described in a progressive manner. The same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on describing the differences from other embodiments.

[0056] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A vehicle OTA (Over-The-Air) program self-upgrade system, deployed on an in-vehicle terminal, characterized in that, The system includes: a startup module, a boot module, and a business control module; The startup module is configured to start the boot module in response to a system startup event; and is configured to start the boot module in response to an exit event of the business master control module. The boot module is configured to, in response to being started by the startup module, access a system-preset storage directory to obtain version information of the business master control module, and call the target version of the business master control module based on a version comparison strategy; and is configured to, when restarted due to the exit of the business master control module, if a target module with a version higher than the exited business master control module is detected, load and execute the target module to complete the self-upgrade; wherein, the business master control module is configured to execute core OTA business logic, and when the business master control module finishes running, transmit an exit event to the startup module.

2. The method according to claim 1, characterized in that, The guidance module is also configured to: After the business control module is called for the first time, the vehicle's characteristic attribute information is obtained through the system interface and written into a preset configuration file.

3. The system according to claim 2, characterized in that, The startup module is also configured to: After the boot module exits, the configuration file is read and parsed, and based on the parsing result and preset triggering conditions, a query request for the OTA program's own upgrade task is sent to the OTA cloud server.

4. The system according to claim 1, characterized in that, The startup module also integrates a keep-alive mechanism; The keep-alive mechanism is configured to monitor the running status of the startup module itself, and automatically restart the startup module when it is detected that the startup module has stopped running; wherein, the restarted startup module is configured to immediately perform the operation of starting the boot module.

5. The system according to claim 3, characterized in that, The preset trigger condition is a system date change event.

6. The system according to claim 1, characterized in that, The version comparison strategy is as follows: compare the version number values ​​and select the business main control module with the largest version number value for invocation.

7. The system according to claim 1, characterized in that, The startup module detects the exit event of the business main control module by monitoring the process status of the business main control module.

8. A self-upgrade method for an in-vehicle OTA program, applied to an in-vehicle terminal, characterized in that, The method includes: In response to a system startup event, a boot module is started; or, in response to an exit event of a business control module, the boot module is restarted. When the boot module is started, it accesses the system's preset storage directory to obtain the version information of the business master control module; based on the version comparison strategy, it calls the target version of the business master control module; when the boot module is restarted due to the exit of the business master control module, if a target module with a version higher than the exited business master control module is detected, the target module is loaded and executed to complete the self-upgrade; wherein, the business master control module is configured to execute core OTA business logic, and when the business master control module finishes running, it transmits an exit event to the boot module.

9. An electronic device, characterized in that, The system includes a memory and a processor, wherein the memory stores computer instructions and the processor is configured to execute the computer instructions to perform the functions of the system according to any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium stores computer instructions that are configured to perform the functions of the system according to any one of claims 1 to 7 when executed.

Images