JPH03149337A - Autonomous distributed engine control device - Google Patents

Abstract

(57) [Summary] This bulletin contains application data before electronic filing, so abstract data is not recorded.

Description

[Detailed Description of the Invention] [Field of Industrial Application] The present invention is a method for controlling fuel supply amount, ignition timing, etc. based on the detection results of various information representing engine operating conditions such as engine rotational speed and intake flow rate. The present invention relates to an autonomous decentralized engine control device, and particularly to an autonomous decentralized engine control device suitable for controlling the fuel supply amount of an automobile gasoline engine.

[Conventional technology]

Among various internal combustion engines, automotive gasoline engines in particular are required to meet strict exhaust gas regulations and sufficiently improve engine performance. Control devices are now being used that sequentially capture data from the engine, calculate predetermined control data based on this data, and use this control data to control fuel supply amount, ignition timing, etc. to optimal conditions. Examples of this can be found, for example, in various publications of JP-A-5-2433 and JP-A-59-153,933.

Furthermore, in such systems, so-called autonomous decentralized engine control systems that give autonomy to the processing of each part have also been proposed. Printing collection 881 1986-5 p2
1 Fu 220 Document No. 881055, the system described therein includes a fuel control controller, an ignition control controller, a throttle control controller, a mass data processing controller, a communication controller, a sensor controller, and A total of seven types of controllers, including an engine speed controller, are mounted on the communication path.

[Problem to be solved by the invention]

The above conventional technology does not consider failsafe when using multiple controllers, and if an abnormality occurs in even one of the multiple controllers, it becomes difficult to maintain normal engine control. There was a problem with putting it away.

In particular, if the communication controller breaks down, the control of all items will be disrupted.

Furthermore, the above-mentioned conventional technology does not take into account changes in the specifications of the engine system, and there is a problem in that when adding a controller or changing characteristics, rematching of programs and data within each controller is required.

An object of the present invention is to provide an autonomous decentralized engine control device that has sufficient fail-safety, maintains high reliability, and can easily reorganize the system to accommodate changes in specifications.

[Means to solve the problem]

In order to achieve the above object, the present invention provides a backup function to modules such as sensors and actuators equipped with an autonomous decentralized function, and also arranges each autonomous decentralized module on a common data bus. A predetermined management device can be arbitrarily connected.

[Effect]

Even if that module fails, the backup function provided to each autonomous decentralized module will maintain the specified function, so the operation of other modules will not be adversely affected.
The engine control maintains the necessary fail-safety, and if necessary, it is possible to connect a management device to the data bus and genialize programs and data for each module, so it can flexibly respond to system reorganization. can.

〔Example〕

DESCRIPTION OF THE PREFERRED EMBODIMENTS The autonomous decentralized engine control device according to the present invention will be described in detail below with reference to illustrated embodiments.

FIG. 1 shows one embodiment of the present invention, and in the figure, 1.2.
3 is an atom, 4 is a system management device, and 5 is a data bus.

Here, the various sensors and actuators necessary for engine control are configured as modules equipped with computers, making them intelligent, and these are called atoms. Therefore, Atom 1 is a water temperature sensor module for detecting engine cooling water temperature, Atom 2 is a hot wire sensor module for measuring engine intake flow rate,
Atom 3 is an injector module for fuel injection, and these modules are connected in parallel to a common data bus 5 and mutually exchange necessary data to control the engine.

System-Administrator
Although not shown, the data bus 4 can be arbitrarily connected to the data bus 5 using a predetermined connection device such as a socket or plug.
It is configured to be removable and is usually kept at the factory where the car is shipped, car dealer, etc. It is connected to the data bus 5 when it becomes necessary to replace the attenuator 1 or to rearrange (reorganize) the control system.

FIG. 2 shows an embodiment of the computer module 20 incorporated in each atom, which includes a C
PU (central processing unit) 21,
Ilo captures signals from external devices such as various sensors and drives actuators such as fuel injection valves.
(input/output circuit) 22, a communication circuit (Cominucat) that sends and receives data via the data bus 5, which is a common line.
ion-ic) 23, an E''PROM 24 and a PROM 25 that store programs and data, and a backup circuit 26 that takes over control when an abnormality occurs in the CPU 21.

