JP5230557B2 - Vehicle failure determination device, vehicle failure determination device design program - Google Patents

Description

  The present invention relates to an apparatus for determining a vehicle failure and a program for designing the apparatus.

  In recent years, control functions installed in vehicles have been increasing, and along with this, the types of sensors and actuators used for control have increased. There is also a need for subdivision of diagnostic content. As a result, the number of objects whose failure occurrence status should be diagnosed has increased.

  As a technique for reducing the number of program development man-hours by increasing the number of failure detection targets and improving the reusability of the failure diagnosis program, a technique described in Patent Document 1 below has been proposed. The failure detection program in this technology is developed using an object-oriented technology, and includes a failure detection object, a failure information storage object, and a failure information management object. In this technique, the failure information management object has a correspondence relationship between the failure detection object and the failure information storage object, thereby improving the independence of the object.

  On the other hand, when another diagnosis or control is performed based on the diagnosis result of a certain diagnosis object, if the diagnosis object in which an abnormality is detected is left unprocessed, a false diagnosis or an abnormal value may be caused. Therefore, a technique for preventing a detection program for diagnosing a diagnostic object from being executed on another diagnostic object that may cause a false detection due to an abnormality of the diagnostic object is described in Patent Document 2 below. Yes.

JP 2002-14839 A JP 2006-264540 A

  When developing a failure diagnosis program, it is necessary to select diagnosis items according to the specifications of the target vehicle. In addition, the diagnosis prohibition process as described above for preventing misdiagnosis and the process for determining whether or not to switch each function unit to the fail-safe state needs to refer to the failure states of a plurality of function units. If the configuration of the functional unit of the target vehicle is changed, it is necessary to change according to the specification of the vehicle.

  Therefore, even if the independence and reusability of the failure detection program (corresponding to each object in Patent Document 1) is increased, the portion where each failure detection program cooperates needs to be changed according to the specifications of each vehicle. is there. That is, it is difficult to completely reuse a portion corresponding to each failure detection processing interface.

  In addition, when performing the above-described diagnosis prohibition process for preventing misdiagnosis and the process of determining whether or not to switch each function unit to the fail-safe state, the failure occurrence information of each function unit is referred to. Although it is necessary, when such failure occurrence information is used as the control condition of the failure detection program, it is necessary to change the control condition according to the specification of each vehicle.

  As described above, even if the independence and reusability of the failure detection program is improved, the parts linked between the programs need to be developed individually according to the specifications of each vehicle. For this reason, the types of failure detection programs are derivatively increased, and not only the reusability is lowered, but also the man-hours for managing the correspondence relationship between each vehicle and the failure detection program are increased. As a result, the development man-hours, debugging man-hours, management man-hours, etc. of the failure detection program become enormous.

  The present invention has been made to solve the above-described problems, and provides a vehicle failure determination device that can flexibly cope with the specifications of each vehicle and a program for designing the vehicle failure determination device. For the purpose.

  In the vehicle failure determination device according to the present invention, the correspondence order of each failure diagnosis program, the control data used when executing the failure diagnosis program, and the diagnosis result data of each failure diagnosis program is independent of the failure diagnosis program. And define.

  In the vehicle failure determination device according to the present invention, since the correspondence relationship between the failure diagnosis program, the control data, and the diagnosis result data is defined separately from the failure diagnosis program main body, these can be easily and flexibly replaced. As a result, it is possible to easily cope with an increase / decrease in failure diagnosis targets, a difference in specifications of the target vehicle, and the like.

2 is a functional block diagram of an engine control unit 200 according to Embodiment 1. FIG. 3 is a block diagram schematically showing a functional configuration of the vehicle failure determination device according to Embodiment 1. FIG. It is a figure which shows a mode that the failure diagnosis item for controlling the injection quantity of an engine differs for every vehicle. An example in which the development method of the vehicle fault diagnosis apparatus is developed more efficiently with respect to the difference in failure detection target items due to the difference in system configuration as described in FIG. It is a figure explaining the specific means which implement | achieves the method demonstrated in FIGS. FIG. 5 is a block diagram schematically showing a functional configuration of a vehicle failure diagnosis apparatus according to a second embodiment. It is a figure explaining the correlation of the diagnostic result of a failure diagnostic program and another failure diagnostic program. It is a figure which shows the specific example of a "diagnosis correlation table". It is a figure explaining the concrete means for implement | achieving the method demonstrated in FIG. FIG. 10 is a diagram showing an example in which the list shown in FIG. 9B is re-expressed in a format that can be easily processed by a software program. FIG. 10 is a block diagram schematically showing a functional configuration of a vehicle failure diagnosis apparatus according to a third embodiment. It is a figure explaining the correlation of the feasibility of a failure diagnosis program, and a fail safe state. It is a figure which shows what actualized the "fail safe (F / S) correlation table" more. It is a figure which shows what actualized the "fail safe (F / S) correlation table" more. It is a figure which shows the flow at the time of receiving an OK flag among operation | movement of the diagnostic result integrated process part 3000. FIG. It is a figure which shows the flow at the time of receiving NG flag among operation | movement of the diagnostic result integrated process part 3000. FIG. It is a figure which shows the flow performed at the time of starting or completion | finish of a vehicle failure diagnostic apparatus among the operation | movement of the diagnostic result integrated process part 3000. FIG. 16 is a processing flow executed by the diagnostic correlation determination unit 5000 in step S1405 of FIG. FIG. 16 is a processing flow executed by the failsafe correlation determination unit 7000 in step S1405 of FIG. It is a figure explaining the operation | movement flow of the intake pipe pressure sensor function diagnostic program 1003 as an example of a failure diagnostic program.

<Embodiment 1>
FIG. 1 is a functional block diagram of an engine control unit 200 according to Embodiment 1 of the present invention. The engine control unit 200 is a device that controls the operation of the engine of the vehicle.

  The engine control unit 200 includes sensors necessary for engine control, such as a crank angle sensor 101, a cam angle sensor 102, an intake pipe pressure sensor 120, an intake air temperature sensor 121, an engine water temperature sensor 122, an atmospheric pressure sensor 123, a throttle sensor 124, An air-fuel ratio sensor 125 and the like are provided. Further, a CPU (Central Processing Unit) 201, an output circuit 220, and a monitor circuit 230 are provided.

  The crank angle sensor 101 and the cam angle sensor 102 detect the engine speed and phase. The pressure sensor 120 measures the intake pipe suction pressure. The intake air temperature sensor 121 is a means for detecting the operating state of the internal combustion engine. The engine water temperature sensor 122 detects the coolant temperature of the internal combustion engine. The atmospheric pressure sensor 123 detects atmospheric pressure. The throttle sensor 124 detects the throttle valve opening. The air-fuel ratio sensor 125 detects the air-fuel ratio of the exhaust.

  The input processing circuit 210 in the engine control unit 200 performs signal processing on the electrical information output from the sensors and outputs the signal to the CPU 201. The signal input to the CPU 201 is divided into an analog signal input to the A / D converter 203 and other signals input as high / low level binary signals.

  The CPU 201 executes arithmetic processing defined by a program stored in the ROM 202, outputs control signals for various actuators necessary for engine control based on the calculation result, and controls these through the output circuit 220.

  For example, the CPU 201 corrects each of the correction amounts including the mass flow rate measured from the input of the intake pipe pressure sensor 120, the engine speed measured from the crank angle sensor 101, the water temperature detected from the engine water temperature sensor 122, and the air-fuel ratio sensor 125. The fuel injection amount is calculated after adding a correction amount corresponding to the air-fuel ratio state detected by the above. Based on the above calculation, the CPU 201 finally outputs a drive pulse width to each injector 111 of the engine.

  Similarly, the CPU 201 controls the ignition signal for controlling the energization timing to the ignition coil 112 necessary for engine combustion, the signal to the electric throttle 114 for controlling the throttle valve opening degree, and the energization to the air-fuel ratio sensor heater 115. An air-fuel ratio sensor heater signal, a signal for controlling the timing of the variable intake valve 113, and the like are output.

  The input sensor signal and the output actuator signal are the minimum required, and some parts are added due to high performance and high functionality, so it is clear that these necessity changes depending on the engine system configuration It is.

  In addition to the above functions, the CPU 201 has a function as a vehicle failure determination device according to the present invention. The CPU 201 executes a failure diagnosis program stored in the ROM 202 to determine whether or not the detection value of each sensor is abnormal based on the level of the input signal from the sensors and the functional operation state. To do. Further, the CPU 201 takes in the above-described control signal output by the CPU 201 itself, the signal monitoring function added to the output circuit 220, or the output signal of the output circuit 220 acquired directly through the monitor circuit 230 into the CPU 201 again. The CPU 201 compares these pieces of information and determines whether or not each actuator is abnormal based on the level of each signal and the functional operation state. The CPU 201 stores these determination results in a RAM (Random Access Memory) 204 or an EEPROM (Electrically Erasable and Programmable Read Only Memory) 205 which is a nonvolatile RAM.

  In the following description, when explaining the operations defined by each program, for convenience of description, each program body is described as an operation subject, but it is added that the actual operation subject is an arithmetic device such as the CPU 201. deep.

  FIG. 2 is a block diagram schematically showing a functional configuration of the vehicle failure determination device according to the first embodiment. The vehicle failure diagnosis apparatus includes a failure diagnosis unit 1000, a diagnosis control data storage unit 2000, a diagnosis result overall processing unit 3000, and a diagnosis result information storage unit 4000.

  The failure diagnosis unit 1000 executes one or a plurality of individual failure diagnosis programs corresponding to each target for failure diagnosis. Here, it is assumed that N failure diagnosis programs 1001 to 100N exist. The failure diagnosis unit 1000 passes the diagnosis result to the diagnosis result overall processing unit 3000.

  The diagnosis control data storage unit 2000 stores control data for controlling the operation of the failure diagnosis program. This control data may be configured in a data format, or may be configured as a program that operates in cooperation with a failure diagnosis program. The relationship between the failure diagnosis program and the control data will be described later. The diagnosis control data storage unit 2000 corresponds to the “diagnosis control unit” in the present invention.

  The diagnosis result overall processing unit 3000 receives each diagnosis result of the failure diagnosis unit 1000, performs necessary processing, and stores it in the diagnosis result information storage unit 4000.

  The diagnosis result information storage unit 4000 stores the diagnosis result of the failure diagnosis unit 1000. In the example shown in FIG. 2, in addition to the “current failure” flag indicating whether or not the diagnosis target is currently in failure, “lamp ON request”, “in-operation diagnosis complete”, “in-operation failure”, “provisional” An example is shown in which flags such as “NG state” and “failure determination in progress” are stored together with the diagnosis result. Each flag described above can be expressed in a format such as a bit string.

  Each storage unit constituting the vehicle fault diagnosis device can be configured using a storage device such as the RAM 204. Each of the other functional units can be configured using hardware such as a circuit device that realizes these functions, or can be configured using an arithmetic device such as the CPU 201 and software that defines the operation thereof.

  The lamp output 50 corresponds to an output to a warning light (check engine lamp) installed on the meter instrument panel in the passenger compartment. In order to make the vehicle user recognize the failure, for example, based on the “lamp ON request” flag stored in the above-described diagnosis result information storage unit 4000, any “lamp ON request” to be diagnosed is set. In this case, the lamp is controlled to be turned on (lighted).

