Head-up display device and vehicle

Abstract

The present invention can reduce the possibility of erroneous use in a head-up display device in which hardware can be shared by a plurality of vehicles by changing a setting method in a vehicle. In addition, contribution is made to the sustainable development goal of 3, good health and welfare. To this end, a memory (17) stores target control software (25), which is any one of a plurality of types of control software (25) corresponding to each of a plurality of types of vehicles, and software identification information (30) for identifying the type of the target control software (25). When the head-up display device is activated, at least some of the software identification information (30), the setting identification information (31) indicating the setting method of the head-up display device in the vehicle, and the vehicle type identification information indicating the type of the vehicle are compared with each other, and on the basis of the comparison result, it is determined whether to transition to the normal operation.

Description

Technical Field

[0001] The present invention relates to a head-up display device and a vehicle equipped with the head-up display device. Background Art

[0002] Patent Document 1 discloses a head-up display device that can share various components including a housing between a right-hand drive vehicle and a left-hand drive vehicle. Specifically, the head-up display device includes a display, a flat mirror that reflects light from the display, and a concave mirror that reflects light from the flat mirror toward a windshield within the housing, and the main optical path inside the housing is set to be symmetric with respect to a reference plane.

[0003] Prior Art Documents

[0004] Patent Documents

[0005] Patent Document 1: Japanese Unexamined Patent Application Publication No. 2019-124868 Summary of the Invention

[0006] Technical Problem to be Solved by the Invention

[0007] As one of the structures of a head-up display device, a structure that can share hardware among multiple vehicles by changing its installation method in a vehicle, such as the installation direction, can be considered. In the case of using such a structure, by changing the control software according to the type of vehicle, multiple vehicles can be supported (compatible). In this specification, the head-up display device is also referred to as a HUD device.

[0008] For example, after installing the control software for a vehicle of type A, such a HUD device is shipped as a HUD device for type A and installed in a vehicle of type A. Here, in order to correctly use the HUD device, the HUD device for type A needs to be correctly installed in the vehicle of type A using the installation method for type A. However, especially when the HUD device is manually installed in a vehicle, due to human installation errors, etc., the HUD device may be misused. In addition, for example, when the control software is updated, etc., a mechanism to prevent confusion is also required.

[0009] The present invention is made in view of such a situation, and one of its purposes is to reduce the possibility of misuse in a head-up display device that can share hardware among multiple vehicles by changing its installation method in a vehicle.

[0010] The above and other objects and novel features of the present invention will be described in the description of this specification and the accompanying drawings.

[0011] Technical Means for Solving the Problem

[0012] A brief summary of representative ones among the technical solutions disclosed in this application is described below.

[0013] A representative head-up display device can share hardware among multiple types of vehicles, including a storage unit, an image display unit, and an image light projection unit. The storage unit stores object control software that is any one of multiple control softwares corresponding to multiple types of vehicles respectively, and software identification information for determining the type of the object control software. The image display unit displays an image and emits image light of the displayed image. The image light projection unit projects the image light emitted from the image display unit onto a display area, so that the projected image light is observed as a virtual image. In order to execute the object control software, when the head-up display device is started, at least a part of the software identification information, setting identification information indicating the setting method of the head-up display device in the vehicle, and vehicle type identification information indicating the type of the vehicle are compared with each other, and based on the comparison result, it is determined whether to transfer to normal operation.

[0014] In addition, a representative head-up display device can share hardware among multiple types of vehicles, including a storage unit, an image display unit, and an image light projection unit. The storage unit stores first control software corresponding to any one of multiple types of vehicles or corresponding to multiple types of vehicles in a general manner, and at least one of first software identification information or first version information for determining the type or version of the first control software. The image display unit displays an image and emits image light of the displayed image. The image light projection unit projects the image light emitted from the image display unit onto a display area, so that the projected image light is observed as a virtual image. Here, the head-up display device receives second control software, and receives at least one of second software identification information or second version information for determining the type or version of the second control software. The head-up display device determines whether to rewrite the control software of the startup object from the first control software to the second control software by comparing the first software identification information with the second software identification information or comparing the first version identification information with the second version information.

[0015] Advantages of the Invention

[0016] The effects that can be obtained by representative ones among the technical solutions disclosed in this application are briefly described below. That is, for a head-up display device that can share hardware among multiple types of vehicles by changing the setting method in the vehicle, the possibility of incorrect use can be reduced in the head-up display device. Brief Description of the Drawings

[0017] Figure 1 It is a schematic diagram showing a structural example of a vehicle equipped with the head-up display device of Embodiment 1.

[0018] Figure 2A It shows Figure 1Block diagram of a structural example of the main part of the control system responsible for control in the HUD device shown.

[0019] Figure 2B It represents Figure 1 Block diagram of a structural example of the main part different from that of the control system responsible for control in the HUD device shown. Figure 2A

[0020] Figure 3 It represents Figure 2A and Figure 2B Block diagram of a structural example of the part related to the control unit in.

[0021] Figure 4A It represents Figure 1 Schematic diagram of a structural example of the main part of the HUD device in and an example of the installation method in a vehicle.

[0022] Figure 4B It represents Figure 1 Schematic diagram of a structural example of the main part of the HUD device in and an example of the installation method different from that in Figure 4A in a vehicle.

[0023] Figure 5A It represents Figure 4A Diagram showing an example of the storage content of the memory in the HUD device shown.

[0024] Figure 5B It represents Figure 4B Diagram showing an example of the storage content of the memory in the HUD device shown.

[0025] Fig. 6A It represents Figure 2A Schematic diagram showing an example of the processing content of the control part in.

[0026] Figure 6B It represents Fig. 6A Diagram showing specific examples of the setting identification information and software identification information in.

[0027] Figure 7 It represents Figure 2A Flowchart showing an example of the processing content of the control part in.

[0028] Fig. 8A It represents Figure 7 Diagram showing specific examples of the processing content in steps S12 - S14 in.

[0029] Figure 8B It represents a diagram of specific examples different from Fig. 8A

[0030] Figure 8C It represents a diagram of specific examples different from Fig. 8A ​​Diagram of further different specific examples.

[0031] Fig.9A This is a schematic diagram showing an example of the processing content of the control unit in the head-up display device of Embodiment 2. Figure 2A This is a diagram showing an example of the storage content of the memory in.

[0032] Fig. 9B This is a diagram showing Fig.9A This is a diagram showing an example of the storage content of the memory in.

[0033] Fig.10 This is a flowchart showing an example of the processing content when the control unit starts up in the head-up display device of Embodiment 2. Figure 2A This is a flowchart showing an example of the processing content during the normal operation of the control unit in the head-up display device of Embodiment 2.

[0034] Fig.11A This is a flowchart showing an example of the processing content during the normal operation of the control unit in the head-up display device of Embodiment 2. Figure 2A This is a flowchart showing an example of the processing content in the display processing (step S34) in.

[0035] Fig. 11B This is a diagram showing Fig.11A This is a flowchart showing an example of the processing content in the display processing (step S34) in.

[0036] Fig. 12A This is a supplementary explanatory diagram for explaining Fig. 11B This is a supplementary explanatory diagram for explaining an example of a part of the processing content in.

[0037] Fig. 12B This is a supplementary explanatory diagram for explaining Fig. 11B This is a supplementary explanatory diagram for explaining an example of a part of the processing content in.

[0038] Fig.13 This is a schematic diagram showing an example of the structure of a system including the head-up display device of Embodiment 3.

[0039] Fig.14 This is a diagram showing Fig.13 This is a diagram showing an example of the screen displayed on the display of an external device in.

[0040] Fig.15A This is a schematic diagram showing an example of the usage method of the memory when rewriting the control software.

[0041] Fig. 15B This is a schematic diagram showing an example of the usage method of the memory when rewriting the control software.

[0042] Fig.16A This is a diagram showing the difference from Fig.15A and Fig. 15B This is a schematic diagram showing an example of the usage method of a different memory.

[0043] Fig. 16B This is a diagram showing the difference from Fig.15A and Fig. 15B Schematic diagram of an example of the usage method of different memories.

[0044] Fig.17 It is a schematic diagram showing an example of the operation when rewriting the control software in the head-up display device of Embodiment 4.

[0045] Fig.18 It is a flowchart showing an example of the schematic processing content when rewriting the control software in the head-up display device of Embodiment 4.

[0046] Fig.19A It is a flowchart showing an example of the detailed processing content when rewriting the control software in the head-up display device of Embodiment 4.

[0047] Fig.19B It is showing Fig.19A An example of the subsequent detailed processing content of

[0048] Fig. 20 It is showing Fig.19A A flowchart of a modified example of the process shown in

[0049] Fig.21 It is a schematic diagram showing an example of the operation when rewriting the control software in the head-up display device of Embodiment 5.

[0050] Fig. 22 It is a flowchart showing an example of the detailed processing content when rewriting the control software in the head-up display device of Embodiment 5, and is Fig.19A or Fig. 20 The subsequent flowchart of

[0051] Fig.23 It is showing the processing content based on the Fig.9A Shared control software shown in an example of a flowchart in the head-up display device of Embodiment 6.

[0052] Fig.24A It is for explaining Fig.23 The supplementary explanatory diagram of the processing content shown in

[0053] Fig. 24B It is for explaining Fig.23 The supplementary explanatory diagram of the processing content shown in

[0054] Fig.25A It is showing the processing content different from Fig.9A Based on the shared control software shown in an example of a flowchart in the head-up display device of Embodiment 6. Fig.23 A flowchart of an example of the processing content.

[0055] Fig.25B It is showing Fig.25AFlowchart of subsequent processing content

[0056] Fig.26A is used to illustrate Fig.25A and Fig.25B Supplementary explanatory diagram of part of the processing content in

[0057] Fig.26B is used to illustrate Fig.25A and Fig.25B Supplementary explanatory diagram of part of the processing content in Detailed implementation manners

[0058] The following will describe in detail the implementation manners of the present invention based on the accompanying drawings. In addition, in all the drawings used to illustrate the implementation manners, the same reference numerals are generally assigned to the same components, and their repeated descriptions are omitted.

[0059] (Embodiment 1)

[0060] <Overview of HUD device>

[0061] Figure 1 It is a schematic diagram showing a structural example of a vehicle equipped with the head-up display device of Embodiment 1. Figure 1 The head-up display (HUD) device 1 shown is mounted in a vehicle 2 which is one of the means of transportation. The vehicle 2 is typically an automobile, but is not limited thereto, and may also be a rail vehicle or the like. In addition, the means of transportation is not limited to a vehicle, and may also be an aircraft or the like. For example, a control unit 21 called an ECU (Electronic Control Unit) is mounted in the vehicle 2.

[0062] The control unit 21 obtains vehicle information 4 from various sensors and navigation devices provided in each part of the vehicle 2, for example. The various sensors detect various events occurring in the vehicle 2 and various parameter values regarding the driving condition, for example. The HUD device 1 obtains the vehicle information 4 obtained by the control unit 21 using CAN (Controller Area Network) communication or the like, for example.