And two types of memory E"PROM24, PROM25
Of these, the E"PROM 24 stores data and subroutines that need to be changed when reconfiguring the system, and the contents can be rewritten as required by instructions from the system management device 4. ing.

Next, we will explain the program configuration of each atom. These are as shown in Figure 3, and are programs that do not require changes even when the system is reconfigured.
slain-progr for OS etc.) and data.
For data and programs that are stored in jsubrotine1~3'' and that require other changes,
It is stored in ta 1~3''.And among these,
“main-program” is PROM25 in Figure 2.
, subrotime 1~3″ and data
1 to 3'' are written to the E'' PROM24.

On the other hand, the program structure of the system management device 4 based on the combination of each atom is shown in FIG.
Program names and data names marked with a plus sign represent those that are required in that combination, and those marked with a minus sign represent those that are unnecessary in that combination.

Therefore, for example, in the combination of Atom ING (ignition system) and THS (water temperature sensor), "subrotine I 1
``is required, and subrotine I 2'' is unnecessary and will be deleted.

Therefore, the system management device 4 optimizes the program of each atom at the time of system reorganization based on the configuration table shown in FIG.

FIG. 5 shows the data format 50 on the common line (data bus 5). First, there is a token 51 at the beginning of the line "Fu" indicating that the signal that follows is information. Next, data-i for data recognition
d″52 and type″ to distinguish the same type of data
53, followed by the original data data"54. Here, each atom looks at type"53 and judges whether the following data is what it needs. do.

On the other hand, when transmitting data from each atom to the common line, it is sufficient to monitor the signal and transmit data to an empty spot after the token 51 has passed.

Note that as another method, the data exit timing may be set to an integral multiple of the basic synchronization cycle, and each data may be transmitted in a nested manner.

FIG. 6 shows the atom combination table held by the system management device 4.
and "register", the -ain" table describes all atoms that can be connected to the common line, and the "register" table records the atoms connected to each system. .

Therefore, when the system management device 4 is connected to a common line (data bus 5) at an automobile dealer or the like, the system management device 4 determines whether or not the atom connected there has already been benevolized, or if additional atoms are to be added. By looking at this atom combination table, you can find out whether or not there is.

FIG. 7 shows a data table that the system management device 4 also has, and this table describes all the data "data-id" necessary for engine control and the similarly necessary units. , these are used to verify data when the program combinations shown in FIG. 4 are used.

Next, the benevolence processing of the entire system in this embodiment will be explained with reference to FIG.

Processing 801 in FIG. 8 is started when the system is powered on, and first, it is determined whether the system has been constructed (step 802). The way to make this determination is to set a flag at a specified location in E"FROM 24 when a system is constructed at a car dealer, etc., and use a program that each atom checks at the time of startup. All you have to do is boost it, and specifically, check the table in Figure 6.

First, if the system has not been constructed, it is then determined whether or not the system management device is connected to the data bus (step 803), and if it is not connected, processing to request it (step 803) is performed. 8
05) is executed.

Incidentally, this system management device connection request may be made by installing a display atom so that the appropriate display (visual or auditory) can be made at the driver's seat of the automobile. On the other hand, if it is determined that the system management device is connected, the system is benevolized for the first time (step 8).
06).

On the other hand, if it is determined in step 802 that the system has been constructed, it is then checked whether there are any additional atoms (
Step 804), if there is no addition, the process ends here because the benevolence has already been completed, but if there is an additional atom, the process returns to step 803 and either step 805 or step 806 is performed. The process is repeated. Note that the presence or absence of additional atoms at this time can be determined by checking the table in FIG. 6. Specifically speaking,
For the added atom, the flag representing it is
Since it has not yet been set in the E''FROM 24, the added atom itself should send a signal to that effect to the common line when it starts up.

Next, details of the system processing in step 806 described above will be explained with reference to FIG.