Here, the failure diagnosis programs 1001 to 100N will be supplemented.
The failure diagnosis programs 1001 to 100N execute diagnosis of each diagnosis target and output the diagnosis result information. In FIG. 2, each failure diagnosis program 1001 to 100N is described as a functional block for convenience of description, but actually, each failure diagnosis program is stored in a storage device such as the ROM 202, and the CPU 201 reads it. Run.

  One failure diagnosis program does not necessarily correspond to one diagnosis object or one diagnosis result information. A plurality of diagnosis objects may be diagnosed by one failure diagnosis program, and one failure is similarly detected. The diagnosis program may output a plurality of pieces of diagnosis result information. As described above, the failure diagnosis program and the diagnosis result information are related to each other, and further, since the diagnosis target is different if the vehicle specifications are different, the correspondence between the two companies is complicated.

  Therefore, in the vehicle failure diagnosis apparatus according to the first embodiment, the correspondence between the diagnosis results output from the failure diagnosis programs 1001 to 100N and the diagnosis result information stored in the diagnosis result information storage unit 4000 is represented as data for diagnosis control. It is defined by control data stored in the storage unit 2000. An example of the control data will be described later with reference to FIG. 5, which will be described later. As a specific mounting method, for example, the correspondence between the two may be defined in order by an array or the like.

  The vehicle failure diagnosis apparatus according to the present invention may be configured as software for performing vehicle control using an arithmetic device such as the CPU 201 and a storage device such as the RAM 204, or may be configured as an independent device separately including each functional unit. May be.

  The configuration of the vehicle failure diagnosis apparatus according to the first embodiment has been described above. Next, the difficulty of changing the diagnosis target of the failure diagnosis program as the vehicle specifications are changed will be described.

  FIG. 3 is a diagram illustrating a state in which failure diagnosis items for controlling the injection amount of the engine are different for each vehicle. FIG. 3A shows vehicle failure diagnosis items in which the intake pipe pressure sensor is mainly used to control the injection amount of the engine. FIG. 3B shows vehicle failure diagnosis items in which the air flow sensor is mainly used to control the injection amount of the engine. In FIG. 3 (B), the number of cylinders of the engine is changed from 4 cylinders to 6 cylinders in addition to mounting a variable intake valve device, an intake pipe length switching mechanism, and the like due to the higher functionality of the vehicle. For convenience of description, FIG. 3 shows only a part of the diagnostic items, but the actual failure detection target may reach several tens to several hundred items.

  Assume that a failure diagnosis program has already been developed under the system configuration (system A) shown in FIG. When the specification around the engine of the vehicle is to be changed from the system configuration shown in FIG. 3A to the system configuration shown in FIG. 3B, it is also necessary to change the diagnosis target of the failure diagnosis program. In the example shown in FIG. 3, the main sensor for performing the failure diagnosis is changed from the intake pipe pressure sensor to the air flow sensor. For this reason, operations such as deletion and addition of failure diagnosis items, such as adding a variable intake valve and an intake pipe length switching device to the failure diagnosis items, and adding the number of corresponding cylinders for misfire diagnosis to the failure diagnosis items, etc. occur.

  As described above, when the vehicle specifications change, it takes time to change or delete a fault diagnosis target, that is, to delete or add individual fault diagnosis programs (for example, any one of 1001 to 100N). Is obvious. In addition, since the number of man-hours for managing the combination of fault diagnosis programs installed in the vehicle fault diagnosis device and the specifications of each vehicle will increase, as a result, the change of the fault diagnosis program according to the individual specifications, The development man-hours for confirmation (debugging) and the like, and the management man-hours for managing them become enormous.

  Therefore, in the first embodiment, means for associating each failure diagnosis program, control data described later, and diagnosis result data of each failure diagnosis program is provided independently of the failure diagnosis program. As a result, it is only necessary to add a corresponding failure diagnosis program or delete an unnecessary failure diagnosis program without changing the main body of the failure diagnosis program, greatly reducing the number of confirmation (debugging) man-hours and management man-hours. be able to.

  FIG. 4 shows an example in which the development method of the vehicle fault diagnosis apparatus is more efficiently developed with respect to the difference in failure detection target items due to the difference in system configuration as described in FIG. Each item in FIG. 4 will be described below.

  FIG. 4A is a total diagnosis item list in which all failure diagnosis items that may exist as failure diagnosis items necessary for performing engine control are described. The list includes all possible sensors and devices as failure diagnosis items related to engine control. The value in the “diagnostic item” column indicates the name or content of the diagnostic item, and the value in the “total number” column indicates the serial number. The actual number of items may reach several hundred items.

  The value in the “selection item” column in FIG. 4A indicates which diagnosis item is selected for each vehicle specification. For example, when trying to correspond to the system configuration (system A) of FIG. 3A, the designer sets “1” in the “selection item” column to be a fault diagnosis target of the system.

  In FIG. 4B, the settings shown in the “A” column in the “Selected Item” column of FIG. 4A are set, and only those having “1” set in this column are extracted and re-executed. It is an arrangement. At the time of rearrangement, the value of the “array address” column is newly assigned from 0.

  The failure diagnosis target extracted as described above is equivalent to “System A” in FIG. In this way, by selecting only the necessary failure diagnosis items for the target vehicle from the preset total diagnosis item list, only the necessary failure diagnosis items can be extracted and assigned to the array addresses. .

  FIG. 5 is a diagram illustrating specific means for realizing the technique described in FIGS. 5A is a total diagnosis item list, FIG. 5B is a list in which only necessary failure diagnosis items are extracted from FIG. 5A, and FIG. 5C is a list shown in FIG. 5B. It is a figure which shows the state expressed in the format which can be mounted in.

  In the total diagnosis item list shown in FIG. 5A, the “selection item” column and the “total number” column described in FIG. 4A (for the convenience of description, “selection” “Total No” in FIG. Is provided). The designer sets “1” in the “selected item” column of the diagnostic items necessary for performing the fault diagnosis of the vehicle.

  In FIG. 5B, only those having “1” set in the “selection item” column are extracted and rearranged from FIG. 5A, and the array addresses are assigned from 0, so that FIG. ) Is compressed. The extraction result and the array address are illustrated on the left side of FIG.

  Further, in FIG. 5B, control data such as the correspondence between each failure diagnosis item and each failure diagnosis program and the number of repetitions of processing executed in each failure diagnosis program are combined with the extracted failure diagnosis items. Described. Each item will be described.

(Item 1) Permission Flag Name, RAM Name The permission flag name, RAM name associates each diagnosis item with a failure diagnosis program, and also associates values used internally by each failure diagnosis program with each failure diagnosis program. Have

(Item 2) Control data The control data is a control parameter used internally by each failure diagnosis program. Here, a DTC (diagnostic trouble code) such as a P code, the number of code erasures, the number of determinations for lighting the lamp, and lamp lighting permission (SW) are illustrated. These parameters affect the operation of each fault diagnosis program. For example, when the value of the number parameter is changed, the number of repetitions of a certain process in the failure diagnosis program is changed.

