Vehicle information registration device

Abstract

To be able to suppress amounts of data from becoming enormous, even when a new type of vehicle is added.SOLUTION: A node table group in which a next node table destination is designated on the basis of conditions for specification information designation and for true / false determination which are used for multiple branching and a determined result, and a vehicle type para-pattern table in which a plurality of vehicle type parameters is recorded for each pattern number are stored in a storage part of a camera unit 1 that is mounted on a vehicle M, and an operator records the table group and the table in an EEPROM11a through an input part 12. When starting the vehicle, a vehicle type code of the vehicle M is read out, specification information written in the vehicle type code is classified for every type, then indexed, and is converted into specification information groups (classification); a node tree is branched into lower classes and a terminal node is searched, while collating the specification information designated on the basis of the node table with the condition for true determination; and a vehicle type para-pattern of the vehicle M is determined in accordance with a pattern number defined in the terminal node.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present invention relates to a vehicle information registration device that registers a vehicle model code of a vehicle in a storage unit of an electronic device mounted on the vehicle. [Background technology]

[0002] As is well known, vehicles are equipped with various electronic devices, and in many cases, electronic devices are common to different vehicle models. Therefore, at the stage of manufacturing an electronic device, it is unknown which vehicle model the electronic device will be installed in. Therefore, in order to be able to handle any vehicle model, the specification data of all vehicle models to which the electronic device will be installed is written in advance in the storage unit (non-volatile memory) of the electronic device, linked 1:1 to the vehicle model code.

[0003] Then, when the vehicle model to be equipped with the electronic device is determined on the production line, or after the electronic device is installed in the vehicle, the vehicle model code of the vehicle written in the storage unit is determined. As a result, the specifications (vehicle model parameters) of the vehicle model linked to the vehicle model code are determined. The vehicle model code is composed of a code that combines multiple pieces of specification information according to classifications such as vehicle type (vehicle model system), body shape, destination, and equipment.

[0004] Since this vehicle model code is added every time a new vehicle model is added, the specifications linked to the vehicle model code of the new vehicle model are naturally also written into the storage unit of the electronic device or into the storage unit read by the electronic device. As a result, since the specification data written into the storage unit is also added every time a new vehicle model is added, there is an inconvenience that the amount of data in the storage unit gradually becomes huge.

[0005] As a countermeasure to this problem, for example, Patent Document 1 (JP Patent Publication No. 8-319880) stores control data (vehicle model parameters) for multiple vehicle models in a first non-volatile memory in which the data cannot be rewritten at the time of shipment from the factory, and stores a vehicle model code for identifying the vehicle model in a second non-volatile memory in which the data can be rewritten.

[0006] When starting to control the vehicle in the market, the vehicle model code is read from the second non-volatile memory, and control data (vehicle model parameters) corresponding to the vehicle model are selected from the first non-volatile memory using this vehicle model code, thereby enabling the technology to be adapted to the case where the amount of data increases. An example of a conventional vehicle model code is shown in Figure 14(a) and (b). [Prior art documents] [Patent documents]

[0007] [Patent Document 1] Japanese Patent Application Publication No. 8-319880 Summary of the Invention [Problem to be solved by the invention]

[0008] The technology disclosed in this document attempts to prevent the amount of data from becoming too large by separating the vehicle model code and the control data (vehicle model parameters). However, the control data (vehicle model parameters) corresponding to the vehicle model written to the first non-volatile memory is added each time a vehicle model code is added, which results in the amount of data becoming too large.

[0009] In addition, every time a grade is added due to a model change (annual revision), additional work is required for vehicle model codes that have not been set. As a countermeasure to this, the vehicle model code information used to determine the control data may be narrowed down and set, but since the vehicle model code information used to determine the control data differs depending on the vehicle series (vehicle type), it is not possible to determine it uniquely.

[0010] In view of the above circumstances, the present invention aims to provide a vehicle information registration device that, even when a new vehicle model is added, does not necessarily increase the corresponding vehicle model parameters, eliminating the need for an expansion of the amount of data or changes to the logic for selecting control data based on the vehicle model code, or, in the case of minor changes to an existing vehicle model, does not require changes even when a vehicle model code is added, and can handle major changes by simply modifying and adding some tables. [Means for solving the problem]

