Abstract:
Provided is a software updating apparatus that can flexibly respond to various situations, including update capacity and use cases of each ECU, in a case of updating control information of a plurality of ECUs. Update control information necessary for update processing, including update data to be newly applied to an ECU, is received from a server and control of the update processing is performed based on the received update control information.

Description:
TECHNICAL FIELD 
       [0001]    The invention relates to a technique to effectively update control software of ECUs in an automobile system which is configured with diverse ECUs and of which configuration is likely to change at any time. 
       BACKGROUND ART 
       [0002]    In recent years, with advances in driving support functions and automatic driving techniques, the scale of software installed in an electronic control apparatus (ECU: Electronic Control Unit) for an automobile has increased. In response to this, in addition, the number of recalls attributable to software defects increases along with the number of times and the number of units that are needed to be dealt with per time have increased. 
         [0003]    Meanwhile, a connected car, which is an automobile wirelessly linked to a center system, has shown a sign of widespread use in response to advances in a communication network. 
         [0004]    Under such circumstances, needs for a remote software updating technique for automobiles, in which a remote software updating technique that has been used in the related mobile phones and televisions is wirelessly applied to automobiles and remotely updates ECU software of the automobiles, are on the rise. 
         [0005]    For example, in PTL1, an Over the Air (OTA) software updating system that remotely updates software of a mobile terminal is disclosed. 
         [0006]    In PTL1, a technique that achieves improved efficiency of update processing by extracting a difference between a program before and after updating and applying this difference is disclosed. 
       CITATION LIST 
     Patent Literature 
       [0007]    PTL 1: JP-A-2012-069131 
       SUMMARY OF INVENTION 
     Technical Problem 
       [0008]    However, in an automobile system where a plurality of ECUs having diverse characteristics exist within one vehicle, in some cases, all of the ECUs cannot deal with a difference technique and whether it is better to transmit a difference or to apply normal update depends on an update situation or update content. In the technique disclosed in PTL1 where the fact that each of updating methods for a plurality of pieces of ECU software is different is not mentioned, the ECU software in such a case cannot be updated. 
       Solution to Problem 
       [0009]    A representative software updating apparatus of the invention for solving the above problems is connected to a server and a plurality of control apparatuses and performs transmission and reception of data. The software updating apparatus includes a first communication unit that receives update data which is applied to each of the plurality of control apparatuses and update control information which is referred to apply the update data to each control apparatus from the server, a second communication unit that transmits the update data to be applied to each control apparatus, for each of the plurality of control apparatuses, and an update control unit that controls the plurality of control apparatuses via the second communication unit such that the update data is applied based on the update control information for each of the plurality of control apparatuses. 
       Advantageous Effects of Invention 
       [0010]    According to the above means, even if it is an automobile system configured with a plurality of ECUs which require control software update processing different from each other, control software update of each ECU can be easily implemented with an appropriate method according to uses. Problems, configurations, and effects other than those described above will be clarified by description of the following embodiments. 
     
    
     
       BRIEF DESCRIPTION OF DRAWINGS 
         [0011]      FIG. 1  is a block diagram illustrating a configuration example of a system. 
           [0012]      FIG. 2( a )  is a block diagram illustrating a hardware configuration example of a software updating apparatus. 
           [0013]      FIG. 2( b )  is a block diagram illustrating a software configuration example of the software updating apparatus. 
           [0014]      FIG. 3( a )  is a block diagram illustrating a hardware configuration example of an ECU 1 . 
           [0015]      FIG. 3( b )  is a block diagram illustrating a software configuration example of the ECU 1 . 
           [0016]      FIG. 4  is a block diagram illustrating a configuration example of an ECU 2 . 
           [0017]      FIG. 5  is a sequence diagram illustrating one example of software update processing. 
           [0018]      FIG. 6  is a configuration example of update information  5  acquired by a software updating apparatus  11  from a server  2 . 
           [0019]      FIG. 7  is a configuration example of ECU update information. 
           [0020]      FIG. 8( a )  is a sequence diagram illustrating one example of preprocessing. 
           [0021]      FIG. 8( b )  is a sequence diagram illustrating one example of the preprocessing. 
           [0022]      FIG. 9( a )  is a sequence diagram illustrating one example of network ID acquisition processing. 
           [0023]      FIG. 9( b )  is a sequence diagram illustrating one example of software version acquisition processing. 
           [0024]      FIG. 9( c )  is a sequence diagram illustrating one example of vehicle state acquisition processing. 
           [0025]      FIG. 10  is a flow chart illustrating one example of application processing in the software updating apparatus. 
           [0026]      FIG. 11( a )  is a sequence diagram illustrating one example of full update application processing. 
           [0027]      FIG. 11( b )  is a sequence diagram illustrating one example of compression update application processing. 
           [0028]      FIG. 11( c )  is a sequence diagram illustrating one example of difference update application processing. 
           [0029]      FIG. 12  is a sequence diagram illustrating one example of postprocessing. 
           [0030]      FIG. 13  is an example of a screen of an HMI. 
           [0031]      FIG. 14( a )  is a block diagram illustrating a hardware configuration example of an ECU 3 . 
           [0032]      FIG. 14( b )  is a block diagram illustrating a software configuration example of the ECU 3 . 
           [0033]      FIG. 15  is a configuration example of ECU 1  update information and ECU 3  update information. 
           [0034]      FIG. 16( a )  is a configuration example of preprocessing information of the ECU 1  update information. 
           [0035]      FIG. 16( b )  is an example of a screen that presents a reason and a solution for a case of a state where a vehicle cannot start software update. 
           [0036]      FIG. 17  is a configuration example of the ECU 1  update information. 
           [0037]      FIG. 18( a )  is a flow chart illustrating one example of update application processing of the ECU 1 . 
           [0038]      FIG. 18( b )  is a flow chart illustrating one example of data transmission request reception processing of the ECU 1 . 
           [0039]      FIG. 18( c )  is a flow chart illustrating one example of update data reception processing of the ECU 1 . 
           [0040]      FIG. 18( d )  is a flow chart illustrating one example of data transmission completion request reception processing of the ECU 1 . 
       
    
    
     DESCRIPTION OF EMBODIMENTS 
       [0041]    Hereinafter, embodiments to implement the invention will be described with reference to the drawings. In the drawings, the same reference signs indicate the same or corresponding portions. In addition, the invention is not limited to illustrated examples. 
       EXAMPLE 1 
       [0042]    In this example, an updating method for a program of an ECU of a vehicle in the invention will be described. Hereinafter, although a case where the program is updated will be described, the technique is applicable to overall control information necessary for controlling the ECU including a program, such as parameters and data. 
         [0043]    &lt;System Configuration&gt; 
         [0044]      FIG. 1  is a configuration example of a software updating system of this example. 
         [0045]    The software updating system of this example is configured with a vehicle  1 , a server  2 , the Internet  3  that links an access network and a base, an access network  4  provided by a communication service provider. 
         [0046]    The vehicle  1  is configured with a low-speed in-car network  10 , a high-speed in-car network  17 , a software updating apparatus  11 , ECUs  12 ,  16 , and  18 , a Human Machine Interface (HMI)  13 , a power source management ECU  14 , and a storage battery  15 . 
         [0047]    The software updating apparatus  11  performs update of the program of the ECU connected via a personal device and an in-car network. 
         [0048]    The ECUs  12  and  16  are connected to the low-speed in-car network  10  and perform control necessary for the vehicle to realize functions, including travelling. 
         [0049]    The ECU 3   18  is connected to the high-speed in-car network  17  and performs control necessary for the vehicle to realize functions, including travelling. 
         [0050]    The HMI  13  presents information to a user or receives input from the user. 
         [0051]    The power source management ECU  14  manages a state of the storage battery  15 . 
         [0052]    In addition, although not illustrated in  FIG. 1 , each configuration element within the vehicle, including the software updating apparatus  11  and the ECU 1   12 , is connected to a storage battery by means of a power line and receives power supply. 
         [0053]    In this configuration, update information  5  necessary for updating the program is distributed from the server  2  to the ECU via the software updating apparatus  11  and a new program is applied to the ECU. 
         [0054]    In this example, the Internet Protocol (IP) is used as a network protocol in the Internet  3  and the access network  4  and the User Datagram Protocol (UDP) and the Transmission Control Protocol (TCP) are used for a higher-level transport protocol. There are different versions of the IP, IPv4 and IPv6, and this example is not limited to any one of IPv4 and IPv6. 
         [0055]      FIG. 2( a )  is a block diagram illustrating a hardware configuration of the software updating apparatus  11 . 
         [0056]    The software updating apparatus  11  is configured with a control unit  1101 , a memory unit  1102 , a time management unit  1104 , a WAN (I/F)  1105 , a low-speed in-car LAN interface (I/F)  1106 , and a high-speed in-car LAN I/F  1107 . 
         [0057]    The control unit  1101  executes a control program and causes the software updating apparatus  11  to function by controlling other configuration elements within the software updating apparatus  11  and giving instruction of data transmission and reception to and from other devices connected over the in-car network and a server connected via the access network. 
         [0058]    The memory unit  1102  is configured of a volatile memory and a nonvolatile memory (ROM: Read Only Memory). The nonvolatile memory stores the control program and control information for operating the software updating apparatus  11 , including necessary parameters. The volatile memory temporarily stores a part of the control program and data necessary for operating the control program. In addition, in accordance with instruction from the control unit  1101 , the volatile memory keeps data under instruction, including connected apparatus information. 
         [0059]    The time management unit  1104  is provided with a real time clock (RTC) and manages time using a Network Time Protocol (NTP) server that exists on the access network  4  or the Internet  3  or time information provided by the Global Positioning System (GPS). The NTP is a protocol for synchronizing a clock of a device, which is the device connected to the network, with the correct time. 
         [0060]    The Wide Area Network (WAN) I/F  1105  performs transmission and reception of data to and from the server connected to the Internet  3  via the access network  4  according to the instruction from the control unit  1101 . The WAN I/F  1105  is configured as a wired communication unit or a wireless communication unit. 
         [0061]    The low-speed in-car LAN I/F  1106  performs transmission and reception of data to and from the ECUs  12  and  16  connected to the low-speed in-car network  10  via the low-speed in-car network  10  according to the instruction from the control unit  1101 . 
         [0062]    The high-speed in-car LAN I/F  1107  performs transmission and reception of data to and from the ECU 3   18 , which is connected to the high-speed in-car network  17 , via the high-speed in-car network  17  according to the instruction from the control unit  1101 . 
         [0063]      FIG. 2( b )  is a block diagram illustrating a configuration of the control program that is operated on the software updating apparatus  11 . 
         [0064]    A control program  11010  that realizes functions of the software updating apparatus  11  is developed in the memory unit  1102  of the software updating apparatus  11  and is executed by the control unit  1101 .  FIG. 2( b )  is functionally divided and illustrated in blocks and division and integration of each of the blocks are possible. In addition, it is not necessary to realize the control program by one program and the control program may be realized in combination with two or more programs. 
         [0065]    The control program  11010  is configured with an update control unit  11011 , an external communication control unit  11012 , an in-car communication control unit  11013 , and a high-speed in-car communication control unit  11014 . 
         [0066]    The update control unit  11011  acquires the update information  5  from the server  2  via the external communication control unit  11012  or transmits a state of the vehicle and a situation of software update processing to the server  2 . In addition, the update control unit  11011  acquires the update information  5  and states of other configuration elements in the car via the in-car communication control unit  11013  and implements software update processing according to the acquired states of other configuration elements. Furthermore, the update control unit  11011  performs application processing in which a program included in the update information  5  is applied to an ECU designated by a system designated in the update information  5 . 
         [0067]    The external communication control unit  11012  operates the WAN I/F  1105  in accordance with instruction from the update control unit  11011  and performs transmission and reception of data to and from the server  2  via the access network  4  and the Internet  3 . In addition, the external communication control unit  11012  has a function of analyzing and configuring a packet including the TCP/IP and the UDP/IP. 
         [0068]    The in-car communication control unit  11013  operates the low-speed in-car LAN I/F  1106  in accordance with the instruction from the update control unit  11011  and performs transmission and reception of data to and from other devices connected to the in-car network via the low-speed in-car network  10 . 
         [0069]    The high-speed in-car communication control unit  11014  operates the high-speed in-car LAN I/F  1107  in accordance with the instruction from the update control unit  11011  and performs transmission and reception of data to and from other devices connected to the in-car network via the high-speed in-car network  17 . 
         [0070]      FIG. 3( a )  is a block diagram illustrating a hardware configuration example of the ECU 1   12 . 
         [0071]    The ECU 1   12  is configured with a control unit  1201 , the memory unit  1102 , and the low-speed in-car LAN I/F  1106  and is connected to a sensor  1202  and an actuator  1203 . 
         [0072]    The control unit  1201  executes the control program and operates the ECU 1   12  to realize a part of necessary functions of the automobile by performing reading of the sensor  1202  and operation of the actuator  1203  and performing transmission and reception of data to and from other devices, which are connected over the low-speed in-car network  10 , via the low-speed in-car LAN I/F  1106 . 
         [0073]    The sensor  1202  acquires data necessary for controlling the automobile according to instruction from the control unit  1201 . 
         [0074]    The actuator  1203  drives configuration elements, including a brake, according to instruction from the control unit  1201 . 
         [0075]    The functions of other configuration elements will not be described since the functions are the same as those of the software updating apparatus  11 . 
         [0076]      FIG. 3( b )  is a block diagram illustrating a configuration of a control program that is operated on the ECU 1   12 . 
         [0077]    A control program  12010  that realizes functions of the ECU 1   12  is developed on the memory unit  1102  of the ECU 1   12  and is executed by the control unit  1201 .  FIG. 3( b )  is functionally divided and illustrated in blocks and division and integration of each of the blocks are possible. In addition, it is not necessary to realize the control program by one program and the control program may be realized in combination with two or more programs. 
         [0078]    The control program  12010  is configured with a control processing unit  12011 , an updating unit  12012 , and the in-car communication control unit  11013 . 
         [0079]    The control processing unit  12011  reads from the sensor  1202  and operates the ECU 1   12  to realize a part of necessary functions of the automobile by performing operation of the actuator  1203  and transmission and reception of data to and from other devices, which are connected over the low-speed in-car network  10 , via the low-speed in-car LAN I/F  1106 . 
         [0080]    The updating unit  12012  is configured with a receiving unit  120121 , a writing unit  120122 , a difference restoration unit  120123 , and a compression and decompression unit  120124 . The receiving unit  120121  receives control instruction and update data from the software updating apparatus  11  via the in-car communication control unit  11013 . The writing unit  120122  writes a program in the nonvolatile memory of the memory unit  1102 . The difference restoration unit  120123  restores a new program from the update data (difference data) received by the receiving unit  120121  and the program before updating, which is developed in the memory unit  1102 . The compression and decompression unit  120124  decompresses the update data (compressed data) received by the receiving unit  120121 . 
         [0081]    By causing the above configuration elements to cooperate with each other, the updating unit  12012  rewrites the control program of the memory unit  1102  of the ECU 1   12  in accordance with an update control request received from the software updating apparatus  11  via the in-car communication control unit  11013  and applies update of the program to the ECU 1   12 . 
         [0082]    The in-car communication control unit  11013  operates the low-speed in-car LAN I/F  1106  in accordance with instruction from the update control unit  11011  and performs transmission and reception of data to and from other devices, which are connected to the in-car network, via the low-speed in-car network  10 . 
         [0083]    The functions of other configuration elements will not be described since the functions are the same as those of the control program  11010  of the software updating apparatus  11 . 
         [0084]      FIG. 4  is a block diagram illustrating a configuration of a control program that is operated on the ECU 2   16 . 
         [0085]    A control program  16010  is configured with the control processing unit  12011 , an updating unit  16011 , and the in-car communication control unit  11013 . 
         [0086]    The updating unit  16011  is configured with the receiving unit  120121  and the writing unit  120122 . The updating unit  16011  of the control program  16010  of the ECU 2   16  cannot restore differences and cannot compress or decompress since the updating unit  16011  does not have the difference restoration unit  120123  or the compression and decompression unit  120124  that the updating unit  12012  of the control program  12010  of the ECU 1   12  has. 
         [0087]    The functions of other configuration elements will not be described since the functions are the same as those of the control program  12010  of the ECU 1   12 . 
         [0088]    The hardware configuration of the ECU 2   16  is the same as that of the ECU 1   12 . 
         [0089]      FIG. 14( a )  is a block diagram illustrating a hardware configuration example of the ECU 3   18 . 
         [0090]    The ECU 3   18  is configured with the control unit  1201 , the memory unit  1102 , and the high-speed in-car LAN I/F  1107  and is connected to the sensor  1202  and the actuator  1203 . 
         [0091]    The function of each element will not be described since the function is the same as that of a functional element corresponding to other apparatuses. 
         [0092]      FIG. 14( b )  is a block diagram illustrating a configuration of a control program that is operated on the ECU 3   18 . 
         [0093]    A control program  18010  is configured with the control processing unit  12011 , the updating unit  12012 , and the high-speed in-car communication control unit  11014 . 
         [0094]    The function of each configuration element will not be described since the function thereof is the same as that of a configuration element corresponding to other apparatuses. 
         [0095]      FIG. 5  is a sequence diagram illustrating flow of entire update processing. 
         [0096]    Initially, at a time of starting an engine, the software updating apparatus  11  downloads information to be updated from the server  2  and keeps the information in the memory unit  1102  of the software updating apparatus  11  (S 100 ). After then, when an engine state transitions from starting to a stop, preprocessing S 200  is implemented and then application processing is performed onto individual ECUs (herein, the ECU 1  is given as an example) (S 300 ). Lastly, postprocessing S 400  is implemented and the update processing is completed. A start timing of update processing (preprocessing S 200 , application processing S 300 , and postprocessing S 400 ) may be immediately after the completion of download processing S 2100  or a predetermined time in addition to a time of engine stop. 
         [0097]      FIG. 6  is a configuration example of the update information  5  acquired by the software updating apparatus  11  from the server  2 . 
         [0098]    The update information  5  is configured with a header portion D 1000 , preprocessing information D 2000 , control apparatus update information D 3000 , and postprocessing information D 4000 . 
         [0099]    The header portion D 1000  is configured with a vehicle ID (D 1001 ), which is information for uniquely identifying a vehicle, which is an update target, and an update ID (D 1002 ) for uniquely identifying the update. 
         [0100]    As in the above description, since the header portion D 1000  includes the vehicle ID D 1001  which can be compared with the IDs of vehicles that the vehicles keep, the vehicle to which update is to be applied can be confirmed without a mistake. In addition, unique identification of content of update can be carried out easier by the update ID D 1002  being included. For example, it is possible to quickly grasp which type of update is to be performed, by using the update ID D 1002  as an index in management information that is separately managed. 
         [0101]    The preprocessing information D 2000  is a region where information necessary for preprocessing, which is commonly implemented beforehand on each ECU in updating the program of the ECU, is stored. In this example, the preprocessing information D 2000  is configured with user approval necessity D 2001 , in which whether or not user approval is necessary in updating the program of the ECU is identified, and an update processing start timing D 2002 . 
         [0102]    The control apparatus update information D 3000  is a region where update information is stored for each ECU to be an update target. In this example, a case where the ECU 1  and the ECU 2  are update targets is given as an example and the control apparatus update information D 3000  is configured with update information D 3100  of ECU 1  and update information D 3200  of ECU 2 . 
         [0103]    The postprocessing information D 4000  is a region where information necessary for implementing postprocessing after updating in updating the program of the ECU is stored. In this example, the postprocessing information D 4000  is configured of user notification necessity D 4001 . 
         [0104]    As in the above description, the software updating apparatus  11  can appropriately execute necessary processing prior to applying update and necessary processing after applying update in software update processing by the update information  5  including preprocessing information and postprocessing information. 
         [0105]    In this example, since the user approval necessity D 2001  is included in the preprocessing information D 2000 , switching can be flexibly performed between processing in a case where approval from the user is not necessary immediately before updating, including a case where approval from the user is obtained in advance with another means and a case where update of the program is intended to be automatically applied to a car before sale, and processing in a case where user confirmation is intended to be obtained in the vehicle. In addition, since the user notification necessity D 4001  is included in the postprocessing information D 4000 , whether or not to perform notification to the user at a time of applying update can be controlled after updating, as in preprocessing. Furthermore, since the update processing start timing D 2002  is included, various start timings in accordance with update content and characteristics (updatable during travelling as well) of an ECU to be updated, including “immediately after download processing completion”, “when an engine state is transitioned from a state of starting to a state of stop”, “designated date and time”, and “discretion (user operation)”, can be flexibly controlled on a server side. 
         [0106]      FIG. 7  is a configuration example of the control apparatus update information D 3000 . 
         [0107]    The ECU 1  update information D 3100  and the ECU 2  update information D 3200  are configured with ECU IDs D 3101  and D 3201 , software versions D 3102  and D 3202 , preprocessing information D 3110  and D 3210 , application processing information D 3120  and D 3220 , postprocessing information D 3130  and D 3230 , and sums D 3104  and D 3204 , respectively. 
         [0108]    The ECU IDs D 3101  and D 3201  are identification information for uniquely identifying an ECU, and in this example,  1  (D 3101 ) is set for the ECU 1   12  and  2  (D 3201 ) is set for the ECU 2   16 . As in the above description, by update information including ECU IDs, an ECU, which is an update target, can be uniquely identified. 
         [0109]    The software versions D 3102  and D 3202  are version numbers of programs currently installed in the ECUs, and in this example, 1.0 (D 3102 ) is set for the ECU 1   12  and 1.1 (D 3202 ) is set for the ECU 2   16 . As in the above description, by update information including program versions, programs, which are update targets, can be identified without a mistake and a defect including applying a difference to the wrong version at a time of difference update can be prevented. 
         [0110]    The preprocessing information D 3110  and D 3210  are regions where information necessary for update preprocessing peculiar to the ECUs is stored and power consumption (D 3111  and D 3211 ) necessary for update, update time (D 3112  and D 3212 ) which takes for updating, error check necessity (D 3113  and D 3213 ), authentication necessity (D 3114  and D 3214 ), and learning value withdrawal information (D 3115  and D 3215 ) are stored. In this example, the power consumption D 3111  of the ECU 1   12  is set to 0.1 Wh, the update time D 3112  is set to 20 sec, the error check necessity D 3113  is set to “check required”, the authentication necessity D 3114  is set to “authentication required”, the learning value withdrawal information D 3115  is set to “learning value withdrawal required” and a read address “ 0 xAA”, the power consumption D 3211  of the ECU 2   16  is set to 0.2 Wh, the update time D 3212  is set to 60 sec, the error check necessity D 3213  is set to “check not required”, the authentication necessity D 3214  is set to “authentication not required”, and the learning value withdrawal information D 3215  is set to “learning value withdrawal not required”. As in the above description, preprocessing different for each ECU can be appropriately set by preprocessing information being included in update information for each ECU. For example, since power consumption and time for update are different for each ECU as described in this example, more appropriate update processing can be performed due to individual setting. In addition, in accordance with update content, error check necessity can be changed or withdrawing learning value can be changed. 
         [0111]    The application processing information D 3120  and D 3220  are regions where information necessary for applying new programs to the ECUs is stored. 
         [0112]    The application processing information D 3120  is configured with an application system ID 1  D 3121 , a block number D 3122 , an application system ID 2  D 3123 , and update data D 3124 . The same applies to the application processing information D 3220 . 
         [0113]    The application system ID 1  D 3121  and an application system ID 1  D 3221  are regions where systems of applying update are set and any one of “normal”, “difference”, “compression”, and “designation for each block” is set. “Normal” indicates applying update data through full update systems and indicates a system in which the update data itself is transmitted to the ECU and the ECU writes the received data as it is in a memory unit. “Difference” indicates applying update data through a difference update system and indicates a system in which difference data acquired from data before updating and data after updating is transmitted to the ECU and the ECU restores the data after updating from the received difference data and the data before updating that exists in the memory unit  1102  of the ECU to write the restored data in the memory unit. “Compression” indicates applying update data through a compression update system and indicates a system in which data obtained by compressing the data after updating is transmitted to the ECU and the ECU decompresses the received compressed data and then writes the decompressed data in the memory unit. “Designation for each block” indicates that the above “normal”, “difference”, and “compression” are designated for each logical block of the nonvolatile memory of the memory unit  1102  of the ECU, in an application system ID 2  which will be described later. 
         [0114]    The block number D 3122  and block numbers D 3125 , D 3222  and D 3224  are set to have the number of a logical block of the nonvolatile memory of the memory unit  1102  of the ECU to be an update target. 
         [0115]    The application system ID 2  D 3123  and an application system ID 2  D 3126  are regions where systems of applying update with respect to blocks designated by block numbers are set and any one of “normal”, “difference”, and “compression” is set. The application system ID 2  is not set in a case where “designation for each block” is set in the application system ID 1 . 
         [0116]    The update data D 3124  and update data D 3127 , D 3223 , and D 3225  are regions where data necessary for applying data after updating to the ECU is stored and a writing destination address information and the data after updating itself are stored in a case where the application system is “normal”, a writing destination address information and difference data acquired from data before updating and the data after updating is stored in a case where the application system is “difference”, or a writing destination address information and data obtained by compressing the data after updating is stored in a case where the application system is “compression”. 
         [0117]    In this example, in the ECU 1  update information D 3100 ,“designation for each block” is set in the application system ID 1  D 3121  and an application system is designated for each block, which is an update target. As an update target of the ECU 1 , the number  3  is designated in the block number D 3122 , the update system of the block is set to a “difference” update system in the application system ID 2  D 3123 , and the update data is stored in D 3124 . Furthermore, the block number  8  is designated as the update target in the block number D 3125 , a “compression” update system is designated as the application system of the block is designated in the application system ID 2  D 3126 , and the update data is stored in D 3127 . In addition, in the ECU 2  update information D 3200 , “normal” is set in the application system ID 1  D 3221  and using a normal update system with respect to all blocks which are update targets is designated. The number  8  is designated as an update target of the ECU 2  in the block number D 3222  and update data with respect to the block is stored in D 3223 . The block number  64  is designated as an update target in the block number D 3224  and update data with respect to the block is stored in D 3225 . 
         [0118]    As described hereinbefore, by including an application system indicating how a program after updating is applied to ECU update information for each ECU, a processing system that varies depending on the timing of update or update content can be designated with respect to the same ECU and which type of system is to be used with respect to which type of ECU at a time of application can be flexibly designated. Furthermore, by designating an application system for each update block, update processing with high efficiency is possible such as changing an application system for each block according to conditions including a generated difference data size and memory resources of the ECU. 
         [0119]    The postprocessing information D 3130  and D 3230  are regions where information necessary for update postprocessing peculiar to the ECUs is stored and resetability D 3131  and D 3231  indicating whether or not the ECUs may be reset immediately after update application are stored. In this example, both of the resetability D 3131  of the ECU 1  and the resetability D 3231  of the ECU 2  are set to “impossible”. As in the above description, by update information for each ECU including postprocessing information, postprocessing different for each ECU can be set. For example, as described in this example, in a case where information indicating resetability immediately after updating is added and there is a dependent relationship with update of other ECU, it is possible to control such that reset is performed after all ECUs having a dependent relationship are updated instead of performing reset immediately after. 
         [0120]    The sums D 3104  and D 3204  are checksums for detecting whether or not the update information D 3100  and D 3200  are wrong. By giving a sum for each ECU update information, instead of a sum for the entire update information, the fact that received ECU update information is correct can be confirmed even when the update information is received through streaming and each ECU update information is developed in a region of a memory corresponding to each ECU. 
         [0121]      FIG. 8  is a sequence diagram illustrating flow of the preprocessing S 200  in the update processing. 
         [0122]      FIG. 8( a )  is a sequence diagram illustrating flow of preprocessing related to the entire vehicle. 
         [0123]    The update control unit  11011  of the software updating apparatus  11  confirms that whether or not the initially received vehicle ID D 1001  matches a vehicle ID to be managed (S 201 ). In a case where the vehicle ID D 1001  does not match the vehicle ID to be managed (NO in S 201 ), processing is ceased without implementing subsequent processing (S 217 ). In a case where the vehicle ID D 1001  matches the vehicle ID (YES in S 201 ), next, network IDs necessary for being connected to the ECUs, which are update targets, via the network are acquired from the ECU IDs D 3101  and D 3201  (S 202 ) and program versions installed in the ECUs are acquired by using the acquired IDs (S 203 ). The update control unit  11011  confirms whether or not the program versions acquired within the vehicle match the software versions D 3102  and D 3202  received from the server (S 204 ) and in a case where the program versions do not match the software versions D 3102  and D 3202  (NO in S 204 ), processing is ceased without implementing subsequent processing (S 217 ). In a case where the program versions match the software versions D 3102  and D 3202  (YES in S 204 ), next, it is confirmed whether or not approval from the user is necessary in updating, from the user approval necessity D 2001  (S 205 ). In a case where the approval is not necessary (NO in S 205 ), processing proceeds to the next vehicle state check S 211 . In a case where the approval is necessary (YES in S 205 ), time (update time) necessary for update processing is calculated by adding the update time D 3112  and D 3212  included in download information together (S 206 ) and a user confirmation request, including the update ID D 1002  and the update time that are calculated in the HMI  13 , is transmitted via the in-car communication control unit  11013  (S 207 ). The HMI  13  configures G 100  of  FIG. 13  from the received update ID D 1002  and the update time and displays whether or not the user approves execution of update processing for confirmation (S 208 ). Next, results of user operation are transmitted as a reply to the user confirmation request S 207  (S 209 ). Once the update control unit  11011  of the software updating apparatus  11  receives the reply via the in-car communication control unit  11013 , update approval from the user included in the reply is confirmed (S 210 ). In a case where update is rejected (NO in S 210 ), processing is ceased without implementing subsequent processing (S 217 ). In a case where update is approved (YES in S 210 ), a variety of states of a vehicle to be confirmed before starting update are acquired (S 211 ) and it is confirmed whether or not update may be started (S 212 ). In a case where it is determined to be a startable state (OK in S 212 ), a start notification is transmitted to the server  2  via the external communication control unit  11012  (S 216 ). On the other hand, in a case where it is determined to be a state in which update start is impossible (NG in S 212 ), a request for displaying a reason for impossible start is transmitted to the HMI  13  via the in-car communication control unit  11013  (S 213 ) and the HMI  13  configures and displays a screen of G 200  of  FIG. 13  based on the received request for displaying a reason for impossible start (S 214 ). After displaying the reason, the HMI  13  transmits a reply to the software updating apparatus  11  (S 215 ) and once the update control unit  11011  of the software updating apparatus  11  receives the reply via the in-car communication control unit  11013 , processing is ceased (S 217 ). 
         [0124]    As described hereinbefore, by the header portion D 1000  including the vehicle ID D 1001  and the vehicle ID D 1001  being comparing with the ID of the vehicle that the vehicle keeps, the vehicle to which update is applied can be confirmed without a mistake. 
         [0125]    In addition, by update information including a program version and the program version being compared with version information acquired from the ECU, a defect, including recognizing a program, which is an update target, without a mistake but applying a difference to the wrong version at a time of difference update, can be prevented. 
         [0126]    Furthermore, since the user approval necessity D 2001  is included and determination as to whether or not to display a user approval screen can be made based on this inclusion, switching can be flexibly performed between processing in a case where approval from the user is not necessary immediately before updating, including a case where approval from user is obtained in advance with another means and a case where update of the program is intended to be automatically applied to the car before sale, and processing in a case where user confirmation is intended to be obtained in the vehicle. 
         [0127]    In addition, in a case where approval is obtained from the user, the user can appropriately determine whether or not to start update processing by time required for update, which is calculated from the update time included in the update information, being transmitted as well to the HMI and the time required for update being displayed by the HMI. 
         [0128]    Furthermore, if the received update ID is transmitted to the HMI and the update ID and detailed content based on the update ID are separately acquired and displayed by the HMI, the user can appropriately determine whether or not to start update processing. 
         [0129]    In a case where update processing cannot be started as a result of the vehicle state check, the user can appropriately grasp the state of the vehicle and obtain information for transitioning the state of the vehicle to a state where software update is possible by the content that the processing cannot be started being presented to the user. 
         [0130]      FIG. 8( b )  is a sequence diagram illustrating flow of preprocessing with respect to the ECU (ECU 1 ), which is an update target. 
         [0131]    The update control unit  11011  of the software updating apparatus  11  performs update preprocessing with the ECU 1  based on the preprocessing information D 3110  ( FIG. 7 ) within the ECU 1  update information D 3100  included in the update information  5  of  FIG. 6 . 
         [0132]    The update control unit  11011  of the software updating apparatus  11  initially reads the error check necessity D 3113  and determines whether or not an error check is necessary (S 220 ). In a case where an error check is not required (NO in S 220 ), processing proceeds to the next step without performing the error check. In a case where an error check is necessary (YES in S 220 ), a Diagnostic Trouble Code (DTC) reading request is transmitted to the ECU 1  (S 221 ). Once a reply is received via the in-car communication control unit  11013  (S 222 ), the update control unit  11011  of the software updating apparatus  11  confirms content of the DTC included in the reply, determines whether or not an abnormality has occurred in the ECU 1  (S 223 ), and performs abnormality termination processing, instead of performing the subsequent processing, in a case where it is determined that an abnormality has occurred (NG in S 223 ). In the abnormality termination processing, the update control unit  11011  transmits an abnormality display request to the HMI  13  via the in-car communication control unit  11013  (S 235 ) and the HMI  13  configures and displays a screen based on the received request (S 236 ). After displaying the screen, the HMI  13  transmits a reply to the software updating apparatus  11  (S 237 ) and the update control unit  11011  of the software updating apparatus  11  transmits an abnormality notification to the server  2  and then ceases processing (S 217 ) once the reply is received via the in-car communication control unit  11013  (S 238 ). In a case where it is determined that the ECU 1  is normal (OK in S 223 ), the update control unit  11011  reads the authentication necessity D 3114  and determines whether or not authentication processing with the ECU 1  is necessary (S 224 ). In a case where authentication is not required (NO in S 224 ), processing proceeds to the next step without performing the authentication processing. In a case where authentication is necessary (YES in S 224 ), an authentication request is transmitted to the ECU 1  (S 225 ). Once a reply is received via the in-car communication control unit  11013  (S 226 ), the update control unit  11011  of the software updating apparatus  11  generates a response from information included in the reply (S 227 ) and transmits the response to the ECU 1  via the in-car communication control unit  11013  (S 228 ). Once a result reply is received via the in-car communication control unit  11013  (S 229 ), the update control unit  11011  of the software updating apparatus  11  determines whether or not authentication has succeeded (S 230 ) and performs abnormality termination processing without performing the subsequent processing in a case where authentication is determined to be failed (NG in S 230 ). In a case where authentication with the ECU 1  is determined to be succeeded (OK in S 230 ), the update control unit  11011  reads the learning value withdrawal information D 3115  and determines whether or not learning value withdrawal with the ECU 1  is necessary (S 231 ). In a case where learning value withdrawal is not required (NO in S 231 ), processing proceeds to the next step without performing learning value withdrawal processing. In a case where learning value withdrawal is necessary (YES in S 231 ), a data acquiring request is transmitted to the ECU 1  based on information included in learning value withdrawal information D 3115  (S 232 ). Once a reply is received via the in-car communication control unit  11013  (S 233 ), the update control unit  11011  saves a learning value included in the reply in the memory unit  1102  of the software updating apparatus  11  (S 234 ). As in the above description, by update information including error check necessity, authentication necessity, and learning value withdrawal information and preprocessing being implemented based on the information, a sequence can be configured such that necessary and sufficient processing only is flexibly implemented, such as error check necessity is changed in accordance with the update content and a withdrawing learning value is changed. 
         [0133]      FIG. 9( a )  is a sequence diagram of network ID acquisition processing S 202 . 
         [0134]    The update control unit  11011  of the software updating apparatus  11  designates ECU ID=1 and transmits an ID acquisition request to the low-speed in-car network  10  via the in-car communication control unit  11013  (S 2021 ). Once the ID acquisition request, in which ECU ID=1 is designated, is received, the ECU 1  returns a reply, in which the network ID of the ECU 1  is set, to the software updating apparatus  11  (S 2022 ). 
         [0135]    Next, the update control unit  11011  of the software updating apparatus  11  designates ECU ID=2 and transmits an ID acquisition request to the low-speed in-car network  10  via the in-car communication control unit  11013  (S 2023 ). Once the ID acquisition request, in which ECU ID=2 is designated, is received, the ECU 2  returns a reply, in which the network ID of the ECU 2  is set, to the software updating apparatus  11  (S 2024 ). 
         [0136]    As in the above description, by acquiring the ID on the network of the corresponding ECU based on the ECU ID, the software updating apparatus  11  can appropriately communicate with the ECU connected through the in-car network. 
         [0137]      FIG. 9( b )  is a sequence diagram of software version acquisition processing S 203 . 
         [0138]    The update control unit  11011  of the software updating apparatus  11  transmits a version acquisition request to the ECU 1  via the in-car communication control unit  11013  (S 2031 ). Once the version acquisition request is received, the ECU 1  returns a reply, in which the software version of the ECU 1  is set, to the software updating apparatus  11  (S 2032 ). 
         [0139]    Next, the update control unit  11011  of the software updating apparatus  11  transmits a version acquisition request to the ECU 2  via the in-car communication control unit  11013  (S 2033 ). Once the version acquisition request is received, the ECU 2  returns a reply, in which the software version of the ECU 2  is set, to the software updating apparatus  11  (S 2034 ). 
         [0140]    As in the above description, by acquiring a program version from the ECU and the program version being compared with a software version included in update information, a detect, including recognizing a program, which is an update target, without a mistake but applying a difference to the wrong version at a time of difference update, can be prevented. 
         [0141]      FIG. 9( c )  is a sequence diagram of vehicle state acquisition processing S 211 . 
         [0142]    The update control unit  11011  of the software updating apparatus  11  calculates (S 2111 ) power consumption of update processing by adding power consumption D 3111  and D 3211  included in the update information  5  together. Next, the update control unit  11011  transmits a battery level acquisition request to the power source management ECU  14  via the in-car communication control unit  11013  (S 2112 ). Once the battery level acquisition request is received, the power source management ECU  14  transmits a reply including the battery level of the storage battery (S 2113 ). Once the battery level acquisition reply is received, the update control unit  11011  of the software updating apparatus  11  compares a value obtained by subtracting power consumption calculated beforehand from the battery level included in the received reply with a predetermined value d (for example, a value obtained by adding a margin to the amount of power necessary for staring an engine, such as 1 Wh) (S 2114 ). It is determined to be a state where update cannot be started in a case where the value obtained by subtracting power consumption from the battery level is equal to or lower than the predetermined value d, it is determined to be a state where update can be started in a case where the value obtained by subtracting power consumption from the battery level is larger than the predetermined value d, and this result is used in start determination S 212  for the update of  FIG. 8 . 
         [0143]    As in the above description, by comparing the battery level acquired from the power source management ECU with the power consumption obtained by adding power consumption included in the update information for each ECU together and by executing update processing based on the result of comparison, a defect of discontinuing power supply during updating treatment of the ECU can be prevented. 
         [0144]      FIG. 10  is a sequence diagram illustrating flow of application processing S 300  in update processing. 
         [0145]    The update control unit  11011  of the software updating apparatus  11  confirms an update system to be applied to the ECU from the application system ID 1  (D 3121  or D 3221 ) included in the update information  5  received from the server (S 301 ). 
         [0146]    Hereinafter, a case where the update system ID 1  (D 3221 ) indicates other than “designation for each block” (other than “designation for each block” in S 301 ) will be described with the update information D 3220  of the ECU 2   16  given as an example. 
         [0147]    In a case where the update system ID 1  (D 3221 ) indicates other than “designation for each block”, the update control unit  11011  determines that common application processing is to be performed on all blocks with respect to the ECU 2 , confirms the application system designated in the update system ID 1  (D 3221 ) (S 302 ), and starts processing on the block number  8  set in an initial application block number D 3222  included in the ECU 2  update information D 3200 . In a case where the application system ID 2  D 3123  indicates full update (“normal” in S 302 ), full update application processing S 310  is applied to the block. In a case where the application system. ID 2  D 3123  indicates compression update (“compression” in S 302 ), compression update application processing S 320  is applied to the block. In a case where the application system ID 2  D 3123  indicates difference update (“difference” in S 302 ), difference update application processing S 330  is applied to the block. Once processing of the block, which is an initial processing target, is completed, the absence and presence of the next processing target block is confirmed (S 303 ) and in a case where the next processing target block is present (YES in S 303 ), the next block number is read and full update application processing is implemented on the set block. After then, application processing is performed on all of processing target blocks. In a case where the next processing target block is absent (NO in S 303 ), processing proceeds to confirm the absence and presence of the next processing target ECU (S 306 ). 
         [0148]    Next, a case where the update system ID 1  (D 3121 ) indicates “designation for each block” (“designation for each block” of S 301 ) will be described with the application processing information D 3120  of the ECU 1   12  given as an example. 
         [0149]    In a case where update system ID 1  (D 3121 ) indicates “designation for each block”, the update control unit  11011  determines that an update system is designated for each block with respect to the ECU 1  and starts processing on the block number  3  set in the initial application block number D 3122  of the ECU 1 . The update control unit  11011  initially confirms the application system ID 2  D 3123  indicating an application system with respect to the block (S 304 ). In a case where the application system ID 2  D 3123  indicates full update (“normal” in S 304 ), the full update application processing S 310  is applied to the block. In a case where the application system ID 2  D 3123  indicates compression update (“compression” in S 304 ), the compression update application processing S 320  is applied to the block. In a case where the application system. ID 2  D 3123  indicates difference update (“difference” in S 304 ), the difference update application processing S 330  is applied to the block. Once processing of the block, which is an initial processing target, is completed, the absence and presence of the next processing target block is confirmed (S 305 ) and in a case where the next processing target block is present (YES in S 305 ), the next block number is read and processing from application system ID 2  confirmation S 304  to confirmation of the absence and presence of processing target block S 305  is implemented on the set block. After then, this processing is repeated with respect to all of processing target blocks. In a case where the next processing target block is absent (NO in S 305 ), processing proceeds to confirmation of the absence and presence of the next processing target ECU (S 306 ). 
         [0150]    Once the application processing of the processing target ECU is completed, the absence and presence of the next processing target ECU is confirmed (S 306 ). In a case where the next processing target ECU is present (YES in S 306 ), processing returns to the beginning and processing of the ECU is started. In a case where the next processing target ECU is absent (NO in S 306 ), the application processing is terminated. 
         [0151]    As described hereinbefore, by selecting an application system to be executed according to the application system included in the received update information and executing the application processing, determination as to which type of system is to be used with respect to which type of ECU, including designating a processing system that varies depending on the timing of update or update content with respect to the same ECU, can be made at a time of application. Furthermore, by selecting an application system to be executed according to the application system designated for each update block as the application system and executing application processing, update processing with high efficiency is possible, such as changing an application system for each block under conditions, such as a generated difference data size and memory resources of the ECU. 
         [0152]      FIG. 11( a )  is a sequence diagram of the full update application processing S 310  implemented between the software updating apparatus  11  and the ECU. 
         [0153]    Initially, the update control unit  11011  of the software updating apparatus  11  designates a block number with respect to the ECU and issues an erasing request via the in-car communication control unit  11013  (S 311 ). The updating unit  12012  of the ECU 2   16  which has received the erasing request via the in-car communication control unit  11013  erases the region of the nonvolatile memory of the memory unit  1102  of the ECU 1  (S 312 ) and transmits a normal reply to the software updating apparatus  11  via the in-car communication control unit  11013  (S 313 ). The update control unit  11011  which has received the normal reply from the ECU 1  transmits a data transmission and writing request that includes a writing destination address and data to be written in the memory unit of the ECU to the ECU 1  via the in-car communication control unit  11013  (S 314 ). The updating unit  12012  of the ECU 1  which has received the data transmission and writing request writes the received data at the designated writing destination address of the nonvolatile memory of the memory unit  1102  (S 315 ) and transmits a normal reply to the software updating apparatus  11  via the in-car communication control unit  11013  in a case where writing has succeeded (S 316 ). 
         [0154]      FIG. 11( b )  is a sequence diagram of the compression update application processing S 320  implemented between the software updating apparatus  11  and the ECU. 
         [0155]    Initially, the update control unit  11011  of the software updating apparatus  11  designates a block number with respect to the ECU and issues an erasing request via the in-car communication control unit  11013  (S 321 ). The updating unit  12012  of the ECU 1   12  which has received the erasing request via the in-car communication control unit  11013  erases the region of the nonvolatile memory of the memory unit  1102  of the ECU 1  (S 322 ) and transmits a normal reply to the software updating apparatus  11  via an in-car communication control unit  11013  (S 323 ). The update control unit  11011  which has received the normal reply from the ECU 1  transmits a data transmission, decompression, and writing request that includes a writing destination address and data to be written in the memory unit of the ECU to the ECU 1  via the in-car communication control unit  11013  (S 324 ). The updating unit  12012  of the ECU 1  which has received the data transmission, decompression, and writing request decompresses the received compressed data (S 325 ), then writes the received data to the designated writing destination address of the nonvolatile memory of the memory unit  1102  (S 326 ), and transmits a normal reply to the software updating apparatus  11  via the in-car communication control unit  11013  in a case where writing has succeeded (S 327 ). 
         [0156]      FIG. 11( c )  is a sequence diagram of the difference update application processing S 330  implemented between the software updating apparatus  11  and the ECU. 
         [0157]    Initially, the update control unit  11011  of the software updating apparatus  11  transmits a data transmission and restoration request that includes difference data read from the ECU 1  update information D 3100  stored in the memory unit  1102  to the ECU 1  via the in-car communication control unit  11013  (S 331 ). The updating unit  12012  of the ECU 1  which has received the data transmission and restoration request restores data after updating using the received difference data and the current program or data stored in the nonvolatile memory of the memory unit  1102  to store the restored data in the volatile memory (S 332 ) and transmits a normal reply to the software updating apparatus  11  via the in-car communication control unit  11013  (S 333 ). The update control unit  11011  which has received the normal reply from the ECU 1  designates a block number with respect to the ECU 1  and issues an erasing request (S 334 ). The updating unit  12012  of the ECU which has received the erasing request via the in-car communication control unit  11013  erases the region of the nonvolatile memory of the memory unit  1102  of the ECU 1  (S 335 ) and transmits a normal reply to the software updating apparatus  11  via the in-car communication control unit  11013  (S 336 ). The update control unit  11011  of the software updating apparatus  11  which has received the normal reply from the ECU 1  transmits a writing request (including a block number of a writing destination) to the ECU 1  via the in-car communication control unit  11013  (S 337 ). The updating unit  12012  of the ECU 1  which has received the writing request writes the update data after restoration, which is stored in the volatile memory of the memory unit  1102 , in the nonvolatile memory of the memory unit  1102  (S 338 ) and transmits a normal reply to the software updating apparatus  11  via the in-car communication control unit  11013  in a case where writing has succeeded (S 339 ). 
         [0158]    Hereinbefore, in a data transmission request (data transmission and writing request/data transmission, decompression, and writing request/data transmission and restoration request) in the processing of  FIG. 11 , update data is divided into an appropriate unit according to the bandwidth of the in-car network and then transmitted. 
         [0159]      FIG. 12  is a sequence diagram illustrating flow of the postprocessing S 400  in update processing. 
         [0160]    Initially, the update control unit  11011  of the software updating apparatus  11  confirms update states of the ECUs, which are update targets (S 401 ). In a case where anyone of the ECUs, which are the update targets, is not updated (NO in S 401 ), the update control unit  11011  again implements confirmation after standing by for a predetermined length of time (for example, 100 msec). In a case where all of the ECUs, which are the update targets, are updated (YES in S 401 ), a reset request is transmitted to the ECUs, which are the update targets (S 402  and S 403 ). Once the reset request from the software updating apparatus  11  is received, the ECU 1  and the ECU 2  transmit a normal reply (S 404  and S 405 ) and perform reset processing (S 406  and S 407 ). The software updating apparatus  11  transmits an update completion notification to the server (S 408 ). Next, the user notification necessity D 4001  included in the postprocessing information D 4000  is confirmed (S 409 ). In a case where a user notification is necessary (YES in S 409 ), a completion notification request is transmitted to the HMI  13  (S 410 ). Once the completion notification request is received, the HMI  13  configures and displays a screen G 300  (S 411 ) and transmits a reply to the software updating apparatus  11  (S 412 ). In a case where a user notification is not necessary (NO in S 409 ), processing is terminated. 
         [0161]      FIG. 13  is an example of a screen of the HMI  13 . G 100  is an example of a screen that is presented to inquire of the user about software update startability. The screen G 100  is configured with an update ID G 101 , time required for update G 102 , an update approval button G 103 , and an update holding button G 104 . 
         [0162]    As in the above description, the user can appropriately determine whether or not to start update processing by the HMI displaying the time required for update received from the software updating apparatus  11 . In addition, if the update ID received from the software updating apparatus  11  or detailed content acquired based on the update ID is displayed, the user can appropriately determine whether or not to start update processing. 
         [0163]    G 200  is an example of a screen that presents a reason for not starting software update and a solution in a case of a state where the vehicle cannot start software update. The screen G 200  is configured with an update cessation reason G 201  and a confirmation button G 202 . Herein, “Update cannot be started due to a low battery level. Please try again after travelling.” is displayed as a reason for update cessation. As in the above description, by presenting content of update cessation to the user in a case where update cannot be started and update is ceased, the user can appropriately grasp a state of the vehicle and obtain information for transitioning the state of vehicle to a state where software update is possible. 
         [0164]    G 300  is an example of a screen to notify the user of completion of processing in a case where software update of the vehicle is completed. The screen G 300  is configured with the update ID G 101  and the confirmation button G 302 . 
       EXAMPLE 2 
       [0165]    In the aforementioned Example 1, a method for inquiring of a device connected on the in-car network and acquiring a network ID for communicating with the device by means of an ECU ID included in ECU update information has been described. In addition, a transmission timing of data has not been particularly mentioned. In this example, a case where ECU update information includes connection information will be described. 
         [0166]      FIG. 15  is a configuration example of ECU update information including information for being connected to a device on the in-car network. 
         [0167]    D 3100  is ECU 1  update information and D 5100  is ECU 3  update information. The ECU update information of this example is configured with domains D 3105  and D 5105 , Net IDs D 3106  and D 5106 , and bandwidths D 3107  and D 5107  in addition to the ECU update information of Example 1. 
         [0168]    The domains D 3105  and D 5105  are identification information to identify a network domain to which the ECU is connected and are set to a low-speed in-car LAN (D 3105 ) in a case of the ECU 1   12  and to a high-speed in-car LAN (D 5105 ) in a case of the ECU 3   18 . 
         [0169]    The Net IDs D 3106  and D 5106  are identification information for identifying an ECU on the network and are set to A (D 3106 ) in a case of the ECU 1   12  and to B (D 5106 ) in a case of the ECU 3   18 . 
         [0170]    As described hereinbefore, by the update information  5  including information necessary for network connection for each ECU, processing can be simplified or speeded up as processing of inquiring of a device within the car and acquiring network connection information is omitted, or setup related to the software updating apparatus  11  necessary for update preprocessing can be simplified as the software updating apparatus  11  may not keep a table in which the ECU ID and the network connection information are correlated with each other. 
         [0171]    The bandwidths D 3107  and D 5107  indicate network bandwidths that are usable for updating the ECUs and are set to 100 kbps (D 3107 ) in a case of the ECU 1   12  and to 10 Mbps (D 5107 ) in a case of the ECU 3   18 . The software updating apparatus  11  controls a data transmission timing such that a set bandwidth is not exceeded at a time of update data transmission, using this bandwidth information. 
         [0172]    As described hereinbefore, by a network bandwidth that is usable in updating the ECU being set in update information for each ECU and the software updating apparatus  11  executing update processing in accordance with the information, speeding-up of update processing can be achieved to an extent of not affecting other apparatuses. 
       EXAMPLE 3 
       [0173]    In the aforementioned Example 1, a method for determining whether or not to start update processing by means of power consumption set in ECU update information has been described. In this example, update processing start conditions other than the above conditions will be described with preprocessing information of ECU update information of the ECU 1  given as an example. 
         [0174]      FIG. 16( a )  is a configuration example of the preprocessing information D 3110  of the ECU 1  update information D 3100  in this example. 
         [0175]    The preprocessing information D 3110  is configured with updatability during travelling D 31131 , an IGN state D 31132 , an engine state D 31133 , a steering lock state D 31134 , a gear state D 31135 , a brake state D 31136 , a door lock stateD 31137 , and a charge state D 31138 . 
         [0176]    The updatability during travelling D 31131  is identification information indicating whether or not a program of the ECU may be updated during travelling and any one of “YES” and “NO” may be set. A case of “YES” refers to a case where the ECU is updatable during travelling and a case of “NO” refers to a case where the ECU cannot be updated during travelling. As in the above description, by update information for each ECU including identification information as to whether or not to approve update during travelling, efficient update processing is possible, such as implementing software update of the ECU, which does not affect travelling during travelling. 
         [0177]    The IGN state D 31132  is identification information indicating a state of ignition (IGN) in which program update of the ECU is startable and is set to any one of “ON”, “accessories (ACC)”, and “OFF”. For example, in a case where the IGN state D 31132  is set to “OFF”, update is not executed in a case where the IGN state of the vehicle acquired by the update control unit  11011  of the software updating apparatus  11  is other than “OFF”. As in the above description, by update information for each ECU including an IGN state in which update processing is startable, starting software update processing of the ECU in an appropriate power supply state is possible. 
         [0178]    The engine state D 31133  is identification information indicating an engine state in which program update of the ECU is startable and is set to any one of “stop”, “ON”, and “- (Don&#39;t Care)”. For example, in a case where the engine state D 31133  is set to “stop”, update is not executed in a case where an engine state of the vehicle acquired by the update control unit  11011  of the software updating apparatus  11  is other than “stop”. As in the above description, by update information for each ECU including an engine state in which update processing is startable, starting software update processing of the ECU in an appropriate state is possible. 
         [0179]    The steering lock state D 31134  is identification information indicating a steering lock state in which program update of the ECU is startable and any one of “lock” and “- (Don&#39;t Care)” is set. For example, in a case where the steering lock state D 31134  is set to “lock”, update is not executed in a case where a steering lock state of the vehicle acquired by the update control unit  11011  of the software updating apparatus  11  is other than “lock”. As in the above description, by update information for each ECU including a steering lock state in which update processing is startable, starting software update processing of the ECU at an appropriate state is possible. 
         [0180]    The gear state D 31135  is identification information indicating a gear (shift lever) state in which program update of the ECU is startable and any one of “P (Parking)”, “N (Neutral)”, and “- (Don&#39;t Care)” is set. For example, in a case where the gear state D 31135  is set to “P”, update is not executed in a case where a gear state of the vehicle acquired by the update control unit  11011  of the software updating apparatus  11  is other than “P”. As in the above description, by update information for each ECU including a gear state in which update processing is startable, starting software update processing of the ECU at an appropriate state is possible. 
         [0181]    The brake state D 31136  is identification information indicating a brake state in which program update of the ECU is startable and any one of “lock” and“- (Don&#39;t Care)” is set. For example, in a case where the brake state D 31136  is set to “lock”, update is not executed in a case where a brake state of the vehicle acquired by the update control unit  11011  of the software updating apparatus  11  is other than “lock”. As in the above description, by update information for each ECU including a brake state in which update processing is startable, starting software update processing of the ECU at an appropriate state is possible. 
         [0182]    The door lock state D 31137  is identification information indicating a door state in which program update of the ECU is startable and any one of “lock”, “open”, and “- (Don&#39;t Care)” is set. For example, in a case where the door lock state D 31137  is set to “lock”, update is not executed in a case where a door lock state of the vehicle acquired by the update control unit  11011  of the software updating apparatus  11  is other than “lock”. As in the above description, by update information for each ECU including a door lock state in which update processing is startable, starting software update processing of the ECU at an appropriate state is possible. 
         [0183]    The charge state D 31138  is identification information indicating a charge state in which program update of the ECU is startable, for example, in a plugin hybrid electric vehicle (PHEV), and anyone of “during charging”, “not during charging”, and “- (Don&#39;t Care)” is set. For example, in a case where the charge state D 31138  is set to “during charging”, update is not executed in a case where a charge state of the vehicle acquired by the update control unit  11011  of the software updating apparatus  11  is other than “during charging”. As in the above description, by update information for each ECU including a charge state in which update processing is startable, starting software update processing of the ECU at an appropriate state is possible. 
         [0184]      FIG. 16( b )  is an example of a screen that presents a reason for not starting software update and a solution in a case of a state where the vehicle cannot start software update. G 2011  is an example of displaying “Update is impossible during travelling. Please start updating after the vehicle is stopped.” as a reason for update cessation from the updatability during travelling D 31131  and a result of vehicle state determination. G 2012  is an example of displaying “Update is impossible during engine operation. Please start updating after an engine stop.” from the engine state D 31133  and a result of vehicle state determination. G 2013  is an example of displaying “Update is impossible when the shift lever is not at “P”. Please start updating after the shift lever is put to “P”.” from the gear state D 31135  and a result of vehicle state determination. G 2014  is an example of displaying “The emergency brake is not put on. Please start updating after the emergency brake is put on.” from the brake state D 31136  and a result of vehicle state determination. As in the above description, by the content of update cessation being presented to the user in a case where update cannot be started and update is ceased, the user can appropriately grasp a state of the vehicle and obtain information for transitioning the state of the vehicle to a state where software update is possible. 
       EXAMPLE 4 
       [0185]    In Example 1, a method responding to different application systems by changing the order (sequence) of transmitting a control request from the software updating apparatus  11  to the ECU, which is an update target, according to an application system included in update information has been described. In this example, a method responding to different application systems by issuing a request in the order common to each of the systems, with a control request being generated based on update information and the ECU, which is an update target, performing processing based on parameters included in the control request, will be described. 
         [0186]      FIG. 17  is a configuration example of the application processing information D 3120  of the ECU 1   12  and a data transmission request transmitted from a software updating apparatus in this example to the ECU 1   12 . Herein, an example in which information necessary for writing is initially listed in all update target blocks and transmission data is combined behind the information will be described. 
         [0187]    In a case where the application system is a difference application system or a compression application system, data sizes 1  D 31281  and D 31291  indicate data sizes which are compressed or data sizes in which a difference is taken into account. Data sizes 2  D 31282  and D 31292  indicate data sizes written in the ROM. In a case where the application system is a difference application system or a compression application system, sizes after restoration are set. Writing destination addresses D 31283  and D 31293  indicate writing destination addresses of a ROM to be written in the ECU, which is an update target. The content of the rest of configuration elements is the same as that of the application processing information D 3120  of  FIG. 7 . 
         [0188]    Data transmission request D 1700  is configured with an application system D 1701 , a data size D 1702 , a writing destination address D 1703 . The application system D 1701  is set to an application system indicating how to apply update in the ECU, which is an update target, and is set to identification information, including “normal”, “difference”, and “compression”. The data size D 1702  indicates a data size transmitted from the software updating apparatus  11  to the ECU 1   12 . The writing destination address D 1703  indicates address information of a destination at which transmission data is to be written. 
         [0189]      FIG. 18  is a sequence example of application processing with respect to one block (block number  3 ) in a case where update application processing is performed with the ECU 1   12  based on the application processing information D 3120  of  FIG. 17 . 
         [0190]      FIG. 18( a )  is a processing sequence between the software updating apparatus  11  and the ECU 1   12  in this example. 
         [0191]    The update control unit  11011  of the software updating apparatus  11  initially reads the update information  5  and configures a data transmission request based on the application processing information D 3120  of  FIG. 17  (S 340 ). In the application system D 1701  of the data transmission request D 1700 , “difference”, which is the application system ID 2  D 3123  of the application processing information D 3120  of  FIG. 17 , is set. In the data size D 1702  of the data transmission request D 1700 , a value of the data size 2  D 31282  of the application processing information D 3120  of  FIG. 17  is set in a case where the application system D 1701  is “normal” and a value of the data size 1  D 31281  of the application processing information D 3120  of  FIG. 17  is set in a case where the application system D 1701  is other than “normal”. In the writing destination address D 1703  of the data transmission request D 1700 , a value of the writing destination address D 31283  of the application processing information D 3120  of  FIG. 17  is set. After data is configured, the update control unit  11011  of the software updating apparatus  11  transmits the configured data transmission request D 1700  to the ECU 1  (S 341 ). Once the data transmission request is received, the ECU 1  implements data transmission request reception processing (S 342 ) and transmits a reply to the software updating apparatus  11 . Once the reply is received (S 343 ), the software updating apparatus  11  reads the update data D 3124  of the ECU 1  from the application processing information D 3120  (S 344 ) and transmits the data to the ECU 1  (S 345 ). Once the update data is received, the ECU 1  implements update data reception processing (S 346 ) and transmits a reply to the software updating apparatus  11  (S 347 ). Data transmissions S 345  to S 346  are repeated until the entire update data D 3124  is transmitted. Once the entire update data D 3124  is transmitted, the software updating apparatus  11  transmits a data transmission completion request (S 348 ). Once the data transmission completion request is received, the ECU 1  implements data transmission completion request reception processing (S 349 ) and returns a reply to the software updating apparatus  11  (S 350 ). Once the reply is received, the software updating apparatus  11  terminates processing with respect to this block (block number  3 ) and performs processing for the next block. 
         [0192]      FIG. 18( b )  is a flow chart of the data transmission request reception processing S 342  in the ECU 1 . The ECU 1  keeps information (the application system D 1701 , the data size D 1702 , and the writing destination address D 1703 ) included in the initially received data transmission request D 1700  (S 3421 ). Whether or not the application system D 1701  indicates “difference” is confirmed (S 3422 ). In a case where the application system D 1701  indicates other than “difference” (NO in S 3422 ), a block of the ROM corresponding to the writing destination address D 1703  is erased (S 3423 ). In a case where the application system D 1701  indicates “difference” (YES in S 3422 ), processing is terminated as it is. In a case where an abnormality has occurred in information saving (S 3421 ) and ROM block erasing (S 3423 ) in the sequence of  FIG. 18( b ) , the ECU 1   12  returns an abnormality reply to the software updating apparatus  11 . 
         [0193]      FIG. 18( c )  is a flow chart of the update data reception processing S 346  in the ECU 1 . The ECU 1  temporarily saves the received data in a random access memory (RAM) (S 3461 ). Next, it is determined that whether or not the application system is a “difference” application system from the application system D 1701  kept in S 3421  (S 3462 ). In a case where the application system D 1701  indicates “difference” (YES in S 3462 ), processing is terminated as it is. In a case where the application system D 1701  indicates other than “difference” (NO in S 3462 ), it is confirmed whether or not a data size saved in a temporary region is equal to or larger than a regular size (a region size of 512 Byte that can be secured as a temporary buffer) (S 3463 ). In a case where the received size is smaller than the regular size (NO in S 3463 ), it is determined whether or not the application system is a “normal” application system from the application system D 1701  kept in S 3421  (S 3464 ). In a case where the received size is equal to or larger than the regular size (YES in S 3463 ), processing is terminated as it is. In a case where the application system is other than “normal” (compression) application system (NO in S 3464 ), the temporarily saved data is restored (S 3465 ) and the restored data is written in the ROM (S 3466 ). In a case where the application system is “normal” application system (YES in S 3464 ), the temporarily saved data is written in the ROM as it is (S 3466 ). In a case where an abnormality has occurred in temporarily saving (S 3461 ), restoration (S 3465 ), writing in the ROM (S 3466 ) in the sequence of  FIG. 18( c ) , the ECU 1   12  returns an abnormality reply to the software updating apparatus  11 . 
         [0194]      FIG. 18( d )  is a flow chart of the data transmission completion request reception processing S 349  in the ECU 1   12 . The ECU 1   12  determines whether or not the application system is a “difference” application system from the application system D 1701  kept in S 3421  (S 3491 ). In a case where the application system is other than a “difference” application system (NO in S 3491 ), the data written in the ROM is verified (S 3496 ) and processing is terminated. In a case where the application system is a “difference” application system (YES in S 3491 ), the temporarily saved data is restored (S 3492 ) and verification of the restored data is performed before being written in the ROM (S 3493 ). In a case where the verification has failed (NG in S 3493 ), processing is terminated. In a case where the verification has succeeded (OK in S 3493 ), the block of the ROM corresponding to the writing destination address D 1703  kept in S 3421  is erased (S 3494 ) and the restored data is written at the writing destination address D 1703  (S 3495 ). After then, the data written in the ROM is verified (S 3496 ) and processing is terminated. The ECU 1   12  returns an abnormality reply to the software updating apparatus  11  in a case where an abnormality has occurred in difference restoration (S 3492 ), ROM block erasing (S 3494 ), and writing in the ROM (S 3495 ), in addition to a case where data verification (S 3493  or S 3496 ) has failed, in the sequence of  FIG. 18( d ) . 
         [0195]    As in the above description, by the application processing information D 3120  including an application system, a data size 1  (data size after difference or compression), a data size 2  (data size written in a ROM), a writing destination address, by a data transmission request to be transmitted to the ECU 1  being configured based on the above information, and by the ECU receiving the request switching processing based on the content of the data transmission request, determination as to which type of system is to be used with respect to which type of ECU, including designating a processing system that varies depending on the timing of update or update content with respect to the same ECU, can be made at a time of application. 
       REFERENCE SIGNS LIST 
       [0196]      1 : vehicle,  2 : server,  3 : Internet,  4 : access network,  5 : update information,  10 : in-car network,  11 : software updating apparatus,  12 : ECU 1 ,  13 : HMI,  14 : power source management ECU,  1101 ,  1201 : control unit,  1102 : memory unit,  1104 : time management unit,  1105 : WAN I/F,  1106 : low-speed in-car LAN I/F,  1107 : high-speed in-car LAN I/F,  1202 : sensor,  1203 : actuator,  11010 ,  12010 ,  16010 : control program,  11011 : update control unit,  11012 : external communication control unit,  11013 : in-car communication control unit,  11014 : high-speed in-car communication control unit,  12012 ,  16012 : updating unit