(Item 2: Supplement)
The control data here corresponds to each data (2001, 2002, etc.) stored in the diagnostic control data storage unit 2000 described in FIG. For example, the control data 2001 is control data for a voltage high failure of the intake pipe pressure sensor, the control data 2002 is control data for a voltage low failure, and the like. Note that parameters such as the permission flag name and the RAM name may be included in the control data.

  In this way, by associating each failure diagnosis program with each parameter, etc., and defining the corresponding relationship in an array format, only the necessary information is extracted for both the failure diagnosis program and parameters, and depending on the order in the array Each can be associated.

  FIG. 5C is a diagram showing an example in which the list shown in FIG. 5B is re-expressed in a programming language format. Here, an example similar to the C language is shown, but the expression method may be appropriately changed according to a program language in which a failure diagnosis program or the like is mounted.

  5C, the list shown in FIG. 5B is represented by (A-1): array definition list, (A-2): flag interface definition list, (A-3): variable definition list, (A -4): The example described anew as a ROM data list is shown. In this way, by listing the list of FIG. 5B in accordance with the specification of the program language, it can be directly implemented in the program, so that development efficiency can be improved.

  Each failure diagnosis program outputs a diagnosis result to the diagnosis result overall processing unit 3000. The diagnosis result overall processing unit 3000 stores each diagnosis result information in an array in the diagnosis result information storage unit 4000. The sequence number of each diagnosis result information is determined according to the sequence order defined by (A-1): sequence definition list. As a result, the failure diagnosis program, the control data, and the diagnosis result information are sequentially associated by the array number.

  5A to 5B, and further to FIG. 5B to FIG. 5C, when a designer or the like performs manually, the work load is large and is not efficient. Therefore, in the first embodiment, a design support program (corresponding to the vehicle failure determination device design program according to the first embodiment) that automatically executes these steps is used. The role of each design support program is explained below.

(Design Support Program α1) Data Definition Information Compression The design support program α1 is executed by the CPU 201. The design support program α1 extracts only items for which “1” is set in the “selected item” column from the total diagnosis item list shown in FIG. 5A, and outputs the list shown in FIG. . Further, control data used by each failure diagnosis program is separately acquired and associated with the array as shown in FIG. Control data corresponding to each failure diagnosis program may be stored in advance on a computer that executes the design support program α1, for example, or may be input by the designer, but prepared in advance from the viewpoint of efficiency. It is better to read things.

(Design Support Program α2) List Generation The design support program α2 is executed by the CPU 201. The design support program α2 generates a list in the program language format shown in FIG. 5C from the list shown in FIG. The format in which the list is output may be determined within the design support program α2, or the rules may be stored in advance on a computer that executes the design support program α2, for example.

(Design support program: supplement)
Each design support program may be divided into two types, such as α1 and α2, or both processes may be executed by a single program. In addition, a program corresponding to each of the design support programs may be configured inside the vehicle failure diagnosis apparatus. However, from the viewpoint of minimizing the program size of the vehicle failure diagnosis apparatus, it is preferable to configure the design support program as an external program and reduce the size of the program incorporated in the vehicle failure diagnosis apparatus.

  As described above, in the vehicle failure diagnosis apparatus according to the first embodiment, each failure diagnosis program, the control data of each failure diagnosis program, and the diagnosis result information of each failure diagnosis program are associated with each other by the array number, and the diagnosis result information Store in the storage unit 4000. Thereby, since each correspondence can be changed easily, it can respond flexibly to the specification change etc. of a vehicle. In addition, since it is not necessary to change the main body of the failure diagnosis program, the development man-hours and management man-hours can be reduced.

  Further, the vehicle failure determination device design program (design support programs α1, α2) according to the first embodiment extracts only items necessary for failure diagnosis of the vehicle from the total diagnosis item list that can be failure diagnosis items. A diagnostic item list for the vehicle is generated. As a result, the designer can select the necessary diagnostic items, and the vehicle failure diagnosis apparatus can be adapted to the specifications of an arbitrary vehicle. Therefore, the number of development steps can be greatly reduced.

  Further, the vehicle failure determination device design program (particularly the design support program α2) according to the first embodiment generates a diagnosis item list for the vehicle in the form of a program language. As a result, the list can be easily incorporated into the program, so that the consumed capacity of the ROM 202 can be suppressed without impairing the function of the vehicle failure diagnosis apparatus.

<Embodiment 2>
In the first embodiment, a vehicle failure diagnosis apparatus and a design program thereof that can easily replace a combination of a failure diagnosis program and control data according to vehicle specifications have been described. In the second embodiment of the present invention, in addition to the configuration described in the first embodiment, a configuration that can deal with the correlation between fault diagnosis programs is newly introduced. Since the other configuration is generally the same as that of the first embodiment, the following description will focus on the differences.

  FIG. 6 is a block diagram schematically showing a functional configuration of the vehicle failure diagnosis apparatus according to the second embodiment. The vehicle failure diagnosis apparatus according to the second embodiment includes a diagnostic correlation determination unit 5000 and a fail-safe state determination unit 6000 in addition to the configuration described in FIG. 2 of the first embodiment.

  The diagnostic correlation determination unit 5000 instructs the execution permission or the execution stop of each failure diagnosis program based on the information stored in the diagnosis result information storage unit 4000. In addition, a diagnostic correlation definition list 5001 that defines items necessary to instruct execution permission or execution stop of each failure diagnosis program is provided. The diagnosis correlation determination unit 5000 stores an instruction to permit or stop execution of each failure diagnosis program in the diagnosis result information storage unit 4000. The storage destination is associated with the diagnosis result information of each failure diagnosis program. Although FIG. 6 shows an example in which each diagnosis result information is integrated and stored, it is not necessarily required to be integrated with each diagnosis result information.