First, in step 910, the system management device checks whether the above-described "system-id" of the system is registered. In this case, as in the case described above, if the atom has already been registered, it may be configured such that each atom sends its respective "system-id" to the common line at 11:00 when the system starts up.

system-id" has been registered, in step 902, the system-i in the system management device is registered.
Search the d table and check the system construction status. Then, the system-id request process in step 903 is executed, and then the process in step 904 is executed, and the system configuration information at this time is registered in the 3system-id table, and the system administrator table (system-id) shown in FIG. administrator reg
ister table).

Next, the system-id request processing in step 903 will be explained with reference to FIG.

First, the system management device stores its own system administrator main table (system-a).
dIIIinistrator main table
) and poll each atom in the table order to see if there is a response. If there is a response, registration is executed (steps 1004 to 1005).

Next, the system management device checks whether a new atom exists in the already constructed system, and if there is a new atom, executes loading of the benevolent program (steps 1006 to 1006). Step 1009).

At this time, in steps 1008 and 1009, the program combination table shown in FIG. 4 is referred to and necessary data and programs are reloaded.

FIG. 11 shows the details of the benevolent program loading process in step 1007.
At 101, a benevolent program load transmission signal is sent to the target atom.

If the atom that received this transmission signal is in a standby state, a reception standby signal is sent back as a process in step 1102, then in step 1103 the serial receiver is put in a receiving state, and then in step 110
4 to release the address data bus.

On the other hand, in response to the above-mentioned received standby signal, the system management device sends a benevolent program to the corresponding atom (step 1106), and the atom that receives this program writes it to the E''FROM 24 (step 1107).
), the process ends when this is confirmed (step 1108).

Therefore, according to this embodiment, each atom (autonomous decentralized module) is provided with a backup function, so even if that module fails, this backup function maintains the specified function, and other The operation of the modules is not adversely affected, the necessary fail-safe engine control is maintained, and if necessary, a management device can be connected to the data bus to perform program and data benevolence for each module. Because it becomes possible,
It can also flexibly respond to system reorganization.

〔Effect of the invention〕

According to the present invention, since the autonomous decentralized module is provided with a backup function, there is no risk of serious trouble in engine control even in the event of a unit abnormality. It is possible to take advantage of the advantages and respond flexibly and easily to system changes.

Further, according to the present invention, since a common data bus is used, it is easy to add or change modules.

Further, according to the present invention, since the program configuration table and module configuration table for each system can be managed by the system management device, program maintenance and hardware configuration maintenance are also facilitated. Since this system management device does not need to be permanently installed in the vehicle, it can be separated from the user and placed under the control of the dealer, which has the effect of freeing the user from space issues associated with mounting it on the vehicle. .

[Brief explanation of the drawing]

FIG. 1 is a block diagram showing an embodiment of an autonomous decentralized engine control device according to the present invention, FIG. 2 is a block diagram showing an embodiment of a computer module according to the present invention, and FIG.
Figures 4 and 4 are program configuration diagrams, Figure 5 is an explanatory diagram of data formats, Figures 6 and 7 are explanatory diagrams of tables, and Figure 8 is an explanatory diagram of tables.
9, FIG. 11, and FIG. 11 are flowcharts for explaining the operation. 1.2.3...Atom, 4...System management device, 5...\Data bus (common line). 1 1 + 11 1 1 1 + 10 heat ■ + 11 Stop Ef saw ``'' ζh

Claims (1)

[Claims] 1. In an engine control device that calculates the engine control data based on the detection result of at least one of the various types of information representing the operating state of the engine, at least one of the types of information for detecting the various types of information is used. a computer unit mounted on each of the sensor means and at least one actuator means for controlling the operating state of the engine using the control data; a data backup means mounted on each of these computer units; A data bus connecting the computer units and an external connection means coupled to the data bus are provided, and the engine control is performed by transmitting and receiving data via the data bus, and
An autonomous decentralized engine control device characterized in that each of the computer units is configured to be arbitrarily accessible from a predetermined management device.