[0063] The vehicle information 4 includes, for example, the speed information, gear information, steering wheel steering angle information, lamp illumination information, external light information, distance information, infrared information, engine on / off information, in-vehicle and out-of-vehicle camera image information, acceleration gyroscope information, GPS (Global Positioning System) information, navigation information, vehicle-to-vehicle communication information, and road-to-vehicle communication information of the vehicle 2. The GPS information also includes information such as the current time. In addition, the vehicle information 4 also includes various warning information. Based on such vehicle information 4, the HUD device 1 projects image light onto a display area such as the windshield 3. Thereby, the HUD device 1 enables a user such as a driver to observe the image light projected onto the display area as a virtual image, specifically, as a virtual image superimposed on the scenery in front of the vehicle 2.

[0064] Figure 2A It represents Figure 1 A block diagram showing a structural example of the main part in the HUD device shown. Figure 2A The HUD device 1 shown includes a mirror drive unit 14, a display drive unit 15, a communication unit 16, a storage unit 17, and a control unit 20 that are connected to each other via a bus 13. In addition, the display drive unit 15 drives the image display unit 11, and the mirror drive unit 14 drives the mirror M1. The image display unit 11 is, for example, a liquid crystal display including a light source and a display panel. The display panel displays an image by modulating the backlight irradiated from the light source for each pixel based on image data. In this case, the display drive unit 15 can be implemented by an LCD drive circuit or the like. Hereinafter, the storage unit 17 will be described as a memory.

[0065] The mirror M1 functions as an image light projection unit, and by projecting the image light emitted from the image display unit 11 onto the display area on the windshield 3, the projected image light is observed as a virtual image by the user. The communication unit 16 is implemented by a communication interface circuit or the like. The communication unit 16 receives or transmits various information to and from the control unit 21 using CAN communication or the like. That is, information can be bidirectionally transmitted and received between the control unit 21 and the communication unit 16. One of its functions is that the communication unit 16 functions as an information acquisition unit and acquires or receives vehicle information 4, which is information about a vehicle, from the control unit 21. The communication unit 16 transmits the acquired vehicle information 4 to the control unit 20 or the memory 17 via the bus 13.

[0066] The memory 17 is composed of a combination of a volatile memory and a non-volatile memory. The memory 17 stores, for example, a control program used in the control unit 20, in other words, control software, data, and the like. The control unit 20 is implemented by a processor such as a CPU (Central Processing Unit) or a GPU (Graphics Processing Unit), for example. The control unit 20 executes the control software stored in the memory 17 to control the entire HUD device 1 including the display content in the image display unit 11.

[0067] One of its controls is that the control unit 20 controls the mirror drive unit 14 and the display drive unit 15 via the bus 13. The mirror drive unit 14 adjusts the setting angle of the mirror M1 accordingly according to a signal or command from the control unit 20. The mirror drive unit 14 can be implemented by a motor for adjusting the setting angle of the mirror M1 and a motor drive circuit for driving the motor, etc. In addition, the control unit 20 generates image data based on the acquired vehicle information 4 and the like, and stores the image data in the memory 17. The display drive unit 15 reads the image data stored in the memory 17 via the bus 13 and drives the image display unit 11 based on the image data.

[0068] In addition, Figure 2A The communication unit 16, the memory 17, and the control unit 20 shown, for example, can be mounted in a microcontroller or the like. However, the implementation method of the HUD device 1 is not limited to such a method using a microcontroller, and can also be a method of appropriately combining an FPGA (Field Programmable Gate Array) or an ASIC (Application Specific Integrated Circuit), etc.

[0069] Figure 2B It represents Figure 1 In the HUD device shown, it is a block diagram of a structural example of the main part different from Figure 2A that shown. Figure 2B The HUD device 1 shown is different from the structural example shown in Figure 2A In this case, instead of setting the control unit 20, it has a communication processing unit 16a. In this case, for example, the control unit 21 generates image data instead of the control unit 20 shown in Figure 2A and stores the generated image data in the memory 17 via the communication processing unit 16a.

[0070] In addition, Figure 2B In the case of the structural example shown, the communication processing unit 16a can have the functions of the control unit 20 shown in Figure 2A For example, the control function of the mirror drive unit 14, etc. Or, the control unit 21 and the communication processing unit 16a can also appropriately share Figure 2A The functions of the control unit 20 shown. The communication processing unit 16a is different from Figure 2A the communication unit 16 shown. It receives information about the vehicle from the control unit 21 using CAN communication or the like, processes the received information, and notifies the processing result to the mirror drive unit 14 and the display drive unit 15. Figure 2B Between the communication processing unit 16a and the control unit 21, information can be bidirectionally transmitted and received.

[0071] Figure 3 It represents Figure 2A and Figure 2B A block diagram showing a structural example of the part related to the control unit in. The control unit 21 mainly obtains the vehicle information 4 as described Figure 1 below. The vehicle information 4 is generated by information acquisition devices such as various sensors connected to the control unit 21 as shown Figure 3 below. Figure 3 An example of such an information acquisition device is shown in.

[0072] In Figure 3 , for example, the vehicle speed sensor 101 detects Figure 1 the speed of the vehicle 2, and generates speed information as the detection result. The gear position sensor 102 detects the current gear position and generates gear position information as the detection result. The steering wheel steering angle sensor 103 detects the current steering wheel steering angle and generates steering wheel steering angle information as the detection result. The headlight sensor 104 detects the on / off of the headlight and generates light illumination information as the detection result. The illuminance sensor 105 and the chromaticity sensor 106 detect the external light and generate external light information as the detection result.

[0073] The distance measuring sensor 107 detects the distance between the vehicle 2 and an external object and generates distance information as the detection result. The infrared sensor 108 detects the presence and distance of an object at a short distance from the vehicle 2 and generates infrared information as the detection result. The engine start sensor 109 detects the on / off of the engine and generates on / off information as the detection result. The acceleration sensor 110 and the gyro sensor 111 respectively detect the acceleration and angular velocity of the vehicle 2, and as the detection result, generate acceleration gyro information indicating the attitude and behavior of the vehicle 2. The temperature sensor 112 detects the temperature inside and outside the vehicle and generates temperature information as the detection result.

[0074] The in-vehicle-to-road communication wireless receiver 113 generates in-vehicle-to-road communication information through vehicle-to-road communication between the vehicle 2 and roads, signs, traffic lights, etc. The vehicle-to-vehicle communication wireless receiver 114 generates vehicle-to-vehicle communication information through vehicle-to-vehicle communication between the vehicle 2 and other surrounding vehicles. The in-vehicle camera 115 and the out-vehicle camera 116 generate in-vehicle captured image information and out-vehicle captured image information respectively by capturing the inside and outside of the vehicle. The in-vehicle camera 115 is, for example, a camera for DMS (Driver Monitoring System) that captures the posture, eye position, actions, etc. of the user, i.e., the driver. In this case, by analyzing the captured images, the fatigue condition of the driver, the position of the line of sight, etc. can be grasped.

[0075] On the other hand, the out-vehicle camera 116 captures the surrounding conditions such as the front and rear of the vehicle 2, for example. In this case, by analyzing the captured images, the presence or absence of obstacles such as other vehicles and people in the vicinity, buildings and terrain, road conditions such as rain, snow accumulation, icing, unevenness, etc., and road signs can be grasped. In addition, the out-vehicle camera 116 may include, for example, a driving recorder that records the driving conditions using images.

[0076] The GPS receiver 117 generates GPS information obtained by receiving GPS signals. For example, the current time can be obtained using the GPS receiver 117. The VICS (Vehicle Information and Communication System, registered trademark) receiver 118 generates VICS information obtained by receiving VICS signals. The GPS receiver 117 and the VICS receiver 118 can be provided as part of a navigation device.

[0077] In addition, regarding Figure 3 the various information acquisition devices shown, other types of devices can be appropriately deleted or added, or replaced with other types of devices. In addition, in addition to acquiring the vehicle information 4 from the various information acquisition devices shown in Figure 3 the control unit 21 can sometimes also acquire information on the type of the vehicle 2, for example, information on whether it is a truck, a passenger car, a minivan, etc.

[0078] <Regarding the Structure and Installation Method of the HUD Device>

[0079] The HUD device 1 of the embodiment can share hardware by multiple vehicles 2 by changing the installation method or installation state in a vehicle, for example, the vehicle 2. Figure 4A It represents Figure 1A schematic diagram of a structural example of the main part of the HUD device in [description], and an example of a method of installation in a vehicle. In FIGS. 4 and the like, with respect to the driver of the vehicle 2, the horizontal direction is the left-right direction, the transverse direction of the vehicle, or the width direction of the vehicle, and the vertical direction is the up-down direction of the vehicle, the longitudinal direction, and the horizontal direction orthogonal to the transverse direction of the vehicle is the front-rear direction or the traveling direction of the vehicle.

[0080] Figure 4B It represents Figure 1 A structural example of the main part of the HUD device in [description], and Figure 4A An example of a different installation method in a vehicle. Figure 4A It shows an installation method in vehicle types with a relatively large inclination of the windshield 3 with respect to the horizontal plane (such as trucks, vans, or some rail vehicles, etc.). On the other hand, Figure 4B It shows an installation method in vehicle types (such as passenger cars, etc.) with a smaller inclination of the windshield 3 than that of Figure 4A trucks and the like.

[0081] Figure 4A and Figure 4B The HUD device 1 shown in [description] and [description] commonly include an image display unit 11 housed in the housing 12, a lens LS, a mirror M1, a mirror drive unit 14, etc. The image display unit 11 may not be entirely housed in the housing 12, but only the display panel. The image display unit 11 is, for example, an LCD (Liquid Crystal Display), an organic EL display, or a projector, etc., displays an image obtained based on input image data, and emits the image light of the displayed image to the mirror M1.

[0082] The lens LS, in other words, the optical element is inserted in the optical path from the image display unit 11 to the mirror M1, for example, for adjusting the diffusion of the image light. The lens LS may not be configured. The mirror M1 functions as an image light projection unit as described above. The image light projection unit in the embodiment, i.e., the mirror M1, causes the image light emitted from the image display unit 11 and incident via the lens LS to be projected onto the display area 5 on the windshield 3 through the opening 7 provided on the housing 12 and the opening provided on the instrument panel 10. Thus, the image light projection unit enables the projected image light to be observed as a virtual image by the user 6.

[0083] Specifically, the mirror M1 is, for example, a concave mirror, i.e., a magnifying glass, which reflects and magnifies the incident image light and projects it onto the display area 5 through the opening 7. The image light projected onto the display area 5 is reflected on the display area 5 and enters the eyes of the user 6. As a result, the user 6 observes the virtual image 9 located in front of the transparent windshield 3 in a form superimposed on the scenery outside the vehicle (roads, buildings, people, etc.). The information represented by the virtual image 9 includes, for example, various information based on the vehicle information 4, such as road signs, the current speed of the vehicle itself, and various information attached to the objects in the scenery, i.e., AR (Augmented Reality) information, etc.

[0084] In addition, the mirror M1 can be, for example, a free-form mirror, a mirror with an asymmetric optical axis shape, etc. In addition, a mirror drive unit 14 is provided for the mirror M1. The mirror drive unit 14 variably adjusts the setting angle of the mirror M1. Specifically, the mirror drive unit 14 includes, for example, an electric motor, and rotates the mirror M1 through the rotational movement of the electric motor. By variably adjusting the setting angle of the mirror M1, the position of the display area 5 on the windshield 3 can be adjusted, that is, the vertical position of the virtual image observed by the user 6.