The fail safe state determination unit 6000 determines that the failure diagnosis target of the failure diagnosis program is in the fail safe state when the diagnosis result of the failure diagnosis program has the following values.
(Fail-safe state 1) When the failure diagnosis result is outside the control range (Fail-safe state 2) When the failure diagnosis result is a value other than the normal control state, for example, an initial value or a fixed value Case

  Heretofore, the configuration of the vehicle failure diagnosis apparatus according to the second embodiment has been described. Next, the fact that the diagnosis results of the failure diagnosis program are related to each other will be described.

  FIG. 7 is a diagram for explaining the correlation between the diagnosis results of the failure diagnosis program and other failure diagnosis programs. Here, an intake pipe pressure sensor function diagnosis program 1003 stored in the ROM 202 is taken as an example.

  FIG. 7A is a diagram showing a general configuration of a conventional intake pipe pressure sensor function diagnostic program 1003. The main components of the program are a diagnosis execution condition part including various conditions for executing failure diagnosis, a part for calculating parameters necessary for diagnosis, and a part for determining a failure using these parts. Divided. The calculation processing result is output as an OK / NG determination flag and a determination establishment flag.

  In the intake pipe pressure sensor function diagnosis program 1003, the diagnosis execution condition section is affected by the system specifications of the vehicle.

  For example, in order to prevent erroneous determination, there is a restriction that a variable intake valve must be in an unfailed state in a system equipped with a variable intake valve device. When the variable intake valve is malfunctioning, a divergence occurs between the pressure detected by the intake pipe pressure sensor and the pseudo pressure value calculated as a comparison value based on other sensor information as a determination parameter. Therefore, the diagnosis execution condition part of the intake pipe pressure sensor function diagnosis program 1003 includes information indicating “whether or not the variable intake valve has failed”, information indicating whether or not the fail-safe state is being executed, and Need to refer to. These can be obtained by referring to the failure state information of the variable intake valve ("current failure" flag) and the fail safe state information of the variable intake valve ("fail safe state" flag).

  Note that in the actual intake pipe pressure sensor function diagnostic program 1003, it may be necessary to refer to a failure state of, for example, a water temperature sensor or an atmospheric pressure sensor in addition to the failure state of the variable intake valve. .

  On the other hand, in the intake pipe pressure sensor function diagnosis program 1003 in a system not equipped with a variable intake valve, it is not necessary to refer to the failure state information of the variable intake valve. In this case, it is not necessary to acquire failure state information of the variable intake valve and fail safe state information of the variable intake valve.

  As described above, it is necessary to modify and change the intake pipe pressure sensor function diagnosis program 1003 depending on whether or not there is a variable intake valve device. As other system components change, more items need to be changed, and program changes, development, verification, and management man-hours increase each time the system changes. For this reason, not only is there a disadvantage in terms of cost due to a decrease in development efficiency and an increase in cost, but an unmatch due to a management error may occur, leading to a decrease in quality.

  FIG. 7B is a diagram showing a configuration of the intake pipe pressure sensor function diagnostic program 1003 in the second embodiment. In the second embodiment, in order to cope with the fact that the information to be referred to by the intake pipe pressure sensor function diagnosis program 1003 has to be changed due to the difference in the system configuration as described above, the information to be referred to is changed. Disconnected from the program itself.

  In the second embodiment, the intake pipe pressure sensor function diagnosis program 1003 acquires the value of the “diagnosis permission request flag” and determines whether or not to perform failure diagnosis of the variable intake valve based on the value. . The value of the “diagnosis permission request flag” is stored in the diagnosis result information storage unit 4000 by a diagnosis correlation determination unit 5000 described later.

  In the example of FIG. 7B, information indicating whether or not the variable intake valve has failed and information indicating whether or not the variable intake valve is performing a fail-safe function are included in the intake pipe. The information is disconnected from the pressure sensor function diagnosis program 1003 and indirectly referred to through the “diagnosis permission request flag”. Thereby, the independence of the intake pipe pressure sensor function diagnosis program 1003 can be enhanced.

  For example, even if the system configuration changes and the variable intake valve does not exist, if the initial value of the “diagnosis permission request flag” is set to a value (1 in the present embodiment) indicating that “diagnosis is permitted”, There is no need to recreate the diagnosis execution condition section.

  In addition, even when the system configuration is changed and failure state information or failsafe state information to be referred to must be changed, the logic itself that determines whether or not diagnosis can be executed by referring to the value of the “diagnosis permission request flag” is There is no need to change. In order to change the failure state information and failsafe state information to be referred to, only the diagnostic correlation determination unit 5000 that sets the value of the “diagnosis permission request flag” referred to by the intake pipe pressure sensor function diagnostic program 1003 needs to be changed. .

  As described above, in the second embodiment, the diagnosis results and fail-safe states of other failure diagnosis programs referred to by each failure diagnosis program for determining whether or not diagnosis can be executed are between the failure diagnosis program and the failure diagnosis program. Only the interface is defined in each fault diagnosis program. Thereby, even if the system specifications (vehicle specifications) are changed, it is not necessary to change the failure diagnosis program itself, so that the development man-hours, verification man-hours, and management man-hours can be greatly reduced. Here, the intake pipe pressure sensor function diagnosis program 1003 is taken as an example, but the same applies to other failure diagnosis programs.

  The correlation between the diagnosis results of the failure diagnosis program and the other failure diagnosis programs in the second embodiment has been described above. Next, the concept of diagnostic correlation and the specific implementation method of the diagnostic correlation determination unit 5000 in the second embodiment will be described with reference to FIGS.

  FIG. 8 is a diagram showing a specific example of the “diagnosis correlation table”. The “diagnosis correlation table” is a table in which failure diagnosis items are arranged on the vertical axis and the horizontal axis. The horizontal axis represents diagnostic result information (normal / failure). When the diagnosis item shown on the horizontal axis is a failure, the failure diagnosis item on the vertical axis, which may cause a false detection due to the failure, is marked with ●. That is, when viewed in the horizontal direction, if a diagnosis result marked with ● in the horizontal direction is detected as a failure, the execution of the failure diagnosis must be prohibited.

  For example, when the water temperature sensor has an electrical failure, the failure diagnosis program for performing the function diagnosis (8-a) of the water temperature sensor cannot be executed. Therefore, the “water temperature sensor Hi side diagnosis”, “water temperature diagnosis Lo side” The value of “diagnosis” was set as ●. In addition, the failure diagnosis program executes an intake pipe pressure (MAP) sensor, an intake temperature sensor, a rotation speed as conditions for determining a functional failure when executing the function diagnosis (8-a) of the water temperature sensor. A crank angle sensor for obtaining information is referred to. For this reason, if it is determined that these are in a failure state, the execution of the failure diagnosis program must be stopped. Therefore, the values related to these are marked with ●.

  In one system, the correlation between fault diagnosis programs as described above is fixed. However, when dealing with different systems, if the diagnostic item changes, the fault detection target, fault status information to be referenced, etc. Must be changed according to the specifications of the system.

  Therefore, in the second embodiment, all possible fault diagnosis items such as sensors and devices are listed and arranged on the vertical axis and the horizontal axis as shown in FIG. 8, and the correlation between all fault diagnosis items is shown in FIG. Consider defining the same. This table will be referred to as a “total diagnosis correlation table”. By extracting only the fault diagnosis items related to the target system (fault diagnosis target vehicle) from the “total diagnosis correlation table”, only necessary ones of the correlations of the respective fault diagnosis programs can be extracted. If the correlation between all fault diagnosis items is defined in advance, there is no fear of missing.

  Heretofore, the concept of diagnostic correlation in the second embodiment has been described. Next, a specific mounting method of the diagnostic correlation determination unit 5000 will be described.

  Each failure diagnosis program is implemented so as to refer to the value of the “diagnosis permission request flag” as described above. The value of this “diagnosis permission request flag” is stored in any area of the diagnosis result information storage unit 4000. Since the value of the “diagnosis permission request flag” is set independently from each failure diagnosis program, each failure diagnosis program has a specific storage location (for example, storage destination address) of the “diagnosis permission request flag”. You must keep track of where it is. Therefore, in the second embodiment, the correlation between each failure diagnosis program and the “diagnosis permission request flag” is defined in a diagnostic correlation definition list 5001 described later, and can be referred to using the arrangement order described in the first embodiment. I made it.

  FIG. 9 is a diagram illustrating specific means for realizing the technique described in FIG. FIG. 9A is a total diagnosis correlation table, and FIG. 9B is a diagram showing a list in which only necessary failure diagnosis items are extracted from FIG. 9A.

  In FIG. 9, the “diagnosis permission request flag” described in FIG. 7 is divided into “diagnosis NG flag” and “fail-safe (F / S) state flag”. This is because the failure diagnosis result of each failure diagnosis item is output by each failure diagnosis program, and the determination result of whether or not in the fail safe state is output by the fail safe state determination unit 6000. The diagnosis correlation determination unit 5000 writes the “diagnosis permission request flag” described in FIG. 8 in the diagnosis result information storage unit 4000 using both flags.

  FIG. 9A shows an example in which the total diagnosis correlation table described in FIG. In the figure, the vertical axis shows all failure diagnosis items and a “selection item” column. In addition to the same items as the vertical axis, the following items are arranged on the horizontal axis.

(Horizontal axis item 1) Location of “diagnostic NG flag” The “diagnostic NG flag” is created when the diagnostic result overall processing unit 3000 stores the fault diagnostic result of each fault diagnostic program in the diagnostic result information storage unit 4000. Is done. This flag corresponds to the second “current failure” flag from the left in the diagnosis result information 4001, 4002, etc. in FIG. The storage location of this flag is specified by (1) RAM name and (2) flag name in FIG. The flag name will be described with reference to FIG.

(Horizontal axis item 2) Location of “F / S status flag” The “F / S status flag” is stored in an appropriate area such as the RAM 204 by the fail-safe status determination unit 6000 based on the diagnosis result of each fault diagnosis program. Store. In FIG. 6, the F / S state flags 6001 to 600N are described. The storage location of this flag is specified by the RAM name and flag name in (3) F / S state of FIG.

(Horizontal axis item 3) Flag indicating final column In the final column, 0xFF, which is information indicating that the horizontal axis is final, is defined for all items. This is used as information for determining the end of loop processing. Even if it is not necessarily 0xFF, any value can be used as long as the information can be identified by the program. Further, this item may be omitted if the total number of diagnosis items can be obtained in advance.

  In FIG. 8, the correlation between the diagnosis results of each failure diagnosis program is represented by using the symbol ●, but in FIG. 9, this is further subdivided and assigned numerical values from “1” to “3”. . A numerical value “1” represents a “current failure”, a numerical value “2” represents a “failure in operation”, and a numerical value “3” represents a diagnostic state “failure established”. Depending on the value set in each cell of the total diagnosis correlation table, the diagnosis result is not only the binary value of OK / NG, but a plurality of diagnosis results can be associated with each other. However, only numerical values “0” and “1” are used to determine whether or not each failure diagnosis target is in a fail-safe state.

  In FIG. 9, the total number of diagnosis items is 403, but is not limited to this. For example, if the number of items to be diagnosed increases in the future, the diagnosis items may be added vertically and horizontally.

  In FIG. 9B, only those in which “1” is set in the “selection item” column are extracted and rearranged from FIG. 9A, and the array addresses are assigned from 0, so that FIG. ) Is compressed.

  FIG. 10 is a diagram illustrating an example in which the list illustrated in FIG. 9B is re-expressed in a format that can be easily processed by the software program. Since FIG. 10 is a continuation of FIG. 9B, it is indicated as (C) in FIG. FIG. 10 shows an example in which the list shown in FIG. 9B is reconfigured as (B-1): diagnostic correlation definition list 5001. In the diagnostic correlation definition list 5001 shown in FIG. 10, based on the list shown in FIG. 9B, the diagnostic item name, the number of diagnostic items, the flag name to be referred to, and the RAM name storing the flag value are arranged in an array form. Are listed in order.

  In the failure diagnosis items corresponding to the array numbers 0 to 4, there is no other failure diagnosis state to be referred to, and there is no situation in which failure diagnosis should be prohibited. Therefore, the item name, 0xFF indicating the final, number of items: 1 is set.

  The fifth (a) of the array corresponds to (a) in FIG. 9 (B). Information to be referred to by the diagnosis item can be understood by looking at (a) in FIG. 9B in the horizontal axis direction. There are 10 items with numerical values “1” to “3” set in the horizontal axis direction, including 0xFF. Therefore, the number of reference information is 10.

  The flag names are set so that the value corresponding to the numerical value “1” of the total diagnosis correlation table is F1, the value corresponding to the numerical value “3” is F3, and the like. The reason why the numerical value itself is not used is to keep the program change range to a minimum even when the numerical value representing each diagnosis state is changed later. For example, a case where the numerical value indicating “current failure” is changed from “1” to “11” can be considered. If the flag name is used instead of the numerical value itself, even if the numerical value is changed as described above, it is only necessary to rewrite the correspondence between the numerical value and the flag name, so that the program body does not need to be changed.

  Based on the list shown in FIG. 10, whether or not each failure diagnosis program can be executed can be finally collected in one “diagnosis permission request flag”. In addition, if the list is made as shown in FIG. 10, it can be installed as it is in a program constituting the diagnosis function of the vehicle failure diagnosis apparatus.

  9A to 9B and FIG. 10 are not efficient when a designer or the like manually performs the process. Therefore, in the second embodiment, a design support program (corresponding to the vehicle failure determination device design program according to the second embodiment) that automatically executes these steps is used. The role of each design support program is explained below.