[0011] A vehicle information registration device according to the present invention includes an electronic device mounted on a vehicle, a storage unit that stores a node table and a vehicle model parameter pattern table in which a plurality of vehicle model parameters are recorded for each pattern number, an input unit that inputs a vehicle model code of the vehicle and a non-volatile memory that records the vehicle model code, and a processing unit that operates the electronic device, and each of the plurality of vehicle model parameters is used to control the electronic device. One The node table includes a node tree consisting of one top node, a plurality of branch nodes, and a plurality of end nodes, and the top node is included in the vehicle model code. Read one specification from multiple specification information the vehicle model code input to the input unit includes designation information to designate a vehicle model code, condition presentation information indicating a condition for read information read from the vehicle model code based on the designation information, true branch destination information specifying one branch node or one terminal node to be referred to next when the read information satisfies the condition, and false branch destination information specifying one branch node or one terminal node to be referred to next when the read information does not satisfy the condition, each of the plurality of branch nodes includes the designation information, the condition presentation information, the true branch destination information, and the false branch destination information, and each of the plurality of terminal nodes includes index information indicating one of the pattern numbers in the vehicle model parameter pattern table, and the calculation processing unit calculates the vehicle model code input to the input unit based on the designation information, The plurality of specification information included inBased on the above, the node tree is branched from the top node to lower levels to search for the terminal node, and the pattern number indicated by the index information included in the terminal node reached by the search is linked to the pattern number indicated by the index information in the vehicle model parameter pattern table. Multiple The vehicle model parameters are used to control the electronic device. Effect of the Invention

[0012] According to the present invention, when an operator inputs a vehicle model code of the vehicle to an electronic device mounted on the vehicle, the arithmetic processing unit classifies the items written in the input vehicle model code by specification and converts them into a specification information group, judges the true / false of the specification information specified in the node table from this organized specification information group, branches to the next node table based on the judgment result, and searches until the branch destination is a terminal node. Then, when the terminal node is reached, of Since the vehicle model parameter table is set to match the vehicle model parameter pattern, there is no need to link each vehicle model code to a vehicle model parameter pattern on a 1:1 basis. Therefore, even when a new vehicle model is added, the vehicle model parameters corresponding to the new vehicle model are not increased, and the data volume can be prevented from exploding. [Brief description of the drawings]

[0013] [Figure 1] Schematic diagram of a vehicle equipped with electronic devices [Diagram 2] Flowchart showing vehicle information registration routine [Diagram 3] Flowchart showing vehicle model parameter table selection subroutine [Figure 4] Flowchart showing vehicle model parameter determination subroutine [Diagram 5] Flowchart showing a subroutine for acquiring specified specification information [Figure 6] Flowchart showing a node branch destination determination subroutine [Figure 7] Flowchart showing vehicle model parameter table selection subroutine [Figure 8] An explanatory diagram showing an example of a specification information group (by category) [Figure 9] Conceptual diagram of node tables [Figure 10] Conceptual diagram of a branch OR true / false condition specification table for a branch node table [Figure 11] Conceptual diagram of vehicle model parameter table [Figure 12] FIG. 1A is an explanatory diagram showing an example of a vehicle-system designated node tree, and FIG. 1B is an explanatory diagram of a vehicle-system designated node tree showing a state in which a vehicle system C is added to FIG. [Figure 13] FIG. 13 is an explanatory diagram showing an example of a node tree for determining a vehicle model pattern corresponding to a vehicle model code. [Figure 14] FIG. 1A is an explanatory diagram showing an example of a configuration of a vehicle model code according to a conventional embodiment; FIG. 1B is an explanatory diagram showing an example of specification information of a vehicle model code; DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0014] An embodiment of the present invention will now be described with reference to the drawings. A camera unit 1 is mounted on a vehicle M shown in Fig. 1. Hereinafter, the camera unit 1 will be described as an example of an electronic device.

[0015] This camera unit 1 is disposed on the upper inside of the front windshield. This camera unit 1 integrates an in-vehicle camera (stereo camera) 2 consisting of a main camera 2a and a sub-camera 2b, an A / D conversion unit 3 that converts images captured by the in-vehicle camera 2 into digital images, and a calculation processing unit 11 that acquires the images converted into digital images by the A / D conversion unit 3 and recognizes objects based on the acquired images.

[0016] The arithmetic processing unit 11 is mainly composed of a microcomputer. The microcomputer is composed of a ROM for storing programs and fixed data, a CPU for executing the programs stored in the ROM and performing calculations, a RAM used as a temporary storage area (work area) during calculation processing, an EEPROM (non-volatile memory), and peripheral devices.