[0085] Furthermore, by variably adjusting the setting angle of the mirror M1, the image display unit 11 can be protected from sunlight. Specifically, sunlight may travel in the reverse direction on the optical path of the image light and enter the image display unit 11. For example, Figure 2A the shown control unit 20 can, when it is determined that the possibility of damage to the image display unit 11 due to sunlight incidence is relatively high, change the setting angle of the mirror M1 via the mirror drive unit 14 so that the sunlight does not reach the image display unit 11.

[0086] Here, in Figure 4A the shown vehicle types such as trucks, the HUD device 1 is set such that the emission direction of the image light from the image display unit 11 is the first direction (in this example, the backward direction) under the vehicle coordinate axes. On the other hand, in Figure 4B the shown vehicle types such as passenger cars, the HUD device 1 is set such that the emission direction of the image light from the image display unit 11 is the second direction, which is the direction opposite to the first direction (in this example, the forward direction) under the vehicle coordinate axes. In this way, the HUD device 1 of the embodiment can be shared by multiple vehicles by changing the setting method in the vehicle, such as the setting direction.

[0087] Figure 5A is a diagram showing Figure 4A an example of the storage content of the memory in the shown HUD device. Figure 5B is a diagram showing Figure 4BFigure showing an example of the stored content of the memory in the HUD device shown. Figure 5A The HUD device 1 shown stores the control software 25a for trucks in the memory 17. On the other hand, Figure 5B The HUD device 1 shown stores the control software 25b for passenger cars in the memory 17.

[0088] In this way, Figure 4A and Figure 4B The HUD device 1 shown can support (be compatible with) multiple vehicles 2 on the basis of shared hardware by changing the setting method in the vehicle 2 and changing the control software accordingly according to the vehicle type. Thus, the manufacturing cost of the HUD device 1 can be reduced, etc.

[0089] On the other hand, such a HUD device 1 is shipped, for example, in the state where the control software 25a and 25b for each vehicle type are installed as shown in Figure 5A and Figure 5B shown, and is set in the corresponding vehicle by using the setting methods shown in Figure 4A and Figure 4B shown, for example, in the production process of the vehicle 2, etc. However, especially in the production process of the vehicle 2, etc., when the HUD device 1 is manually set in the vehicle 2, human setting errors may occur. As a result, there is a risk that the HUD device 1 is misused.

[0090] As a specific example, the HUD device 1 may be set in the wrong direction, i.e., the direction shown in Figure 4A shown, in the truck shown in Figure 4B shown. At this time, the control software 25a for trucks may be installed in the HUD device 1, or the control software 25b for passenger cars may be installed. That is, a situation where the setting method of the HUD device 1 is incorrect and the control software is correct or incorrect may occur. Or, the HUD device 1 equipped with the control software 25a for trucks shown in Figure 5A may be set in the direction shown in Figure 4B shown in a passenger car. That is, a situation where the setting method of the HUD device 1 is correct but the control software is incorrect may occur.

[0091] <Details of the control unit>

[0092] For this reason, the control unit 20 performs the following processing, for example. Fig. 6A is a schematic diagram showing an example of the processing content of the control unit in Figure 2A shown. Figure 6B is a schematic diagram showing an example of the processing content of the control unit in Fig. 6AFigure showing specific examples of the setting identification information and the software identification information. First, as a prerequisite, the setting identification information 31 is pre-registered, which represents the setting method or setting state used when the HUD device 1 is set in the vehicle 2 during the production process of the vehicle 2, such as the setting direction. The setting identification information 31 can be built into the HUD device 1 or manually registered separately by an operator or the like. The setting identification information 31 is in a state where it can be read from the control unit 20 or the vehicle control unit 21. In addition, the comparison and determination are made in the control unit 20 of the signal acquisition target regarding the identification information or in the communication processing unit 16a of Figure 2A or in the control unit 20 of Figure 2B or in the vehicle control unit 21, but the specific processing other than this is the same. The following description uses the setting identification information 31 that can be read from the control unit 20.

[0093] Fig. 6A In the example shown, the setting identification information 31 is stored in the memory 17 or the register mapped to the memory 17. However, the setting identification information 31 only needs to be registered in a state where it can be read from the control unit 20 and does not need to be stored in the memory 17. For example, it is also possible to adopt a method in which a mechanical switch for registering the setting identification information 31, specifically a DIP switch or the like, is provided in the HUD device 1, and the state of the mechanical switch is read from the control unit 20 connected to the mechanical switch.

[0094] In addition, as described above, the memory 17 stores the control software 25. In this specification, the software is also referred to as SW. The control software 25 includes SW identification information 30 for determining its own type from various control softwares 25 such as for trucks and passenger cars. When the HUD device 1 is started, the control unit 20 compares the SW identification information 30 stored in the memory 17 with the setting identification information 31. If they match, it transfers to the normal operation. If they do not match, it does not transfer to the normal operation but outputs an error.

[0095] The SW identification information 30 and the setting identification information 31 are as Figure 6B shown. In the case where there are two types of vehicle types, they have a length of at least 1 bit. In this example, the SW identification information 30 is "0" when the control software 25 is for trucks and "1" when it is for passenger cars. In addition, the setting identification information 31 is registered as "0" when the HUD device 1 is set in the direction shown in Figure 4A and registered as "1" when it is set in the direction shown in Figure 4B .

[0096] In addition, here, in order to distinguish between two types of vehicles, each identification information is represented by 1 bit. However, for example, if a state where the setting identification information 31 is not registered is added, that is, a state where the operator forgets to register the setting identification information 31, in order to distinguish these three states, each identification information can be represented by 2 bits or the like.

[0097] Figure 7 represents Figure 2A An example of the processing content of the control unit in Fig. 8A , Figure 8B and Figure 8C represents Figure 7 A specific example of the processing content in steps S12 to S14 in Figure 7 In , when the HUD device 1 is started, the control unit 20 first establishes communication with the outside of the HUD device 1 via the communication unit 16 or the like (step S11). Next, the control unit 20 acquires various identification information (step S12). Then, the control unit 20 compares the acquired various identification information (step S13) and performs an action corresponding to the comparison result (step S14).

[0098] Fig. 8A In the example shown in , as various identification information, the control unit 20 acquires Fig. 6A and Figure 6B the SW identification information 30 and the setting identification information 31 shown in (step S12). Then, when the SW identification information 30 matches the setting identification information 31 (step S13), the control unit 20 does not output an error but transfers to the normal operation (step S14, Fig. 8A No. 1 in ). When the SW identification information 30 matches the setting identification information 31, it is highly likely that the HUD device 1 with the correct control software 25 installed is set correctly. For this reason, in this case, it transfers to the normal operation, for example, displaying vehicle information 4 or the like on the image display unit 11.

[0099] On the other hand, when the SW identification information 30 does not match the setting identification information 31 (step S13), the control unit 20 does not transfer to the normal operation but outputs an error [1] indicating that these two identification information do not match (step S14, Fig. 8A No. 2 in ). Specifically, the control unit 20 externally notifies the error [1] to the control unit 21 or the like via the communication unit 16 using a notification message or sound, or stores it in the memory 17 as an error log.

[0100] In the case where the SW identification information 30 and the setting identification information 31 do not match, there is a high possibility that the wrong control software 25 is installed in the HUD device 1, or the HUD device 1 is set in the wrong way. As a result, the possibility of the HUD device 1 being misused increases. Therefore, in this case, it does not transfer to the normal operation.

[0101] Figure 8B In the example shown, as various identification information, the control unit 20 acquires vehicle type identification information indicating the type of the vehicle 2 such as a truck or a passenger car and the SW identification information 30 (step S12). Then, when the vehicle type identification information and the SW identification information 30 match (step S13), instead of outputting an error, it transfers to the normal operation (step S14, Figure 8B No. 1 in).

[0102] In this way, there are cases where the HUD device 1 can acquire vehicle type identification information through communication with the outside. Specifically, there are cases where the HUD device 1 can acquire vehicle type identification information from the control unit 21 via the communication unit 16, or can acquire vehicle type identification information from an external mobile terminal such as a smart phone via a separately provided wired communication unit or wireless communication unit. The wired communication unit or wireless communication unit is, for example, a USB interface, a wireless LAN interface, a Bluetooth (registered trademark) interface, etc. The communication unit 16, the wired communication unit or the wireless communication unit functions as an information acquisition unit for acquiring vehicle type identification information.

[0103] In this way, the vehicle type identification information acquired from the outside of the HUD device 1 can be regarded as correct information. Therefore, when the vehicle type identification information and the SW identification information 30 match, it can be at least judged that the combination of the vehicle 2 and the product itself of the HUD device 1 is correct. Therefore, in this case, it transfers to the normal operation.

[0104] On the other hand, when the vehicle type identification information and the SW identification information 30 do not match (step S13), instead of transferring to the normal operation, the control unit 20 outputs an error indicating that the two identification information do not match [2] (step S14, Figure 8B No. 2 in). When the vehicle type identification information and the SW identification information 30 do not match, it can be judged that the combination of the vehicle 2 and the product itself of the HUD device 1 is incorrect. Therefore, in this case, it does not transfer to the normal operation.

[0105] Figure 8CIn the example shown, the control unit 20 obtains the vehicle type identification information, the SW identification information 30, and the setting identification information 31 as various identification information (step S12). Then, when the three pieces of identification information are consistent (step S13), the control unit 20 does not output an error but transfers to normal operation (step S14, Figure 8C No. 1 in the article).

[0106] In addition, when the vehicle type identification information and the SW identification information 30 are consistent, but the vehicle type identification information and the setting identification information 31 are inconsistent (step S13), the control unit 20 shifts to normal operation and outputs an error [3] indicating that only the setting identification information 31 is inconsistent (step S14, Figure 8C No. 2 in the figure). That is, in this case, as described above, at least the combination of the vehicle 2 and the HUD device 1 itself can be determined to be correct. However, there is a possibility that the setting method is wrong, or the operator may have made a mistake in registering the setting identification information 31. Therefore, in this case, the normal operation is transferred and an error output is performed.

[0107] In addition, when the vehicle type identification information and the SW identification information 30 do not match (step S13), the control unit 20 sets the vehicle type identification information to the same level as the SW identification information 31. Figure 8B In the same way, the process does not transfer to the normal operation but outputs an error (step S14, Figure 8C 3, No. 4 in ). At this time, when the vehicle type identification information and the setting identification information 31 are consistent, the control unit 20 outputs an error [4] indicating this situation ( Figure 8C 3), when the vehicle type identification information and the setting identification information 31 are inconsistent, an error indicating this situation is output [5] ( Figure 8C No. 4 in the article).

[0108] like Figure 8C As shown, in addition to the comparison between the vehicle type identification information and the SW identification information 30, the vehicle type identification information is also compared with the setting identification information 31, thereby comparing with Figure 8B Unlike the case of , it is possible to verify whether the HUD device 1 can be used correctly, including the setting method. Figure 8B Compared with the case where the two identification information are the same, Figure 8C When all three pieces of identification information are consistent, the reliability of being able to correctly use the HUD device 1 is higher.

[0109] <Main effects of embodiment 1>

[0110] As described above, in the manner of Embodiment 1, on the premise of the HUD device 1 capable of sharing hardware by multiple vehicles by changing the setting method in the vehicle, by comparing at least a part of the SW identification information 30, the setting identification information 31, and the vehicle type identification information with each other, the correctness of the control software 25 and / or the setting method can be verified. Then, when it is inferred from the comparison result that the control software 25 and / or the setting method is correct, the normal operation is transferred to. As a result, the possibility of the HUD device 1 being misused can be reduced.