(Design Support Program β1) Total Diagnosis Correlation Table Compression The design support program β1 is executed by the CPU 201. The design support program β1 extracts only the items for which “1” is set in the “selected item” column from the total diagnosis correlation table shown in FIG. 9A, and outputs the list shown in FIG. 9B. . Moreover, the value of each item shown on the horizontal axis of FIG. 9 is separately acquired and associated with the array. Each value shown on the horizontal axis in FIG. 9 may be stored in advance on a computer that executes the design support program β1, for example, or may be input by the designer, but prepared in advance from the viewpoint of efficiency. It is better to read things.

(Design Support Program β2) List Generation The design support program β2 is executed by the CPU 201. The design support program β2 generates the list shown in FIG. 10 from the list shown in FIG. The format in which the list is output may be determined within the design support program β2, or the rules may be stored in advance on a computer that executes the design support program β2, for example.

(Design support program: Supplement 1)
Each design support program may be divided into two types such as β1 and β2, or both processes may be executed by a single program. In addition, a program corresponding to each of the design support programs may be configured inside the vehicle failure diagnosis apparatus. Furthermore, the design support programs α1 and α2 described in the first embodiment and the design support programs β1 and β2 in the second embodiment may be integrated.

(Design support program: Supplement 2)
The reason why the design support program is divided into β1 and β2 in the second embodiment will be supplemented. After creating the compressed diagnostic correlation table shown in FIG. 9B from the total diagnostic correlation table shown in FIG. 9A, the system configuration may be changed in the course of the design work. In this case, the work may be performed again from FIG. 9A, but it may be more efficient to directly edit the compressed diagnostic correlation table. For example, only the numerical values of some table cells are changed from “1” to “2”. Therefore, in the second embodiment, the process from FIG. 9A to FIG. 10 is divided into two stages, and the function of the design support program is also divided into two types corresponding to this, and the editing work is intervened in the middle. I was able to do that. As a result, the process of creating the diagnostic correlation definition list 5001 collectively from the total diagnostic correlation table and the work of individually editing the compressed diagnostic correlation table can be made compatible, greatly increasing the development man-hours. can do.

  Heretofore, the vehicle failure diagnosis apparatus and its design support program according to the second embodiment have been described. In the case where a plurality of pieces of diagnosis result information are output by one failure diagnosis program, the execution permission instruction and the execution stop instruction of each failure diagnosis program output by the diagnosis correlation determination unit 5000 are made based on the same information. It is desirable to keep it. Specifically, this may be the case when the state where the voltage level of the input sensor is abnormally high or low is detected by a single failure diagnosis program and the diagnosis result information is divided into high or low voltage levels.

  As described above, in the second embodiment, the diagnosis correlation determination unit 5000 uses the diagnosis result of each failure diagnosis program or at least one of whether or not each failure diagnosis target is in a fail-safe state, Determines whether diagnosis can be executed. Thereby, when the failure diagnosis items are related to each other, the correlation can be reflected in the failure diagnosis.

  According to the second embodiment, the diagnostic correlation determination unit 5000 includes the diagnostic correlation definition list 5001 that defines the correlation, and instructs the start and stop of execution of each fault diagnosis program based on the diagnostic correlation definition list 5001. Thereby, the diagnosis execution condition part of each failure diagnosis program can be separated from other failure diagnosis programs, and the independence can be enhanced.

  Further, according to the second embodiment, the diagnosis correlation definition list 5001 represents a plurality of types of diagnosis results by numerical values “1” to “3”, and the correlation between each diagnosis result and whether or not another failure diagnosis program can be executed. Define Thereby, the correlation between the respective diagnostic programs can be defined in more detail. Furthermore, for example, when “current failure information” is selected, when the failure state is recovered during operation, it is possible to immediately return from fail-safe. When “in-operation failure information” is selected, it is possible to select a function that continues fail-safe during operation even if the failure is recovered. Further, when “failure establishment information” is selected, even when the operation is stopped and restarted, the fail safe can be continued unless it is determined that the failure state has been restored. In this way, it is possible to select a condition for canceling the activation of the fail-safe function, in particular, according to the return condition of the fail-safe function.

  Further, according to the second embodiment, the “diagnosis permission request flag” is stored in the diagnosis result information storage unit 4000 using the same array number as each failure diagnosis program and its failure diagnosis result information. The relationship can be easily grasped.

  Further, the vehicle failure determination device design program (design support programs β1, β2) according to the second embodiment extracts only the items necessary for failure diagnosis of the vehicle from the total diagnosis correlation table, and performs diagnosis for the vehicle. A correlation definition list 5001 is generated. As a result, the designer can select the necessary diagnostic items, and the vehicle failure diagnosis apparatus can be adapted to the specifications of an arbitrary vehicle. Therefore, the number of development steps can be greatly reduced.

<Embodiment 3>
In the second embodiment, the configuration capable of dealing with the correlation between the fault diagnosis programs has been described. In the third embodiment of the present invention, a configuration capable of dealing with the correlation between the diagnosis result of the failure diagnosis program and whether or not to shift to the fail-safe state will be described. Since the other configuration is substantially the same as that of any one of the first and second embodiments, the following description will focus on the differences. In the following, for convenience of explanation, an example in which the above configuration is newly introduced in addition to the configuration described in Embodiment 2 will be described. However, in addition to the configuration described in Embodiment 1, the above configuration can also be introduced. . When combining Embodiment 3 and Embodiment 1, in addition to the configuration newly described in Embodiment 3, fail-safe state determination unit 6000 or a functional unit corresponding thereto is required.

  FIG. 11 is a block diagram schematically showing a functional configuration of the vehicle failure diagnosis apparatus according to the third embodiment. The vehicle failure diagnosis apparatus according to the third embodiment is additionally provided with a fail-safe correlation determination unit 7000 and a fail-safe activation information storage unit 8000 in addition to the configuration described in FIG. 6 of the second embodiment.

  The fail-safe correlation determination unit 7000 is based on a flag (F / S state flag 6001 or the like) indicating whether each failure diagnosis target is in a fail-safe state, which is stored in the fail-safe state determination unit 6000. Instructs the execution permission and execution stop of each fail-safe function provided. In addition, it has a fail-safe correlation definition list 7001 for defining matters necessary for instructing execution permission or execution stop of each fail-safe function. The failsafe correlation determination unit 7000 stores an instruction to permit or stop execution of each failsafe function in the failsafe activation information storage unit 8000. The storage destination is associated with the diagnosis result information of each failure diagnosis program using the order on the array.

  The fail safe activation information storage unit 8000 stores the determination result of the fail safe correlation determination unit 7000. The storage format is an array format with the same array number as each failure diagnosis program and its diagnosis result information.

  The configuration of the vehicle fault diagnosis apparatus according to the third embodiment has been described above. Next, it will be described that whether or not the failure diagnosis program can be executed and whether or not each diagnosis target item is in a fail-safe state are related to each other.

  FIG. 12 is a diagram for explaining the correlation between the feasibility of the failure diagnosis program and the fail-safe state. Here, the air-fuel ratio control program 1004 stored in the ROM 202 is taken as an example. The air-fuel ratio control program 1004 is a program for performing engine control, which is configured separately from the failure diagnosis program.

  FIG. 12A is a diagram showing a configuration of a conventional air-fuel ratio control program 1004. In order for the air-fuel ratio control program 1004 to correctly calculate the air-fuel ratio correction amount, sensors that affect the air-fuel ratio control, such as the intake pipe pressure sensor and the air-fuel ratio sensor, must be in a state that does not fail. Therefore, the air-fuel ratio control program 1004 needs to refer to these diagnosis result information. If it is determined that these are malfunctioning, the air-fuel ratio control program 1004 shifts to a fail-safe state in which the air-fuel ratio correction amount is returned to the initial value.

  In addition, based on an external command acquired through communication, etc., when the control is executed in a state that is not a normal control state, for example, when the fuel injection amount is set to a fixed injection state, an abnormal air-fuel ratio correction amount is output. There is a possibility. Under such circumstances, the air-fuel ratio control program 1004 needs to stop the calculation of the air-fuel ratio correction amount, and therefore, similarly to the above, shifts to a fail-safe state in which the air-fuel ratio correction amount is returned to the initial value.

  Similarly to the correlation between the failure diagnosis programs described in the second embodiment, even in the program for controlling vehicle components such as the engine, when failsafe is executed with reference to the diagnosis result information, the system configuration Affected by changes. For example, consider a case where the system configuration is changed and the main sensor used for calculating the air-fuel ratio is changed from an intake pipe pressure sensor to an air flow sensor. At this time, when the diagnosis result information is individually referred to in the control program, the program needs to be changed, so that the development efficiency is lowered.

  Furthermore, when determining whether or not to shift to the fail-safe state, if there is a restriction that a specific diagnosis item should not be in the fail-safe state, a fail-safe state flag is added to the diagnosis result information. It is also necessary to refer to 6001 and the like.

  Therefore, in the third embodiment, information such as the diagnosis result information and the fail safe state flag referred to by the air-fuel ratio control program 1004 is collected as one “fail safe start request flag”. This flag corresponds to 8001 to 800N in FIG.

  FIG. 12B is a diagram showing the configuration of the air-fuel ratio control program 1004 in the third embodiment. The independence of the control program can be improved by introducing the “fail safe start request flag”.

  For example, even if the system configuration changes, if the initial value of the “fail safe start request flag” is set to a value indicating “prohibit start” (0 in this embodiment), it is not necessary to recreate the execution condition section Absent.

  In addition, even if the system configuration is changed and the diagnostic result information and failsafe status information to be referred to must be changed, it is determined whether or not the failsafe function can be executed by referring to the value of the “failsafe start request flag”. The logic itself does not need to be changed. In order to change the diagnosis result information and fail-safe state information to be referred to, only the fail-safe correlation determination unit 7000 that sets the value of the “fail-safe start request flag” referred to by the air-fuel ratio control program 1004 needs to be changed. Although the air-fuel ratio control program 1004 is taken as an example here, the same applies to other control programs.

  The correlation between the failure diagnosis program and the failsafe function in the third embodiment has been described above. Next, the concept of fail-safe correlation in the third embodiment and a specific mounting method of the fail-safe correlation determination unit 7000 will be described.

  In the third embodiment, the same method as that of the total diagnosis correlation table described in the second embodiment is used. In other words, a “fail-safe (F / S) correlation table” is used in which the vertical axis in FIG. In the table, the diagnosis result information is handled as one flag information for each fail-safe function.

  FIG. 13 to FIG. 14 are diagrams showing a more specific example of the “fail-safe (F / S) correlation table”. 13A shows the “F / S total correlation table”, FIG. 13B shows the “compressed F / S correlation table”, and FIG. 14C shows the fail-safe correlation definition list 7001.

  The concept of the fail-safe correlation table is the same as that of the diagnostic correlation table. The F / S correlation table is obtained by replacing the vertical axis of the diagnostic correlation table described in FIG. 9 with the F / S function item and arranging the flag and RAM name information in an array. The same applies to the compressed F / S correlation table. Further, from FIG. 13B, the F / S function items are listed in the order of arrangement, and (C-1): fail-safe correlation definition list 7001 can be obtained.

  A specific example will be described by taking the F / S3 item shown in FIG. 13B as an example. When cells with numerical values 1 to 3 are set in the horizontal axis direction based on the same item and the RAM name and the value of the NG flag are extracted, three items including 0xFF are searched. In this case, the number of reference information is 3. The numerical values are replaced with flag names as in FIGS. 9 to 10 and are listed as shown in FIG.

  In the third embodiment, since the number of F / S functions is smaller than that of the diagnostic items, the value of the “selected item” column is 1 among the F / S items as described in the first and second embodiments. The process of extracting only certain things was omitted. However, if the number of F / S items becomes large, the F / S function items are also selected in the same manner as in the first and second embodiments, the rearranged flags and RAM names, and the controls that refer to them. In addition to this, an interface definition with the program side may be created.

  Note that the steps from FIG. 13A to FIG. 14C are not efficient when a designer or the like manually performs the process. Therefore, in the third embodiment, a design support program (corresponding to the vehicle failure determination device design program according to the third embodiment) that automatically executes these steps is used. The role of each design support program is explained below.