[0017] Moreover, the input unit 12 can be freely connected to the input side of the arithmetic processing unit 11. The input unit 12 is operated by a worker on the production line or at a dealer, and after the camera unit 1 is attached to the vehicle M, the vehicle model code of the vehicle M is input from the input unit 12 to the arithmetic processing unit 11, whereby the vehicle model code of the vehicle M is registered in the EEPROM of the camera unit 1. Furthermore, each control unit 13 that performs various controls based on the driving environment recognized by the camera unit 1, such as driving control and steering control, is connected to the output side of the arithmetic processing unit 11. The input unit 12 does not necessarily have to be a dedicated port, and may be connected to a shared port for fault diagnosis such as OBD (On-board diagnostics) or an in-vehicle LAN such as CAN (Controller Area Network).

[0018] Also, in this embodiment, the vehicle model code is recorded in the EEPROM 11a in the control device, but it may be registered in an EEPROM (non-volatile memory) of another control unit connected to the control device.

[0019] Incidentally, at the shipping stage before mounting the camera unit 1 on the vehicle M, it is unknown in which vehicle the camera unit 1 will be installed. Therefore, after mounting the camera unit 1 on the vehicle M, an operator must adjust the characteristics of the camera unit 1 so that it is compatible with the vehicle M. At that time, the operator inputs the vehicle model code from the input unit 12 and registers it in the EEPROM, and the calculation processing unit 11 reads the vehicle model code recorded in the EEPROM at startup, thereby adjusting the vehicle model parameters so that the camera unit 1 is compatible with the vehicle M.

[0020] A node table that specifies a control data pattern by branching multiple nodes from a vehicle model code, and a vehicle model parameter (parameter) pattern table that stores different vehicle model parameter data for each pattern are written in the ROM of the arithmetic processing unit 11. The vehicle model parameter pattern table may be provided in the input unit 12 or may be stored in a storage unit externally connected to the input unit 12, or may be recorded in the EEPROM 11a of the arithmetic processing unit 11.

[0021] Incidentally, the vehicle model parameters (such as camera height, distance between the camera and bumper, vehicle width, etc.) stored in this vehicle model parameter table are determined by specific specification information such as vehicle type, body shape, destination, etc., and are often common across multiple or more different vehicle model codes prepared for differences in various equipment, etc.

[0022] Therefore, in this embodiment, only different vehicle model parameters are written in the vehicle model parameter pattern table, and vehicle model codes and vehicle model parameters are not linked 1:1 as in the past. That is, as shown in Figures 9 to 11, in this embodiment, regardless of the vehicle model, the node tree table that determines the pattern and the vehicle model parameter table in which the vehicle model parameters are written for each index are stored separately. As a result, the number of vehicle model parameter tables to be registered can be reduced.

[0023] Next, each table will be explained. As shown in Figure 9, there are two types of node tree tables: branch nodes and terminal nodes.

[0024] The branch node checks whether the specified specification information matches, and specifies the next node table if it matches (true) or not (false). A true condition is specified as one or more conditions, and judged by the number of true conditions specified in the "number of true conditions." This one or more true conditions are specified by the "branch OR true condition presentation" in the branch OR true condition specification table shown in Figure 10.

[0025] Since this table is determined by the number of true conditions (number of OR conditions), the table length is variable and determined by the number of OR conditions. (If there is one OR condition, the table length is 1, and if there are five OR conditions, the table length is 5.) However, if the maximum number of OR conditions is determined, the table length may be fixed.

[0026] Furthermore, the terminal node is a node where the node tree search is completed and a pattern is determined, and is determined by "terminal discrimination". In this embodiment, it is set to 0, but it is not limited to this and any value can be set as long as it can be discriminated from the "number of true conditions" at the same position of the branch node. Furthermore, the pattern index is specified by the "pattern index specification" of the terminal node. Furthermore, terminal nodes and branch nodes have the same configuration but have different meanings, but they can be distinguished by making the terminal discrimination unique.

[0027] In addition, in the node tree table, vehicle model parameter patterns are determined by combining branch nodes and terminal nodes as shown in Figures 12 and 13. The vehicle model parameter pattern table is composed of pattern indexes and vehicle model parameter patterns such as camera height, as shown in Figure 11. The pattern indexes do not need to be consecutive in the order of the table, and by searching the node tree table and checking against the determined pattern index, it is possible to add additional patterns for new vehicle types or existing vehicle models without rearranging the table.