[0111] (Embodiment 2)

[0112] <Details of the control unit>

[0113] Fig.9A It shows the head-up display device in Embodiment 2, Figure 2A It is a schematic diagram showing an example of the processing content of the control unit in. Fig. 9B It shows Fig.9A It is a diagram showing an example of the stored content of the memory in. Fig.9A Different from the case of Embodiment 1, the HUD device 1 shown stores a plurality of control softwares corresponding to a plurality of vehicles 2 respectively as the shared control software 25c.

[0114] The shared control software 25c has a general part 35 independent of the vehicle type and a dedicated part for each vehicle type, here a truck dedicated part 36a and a passenger car dedicated part 36b. Which of the truck dedicated part 36a and the passenger car dedicated part 36b is to be executed is selected according to the operation mode 37. That is, the control unit 20 selects any one of the plurality of control softwares based on the setting information of the operation mode 37 and executes the selected control software, thereby controlling the entire HUD device 1. By using such a shared control software 25c, the HUD device 1 can be shared by multiple vehicles not only including hardware but also software, and the product cost etc. can be further reduced.

[0115] In addition, as shown in Fig. 9B the memory 17 stores, in addition to the shared control software 25c, the setting identification information 31 as described in Fig. 6A and Figure 6B . Different from the case of Fig. 6A , the shared control software 25c does not include the SW identification information 30. Here, the control unit 20 compares the vehicle type identification information described in Figure 8B with the setting identification information 31 substantially when the HUD device 1 is started (preferably at the first start). Then, when the two identification information is consistent, the control unit 20 sets the operation mode 37 corresponding to the consistent identification information and transfers to the normal operation, and when they are inconsistent, it does not transfer to the normal operation but outputs an error.

[0116] Fig.10 This is a flowchart showing an example of the processing content when the control unit in the head-up display device of Embodiment 2 is started. Figure 2A In it, when the control unit 20 starts the HUD device 1 (preferably at the first start), via the information acquisition unit, i.e., the communication unit 16 or Fig.10 the wired communication unit, wireless communication unit, etc. mentioned above, establish communication with the outside of the HUD device 1 (step S21). Figure 8B Then, the control unit 20 acquires vehicle type identification information from the outside (step S22), and further reads the setting identification information 31 from the memory 17, etc. (step S23). Then, the control unit 20 determines whether the vehicle type identification information and the setting identification information 31 are consistent (step S24). When these two identification information are consistent (step S24: "Yes"), the control unit 20 sets the operation mode 37 corresponding to the consistent identification information to the storage area referred to by the common control software 25c (step S25). After that, the control unit 20 transfers to

[0117] the normal operations shown in Fig.11A and Fig. 11B On the other hand, when the vehicle type identification information and the setting identification information 31 are inconsistent (step S24: "No"), the control unit 20 does not set the operation mode 37 or saves information indicating that the operation mode 37 cannot be set in the storage area, and outputs an error indicating that the setting identification information 31 is incorrect (step S26). In this case, the control unit 20 does not transfer to the normal operation.

[0118] In addition, in step S25, the control unit 20 preferably saves the setting information of the operation mode 37 in a non-volatile storage area, such as the non-volatile memory contained in the memory 17. In this case, when the HUD device 1 is started for the second time and later, there is no need to execute

[0119] the process shown in Fig.10 Instead, it is only necessary to refer to the setting information of the operation mode 37 saved in the non-volatile storage area in the common control software 25c. In this way, when the HUD device 1 is started for the second time and later, by omitting Fig.10 the process shown in

[0120] In addition, Fig.10In the example shown, when the vehicle type identification information matches the setting identification information 31, the control unit 20 sets the operation mode 37. However, it is not limited to this. For example, the control unit 20 can also set the operation mode 37 based only on the vehicle type identification information. However, in this case, since the HUD device 1 may not be set correctly, it is more preferable to use the Fig.10 flow shown.

[0121] Furthermore, the control unit 20 can also set the operation mode 37 based only on the setting identification information 31. For example, this method can be used when the vehicle type identification information cannot be obtained. However, since the HUD device 1 may not be set correctly and the setting identification information 31 may not be registered correctly, when the vehicle type identification information can be obtained, it is more preferable to use the Fig.10 flow shown.

[0122] <Normal operation of the control unit>

[0123] Fig.11A This is a flowchart showing an example of the processing content during the normal operation of the control unit in the head-up display device of Embodiment 2. Figure 2A This is a flowchart showing an example of the processing content in the display processing (step S34) in Fig. 11B This is a flowchart showing Fig.11A an example of the processing content in the display processing (step S34) in Fig. 12A and Fig. 12B are supplementary explanatory diagrams for explaining a part of the processing content in Fig. 11B This is a supplementary explanatory diagram for explaining a part of the processing content in

[0124] Fig.11A In this case, the control unit 20 first obtains the setting information of the operation mode 37 from a predetermined storage area (preferably a non-volatile storage area) (step S31). Although not shown here, when the control unit 20 fails to obtain the setting information of the operation mode 37 in Fig.10 step S26 in this case, and when the operation mode 37 is not set, the processing ends. On the other hand, when the control unit 20 successfully obtains the setting information of the operation mode 37, the processing of steps S32 to S34 is repeatedly executed in a predetermined processing cycle until a display end request is input (step S35).

[0125] In this loop processing, the control unit 20 first obtains the vehicle information 4 from the control unit 21 via the communication unit 16 (step S32). Then, based on the obtained vehicle information 4, the control unit 20 determines the display content to be displayed on the image display unit 11 and generates image data based on the determined display content (step S33). Then, the control unit 20 performs display processing using the generated image data (step S34).

[0126] In the display process (step S34), as Fig. 11B shown, the control unit 20 first determines the operation mode 37 obtained in step S341. In the case of the truck mode, it transfers to step S342, and in the case of the passenger car mode, it transfers to step S346. When the operation mode 37 is the truck mode, the control unit 20 determines whether the generated image data is for a truck (step S342). When the image data is for a truck (step S342: "Yes"), the control unit 20 transfers to step S343. When it is for a passenger car (step S342: "No"), it transfers to step S343 via step S345.

[0127] In step S345, the control unit 20 performs left - right flipping processing of the display content or additionally performs up - down flipping processing. Fig. 12A An example of the relationship between the display content of the image display unit 11 and the display content observed by the user 6 in the HUD device 1 provided in a truck is shown. Fig. 12B An example of the relationship between the display content of the image display unit 11 and the display content observed by the user 6 in the HUD device 1 provided in a passenger car is shown.

[0128] For example, in the Fig. 12A shown installation state, the display surface of the display panel of the image display unit 11 is in a directly facing relationship with the eyes of the user 6. That is, the emission direction of the image light emitted from the display surface of the display panel of the image display unit 11 is opposite to the advancing direction of the vehicle 2. Therefore, the image displayed on the display surface of the display panel of the image display unit 11 can be observed by the user 6 in its original orientation. On the other hand, in the Fig. 12B shown installation state, the back surface of the image display unit 11 is in a directly facing relationship with the eyes of the user 6. That is, the emission direction of the image light emitted from the display surface of the display panel of the image display unit 11 is the same as the advancing direction of the vehicle 2. Therefore, the image displayed on the display surface of the image display unit 11 is observed by the user 6 in a left - right flipped orientation. For this reason, the control unit 20, as Fig. 12B shown, displays a pre - left - right - flipped image on the image display unit 11.

[0129] Based on such a relationship, the control unit 20 performs left - right flipping processing of the display content in Fig. 11B step S345. Specifically, when a left - right flipping mechanism is provided in the display driving unit 15 or the image display unit 11, the control unit 20 uses this mechanism. When no left - right flipping mechanism is provided, the image data is processed in a left - right flipped manner and then stored in the memory 17.

[0130] Next, in step S343, the control unit 20 performs distortion correction processing for the truck. That is, in the image observed by the user 6, distortion may occur corresponding to the shape of the windshield 3 of the truck or the like. The control unit 20 processes the image data in a manner that pre-corrects such distortion. After that, the control unit 20 uses the distortion-corrected image data to cause the image display unit 11 to update the display content (step S344).

[0131] On the other hand, when the operation mode 37 is the passenger car mode, in the same manner as in the case of the truck mode, the control unit 20 determines whether the generated image data is for the truck (step S346). When the image data is for the truck (step S346: "Yes"), after performing left-right flipping processing of the display content (step S347), the control unit 20 proceeds to step S348. When the image data is for the passenger car (step S346: "No"), the control unit 20 directly proceeds to step S348. Then, the control unit 20 performs distortion correction processing for the passenger car based on the shape of the windshield 3 of the passenger car or the like (step S348), and after that, causes the image display unit 11 to update the display content (step S344).

[0132] In this way, in the common control software 25c, for each type of vehicle 2, at least the specifications of the orientation of the image displayed on the image display unit 11 and the processing content for distortion correction of the image are different. Moreover, these differences are reflected in Fig.9A the shown truck-specific part 36a and passenger car-specific part 36b. In addition, in the general part 35, for example, the processing content when generating image data based on the vehicle information 4 is specified.

[0133] <Main effects of Embodiment 2>

[0134] By using the above-described Embodiment 2, the same effects as those described in Embodiment 1 can also be obtained. Furthermore, by using the common control software 25c, it is possible to further reduce product costs and the like.

[0135] (Embodiment 3)

[0136] <Regarding the engineering mode>

[0137] For example, as Fig. 8A , Figure 8B , Figure 8C or Fig.10As shown, when there is a mismatch among the vehicle type identification information, the SW identification information 30, and the setting identification information 31, the control unit 20 basically does not transfer to the normal operation, but outputs an error to the control unit 21 and the like. On the other hand, in such a case, it is desirable to be able to adopt some means for error analysis and error countermeasures including cause investigation. For this purpose, an engineering mode is set here as an operation mode for analysis executed by the control unit 20. Specifically, the control unit 20 operates in the engineering mode by, for example, executing a program for the engineering mode stored in the memory 17.

[0138] When outputting an error, the control unit 20 can automatically transfer to the engineering mode together, or can only prompt the transfer to the engineering mode. Alternatively, the control unit 20 can also transfer to the engineering mode when an engineer makes a special operation input via the operation buttons of the vehicle 2. At this time, limiting conditions can be added, for example, the special operation input is made only when a certain menu is displayed. In addition, the operation input is not limited to the operation buttons of the vehicle 2. For example, it can also be input by voice, or input from an external device additionally connected to the HUD device 1.

[0139] After the control unit 20 transfers to the engineering mode, it can execute the following processing, for example.

[0140] · Force the normal operation even when the conditions for transferring to the normal operation are not satisfied.

[0141] · Display specified display content on the image display unit 11. Or, in a state where an external display is connected to the HUD device 1, control can be performed to confirm the specified display content with the external display.

[0142] · In a state where the HUD device 1 is connected to an external device such as a computer system via a USB cable or the like, control the communication of information or commands between the external device and the HUD device 1. The external device has, for example, a display and a user interface for receiving user operations.

[0143] · Control the update / download / reinstallation of the control software.