(Design Support Program γ1) Fail-Safe Breaking Correlation Table Compression The design support program γ1 is executed by the CPU 201. The design support program γ1 extracts only items for which “1” is set in the “selected item” column on the horizontal axis from the F / S total correlation table shown in FIG. Output the list shown. Moreover, the value of each item shown on the horizontal axis of FIG. 13 is acquired separately and associated with the array. Each value shown on the horizontal axis in FIG. 13 may be stored in advance on a computer that executes the design support program γ1, for example, or may be input by the designer, but prepared in advance from the viewpoint of efficiency. It is better to read things.

(Design Support Program γ2) List Generation The design support program γ2 is executed by the CPU 201. The design support program γ2 generates a list shown in FIG. 14C from the list shown in FIG. The format in which the list is output may be determined within the design support program γ2, or the rules may be stored in advance on a computer that executes the design support program γ2, for example.

(Design support program: Supplement 1)
Each design support program may be divided into two types such as γ1 and γ2, or both processes may be executed by a single program. In addition, a program corresponding to each of the design support programs may be configured inside the vehicle failure diagnosis apparatus. Furthermore, the design support programs α1, α2, β1, and β2 described in the first and second embodiments may be integrated with one or more of them.

(Design support program: Supplement 2)
In the third embodiment, the reason for dividing the design support program into γ1 and γ2 is the same as the reason for dividing the design support programs β1 and β2 in the second embodiment.

  Heretofore, the vehicle failure diagnosis apparatus and the vehicle failure diagnosis apparatus design program according to Embodiment 3 have been described.

  As described above, in the third embodiment, the fail safe correlation determination unit 7000 uses the diagnosis result of each failure diagnosis program or at least one of whether each failure diagnosis target is in a fail safe state, Determines whether or not the failsafe function can be executed. Thereby, when fail-safe function items are related to each other, the correlation can be reflected in the start / stop control of the fail-safe function.

  Further, according to the third embodiment, the fail-safe correlation determination unit 7000 includes the fail-safe correlation definition list 7001 that defines the correlation, and instructs to start or stop the execution of each fail-safe function based on the fail-safe correlation definition list 7001. . Thereby, the execution condition part of each fail-safe function can be separated from other control programs, and independence can be enhanced.

  Further, according to the third embodiment, the fail-safe correlation definition list 7001 represents a plurality of types of diagnosis results by numerical values “1” to “3”, and indicates the correlation between each diagnosis result and the feasibility of the fail-safe function. Define. Thereby, the correlation between the fail-safe functions can be defined in more detail.

  Further, according to the third embodiment, the “fail-safe activation request flag” is stored in the fail-safe activation information storage unit 8000 using the same array number as each failure diagnosis program and its failure diagnosis result information. Can be easily grasped.

  Further, the vehicle failure determination device design program (design support programs γ1, γ2) according to the third embodiment extracts only the items necessary for failure diagnosis of the vehicle from the total fail-safe correlation table, and A fail-safe correlation definition list 7001 is generated. As a result, the designer can select the necessary diagnostic items, and the vehicle failure diagnosis apparatus can be adapted to the specifications of an arbitrary vehicle. Therefore, the number of development steps can be greatly reduced.

<Embodiment 4>
In the fourth embodiment of the present invention, the operation flow of each functional unit and each design support program described in the first to third embodiments will be described. In the following description, for convenience of explanation, each program may be described as being an operation subject, but the actual operation subject is an arithmetic device such as the CPU 201 that executes each program.

  FIG. 15 is a diagram illustrating a flow when the OK flag is received among the operations of the diagnosis result overall processing unit 3000. Hereinafter, each step of FIG. 15 will be described.

(FIG. 15: Step S1401)
Each failure diagnosis program outputs an OK / NG flag or the like as a diagnosis result. This step is started when the diagnosis result overall processing unit 3000 receives the output. If the received output is an OK flag, the process proceeds to step S1402, and if not, the operation flow ends.

(FIG. 15: Step S1402)
The diagnosis result overall processing unit 3000 adds the array address information corresponding to the diagnosis item received in step S1401 to the received output. The diagnosis result overall processing unit 3000 can obtain the array address corresponding to the diagnosis item from the information defined in the “diagnosis name” column described in FIG.

(FIG. 15: Step S1403)
The diagnosis result overall processing unit 3000 writes the in-operation diagnosis completion flag in a bit on the array corresponding to the diagnosis item in the diagnosis result information storage unit 4000. The in-drive diagnosis completion flag is a flag indicating that the OK / NG flag has already been output for the diagnosis item, that is, the diagnosis has been completed.

(FIG. 15: Step S1404)
The diagnosis result overall processing unit 3000 clears the “current failure” flag on the array corresponding to the diagnosis item in the diagnosis result information storage unit 4000. This flag is a flag indicating whether or not the corresponding diagnosis target is in failure.

(FIG. 15: Step S1405)
The diagnostic correlation determination unit 5000 writes a bit instructing whether or not the failure diagnostic program can be executed to the “diagnosis permission” flag on the corresponding array of the diagnostic result information storage unit 4000. Further, the fail safe correlation determination unit 7000 writes a “fail safe start request” flag in the fail safe start information storage unit 8000. The diagnostic result overall processing unit 3000 ends the operation flow after the above processing ends.

  As described above, by defining the name and position of each bit (flag) in the array stored in the diagnosis result information storage unit 4000 with the same name, the same processing can be performed if only the array name is changed in program processing. Therefore, the diagnosis result overall processing unit 3000 can be an independent process. As a result, the diagnosis result overall processing unit 3000 is less affected by each failure diagnosis program and the like, and the independence is enhanced.

  FIG. 16 is a diagram showing a flow when the NG flag is received among the operations of the diagnosis result overall processing unit 3000. Hereinafter, each step of FIG. 16 will be described.