[0028] Every time the control device is started, it inputs the vehicle model code recorded in the EEPROM 11a to the calculation processing unit 11. The calculation processing unit 11 then determines the pattern number of the vehicle model parameters corresponding to the vehicle model code from the vehicle model parameter pattern table, and sets the vehicle model parameter pattern table that matches this vehicle model parameter.

[0029] The selection of the pattern index of the vehicle model parameters executed by the arithmetic processing unit 11 is specifically performed according to a vehicle information registration routine shown in FIGS.

[0030] In the routine shown in FIG. 2, first, in step S1, a vehicle model code is input, and when this vehicle model code is read by the arithmetic processing unit 11, the process proceeds to step S2.

[0031] In step S2, the items written in the vehicle model code (vehicle information, vehicle shape, sensor arrangement, destination, etc.) are converted into each specification information classified by type, indexes are assigned to each specification information, and the specification information is stored in RAM or EEPROM as a specification information group (by classification). The processing in this step corresponds to the specification information classification storage unit of the present invention.

[0032] Next, the process proceeds to step S3, where the vehicle model parameter pattern table selection subroutine shown in Fig. 3 is executed to determine a pattern index of the vehicle model parameters (specifications) of the vehicle M. Then, various parameters are read from the address of the vehicle model parameter pattern table in which this pattern index is recorded, this routine is terminated, and thereafter, the vehicle model parameters are used to carry out control calculation processing.

[0033] Next, the process of the vehicle model parameter table selection subroutine shown in FIG. 3, which is executed in the above-mentioned step S3, will be described.

[0034] In this subroutine, first, in step S11, the vehicle model parameter pattern determination subroutine shown in Fig. 4 is executed to convert the vehicle model code set for the vehicle M, extract specific specification information from the stored specification information group (by classification), and finally determine the vehicle model parameter pattern of the vehicle M by branch search using a node tree. The processing in this subroutine corresponds to the vehicle model parameter pattern determination unit of the present invention.

[0035] Next, the process proceeds to step S12, where the vehicle model parameter pattern table selection subroutine shown in Fig. 7 is executed to set the vehicle model parameter pattern table in which the pattern number indicating the vehicle model parameters of the vehicle M is recorded. Then, the process proceeds to step S13, where the (address of) the set vehicle model parameter pattern table is output, and the subroutine is terminated.

[0036] Next, the process of the vehicle model parameter pattern determination subroutine shown in Fig. 4 will be described. In this subroutine, first, in step S21, the top node table (see Fig. 12) is read. As shown in Fig. 12 and Fig. 13, a group of node tables corresponding to indexes attached to specification information classified from each vehicle model code for each vehicle series are written under the top address.

[0037] Next, the process proceeds to step S22, where the node branch count counter is initialized, and then the process proceeds to step S23, where it is checked whether the node branch count is equal to or less than a specified count. This specified count is set to prevent the process from falling into an infinite loop, and can be set arbitrarily. If the count is within the specified count, the process proceeds to step S24, and if the count exceeds the specified count, the process jumps to step S29.

[0038] When the process proceeds to step S24, it is checked whether the current node is an end node, and if it is not an end node, the process proceeds to step S25. If it is an end node, the process jumps to step S30. When the process proceeds to step S25, the process of acquiring the specified specification information is executed according to the specified specification information acquisition subroutine shown in FIG. 5, and then the process proceeds to step S26.

[0039] Here, the subroutine shown in Fig. 5 will be described. In this subroutine, first, in step S41, the vehicle model code designated by the worker is read, and in step S42, it is checked whether the designated vehicle model code value is a numerical value that does not exceed the number of types of specification information groups (by classification).

[0040] If a value (normal value) that does not exceed the types of the specification information group (by classification) is specified, it is determined to be normal and the process proceeds to step S43. On the other hand, if a value that exceeds the types of the specification information group (by classification) is specified, it is determined that the specification information is abnormal and the process branches to step S44.

[0041] When the process proceeds to step S43, the designated specification information is output, and the process proceeds to step S26 in Fig. 4. When the process proceeds to step S44, 0 (abnormal value) is output as the designated specification information, and the process proceeds to step S26 in Fig. 4. Note that a value other than 0 may be specified as the abnormal value, as long as the value is known to be abnormal.