[0144] As a specific example, the control unit 20 outputs, for example, an error including a phenomenon such as Fig. 8A , Figure 8B , Figure 8C or Fig.10 to the external device by communicating with the above-mentioned external device, for example, the error log stored in the memory 17. Or, the control unit 20 is not limited to outputting an error caused by such control software, and can also output an error occurring in various hardware in the HUD device 1 to the external device.

[0145] Furthermore, the control unit 20 can prompt the content of the error countermeasure, which is a method for solving the occurred error, to an external device or the like. Specifically, examples include forcibly restarting the HUD device 1, updating / downloading / reinstalling the control software, replacing the hardware, etc. In addition, for example, when an engineer performs an operation to end the engineering mode, when the HUD device 1 is restarted, and when the control software is updated / reinstalled, etc., the control unit 20 ends the engineering mode.

[0146] Fig.13 It is a schematic diagram showing a structural example of a system including the head-up display device of Embodiment 3. In Embodiment 3, a case where the head-up display device can be operated using one or more external devices 45 is described. That is, an example of cooperation between one or more external devices 45 and the head-up display device via wire or wireless is described. Fig.13 The HUD device 1 shown, for example, in addition to Figure 2A structures such as those shown, also includes a wired communication interface 40 and / or a wireless communication interface 41.

[0147] The wired communication interface 40 is, for example, a USB interface or the like, and is connected to the external device 45a via a USB cable. The wireless communication interface 41 is, for example, a wireless LAN interface or a Bluetooth interface or the like, and is connected to the external device 45b via the network 46 as needed. The external devices 45a and 45b are, for example, mobile devices such as smartphones and tablet terminals, and have a display and a user interface.

[0148] Here, the control of the engineering mode of the head-up display device using the external device 45 is described. An operator such as an engineer can obtain information from the control unit 20 using the external devices 45a and 45b and send signals / commands, etc., to the control unit 20. In addition, the operator can cause the control unit 20 to shift to the engineering mode by performing operation input using the user interface of the external devices 45a and 45b. In addition, the control unit 20 can also obtain the above vehicle type identification information from the external devices 45a and 45b.

[0149] In addition, the engineering mode can have multiple privilege levels. Specifically, for example, it can have an engineering mode for general users and an engineering mode for engineers who are the suppliers of the HUD device 1. Each engineering mode is distinguished, for example, by the content of the operation input when shifting to the engineering mode. For example, in the engineering mode for general users, items that do not have a great impact on the actual use of the HUD device 1 can be executed. On the other hand, in the engineering mode for engineers, items that may have a great impact on the actual use of the HUD device 1 can be executed.

[0150] Fig.14 It is showing Fig.13A diagram showing an example of a screen displayed on the display of an external device. In this example, in the engineering mode, the control unit 20 provides a screen for reminding to restart the HUD device 1 to the external devices 45a and 45b. Additionally, the control unit 20 provides a screen to external devices such as mobile devices 45a and 45b here, but the external device only needs to have at least a display. Additionally, depending on the situation, the control unit 20 can also display such a screen as a virtual image 9 in front of the windshield 3.

[0151] <Main effects of Embodiment 3>

[0152] By using the method of Embodiment 3 above, for example, in a situation where the HUD device 1 cannot be used correctly, it is possible to easily analyze the reasons and the like. Furthermore, it is possible to formulate countermeasures or provide countermeasure contents according to the reasons and the like. By enabling the external device to cooperate with the head-up display device via wired or wireless means, the operation becomes more convenient.

[0153] (Embodiment 4)

[0154] <Regarding the rewrite of control software>

[0155] For example, by rewriting the control software of the HUD device 1, new functions can be added to the HUD device 1, or problems of the HUD device 1 can be corrected, the user interface can be changed, and the usability of the HUD device 1 can be improved. Or, there are also cases where, in order to realize the linked operation between the devices mounted in a vehicle (such as a vehicle) including the HUD device 1, it is necessary to rewrite the control software and update the control software. For example, when the HUD device 1 operates in linkage with device A, there is a case where it is necessary to update the software of the HUD device 1 as the software of device A is updated.

[0156] As a specific example, consider the case where device A is a vehicle navigation device. In such a case, since it is necessary to synchronize the software updates of the HUD device 1 and device A, it can be considered to perform software updates according to a request on vehicle control for managing the HUD device 1 and device A. At this time, the HUD device 1 obtains the control software for rewriting (such as for updating) from Fig.13 the shown wired communication interface 40 or wireless communication interface 41 for use.

[0157] In the former case, the wired communication interface 40 is connected to, for example, a USB memory or the like that stores the control software for rewriting. In the latter case, the wireless communication interface 41 is wirelessly connected to, for example, an update server that distributes the control software for rewriting. The function of rewriting the control software achieved through wireless communication is called FOTA (Firmware On The Air).

[0158] In addition, the vehicle can store control software for rewriting and updating in its storage unit, control unit, etc. The HUD device 1 acquires the control software for rewriting or updating via the communication path between the vehicle and the HUD device 1. In addition, the storage location of the control software for rewriting and updating only needs to be a unit capable of communicating with the HUD device 1 or the storage unit of this unit, and is not limited to the storage unit of the vehicle. Hereafter, the case where the control software for rewriting or updating is stored in the HUD device 1 will be described as an example. However, the control software for rewriting or updating can be stored in a storage unit other than the HUD device 1, such as the storage unit of the vehicle, and the rewriting or updating operations in this case are the same as those when stored in the HUD device 1.

[0159] Fig.15A And Fig. 15B is a schematic diagram showing an example of the usage method of the memory when rewriting the control software. In Embodiment 4, Fig.15A the shown memory 17 has storage areas 51[1], 51[2] for control software with multiple sides (here, two sides, that is, two), and further stores SW start surface information 50 for selecting one of the multiple sides. When using such a memory 17, the control software of the start target can be rewritten by Fig. 15B the method shown.

[0160] Fig. 15B In the left figure of, the value of the SW start surface information 50 is "0", which indicates the selection of the storage area 51[1]. The storage area 51[1] stores the first control software 25[1]. The HUD device 1 starts the first control software 25[1] by referring to the SW start surface information 50 and operates based on the first control software 25[1]. In this state, the HUD device 1 stores the second control software 25[2], that is, the control software for rewriting, obtained by wired or wireless means, in the storage area 51[2].

[0161] The second control software 25[2] is, for example, obtained by upgrading the version of the first control software 25[1]. However, it is not limited to this. In the case of reinstalling a control software that has become unstable for some reason, etc., the second control software 25[2] can also be the same or an older version than the first control software 25[1]. After the HUD device 1 stores the second control software 25[2] in the storage area 51[2], it rewrites the value of the SW start surface information 50 to "1", which indicates the selection of the storage area 51[2].

[0162] After that, the HUD device 1 restarts. As a result, as Fig. 15BAs shown in the right figure in [ ], the HUD device 1 starts the second control software 25[2] stored in the storage area 51[2] by referring to the SW startup screen information 50, and operates based on the second control software 25[2]. Additionally, specifically, the storage areas 51[1] and 51[2] are set, for example, in a ROM which is a non-volatile memory. The HUD device 1 loads the first control software 25[1] into the RAM which is a volatile memory and executes it before restart by referring to the SW startup screen information 50, and loads the second control software 25[2] into the RAM and executes it after restart.

[0163] Furthermore, the storage location in the case of rewriting the control software next time is the storage area 51[1]. This is because the SW startup screen information 50 is "1", which indicates that the second control software 25[2] stored in the storage area 51[2] is in operation. Therefore, it is better to save the control software for the next rewrite not in the storage area 51[2] but in the storage area 51[1] where the non-operating first control software 25[1] is stored.

[0164] Fig.16A and Fig. 16B is a schematic diagram showing an example of the usage method of different memories from Fig.15A and Fig. 15B The storage device 17 shown is a ROM which specifically has a storage area 51 for one-sided control software. As Fig.16A shown, when the HUD device 1 is started with the first control software 25[1] stored in the storage area 51 within the ROM, the HUD device 1 loads all of the first control software 25[1] into the RAM and executes it. Fig. 16B In this state, the HUD device 1 overwrites and writes the second control software 25[2] obtained by wire or wirelessly into the storage area 51 within the ROM. After that, the HUD device 1 restarts. As a result, after restart, the HUD device 1 loads the second control software 25[2] into the RAM and executes it. Additionally, such an example of software rewriting can be achieved only in the following operation mode, in which all of the control software is loaded into the RAM at startup, and thereafter it is not necessary to refer to the control software within the ROM again, that is, it is not necessary to load the control software within the ROM into the RAM as needed.

[0165]

[0166] Fig.16A Fig. 16B and Fig.15A The method shown in [ ] and Fig. 15B and Fig. 15BCompared with the method shown, it is possible to reduce the capacity required for the memory 17, specifically the ROM. However, for example, in the case where the rewrite of the second control software 25[2] fails, a situation may occur where the control software cannot be started later. If the method shown in Fig.15A and Fig. 15B is used, when the rewrite to the second control software 25[2] fails, the first control software 25[1] can be selected as the control software to be started.

[0167] <Summary of the rewrite operation of the control software>

[0168] Fig.17 is a schematic diagram showing an operation example when rewriting the control software in the head-up display device according to the fourth embodiment. Fig.17 In this case, the memory 17, specifically the ROM, has a start surface registration area 55, a first storage area 51[1], and a second storage area 51[2]. In addition, the memory 17 also has an area for registering the setting identification information 31 shown in Fig. 6A and so on.

[0169] In the first storage area 51[1], the first control software 25[1] is stored. The first control software 25[1] is, for example, the control software 25a for a truck or the control software 25b for a passenger car described in Figure 5A or Figure 5B In addition to the software SW identification information 30[1] shown in Fig. 6A and so on, the first control software 25[1] also has version information 56[1]. The SW identification information 30[1] is used to determine the type of the first control software 25[1]. The version information 56[1] is used to determine the version of the first control software 25[1]. In addition, not limited to the method of separately setting the SW identification information 30[1] and the version information 56[1] in this way, it is also possible to set one identification information that can be used to determine both the type and version of the control software.

[0170] The second control software 25[2] is a control software for rewriting received from the outside. That is, as described above, the HUD device 1 has a wired communication interface 40 or a wireless communication interface 41 for connecting to an external device that sends the second control software 25[2], such as a USB memory or an update server. The HUD device 1 receives the second control software 25[2] via such a communication interface. The second storage area 51[2] is an area for storing the received second control software 25[2] as needed.

[0171] Similar to the first control software 25[1], the second control software 25[2] has a second SW identification information 30[2] and a second version information 56[2]. The second SW identification information 30[2] is used to determine the type of the second control software 25[2]. The second version information 56[2] is used to determine the version of the second control software 25[1]. The SW startup screen information 50 is registered in the startup screen registration area 55. The SW startup screen information 50 is as Fig.15A and Fig. 15B described, and is used to indicate which one of the first storage area 51[1] and the second storage area 51[2] is selected as the control software for the startup object.

[0172] Here, the HUD device 1 - specifically, Figure 2A the control unit 20 shown or Figure 2B the communication processing unit 16a shown, receives the second control software 25[2] including the second SW identification information 30[2] and the second version information 56[2]. Then, the HUD device 1 compares the first SW identification information 30[1] with the second SW identification information 30[2]. Based on the comparison result of the SW identification information, the HUD device 1 determines whether to rewrite the control software for the startup object from the first control software 25[1] to the second control software 25[2]. Specifically, it determines whether to save the second control software 25[2] in the second storage area 51[2] and rewrite the SW startup screen information 50.