(FIG. 16: Step S1501)
The diagnosis result overall processing unit 3000 proceeds to step S1502 if the output received from each failure diagnosis program is an NG flag, and ends the operation flow otherwise.

(FIG. 16: Steps S1502 to S1503)
This step is the same as steps S1402 to S1403 in FIG.

(FIG. 16: Step S1504)
The diagnosis result overall processing unit 3000 sets a “current failure” flag on the array corresponding to the diagnosis item in the diagnosis result information storage unit 4000.

(FIG. 16: Step S1505)
The diagnosis result overall processing unit 3000 counts up a lamp counter.

(FIG. 16: Step S1506)
The diagnosis result overall processing unit 3000 obtains the control data stored in the diagnostic control data storage unit 2000 and having the array address corresponding to the diagnosis item. The diagnosis result overall processing unit 3000 determines whether or not the lamp counter has reached a numerical value defined in the determination number field of the control data. If it has reached, the process proceeds to step S1507, and if not, the process skips to S1510. The above-mentioned judgment shows that the number of NG detections for lighting the lamp can be arbitrarily set. By defining in the judgment number column, the versatility with respect to the laws and regulations of each country or the request for each car manufacturer is improved. Yes.

(FIG. 16: Step S1507)
The diagnosis result overall processing unit 3000 sets a “lamp ON request” flag on the array corresponding to the diagnosis item in the diagnosis result information storage unit 4000.

(FIG. 16: Step S1508)
The diagnosis result overall processing unit 3000 sets DTC (diagnostic trouble code) information such as a P code on the array corresponding to the diagnosis item in the diagnosis result information storage unit 4000.

(FIG. 16: Step S1509)
The diagnosis result overall processing unit 3000 sets the number of times for clearing the DTC.

(FIG. 16: Step S1510)
This step is the same as step S1405 in FIG.

  FIG. 17 is a diagram illustrating a flow executed at the time of starting or ending the vehicle failure diagnosis apparatus, among the operations of the diagnosis result overall processing unit 3000. Hereinafter, each step of FIG. 17 will be described.

(FIG. 17: Step S1601)
The diagnosis result overall processing unit 3000 sets the array addresses in order from 0. When this step is executed again, the array address is incremented by one. This step has the role of sequentially increasing the diagnostic item counter one by one.

(FIG. 17: Step S1602)
The diagnosis result overall processing unit 3000 determines whether or not the failure diagnosis has been completed in the operation and no failure has occurred. This can be determined by referring to the “diagnosis within operation” flag and the “failure within operation” flag on the array corresponding to the diagnosis item in the diagnosis result information storage unit 4000. If failure diagnosis is completed within the operation and there is no failure, the process proceeds to step S1603. If any condition is not satisfied, the process proceeds to step S1609.

(FIG. 17: Step S1603)
This step is the same as step S1404 in FIG.

(FIG. 17: Step S1604)
The diagnosis result overall processing unit 3000 counts the number of times the lamp is turned off and the number of times the DTC is erased.

(FIG. 17: Step S1605)
If the number counted in step S1604 has reached the number of times the lamp is extinguished, the process proceeds to step S1606, and if not, the process proceeds to step S1609.

(FIG. 17: Step S1606)
The diagnosis result overall processing unit 3000 clears the “lamp ON request” flag on the array corresponding to the diagnosis item in the diagnosis result information storage unit 4000.

(FIG. 17: Step S1607)
If the number counted in step S1604 has reached the DTC clear count, the process proceeds to step S1608; otherwise, the process proceeds to step S1609.

(FIG. 17: Step S1608)
The diagnosis result overall processing unit 3000 clears the DTC related information.

(FIG. 17: Step S1609)
The diagnosis result overall processing unit 3000 determines whether or not the above processing has been completed for all the array addresses. If not completed, the process returns to step S1601 and the same processing is executed for the next array address. If completed, the process proceeds to step S1610.

(FIG. 17: Step S1610)
This step is the same as step S1405 in FIG.

  FIG. 18 is a processing flow executed by the diagnostic correlation determination unit 5000 in step S1405 of FIG. Hereinafter, each step of FIG. 18 will be described.

(FIG. 18: Step S1701)
The diagnostic correlation determination unit 5000 sets the array addresses in order from 0. When this step is executed again, the array address is incremented by one. This step has the role of sequentially increasing the diagnostic item counter one by one.

(FIG. 18: Step S1702)
The diagnostic correlation determination unit 5000 acquires the contents of the array address set in step S1701 in the diagnostic correlation definition list 5001. The diagnostic correlation determination unit 5000 acquires the value of each flag defined by the content of the same array address.

(FIG. 18: Step S1703)
If the values of all the flags acquired in step S1702 are 0, the process proceeds to step S1704, and if any value is not 0, the process proceeds to step S1705.

(FIG. 18: Step S1704)
The diagnosis correlation determination unit 5000 determines that there is no failure diagnosis target or no fail-safe diagnosis target, and the “diagnosis permission” flag on the array corresponding to the array address in the diagnosis result information storage unit 4000 Set. This corresponds to permitting diagnosis of the diagnosis item.

(FIG. 18: Step S1705)
The diagnosis correlation determination unit 5000 clears the “diagnosis permission” flag on the array corresponding to the array address in the diagnosis result information storage unit 4000. This corresponds to prohibiting diagnosis of the diagnosis item.

(FIG. 18: Step S1706)
The diagnostic correlation determination unit 5000 determines whether or not the above processing has been completed for all the array addresses. If not completed, the process returns to step S1701 and the same processing is executed for the next array address. If completed, the operation flow is terminated.

  FIG. 19 is a processing flow executed by the failsafe correlation determination unit 7000 in step S1405 of FIG. Hereinafter, each step of FIG. 19 will be described.

(FIG. 19: Step S1801)
The fail safe correlation determination unit 7000 sets the array addresses in order from 0. When this step is executed again, the array address is incremented by one. This step has the role of sequentially increasing the diagnostic item counter one by one.

(FIG. 19: Step S1802)
The failsafe correlation determination unit 7000 acquires the contents of the array address set in step S1801 in the failsafe correlation definition list 7001. The fail-safe correlation determination unit 7000 acquires the value of each flag defined by the contents of the same array address.

(FIG. 19: Step S1803)
If all the flag values acquired in step S1802 are 0, the process proceeds to step S1804, and if any value is not 0, the process proceeds to step S1805.

(FIG. 19: Step S1804)
The fail-safe correlation determination unit 7000 determines that there is no failure diagnosis target or that there is no failure-safe diagnosis target, and “start-up request” on the array corresponding to the array address in the fail-safe start-up information storage unit 8000. Set flag. This corresponds to permitting execution of the failsafe function.

(FIG. 19: Step S1805)
Fail-safe correlation determination unit 7000 clears the “activation request” flag on the array corresponding to the array address in fail-safe activation information storage unit 8000. This corresponds to prohibiting the execution of the failsafe function.

(FIG. 19: Step S1806)
Fail-safe correlation determination section 7000 determines whether or not the above processing has been completed for all array addresses. If not completed, the process returns to step S1801 and the same processing is executed for the next array address. If completed, the operation flow is terminated.

  FIG. 20 is a diagram for explaining the operation flow of the intake pipe pressure sensor function diagnosis program 1003 as an example of the failure diagnosis program in the present invention. Hereinafter, each step of FIG. 20 will be described.

(FIG. 20: Step S1900)
This operation flow is executed at predetermined time intervals (for example, 40 ms).

(FIG. 20: Step S1901)
The intake pipe pressure sensor function diagnosis program 1003 acquires the array value of the array number corresponding to the diagnosis item of the intake pipe pressure sensor function diagnosis program 1003 in the diagnosis result information storage unit 4000. The intake pipe pressure sensor function diagnosis program 1003 checks the value of the “diagnosis permission request” flag among the acquired array values. If “diagnosis permitted” is set in the flag, the process proceeds to step S1902, and if it is not set, the operation flow ends.

(FIG. 20: Step S1902)
The intake pipe pressure sensor function diagnosis program 1003 checks whether the operating conditions are suitable for determination. If the condition is not satisfied, the operation flow ends. When the condition is satisfied, the process proceeds to step S1903.

(FIG. 20: Step S1903)
The intake pipe pressure sensor function diagnosis program 1003 takes in the intake pipe pressure sensor value.

(FIG. 20: Step S1904)
The fail safe state determination unit 6000 (or the intake pipe pressure sensor function diagnosis program 1003) determines whether or not the diagnosis target is in the fail safe state from the sensor output value captured in step S1903. If it is in the fail safe state, the process proceeds to step S1905, and if it is not in the fail safe state, the process proceeds to step S1906.

(FIG. 20: Step S1905)
Fail-safe state determination unit 6000 (or intake pipe pressure sensor function diagnosis program 1003) sets an F / S state flag corresponding to a diagnosis item of intake pipe pressure sensor function diagnosis program 1003. In this step, the number of F / S state flags is not necessarily one, and a plurality of F / S state flag values may be set according to the control purpose. Since the purpose of using the F / S state flag is to create the F / S state flag on the horizontal axis in the F / S correlation table, the execution / prohibition of execution of the fault diagnosis program or the activation / deactivation of each fail-safe function / What is necessary is just to set a flag suitably for every objective regarding a stop. The same applies to the next step S1906.