[0042] When the process proceeds to step S26 in Fig. 4, the branch destination of the node is determined according to a node branch destination determination subroutine shown in Fig. 6, and the process proceeds to step S27. The process in the subroutine in Fig. 6 corresponds to the node search unit of the present invention.

[0043] In the subroutine shown in FIG. 6, first, in step S51, the OR condition confirmation count counter for the node tree is initialized, and the process proceeds to step S52.

[0044] When the process proceeds to step S52, the number of times the OR condition has been checked is compared with the number of times (specified number of times) specified in the "number of true / false conditions" of the node tree table being searched. This step S52 determines whether the number of times the true condition has been searched is equal to the specified number of ORs, and this determination is repeated until the specified number of times is reached. Then, if the number of times the OR condition has been checked has not reached the specified number of times, the process proceeds to step S53. On the other hand, if the number of times the OR condition has been checked exceeds the specified number of times, the process branches to step S54.

[0045] When the process proceeds to step S53, the branch OR condition (see Figs. 9 and 10) recorded in the table specified in "branch OR condition presentation" of the node table being searched is compared with the specification information specified in "specification information index" of the node tool table being searched to see if they match. The branch OR condition used at this time is read by shifting one by one according to the OR condition confirmation count. If the branch OR condition does not match the specified specification information, the process proceeds to step S55, increments the OR condition confirmation count counter, and returns to step S52. On the other hand, if the branch OR condition matches the specified specification information, the process proceeds to step S56.

[0046] On the other hand, if the process branches from step S52 to step S54, the false node table is determined as the next node table, and the process proceeds to step S27 in Fig. 4. If the process proceeds to step S56, the true node table is set as the next node table, and the process proceeds to step S27 in Fig. 4.

[0047] 4, it is checked whether or not the next node exists, and if so, it proceeds to step S28, increments the node branch count counter, and returns to step S23. On the other hand, if the next node does not exist, it proceeds to step S29.

[0048] If the process proceeds from step S23 or step S27 to step S29, since there is no branching node, the index (0) of the preset default pattern is determined and the process proceeds to step S31. On the other hand, if the process proceeds from step S24 to step S30, the index of the vehicle model parameter pattern is determined by the "pattern index designation" of the terminal node and the process proceeds to step S31.

[0049] Then, when the process proceeds from step S29 or step S30 to step S31, the determined vehicle model parameter table is output, and the process proceeds to step S12 in Fig. 3. In step S12 in Fig. 3, the vehicle model parameter table is set according to the vehicle model parameter table selection subroutine shown in Fig. 7, and the process proceeds to step S13.

[0050] Here, a description will be given of the subroutine shown in Fig. 7. The processing in this subroutine corresponds to the vehicle model parameter table selection unit of the present invention.

[0051] In this subroutine, first, in step S61, a counter (table counter) for the vehicle model parameter table is initialized.

[0052] Next, the process proceeds to step S62 to check whether the table counter has exceeded the maximum number. If the table counter has not exceeded the maximum number, the process proceeds to step S63. If the table counter has exceeded the maximum number, the process branches to step S64.

[0053] In step S63, it is checked whether the designated number (index) of the vehicle model parameter table and the set number (pattern) of the vehicle system table match. If they do not match, the process branches to step S65, increments the table counter, and returns to step S62. If they match, the process proceeds to step S66.

[0054] When the process branches from step S62 to step S64, since there is no corresponding vehicle model parapattern table, the preset default vehicle model parapattern table (index 0) is output, and the process proceeds to step S13 in Fig. 3. Also, when the process proceeds from step S63 to step S66, the vehicle model parapattern table having the matching index (designated number) is output, and the process proceeds to step S13 in Fig. 3.

[0055] In step S13 of FIG. 3, the vehicle type parameter pattern table corresponding to the selected pattern is output, and the routine ends.

[0056] In this manner, in this embodiment, the node table group that determines the pattern of the vehicle model parameters and the vehicle model parameter pattern table are separated, and the branching OR condition of the node tree is To Therefore, a vehicle model parameter table corresponding to the vehicle model code is set, and the address of the vehicle model parameter table is registered in the memory section of the camera unit 1. Therefore, even if a new vehicle model code is added due to a new vehicle model or model change (yearly revision), the corresponding vehicle model parameters do not increase in a single manner, and the expansion of the amount of data can be suppressed.