[0173] At this time, when the comparison result of the SW identification information by the HUD device 1 is inconsistent, the control software for the startup object is not rewritten. Specifically, the HUD device 1 does not save the second control software 25[2] in the second storage area 51[2], nor does it rewrite the SW startup screen information 50. On the other hand, when the comparison result of the SW identification information is consistent and other conditions are met as needed, the HUD device 1 rewrites the control software for the startup object. Specifically, the HUD device 1 saves the second control software 25[2] in the second storage area 51[2] and rewrites the SW startup screen information 50 from "0" to "1".

[0174] In this example, as other conditions, the HUD device 1 compares the first version information 56[1] with the second version information 56[2]. Then, when the version of the second version information 56[2] is the same as or newer than the version of the first version information 56[1], the HUD device 1 rewrites the control software for the startup object.

[0175] Accordingly, for example, when the first control software 25[1] is the control software 25a for a truck and the control software for rewriting receives the control software 25a for a truck of the same version or a new version, the rewriting is executed. On the other hand, when the control software 25a for an old version of the truck is received, the rewriting is not executed in principle. However, in this case, for example, the rewriting may be executed by presetting. In this case, the comparison of the version information may not be performed.

[0176] Fig.18 It is a flowchart showing an example of the schematic processing content when rewriting the control software in the head-up display device according to Embodiment 4. Fig.18 The shown process is performed by Figure 2A the control unit 20 shown or Figure 2B the communication processing unit 16a shown. Here, Figure 2A the control unit 20 shown or Figure 2B both the communication processing unit 16a shown are regarded as the control unit 20.

[0177] The control unit 20 first receives a rewrite request for the control software, for example, an update request or the like (step S401). Specifically, the control unit 20 receives the rewrite request via Fig.13 the wired communication interface 40 shown or the wireless communication interface 41. Each communication interface 40, 41 may be included in Figure 2A the communication unit 16. That is, the control unit 20 may receive the rewrite request from the upper control unit 21.

[0178] Next, the control unit 20, for example, Fig.17 as described, based on the comparison result of the SW identification information 30[1], 30[2], or additionally based on the comparison result of the version information 56[1], 56[2], determines whether it is necessary to rewrite the control software to be started (step S402). When the control unit 20 determines that it is necessary to rewrite the control software (step S403: "Yes"), the rewriting is executed (step S404). Specifically, the control unit 20 receives the control software for rewriting, that is, the second control software 25[2], via the respective communication interfaces 40, 41 and stores it in the second storage area 51[2]. Further, the control unit 20 rewrites the SW start surface information 50.

[0179] When the rewrite in step S404 by the control unit 20 is successful (step S405: "Yes"), the process ends. On the other hand, when the rewrite in step S404 by the control unit 20 fails (step S405: "No"), an error notification is output (step S406). Specifically, the control unit 20 outputs an error notification, for example, when an error is detected based on an error detection code or the like during the reception of the control software, or when a write error in the ROM is detected. In this case, the control unit 20 does not rewrite the SW startup screen information 50.

[0180] In addition, when the control unit 20 determines in step S403 that there is no need to rewrite the control software (step S403: "No"), a notification indicating no need to rewrite is output (step S406). Specifically, the control unit 20 determines that there is no need to rewrite when the SW identification information is inconsistent, or when the SW identification information is consistent but the version of the control software for rewriting is older than the current version.

[0181] By using the above-described method for rewriting the control software, it is possible to prevent the control software from being erroneously rewritten, and as a result, the possibility of the HUD device 1 being erroneously used can be reduced. In particular, when receiving the control software for rewriting via a USB memory and when receiving a rewrite request for the control software via the network 46 without distinguishing the type, the control software may not be suitable. For this reason, using Fig.17 and Fig.18 the method shown is beneficial.

[0182] <Details of the control software rewrite operation>

[0183] Fig.19A is a flowchart showing an example of the detailed processing content when rewriting the control software in the head-up display device of Embodiment 4. Fig.19B is a flowchart showing Fig.19A an example of the subsequent detailed processing content. Fig.19A and Fig.19B The processes shown are executed by the control unit 20 shown in Figure 2A or the communication processing unit 16a shown in Figure 2B Here, both the control unit 20 shown in Figure 2A and the communication processing unit 16a shown in Figure 2B are regarded as the control unit 20.

[0184] Fig.19A In, the control unit 20 communicates with Fig.18Similarly, in this case, a rewrite request for the control software is received (step S401). Correspondingly, the control unit 20 determines whether the HUD device 1 is in a state where the control software can be rewritten (step S501). Specifically, for example, when the HUD device 1 is performing normal operations such as display processing, the control unit 20 needs to use resources such as the CPU and memory for both normal operations and the rewrite of the control software. In this case, since there is a possibility of running out of resources, the control unit 20 gives priority to normal operations and determines that it is in a non-rewritable state.

[0185] When the control unit 20 determines in step S501 that it is in a non-rewritable state ("no" case), the content of the rewrite request is registered as a rewrite reservation in the memory 17, and the process ends (step S504). In this case, although not shown in the figure, the control unit 20 determines whether a rewrite reservation has been registered at the next startup or when sufficient resources become available. Then, when a rewrite reservation has been registered, the control unit 20 regards the process of step S401 as having been performed.

[0186] On the other hand, when the control unit 20 determines in step S501 that it is in a rewritable state ("yes" case), it determines the SW update area by referring to the SW startup surface information 50 (step S502). Specifically, when the value of the SW startup surface information 50 is "0", the second storage area 51[2] corresponding to "1" is determined as the SW update area. In addition, when the value of the SW startup surface information 50 is "1", the first storage area 51[1] corresponding to "0" is determined as the SW update area.

[0187] After that, the control unit 20 transfers to the rewrite mode of the control software (step S503). When the control unit 20 transfers to the rewrite mode, it executes a rewrite execution program that specifies a series of rewrite processes as shown in Fig.19B In this case, the control unit 20 receives the actual data including the control software for rewriting, that is, the second control software 25[2], via each communication interface 40, 41 (step S601). Fig.19B In step S601, the control unit 20 temporarily accumulates (in other words, downloads) the received actual data into the RAM. At this time, the entire control software for rewriting can be downloaded, or only a part of the control software for rewriting including the information required to determine whether rewriting is necessary, which will be described later, can be downloaded. In the latter case, the control unit 20 can download the undownloaded part of the control software for rewriting when it is determined that rewriting is necessary.

[0188]

[0189] ​Next, the control unit 20 refers to the second SW identification information 30[2] which is the SW identification information included in the received actual data, or additionally refers to the second version information 56[2] which is the version information (step S602). Fig.18 In the same manner, it is determined whether rewriting is required (step S402 ), and if it is determined that rewriting is required, rewriting is performed (step S404 ).

[0190] In step S404, the control unit 20 saves (in other words, installs) the rewriting control software temporarily accumulated in the RAM into the ROM. When saving into the ROM, the rewriting control software may be saved into the ROM after the entire rewriting control software is downloaded, or the download of the rewriting software and the saving into the ROM may be performed in parallel. That is, the rewriting control software may be installed by downloading a part of the rewriting control software and then saving it into the ROM, and then downloading another part of the rewriting control software.

[0191] Furthermore, the control unit 20 Fig.18 As described above, when the rewriting is successful (step S405: "Yes"), the SW startup surface information 50 is rewritten (step S603). As a specific example, when the control software for rewriting is normally stored in the second storage area 51 [2], the control unit 20 rewrites the SW startup surface information 50 from "0" to "1". On the other hand, when the rewriting fails (step S405: "No"), the control unit 20 outputs an error notification (step S406a). In this case, the control unit 20 can, for example, return to step S601 to receive the actual data again. In addition, when the control unit 20 determines in step S403 that rewriting is not necessary, it outputs a notification that rewriting is not necessary (step S406b).

[0192] Fig. 20 Yes means Fig.19A A flowchart of a variation of the process shown. Fig. 20 In the embodiment, the control unit 20 replaces Fig.19A In the process of step S501 in the above, it is determined whether the HUD device 1 is in the power saving state (step S701). When the HUD device 1 is in the power saving state (step S701: "Yes"), the control unit 20 cancels the power saving state and transfers to the process of step S502 (step S702). On the other hand, when the HUD device 1 is not in the power saving state (step S701: "No"), the control unit 20 directly transfers to the process of step S502.

[0193] For example, when the vehicle is parked, the HUD device 1 is connected to the battery of the vehicle and is in a power saving state. Fig. 20When the process shown is performed, even if the HUD device 1 receives a request to rewrite the control software while in such a power-saving state, it can execute the rewrite. That is, the HUD device 1 can update the control software, for example, during a period when the vehicle is not being driven.

[0194] In addition, Fig.17 , Fig.19A and Fig.19B etc. are described on the premise of using the rewrite method shown in Fig.15A and Fig. 15B . However, it is not limited to this, and the rewrite method shown in Fig.16A and Fig. 16B can also be used. In this case, for example, the processing of step S502 in Fig.19A and the processing of step S603 in Fig.19B are not required.

[0195] <Regarding various modification examples>

[0196] As another additional function, when rewriting the control software, the control unit 20 can also record rewrite history information in the memory 17, specifically in the ROM. As the rewrite history information, for example, version information before and after the rewrite, information on the rewrite date and time, start / end times of the rewrite, and information on the time required for the rewrite can be cited. The rewrite history information records at least one rewrite, and can also record multiple rewrites as needed.

[0197] In addition, the control unit 20 can also execute an exceptional rewrite that is not normally allowed under the responsibility of an engineer by using the engineering mode described in Embodiment 3 - for example, an engineering mode for engineers. As a specific example, the control unit 20 can rewrite the control software of the startup target to an older version of the control software.

[0198] <Main effects of Embodiment 4>

[0199] By using the method of Embodiment 4 above, in the HUD device 1 that shares hardware and is equipped with control software corresponding to the type of vehicle, it is possible to prevent confusion of the control software when rewriting the control software. As a result, the possibility of the HUD device 1 being misused can be reduced.

[0200] (Embodiment 5)

[0201] <Outline of the rewrite operation of the control software>

[0202] Fig.21 is a schematic diagram showing an example of the operation when rewriting the control software in the head-up display device of Embodiment 5. Fig.21 shows the same operation example as in the case of Fig.17 . However, Fig.21 in the following aspects from Fig.17 is different. The first difference is that the first control software 25[1] stored in the first storage area 51[1] is the shared control software 25c shared by multiple vehicles as Fig.9A shown.

[0203] The second difference is that the first control software 25[1] has the first version information 56[1] in the same way as Fig.17 the case of, but does not have the SW identification information as Fig.17 shown due to the first difference. This also applies to the second control software 25[2]. The third difference is that the memory 17 (specifically, the ROM) also has an operation mode setting area in which the setting information of the operation mode 37 as Fig.9A shown, etc. is registered.

[0204] That is, in the case of using the shared control software 25c, the control unit 20 selects one of the multiple vehicles through the operation mode 37 as Fig.9A shown, etc. Then, the control unit 20 controls the entire HUD device 1 by causing the control software of the activation target to operate in the selected operation mode 37.