(FIG. 20: Step S1906)
Fail-safe state determination unit 6000 (or intake pipe pressure sensor function diagnosis program 1003) clears the F / S state flag corresponding to the diagnosis item of intake pipe pressure sensor function diagnosis program 1003.

(FIG. 20: Step S1907)
The intake pipe pressure sensor function diagnosis program 1003 checks whether or not the sensor output value acquired in step S1903 is within a predetermined range for failure determination. If it is within the range, the process proceeds to step S1908, and if it is not within the range, the process proceeds to step S1909.

(FIG. 20: Step S1908)
The intake pipe pressure sensor function diagnosis program 1003 measures the duration for OK determination. If the duration does not reach the predetermined time, the operation flow is terminated, and if it has reached, the process proceeds to step S1910.

(FIG. 20: Step S1909)
The intake pipe pressure sensor function diagnosis program 1003 measures the duration for NG determination. If the continuation time does not reach the predetermined time, the operation flow is terminated, and if it has reached, the process proceeds to step S1911.

(FIG. 20: Step S1910)
The intake pipe pressure sensor function diagnosis program 1003 sets the “current failure” flag of the array element number corresponding to the diagnosis item of the intake pipe pressure sensor function diagnosis program 1003 in the diagnosis result information storage unit 4000.

(FIG. 20: Step S1911)
The intake pipe pressure sensor function diagnosis program 1003 clears the “current failure” flag of the array number corresponding to the diagnosis item of the intake pipe pressure sensor function diagnosis program 1003 in the diagnosis result information storage unit 4000.

(FIG. 20: Step S1912)
The intake pipe pressure sensor function diagnosis program 1003 sets a determination establishment flag.

  As described above, the diagnostic correlation determination unit 5000 and the failsafe correlation determination unit 7000 sequentially execute loop processing for the diagnostic items defined at all the array addresses. Therefore, if the number of items is large, the load for searching and calculating becomes heavy.

  Therefore, in the present invention, the above-described flows are executed in the timing at which the failure diagnosis program outputs the OK / NG flag and the processing at the time of start or stop, and the situation where the processing timings of a plurality of items overlap is avoided as much as possible. ing. However, there is no practical problem as long as the above processing is executed using a CPU having a high processing capacity.

  As another method for reducing the calculation load, there is a method for limiting the items to be extracted when generating the diagnostic correlation definition list 5001 and the failsafe correlation definition list 7001 instead of processing the array of all the diagnostic items. Conceivable. That is, in each definition list described in FIG. 10 and FIG. 14C, 0xFF is described as an array element for an array element that does not have an item, and the item itself is left. The array elements that do not have items are removed from the beginning, and in the correlation table described in FIGS. 9B and 13B, the vertical axis direction is searched when NG is detected based on the diagnostic item criteria on the horizontal axis. In this method, a definition list is created so as to set a “diagnosis permission request flag” for a diagnostic item to be prohibited and a “fail safe activation request flag” for a fail safe item to be executed.

  However, if the definition list is configured as described above, it is possible to execute diagnosis or failsafe function based on failure status information (“current failure information”, “in-operation failure information”, or “failure establishment information”). In order to control this, it is necessary to preset three patterns of failure status information for one horizontal axis diagnostic item, and the control target item must be created using this.

  This complicates the failure diagnosis program and the definition list. Also, since the definition information of the storage location (that is, the corresponding storage location indicating the item name and the corresponding array address) such as the flag of each control target item must be stored in the storage unit, Inefficient. Further, since the definition information used for the association is increased, when the number of items is several hundred, it is not suitable for the process of compressing the correlation table or the like.

  As described above, in the fourth embodiment, the operation flow of each functional unit and each design support program described in the first to third embodiments has been described.

  The vehicle fault diagnosis apparatus design program according to the present invention can be implemented as a software program developed using, for example, a Java (registered trademark) language or a macro original language of spreadsheet software.

  101: Crank angle sensor, 102: Cam angle sensor, 120: Intake pipe pressure sensor, 121: Intake pipe temperature sensor, 122: Engine water temperature sensor, 123: Atmospheric pressure sensor, 124: Throttle sensor, 125: Air-fuel ratio sensor, 200: Engine control unit, 201: CPU, 202: ROM, 203: A / D converter, 204: RAM, 210: input processing circuit, 220: output circuit, 230: monitor circuit, 1000: fault diagnosis unit, 2000: diagnostic control Data storage unit, 3000: diagnostic result overall processing unit, 4000: diagnostic result information storage unit, 5000: diagnostic correlation determination unit, 5001: diagnostic correlation definition list, 6000: fail safe state determination unit, 7000: fail safe correlation determination unit 7001: Fail-safe correlation definition list, 8000: Fail -Safe start-up information storage unit.

Claims (7)

An apparatus for determining a vehicle failure,
A fault diagnosis unit that executes fault diagnosis by executing one or more fault diagnosis programs that perform fault diagnosis on the vehicle fault diagnosis items ;
A diagnostic correlation determination unit that instructs execution permission or stop of execution of the other failure diagnosis program based on a diagnosis result of the failure diagnosis program;
Equipped with a,
The diagnostic correlation determination unit
A diagnostic correlation definition list that defines a correlation between a diagnostic result of the fault diagnostic program and execution permission or execution stop of the other diagnostic program;
The diagnostic correlation definition list is:
Defining a correlation between a plurality of types of failure states of the failure diagnosis item and execution permission or execution stop of the other diagnostic programs;
The diagnostic correlation determination unit
A vehicle failure determination device , wherein the diagnosis result of the failure diagnosis program, the failure state, and the diagnosis correlation definition list are collated to instruct execution permission or stop execution of the failure diagnosis program . The vehicle failure determination device is
A diagnostic control unit that defines a correspondence order of each failure diagnosis program, control data used when executing the failure diagnosis program, and diagnosis result data of each failure diagnosis program;
The diagnostic correlation determination unit
In the same corresponding order as the corresponding order in which the diagnosis controller is defined, according to claim 1, characterized in that associating a diagnostic result and an instruction execution permission or execution stop of the other of said failure diagnosis program of the fault diagnosis program mutually The vehicle failure determination device described. An apparatus for determining a vehicle failure,
A fault diagnosis unit that executes fault diagnosis by executing one or more fault diagnosis programs that perform fault diagnosis on the vehicle fault diagnosis items;
A diagnostic correlation determination unit that instructs execution permission or stop of execution of the other failure diagnosis program based on a diagnosis result of the failure diagnosis program;
A fail-safe correlation determination unit for instructing execution permission or stop of the fail-safe function of the vehicle based on a diagnosis result of the failure diagnosis program ;
With
The failsafe correlation determination unit
A fail-safe correlation definition list that defines the correlation between the diagnosis result of the failure diagnosis program and the execution permission or execution stop of the fail-safe function included in the vehicle;
The failsafe correlation definition list is:
Defines the correlation between the failure types of the failure diagnosis items and the execution permission or execution stop of the other failsafe function,
The failsafe correlation determination unit
The failure diagnosis program analysis of results, the fault condition, and the fail-safe correlation definition list matching to the fail-safe function of the execution permission or execution stop instruction car both failure determination system, characterized by. The vehicle failure determination device is
A diagnostic control unit that defines a correspondence order of each failure diagnosis program, control data used when executing the failure diagnosis program, and diagnosis result data of each failure diagnosis program;
The failsafe correlation determination unit
The vehicle failure determination device according to claim 3 , wherein instructions for permitting or stopping execution of the failsafe function included in the vehicle are associated with each other in the same order as the order of correspondence defined by the diagnosis control unit. A program for causing a computer to execute a process for designing a device for determining a vehicle failure,
In the computer,
Reading a total diagnostic item list describing all items that can be fault diagnostic items of the vehicle;
Extracting a failure diagnosis item corresponding to the vehicle from the failure diagnosis items described in the total diagnosis item list to generate a failure diagnosis item list of the vehicle;
Reading a total diagnosis correlation definition list that defines the correlation between the diagnosis result of the failure diagnosis item and whether or not to perform the failure diagnosis of the other failure diagnosis items for all items that can be the failure diagnosis items of the vehicle; ,
Extracting a correlation related to a failure diagnosis item corresponding to the vehicle from the correlation defined by the total diagnosis correlation definition list to generate a diagnosis correlation definition list of the vehicle;
Was executed,
The total diagnostic correlation definition list is:
A vehicle failure determination device design program defining a correlation between whether or not to perform failure diagnosis of a plurality of types of failure diagnosis items and failure diagnosis of other failure diagnosis items . In the computer,
Correlation between the diagnosis result of the failure diagnosis item and whether or not to execute the fail-safe function of the vehicle, all items that can be the failure diagnosis item of the vehicle and all functions that can be the fail-safe function of the vehicle Loading a total failsafe correlation definition list to be defined;
Of the correlations defined in the total fail-safe correlation definition list, the failure diagnosis items corresponding to the vehicle and those relating to the fail-safe function of the vehicle are extracted to generate the fail-safe correlation definition list of the vehicle Steps,
The vehicle failure determination device design program according to claim 5, wherein: The total failsafe correlation definition list is:
The vehicle failure determination device design program according to claim 6 , wherein a correlation between a plurality of types of failure states of the failure diagnosis items and whether or not to execute the fail-safe function is defined.

Images