[0057] Furthermore, if minor changes in specifications do not affect the selection of vehicle model parameter patterns, there is no need to change the table, and the labor and costs required for software changes can be reduced.

[0058] That is, when the node branching configuration is as shown in Figures 12 and 13, first, for each vehicle type, it is specified which node branch to enter. For example, as shown in Figure 12(a), if the vehicle type is "A", it branches to node 1, if the vehicle type is "B", it branches to node α, and if there is no corresponding vehicle type, it branches to pattern 0.

[0059] In contrast, as shown in FIG. 12(b), when a vehicle type “C” is added, the addition of a new vehicle type can be accommodated by only modifying the table configuration by adding a node tree table for vehicle type “C” and a vehicle type parapattern table through partial modification of the node table and addition of a node tree.

[0060] For the existing vehicle type "A," as shown in Fig. 13, one vehicle model parameter pattern specified by the pattern number is determined by reaching the hierarchy of the terminal node (any of 06 to 11) from the node table with five nodes according to the branch OR condition. Therefore, there is no need to directly link the vehicle model parameter pattern to the vehicle model code, and the expansion of the data volume, the labor hours required to change the software, and the costs can be suppressed.

[0061] Furthermore, in the case of minor changes such as yearly revisions, even if there is a change or addition to the vehicle model code, there is no need to change the vehicle model parameter pattern. Even in the case of major changes such as a change in body shape, it is possible to deal with the change simply by changing and adding a part of the node tree of this vehicle series and changing the table configuration to add a vehicle model parameter pattern table.

[0062] In addition, the vehicle model code and the vehicle model parapattern table are separated, and the vehicle model parapattern table having an index (designated number) that coincides with the designated number of the vehicle model code is output, so that when a new vehicle type is added, the vehicle model parapattern table can be determined by confirming the minimum required vehicle model code.

[0063] Incidentally, this embodiment is not limited to the above-described embodiment, and can be applied to any electronic device, not limited to the camera unit 1, as long as the electronic device requires the vehicle model code of the vehicle on which it is installed. [Explanation of symbols]

[0064] 1...Camera unit, 2...In-vehicle camera, 2a…Main camera, 2b…Sub camera, 11...arithmetic processing unit, 11a…EEPROM, 12...input section, 13...control unit, M…Vehicle

Claims

1. An electronic device mounted on a vehicle; a storage unit for storing a node table and a vehicle model parameter pattern table in which a plurality of vehicle model parameters are recorded for each pattern number; an input unit for inputting a vehicle model code of the vehicle and a processing unit having a non-volatile memory for recording the vehicle model code and for operating the electronic device; Equipped with each of the plurality of vehicle model parameters is made up of information representing one piece of control data used to control the electronic device; the node table includes a node tree that is configured with one top node, multiple branch nodes, and multiple end nodes; the top node includes: designation information for reading and designating one piece of specification information from a plurality of pieces of specification information included in the vehicle model code; condition presentation information for indicating a condition for the read information read from the vehicle model code based on the designation information; true branch destination information for designating one branch node or one terminal node to be referenced next when the read information satisfies the condition; and false branch destination information for designating one branch node or one terminal node to be referenced next when the read information does not satisfy the condition; each of the plurality of branch nodes includes the specification information, the condition presentation information, the true branch destination information, and the false branch destination information; each of the plurality of terminal nodes includes index information indicating one of the pattern numbers in the vehicle model parameter pattern table; The arithmetic processing unit is based on the plurality of pieces of specification information included in the vehicle model code input to the input unit, branching the node tree from the top node to lower levels and searching through to the terminal node; The plurality of vehicle model parameters linked to the pattern number indicated by the index information included in the terminal node reached by the search in the vehicle model parameter pattern table are used to control the electronic device. A vehicle information registration device comprising:

2. The calculation processing unit uses the plurality of vehicle model parameters linked to a default pattern for controlling the electronic device when it is determined that the number of node branchings in the search of the node tree exceeds a prescribed number.

2. The vehicle information registration device according to claim 1.

3. One of the plurality of pieces of specification information included in the vehicle model code is vehicle system information indicating a vehicle system of the vehicle, The head node includes the designation information that designates the vehicle information.

3. The vehicle information registration device according to claim 1 or 2.

Images