[0205] On the premise of such differences, the control unit 20 receives the second control software 25[2] and the second version information 56[2] from the outside in the same way as Fig.17 the case of. Then, the control unit 20 compares the first version information 56[1] with the second version information 56[2]. At this time, different from Fig.17 the case of, the comparison of the SW identification information is not performed.

[0206] The control unit 20 determines whether to rewrite the control software of the activation target from the first control software 25[1] to the second control software 25[2] based on the comparison result of the version information. Specifically, the control unit 20 rewrites the control software of the activation target when the version of the second version information 56[2] is the same as or newer than the version of the first version information 56[1].

[0207] <Details of the control software rewriting operation>

[0208] The detailed process of the control software rewriting operation is substantially the same as that described in Embodiment 4 for Fig.19A , Fig.19B and Fig. 20 . However, Fig.19B the process shown as Fig. 22 is replaced with the process shown as Figure 22 for example. Figure 19A or Figure 20The subsequent flow chart.

[0209] Figure 22 The process shown is similar to Figure 19B Compared with the process shown in the figure, it is different in the following aspects. The first difference is that Figure 19B The processing of step S602 in is replaced by Figure 22 In step S801, the control unit 20 refers to the second version information 56[2] which is the version information included in the actual data received in step S601. At this time, unlike the process of step S602, the SW identification information is not referred to.

[0210] The second difference is that the processing of steps S802 and S803 is added after the processing of step S603. In step S802, the control unit 20 determines whether the action mode 37 has been registered in the memory 17. Then, if the action mode 37 has been registered (step S802: "Yes"), the control unit 20 ends the processing. On the other hand, if the action mode 37 has not been registered (step S802: "No"), the control unit 20 registers the action mode in the action mode setting area of ​​the memory 17 in step S803. The registration of the action mode is performed based on the setting identification information 31, or as Figure 9B As described above, this is performed based on the comparison result between the vehicle type identification information and the installation identification information 31 .

[0211] If, for example, the setting information of the operation mode 37 is lost due to some reason when the control software is rewritten, even if the control software is rewritten successfully, the rewritten control software cannot be started correctly. Figure 22 The processing of steps S802 and S803 is added.

[0212] <Main effects of embodiment 5>

[0213] By using the method of the fifth embodiment, in the HUD device 1 in which hardware and control software are shared by multiple vehicles, the control software of the start-up object can be rewritten to the correct control software, specifically, the control software that is not an old version. As a result, the possibility of the HUD device 1 being used incorrectly can be reduced.

[0214] (Implementation method 6)

[0215] <Details of common control software>

[0216] Figure 23 In the head-up display device of the sixth embodiment, based on Figure 9A A flowchart showing an example of the processing contents to be performed by the common control software shown. Figure 24A andFigure 24B is a supplementary explanatory diagram for explaining Figure 23 the processing content shown. Figure 24A Shows the state where the HUD device 1 is installed in a truck. Figure 24B Shows the state where the HUD device 1 is installed in a passenger car. The direction in which the image light is emitted from the image display unit 11 is defined as the installation direction of the HUD device 1, and the installation directions are opposite in a truck and a passenger car.

[0217] In addition, the range within which the user 6 can observe the virtual image is called the eye box or Eyebox. Sometimes the user 6 may want to adjust the height in the vertical direction where the virtual image is located, that is, the height of the eye box, with respect to the HUD device 1. In this case, the common control software 25c, as Figure 24A and Figure 24B shown, rotates the mirror M1 by driving the mirror driving unit 14 (for example, a motor) to change the installation angle of the mirror M1 and thereby adjust the height of the eye box.

[0218] Here, as Figure 24A shown, by tilting the mirror in the direction opposite to the emission direction of the image light emitted from the image display unit 11, in the vertical direction or the plumb direction of the vehicle, the eye box in the case of a truck will drop. Therefore, when it is necessary to lower the eye box, the common control software 25c needs to rotate the mirror M1 via the mirror driving unit 14 in such a way that the mirror M1 tilts in the direction opposite to the emission direction of the image light. Conversely, when it is necessary to raise the eye box, the common control software 25c needs to rotate the mirror M1 via the mirror driving unit 14 in such a way that the mirror M1 tilts in the same direction as the emission direction of the image light.

[0219] On the other hand, as Figure 24B shown, different from the case of a truck, by tilting the mirror in the same direction as the emission direction of the image light emitted from the image display unit 11, in the vertical direction or the plumb direction of the vehicle, the eye box in the case of a passenger car will drop. Therefore, when it is necessary to lower the eye box, the common control software 25c needs to rotate the mirror M1 via the mirror driving unit 14 in such a way that the mirror M1 tilts in the same direction as the emission direction of the image light. Conversely, when it is necessary to raise the eye box, the common control software 25c needs to rotate the mirror M1 via the mirror driving unit 14 in such a way that the mirror M1 tilts in the direction opposite to the emission direction of the image light.

[0220] In addition, Figure 24A and Figure 24BThis is just one example. Depending on the structure of the HUD device 1, there are also cases where the tilting direction of the mirror M1 is different when the eye box is raised or lowered. However, even in such cases, as long as the installation directions of the HUD device 1 in the truck and the passenger car are opposite, the tilting direction of the mirror M1 when the eye box is raised or lowered is opposite in the truck and the passenger car, which remains unchanged.

[0221] For this reason, Figure 2A the control unit 20 shown in Figure 2B or the communication processing unit 16a shown in Figure 23 executes the process shown in Figure 2A based on the common control software 25c. Here, both the control unit 20 shown in Figure 2B and the communication processing unit 16a shown in Figure 23 are regarded as the control unit 20. In the process shown in

[0222] Specifically, Figure 23 in, the control unit 20 first receives a height adjustment request for the eye box (step S901) based on the operation input of the user 6, and receives a height request value (step S902). Next, the control unit 20 obtains the current height setting value of the eye box (step S903). Next, the control unit 20 determines the moving direction of the eye box, that is, up / down and the moving amount, based on the height request value in step S902 and the height setting value in step S903 (step S904).

[0223] Next, the control unit 20 determines Figure 9A whether the operation mode 37 shown in

[0224] is for a passenger car or a truck (step S905). When the operation mode 37 is for a passenger car in step S905, the control unit 20 sets the rotation direction of the mirror drive unit 14 (here, the motor) to be for a passenger car and transfers to step S907 (step S906a). On the other hand, when the operation mode 37 is for a truck in step S905, the control unit 20 sets the rotation direction of the motor to be for a truck, that is, the opposite direction to that for a passenger car, and transfers to step S907 (step S906b).

[0225] When the height set value of the eye box reaches the height request value (step S908: "Yes"), the control unit 20 records the height set value of the moved eye box in the memory 17 such as ROM (step S909). In addition, the control unit 20 notifies the user 6 of the completion of the height adjustment by display or sound (step S910).

[0226] Figure 25A This is an example of a flowchart showing different processing contents based on the common control software shown in the head-up display device of Embodiment 6 Figure 9A and Figure 23 different processing contents. Figure 25B This is a flowchart showing Figure 25A subsequent processing contents. Figure 26A and Figure 26B are supplementary explanatory diagrams for explaining Figure 25A and Figure 25B part of the processing contents. Figure 25A and Figure 25B The processes shown are executed by the control unit 20 shown in Figure 2A or the communication processing unit 16a shown in Figure 2B Here, both the control unit 20 shown in Figure 2A and the communication processing unit 16a shown in Figure 2B are regarded as the control unit 20.

[0227] In the Figure 11B , Figure 12A and Figure 12B described in Embodiment 2, it is explained that in the common control software 25c, the specifications of the horizontal orientation of the image displayed on the image display unit 11 and the processing content for distortion correction of the image differ depending on the operation mode 37. In addition to this, the specifications of the vertical orientation of the image displayed on the image display unit 11 in the common control software 25c may also differ depending on the operation mode 37.

[0228] In Figure 26A , similar to the case of Figure 12A , an example of the relationship between the display content of the image display unit 11 and the display content observed by the user 6 is shown in the HUD device 1 provided in a truck. In Figure 26B , similar to the case of Figure 12B , an example of the relationship between the display content of the image display unit 11 and the display content observed by the user 6 is shown in the HUD device 1 provided in a passenger car.

[0229] According to the optical path 18 of the image light shown in Figure 26A , in the case of a truck, the vertical orientation of the image is the same in both the display content of the image display unit 11 and the display content observed by the user 6. On the other hand, according to Figure 26BAs can be seen from the optical path 18 of the image light shown, in the case of a passenger car, the up-down orientation of the image in the display content of the image display unit 11 and the display content observed by the user 6 are opposite to each other. For this reason, the control unit 20, through Figure 25A and Figure 25B the processes shown, determines whether the image needs to be flipped vertically. In the case where vertical flipping is required, an image that has been flipped vertically in advance is displayed on the image display unit 11.

[0230] Specifically, Figure 25A in, the control unit 20 first receives a request for starting or updating the display of the HUD device 1 (step S1001). Next, the control unit 20 obtains display-related information from the control unit 21 via the communication unit 16, i.e., the information acquisition unit (step S1002). Then, the control unit 20 determines the display content, i.e., the image to be displayed on the image display unit 11 (step S1003). Next, the control unit 20 obtains the current height setting value of the eye box (step S1004). In addition, the control unit 20 clears the vertical flipping flag of the image held in the memory 17 (e.g., RAM or register) (step S1005).

[0231] Next, Figure 25B in, the control unit 20 determines whether the operation mode 37 is for a passenger car or a truck (step S1006). In the case where the operation mode 37 is for a passenger car in step S1006, the control unit 20 selects the distortion correction table for a passenger car (step S1007a). Then, the control unit 20 sets the vertical flipping flag of the image and transfers to step S1009.

[0232] On the other hand, in the case where the operation mode 37 is for a truck in step S1006, the control unit 20 selects the distortion correction table for a truck and transfers to step S1009 (step S1007b). In addition, each of the distortion correction tables for a passenger car and a truck is Figure 11B as described, generated based on the shape of the windshield 3 of the passenger car and the truck, etc., and is stored in advance in the memory 17, e.g., ROM.

[0233] In step S1009, the control unit 20 generates the image data to be displayed on the image display unit 11 (step S1009). Then, the control unit 20 performs distortion correction processing on the generated image data based on the selected distortion correction table (step S1010). In addition, the control unit 20 determines whether the vertical flipping flag of the image is set (step S1011). In the case where the vertical flipping flag of the image is not set (step S1011: "No"), the control unit 20 causes the image display unit 11 to obtain the image data after the distortion correction processing, thereby starting the image display or updating the image (step S1012).

[0234] On the other hand, when the image upside-down flag is set (step S1011: Yes), the control unit 20 further performs upside-down processing on the image data after the distortion correction processing (step S1013). Figure 11B Similarly, if a vertical flip mechanism is pre-set in the image display unit 11, the mechanism is used, and if no vertical flip mechanism is set, the image data is processed in a vertically flipped manner. Thereafter, the control unit 20 causes the image display unit 11 to obtain the vertically flipped image data, thereby starting image display or updating the image (step S1012).

[0235] <Main effects of embodiment 6>

[0236] By using the method of the sixth embodiment, the control software can be shared by a plurality of vehicles, and the shared control software 25c can be used to execute appropriate processing corresponding to the vehicle, in other words, processing without malfunction. In addition, the shared control software can reduce costs.

[0237] In addition, when using the methods of each embodiment, the user 6 can observe various information required for driving, such as the destination and speed, as an image across the windshield 3, under the condition that the HUD device 1 can be used correctly. Thus, it is possible to provide a HUD device 1 that reduces the movement of the user's 6 viewpoint and helps assist safe driving. As a result, traffic accidents can be prevented. Furthermore, it is possible to contribute to "3. Good health and well-being" of the Sustainable Development Goals (SDGs) advocated by the United Nations.

[0238] The invention made by the inventor is specifically described above based on the embodiments, but the present invention is not limited to the above embodiments, and various changes can be made within the scope of the main purpose. For example, the above embodiments are described in detail to explain the present invention in an easy-to-understand manner, and are not limited to all the structures that must be described. In addition, a part of the structure of a certain embodiment can be replaced with the structure of other embodiments, and the structure of other embodiments can be added to the structure of a certain embodiment. In addition, for a part of the structure of each embodiment, other structures can be added, deleted, or replaced.

[0239] Description of Reference Numerals

[0240] 1…Head-up display (HUD) device, 2……Vehicle, 4……Vehicle information, 5……Display area, 11……Image display unit, 14……Mirror drive unit, 16……Communication unit (information acquisition unit), 17……Memory, 20……Control unit, 25, 25[1], 25[2]……Control software, 30, 30[1], 30[2]……SW identification information, 31……Setting identification information, 37……Operation mode, 45a, 45b……External device, 50……SW startup surface information, 51[1], 51[2]……Storage area, 55……Startup surface registration area, 56[1], 56[2]……Version information, M1……Mirror (image light projection unit).

Claims

1. A head-up display device capable of sharing hardware among multiple vehicles, characterized in that, Comprising: A storage unit that stores object control software which is any one of a plurality of control softwares respectively corresponding to the plurality of transportation means, and software identification information for determining the type of the object control software; An image display unit that displays an image and emits image light of the displayed image; and An image light projection unit that projects the image light emitted from the image display unit onto a display area, so that the projected image light is observed as a virtual image, wherein setting identification information representing a setting method used when the head-up display device is installed in the transportation means is registered in advance, When the head-up display device is started, the software identification information is compared with the setting identification information. If they are the same, it transfers to the normal operation. If they are different, it does not transfer to the normal operation but outputs an error.

2. The head-up display device according to claim 1, characterized in that: The setting identification information is stored in the storage unit.

3. The head-up display device according to claim 1, characterized in that: It further includes a mechanical switch for registering the setting identification information.

4. The head-up display device according to claim 1, characterized in that: According to the type of the transportation means, the head-up display device is set such that the emission direction of the image light from the image display unit is a first direction under the coordinate axes of the transportation means, or a second direction which is the direction opposite to the first direction.

5. The head-up display device according to claim 1, characterized in that: Among the plurality of control softwares, at least the specification of the orientation of the image displayed on the image display unit and the processing content for distortion correction of the image are different for each type.

6. The head-up display device according to claim 1, characterized in that, It further comprises: A control unit that controls the display of the image display unit; and A communication interface that can be connected to an external device having a display, wherein the control unit outputs the error to the external device via the communication interface.

7. A head-up display device capable of sharing hardware among multiple vehicles, characterized in that, Comprising: A storage unit that stores object control software which is any one of a plurality of control softwares respectively corresponding to the plurality of transportation means, and software identification information for determining the type of the object control software; An image display unit that displays an image and emits image light of the displayed image; An image light projection unit that projects the image light emitted from the image display unit onto a display area, so that the projected image light is observed as a virtual image; and An information acquisition unit that acquires vehicle type identification information representing the type of the transportation means by communicating with the outside, wherein When the head-up display device is started, the vehicle type identification information acquired by the information acquisition unit is compared with the software identification information. If they are the same, it transfers to the normal operation. If they are different, it does not transfer to the normal operation but outputs an error.

8. The head-up display device according to claim 7, characterized in that: The setting identification information representing the setting method used when the head-up display device is installed in the transportation means is registered in a readable state in advance, In the case where the vehicle type identification information is the same as the software identification information but different from the setting identification information, it transfers to the normal operation and outputs an error.

9. The head-up display device according to claim 8, characterized in that: The setting identification information is stored in the storage unit.

10. The head-up display device according to claim 8, characterized in that: It further includes a mechanical switch for registering the setting identification information.

11. The head-up display device according to claim 7, wherein: According to the type of the vehicle, the head-up display device is configured such that the emission direction of the image light from the image display unit is a first direction under the coordinate axes of the vehicle, or a second direction opposite to the first direction.

12. The head-up display device according to claim 7, wherein: Among the multiple control software, at least the specification of the orientation of the image displayed on the image display unit and the processing content for distortion correction of the image differ for each type.

13. The head-up display device according to claim 7, wherein Further comprising: a control unit that controls the display of the image display unit; and a communication interface that can be connected to an external device having a display, wherein the control unit outputs the error to the external device via the communication interface.

14. A head-up display device capable of sharing hardware among multiple vehicles, wherein Comprising: a storage unit that stores multiple control software corresponding to the multiple vehicles respectively; an image display unit that displays an image and emits image light of the displayed image; an image light projection unit that projects the image light emitted from the image display unit onto a display area so that the projected image light can be observed as a virtual image; a control unit that selects any one of the multiple control software based on the setting information of the operation mode, and controls the entire head-up display device including the image display unit by executing the selected control software; and an information acquisition unit that acquires vehicle type identification information indicating the type of the vehicle by communicating with the outside, wherein setting identification information indicating the setting method used when the head-up display device is installed in the vehicle is registered in advance, when the head-up display device is started at least for the first time, the control unit compares the vehicle type identification information with the setting identification information. If they are consistent, the control unit sets the operation mode corresponding to the consistent identification information and transfers to the normal operation. If they are inconsistent, the control unit does not transfer to the normal operation but outputs an error.

15. The head-up display device according to claim 14, wherein: The control unit stores the setting information of the operation mode in a non-volatile storage area. When the head-up display device is started for the second time and later, instead of comparing the vehicle type identification information with the setting identification information, the control unit transfers to the normal operation based on the setting information of the operation mode stored in the non-volatile storage area.

16. The head-up display device according to claim 14, wherein: The setting identification information is stored in the storage unit.

17. The head-up display device according to claim 14, wherein: A mechanical switch for registering the setting identification information is further included.

18. The head-up display device according to claim 14, wherein: According to the type of the vehicle, the head-up display device is configured such that the emission direction of the image light from the image display unit is a first direction under the coordinate axes of the vehicle, or a second direction opposite to the first direction.

19. The head-up display device according to claim 14, wherein: Among the multiple control software, at least the specification of the orientation of the image displayed on the image display unit and the processing content for distortion correction of the image differ for each type.

20. The head-up display device according to claim 14, wherein Further comprising: a communication interface that can be connected to an external device having a display, wherein the control unit outputs the error to the external device via the communication interface.

21. A head-up display device capable of sharing hardware among multiple vehicles, wherein Comprising: A storage unit that stores a first control software which is any one of a plurality of control softwares corresponding to the plurality of transportation means respectively, and first software identification information for determining the type of the first control software; An image display unit that displays an image and emits image light of the displayed image; and An image light projection unit that projects the image light emitted from the image display unit onto a display area so that the projected image light is observed as a virtual image, where receives a second control software and second software identification information for determining the type of the second control software, compares the first software identification information with the second software identification information, and based on the comparison result of the software identification information, determines whether to rewrite the control software to be started from the first control software to the second control software.

22. The head-up display device according to claim 21, wherein: In the case where the comparison results of the software identification information are inconsistent, the control software to be started is not rewritten.

23. The head-up display device according to claim 21, wherein: The storage unit also stores first version information for determining the version of the first control software, also receives second version information for determining the version of the second control software, compares the first version information with the second version information, and based on the comparison result of the version information in addition to the comparison result of the software identification information, determines whether to rewrite the control software to be started.

24. The head-up display device according to claim 23, wherein: In the case where the comparison results of the software identification information are consistent and the version obtained based on the second version information is the same as or newer than the version obtained based on the first version information, the control software to be started is rewritten.

25. The head-up display device according to claim 21, wherein: The storage unit includes a non-volatile memory and a volatile memory, The non-volatile memory includes: A first storage area that stores the first control software; A second storage area that is used to store the second control software; and A startup surface registration area that registers software startup surface information indicating which one of the first storage area and the second storage area is selected as the control software to be started, where The control software stored in the storage area based on the software startup surface information is loaded into the volatile memory.

26. The head-up display device according to claim 21, wherein: It further includes a communication interface that can be connected to an external device that sends the second control software.

27. The head-up display device according to claim 21, wherein: In the case where a control software rewrite request is received in the power saving state, the power saving state is released, and it is determined whether to rewrite the control software to be started.

28. The head-up display device according to claim 21, wherein: According to the type of the transportation means, the head-up display device is arranged such that the emission direction of the image light from the image display unit is a first direction under the coordinate axes of the transportation means, or a second direction which is the direction opposite to the first direction.

29. A head-up display device capable of sharing hardware among multiple vehicles, wherein, Includes: A storage unit that stores a first control software that can be shared by the plurality of transportation means, and first version information for determining the version of the first control software; An image display unit that displays an image and emits image light of the displayed image; An image light projection unit that projects the image light emitted from the image display unit onto a display area so that the projected image light is observed as a virtual image; and A control unit that selects any one of the plurality of transportation tools through an action mode, and controls the entire head-up display device including the image display unit by causing the control software of the start-up object to operate in the selected action mode, wherein: The control unit receives second control software and second version information for determining a version of the second control software, compares the first version information with the second version information, and based on a result of the version information comparison, determines whether to rewrite the control software of the startup object from the first control software to the second control software.

30. The head-up display device according to claim 29, wherein: The control unit rewrites the control software to be activated when the version obtained based on the second version information is the same as or newer than the version obtained based on the first version information.

31. The head-up display device according to claim 29, wherein: The storage unit includes a nonvolatile memory and a volatile memory. The non-volatile memory comprises: A first storage area storing the first control software; A second storage area for storing the second control software; and A startup surface registration area is used to register software startup surface information indicating which of the first storage area and the second storage area is selected as the control software of the startup object, wherein: The control software stored in the storage area based on the software startup surface information is loaded into the volatile memory.

32. The head-up display device according to claim 29, wherein: The device also includes a communication interface capable of connecting to an external device that sends the second control software.

33. The head-up display device according to claim 29, wherein: When receiving a request to rewrite control software in the power saving state, the control unit cancels the power saving state and determines whether to rewrite the control software to be activated.

34. The head-up display device according to claim 29, wherein: According to the type of the vehicle, the head-up display device is configured such that the emission direction of the image light from the image display unit is a first direction or a second direction opposite to the first direction under the coordinate axis of the vehicle.

35. The head-up display device according to claim 34, wherein: In the control software of the activation target, at least a specification of an orientation of the image displayed on the image display unit and processing contents of distortion correction for the image differ for each of the operation modes.

36. The head-up display device according to claim 34, wherein: The image light projection unit comprises: a reflector that reflects the image light emitted from the image display unit toward the display area; and A reflector driving unit, which adjusts the setting angle of the reflector by rotating the reflector, wherein: In the control software to be activated, the direction of rotation of the reflector instructed to the reflector drive unit when adjusting the position of the eye box is different for each of the operation modes.

Images