JP2008077219A - Object-oriented vehicle control system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide an object-orientated vehicle control system for easily and accurately specifying a listener to the same type of events and controlling a notification sequence to a plurality of listeners, and for effectively eliminating event notification at an unintended timing or to any unexpected listener. <P>SOLUTION: Each time an event notification request is accepted, destination candidate objects 102J, 102K and 102L who have made an event notification request are defined as listeners and dynamically registered each time in a listener registration list 201, and only the listeners registered in the listener registration list 201 are notified of the issued event. That is, it is possible to selectively notify only the destination candidate objects 102J, 102k and 102L having applied (event notification request) for notification of the event by referring to the listener registration list 201. <P>COPYRIGHT: (C)2008,JPO&INPIT

Description

  The present invention relates to an object-oriented vehicle control system.

JP 2001-270399 A

  2. Description of the Related Art In recent years, electronic devices mounted on automobiles are mainly controlled using a hardware unit including a microcomputer (MPU) called an ECU. As exemplified in Patent Document 1, a method of realizing this control by a computer system designed by object orientation (hereinafter, also referred to as “object-oriented system”) has become widespread (Patent Document 1). By adopting the object-oriented system, it is possible to conceal the difference in the hardware configuration of the devices involved in the control inside the object constituting the software, and to increase the independence of each control program for each control target. As an object-oriented programming language, for example, Java (registered trademark) or C ++ is known, and both describe a program in units of objects. An object is a unit of an organic program with autonomy, and is described in an integrated form of data and procedures. Work as a whole program is advanced by exchanging messages between objects. A procedure that is started by receiving a message is called a method. Requests for work on objects can only be made via methods, and direct access to the data in the objects is prohibited.

  In an object-oriented system, each object receives a message for calling a method incorporated in the object from another object, and processing is executed in such a manner that an execution result of the method is returned to the message source. Here, objects can be broadly classified into classes (class objects) and instances (instance objects) created using the classes. The class describes the definition of variables that store data and methods that describe functional processing. A class corresponds to a template of an object, and has only a general-purpose method set and variable definition, and a specific process cannot be directly executed as it is. Therefore, an instance, which is an object that defines the actual processing contents, assigns a specific value to a variable included in the class, and links to the method actually used among the methods described in the class. It is created through a procedure such as describing a pointer for extension. Note that an instance is newly created using a class as a template, and the original class is not rewritten. Further, the actual processing proceeds in such a manner that each instance created from the corresponding class receives a message and passes control to a method of the corresponding class.

  Next, in the object-oriented system, a concept called an event system has been established. An “event” is issued to request an operation or process corresponding to another object on condition that a specific object involved in the control process is in a predetermined processing state. The corresponding object is received by the event, and the above-described operations and processes are executed. In this case, a method (event handler) for performing processing corresponding to the event must be incorporated in the event issuing object. However, the method does not necessarily exist in the object, but rather it is overwhelmingly implemented in inheritance from other classes. In this case, the event issuing side object is searched until an inheritance class in which the event handler is directly incorporated is found. However, as the number of events issued increases and the number of classes and related branches involved in the same type of event increase, it becomes very difficult to understand the entire event processing, and the system becomes complicated, resulting in errors or errors. There is a problem that the risk of processing increases.

  In order to solve this problem, a system called a proxy event model has been devised and put into practical use. In the concept of the proxy event model, a dedicated class called an event listener is prepared as an interface for event processing, and this is incorporated into a receiving object and used. In the event listener, an event handler method used for the event is prepared and waits for event processing on behalf of the receiving object. As a result, all issued events are once sent to the event listener, where event processing is executed, and the results are passed to the receiving object (that is, the final event notification destination object). This avoids the problem of searching for an inheritance destination class (super class) by searching for an event handler that does not know where it exists to process the issued event.

  However, by classifying event processing into event listeners, when multiple instances (application programs) can be event listeners for the same type of event, it is possible to specify event listeners that actually perform notifications and the order of notifications. Or there may be a problem in the notification timing processing. A specific example is shown in FIG.

  That is, in the event issuing instance 101J (application program 1: hereinafter, the application program is also abbreviated as “app”), the event listener of the event class 103 is sent to the event notification destination instances 102J to 102L (application 2 to application 4). Is incorporated. When an event generation condition is satisfied in the issuing source instance 101J and an event is issued, the event is automatically delivered (notified) sequentially to the applications 2 to 4, which are instances incorporating event listeners of the event class 103.

  However, when the first action is issued, only the app 2 is notified, and when the same event is issued again after a certain delay, only the app 3 is now activated. When it is desired to make a notification, the method of FIG. 12 clearly has a problem. In other words, not only the app 2 but also the app 3 (and the app 4) are notified when the first event is issued, and the event handler operates in the app 3 (and the app 4) regardless of the timing that is not originally desired. As a result, the entire system will malfunction. The cause of this problem is that the notification destination (listener) of the target event is registered fixedly (static) in the built-in event listener, and the event is unconditionally registered to the registered listener. The point is that notification is made.

  It is an object of the present invention to specify a listener for the same type of event and to control the order of notification to a plurality of listeners simply and accurately, and to notify an event to an undesired or unintended listener. It is an object of the present invention to provide an object-oriented vehicle control system that can effectively eliminate such problems.

Means for Solving the Problems and Effects of the Invention

An object-oriented vehicle control system according to the present invention includes a CPU, and is a vehicle control device having a control entity that controls operation of an in-vehicle electronic device by object-oriented program processing using the CPU. In order to solve the problem of
An event management object that obtains an event that is generated when the event generation object is in a predetermined execution state and issues this as a currently valid event;
An event notification request receiving object that receives an event notification request from an event notification destination candidate object;
Each time an event notification request is accepted, the notification destination candidate object that made the event notification request is registered as a listener dynamically in the listener registration list each time, and the listener registered in the listener registration list is registered. Only an event processing object that notifies of published events, and
It is characterized by comprising.

  According to the above configuration, every time an event notification request is accepted, the notification destination candidate object that has made the event notification request is registered as a listener dynamically in the listener registration list each time and registered in the listener registration list. Only the listeners who are present are notified of the issued event. In other words, by referring to the listener registration list, it is possible to selectively notify the event only to the notification destination candidate object that has made a request for notification (event notification request). Even when there are a plurality of destination candidate objects, it is possible to effectively eliminate the problem that event notifications are randomly made up to unintended notification destination candidate objects.

  The event processing object monitors the registration contents of the listener registration list, and based on the issue timing of the event from the event management object and the reception timing of the event notification request from the notification destination candidate object by the event notification request reception object It is possible to determine the event notification timing and notify the corresponding listener on the listener registration list. In other words, in the conventional event notification method that relies only on the fixed listener list, the notification timing is uniformly governed by the event issuance timing, and the event cannot be notified at an appropriate timing. However, in the present invention, the notification destination candidate object that is the receiving side autonomously issues an event notification request and is dynamically registered as a listener, so the timing at which the notification destination candidate object issues an event notification request by the above method In consideration of this, it is possible to accurately grasp which notification destination candidate object is notified of the event, and effectively eliminate the problem of event notification being made at an undesired timing.

  The event processing object copies the listener corresponding to the event issued by the event management object from the listener registration list to the notification execution list prepared separately from the listener registration list, and the notification execution target on the notification execution list Can be constructed to search for listeners Then, notification of issued events is sequentially executed for the searched listeners, and the listener corresponding to the event for which notification has been completed can be deleted from the notification execution list.

  In this way, the listener newly registered during the event issuance is held on the listener registration list until the event notification to the listener on the notification execution list is completed, and the next event is sent at the timing when the notification should be received. The event notification can be received by moving to the notification execution list for the first time after being issued, so that the event notification can be performed at a consistent timing.

  Next, in the present invention, all notification destination candidate objects that can be registered in the listener registration list can be statically registered in an auxiliary list different from the listener registration list regardless of event issuance. is there. In this case, the event processing object executes notification of the event issued to the listener only when the listener registered in the listener registration list matches any of the notification destination candidate objects on the auxiliary list. Build as. As described above, the registration of the listener to the listener registration list is dynamically performed every time a notification request is generated. Therefore, the listener registration list itself is rewritable memory (EEPROM and flash memory can also be used conceptually). However, since the rewriting speed is slow, it is desirable to use a RAM). With the above configuration, even if the memory contents of the memory to which the listener registration list is written are destroyed due to bugs, runaway, etc., the event notification listener can be a regular one by using a fixed auxiliary list together. It can be easily confirmed whether or not there is.

Hereinafter, embodiments of the present invention will be described with reference to the drawings.
FIG. 1 is a diagram conceptually showing the configuration of a control subject 40 in the object-oriented vehicle control system of the present invention from the viewpoint of an object-oriented platform. In this embodiment, the control subject 40 is configured as an arithmetic processing device that executes information processing based on a program described in Java. The program execution device 1 is a CPU in which a circuit for executing bytecode by Java is incorporated, and includes a program execution unit 3, a method search unit 4, a memory controller 5, and the like. The memory 2 is a ROM or RAM, or a storage area including both, and storage areas such as a program data area 6 and a search table area 7 are set (in FIG. 1, the program execution device 1 is shown). Although it is handled as a single CPU for convenience, the configuration is not limited to this. For example, a CPU group connected by an in-vehicle network such as a CAN (Controller Area Network) may be used.

  The program data area 6 stores a byte code program compiled from a Java source program (hereinafter, a program for one address is referred to as “program data”). The search table area 7 stores a class table, a method table, etc. (not shown) in order to search a place where the called method is stored when the method is called.

  Memory access in the program execution device 1 is controlled by the memory controller 5. The program execution unit 3 obtains the program data from the program data area 6 and executes it by giving the memory controller 5 a program address indicating the storage location of the program data to be read. In particular, when the program data is a message indicating a method call, the program execution unit 3 sends the message to the method search unit 4 to request a method storage location search.

  The message includes data indicating the name of the class to which the object that is the object of the message belongs, the method name of the method to be executed, the arguments, the presence / absence of a return value, and its type. Based on this message, the method search unit 4 recognizes the class to which the object that is the message belongs and the specified method, and then searches the storage location of the method using the search table. This search processing is performed by causing the memory controller 5 to read out information by designating an address (indicated as “table address” in the figure) of a storage location of search information required in the search table area 7. Realize. The table address is given by a pointer indicating the entry position of each search table or a value indicating the address of the area corresponding to the entry position in the memory 2.

  The method search unit 4 acquires the start address (hereinafter referred to as “program start address”) of the storage location of the designated method as a search result, and transmits this program start address to the program execution unit 3 as a program counter. The program execution unit 3 sets a work area for the method in a memory area for a stack (not shown), and sequentially transmits each program data constituting the method from the program data area 6 starting from an address indicated by the program counter. Read and execute processing corresponding to each program data.

The execution program of the control subject 40 is constructed on the object-oriented platform. FIG. 2 is a class diagram according to the UML (Unified Modeling Language) notation showing the configuration of the program. The program is composed of the following objects.
Event management object 101C: An event generated when the event generation object 101J enters a predetermined execution state is acquired and issued as a currently valid event.
Event notification request receiving object 102C: Receives an event notification request from event notification destination candidate objects 102J, 102K, and 102L.
Event processing object 103C: Every time an event notification request is accepted, the notification destination candidate objects 102J, 102K, and 102L that have made the event notification request are registered as listeners dynamically in the listener registration list 201 each time. Only the listener registered in the listener registration list 201 is notified of the issued event.

  The event management object 101C is a class object that can create an instance object corresponding to an application program (app 1 is displayed in FIG. 2) that is an event generation source as the event generation object 101J. As an event is generated on the application program side, the instance object is created and the generated event is issued and delivered to the event processing object 103C.

  The event notification request receiving object 102C can create an instance object corresponding to an application program as an event notification destination as notification destination candidate objects 102J, 102K, and 102L, and an event listener class 104I corresponding to an event to be notified. Is a class object implemented as an interface. Then, the notification destination candidate objects 102J, 102K, and 102L called by the event listener class 104I are incorporated into the listener registration list 201 (and the notification execution list 202 and the auxiliary list 203 described later) of the event processing object 103C as listeners. It is. In FIG. 2, the listener registration list 201 is “dynamically registered listener list”, the notification execution list 202 is “event issuing listener list”, and the auxiliary list 203 is “statically registered”. "List of listeners".

  Then, the event processing object 103C monitors the registered contents of the listener registration list 201, and also issues the event issuance timing from the event management object 101C and the notification destination candidate objects 102J, 102K, and 102L by the event notification request receiving object 102C. The event notification timing is determined based on the reception timing of the event notification request, and the corresponding listener on the listener registration list 201 is notified.

  FIG. 3 is a sequence diagram corresponding to the class diagram of FIG. That is, each of the notification destination candidate objects 102J, 102K, and 102L is dynamically registered in the listener registration list 201 of FIG. 4 as a listener that receives an event notification every time any of the event notification requests is made. The issued event is notified only to the listeners registered in the listener registration list 201. In other words, by referring to the listener registration list 201, it is possible to selectively perform event notification only to a notification destination candidate object that has made an offer for requesting (event notification request). As a result, even when there are a plurality of notification destination candidate objects 102J, 102K, and 102L for the same event, the notification destination candidate objects 102J, 102K, and 102L on the receiving side independently issue an event notification request, Each time it is dynamically registered as a listener, event notification is made only for the registered listener. Therefore. As shown in FIG. 12, there is no problem that event notifications are randomly made to unintended notification destination candidate objects 102J, 102K, and 102L, and event notification is performed at appropriate timing for each notification destination candidate object 102J, 102K, and 102L. Is possible. In this case, an event is issued separately for each notification.

  FIG. 4 conceptually shows the listener registration list 201. The listener registration list 201 is always in a state in which registration of a new listener can be accepted, and a listener for the same event may be additionally registered while a certain event is issued. This listener may be the same as the listener involved in the event being published, or may be a different listener. In the former case, after the event being issued is notified, the same listener will be notified the next time the same type of event is issued. In the latter case, the event to be issued next time Another listener is notified. In any case, registered listeners are sequentially registered in order of time series in which notification is requested for each event type, and receive notification of corresponding events in order from the top one.

  Here, in the case of processing for performing event notification by directly searching for listeners on the listener registration list 201, if a new listener for the event is added in the middle of issuing an event, the listener added later On the other hand, the event that was originally intended to be notified in the event loop cycle after the next time is accidentally caught in the search cycle of the event loop that covers the currently issued event, and the event notification is made earlier than desired. Can occur.

  In order to solve this, in the present embodiment, the following method is adopted. In other words, in the event processing object 103C, as shown in FIG. 4, a listener corresponding to the event issued by the event management object 101C is sent from the listener registration list 201 to the notification execution list 202 prepared separately from the listener registration list 201. And the listener to be a notification execution target is searched for on the notification execution list 202. And notification of the issued event is sequentially performed with respect to the searched listener. Note that the listener corresponding to the event for which the notification has been completed is deleted from the notification execution list 202.

  When an event notification request for another event is made while an event is issued, the notification destination candidate objects 102J, 102K, and 102L (application 2 to application 4) that have made the event notification request are added to the listener registration list 201 as listeners. In addition to being registered, the listener is held on the listener registration list 201 until a corresponding event is issued. The listener newly registered during the event issuance is suspended on the listener registration list 201 until the event notification to the listener on the notification execution list 202 is completed, and the next event is issued at the timing when the notification should be received. Then, it is possible to receive the event notification by moving to the notification execution list 202 for the first time. Thereby, the above problems are eliminated. In order to improve the accuracy of event notification timing, in the event processing object 103C, as the event management object 101C issues an event, the listener corresponding to the event is transferred from the listener registration list 201 to the notification execution list 202. The list 201-203 is defined in such a way that the number of registered listeners is 0 or more and no upper limit is set (0 .. *) as is clear from FIG. .

  Note that, even when events of different instances (types) are sequentially issued, as shown in FIG. 4, a plurality of events of different instances ( Listener registration list 201 is prepared individually for each of α, β, γ. When an event is issued, the event processing object 103C sequentially copies the listener from the listener registration list 201 corresponding to the event to the notification execution list 202.

  FIG. 4 illustrates a case where a notification request is issued from the application 2 for the event β. Application 2 (identified by the number “2”) is already registered as a listener in the event β allocation area of the listener registration list 201. When the event β is actually issued, the application 2 that is the listener in the listener registration list 201 is copied to the notification execution list 202 (T1). Then, by searching the notification execution list 202, the copied “application 2” is searched, and the event β is notified (T2).

  Note that the listener corresponding to the event for which the notification has been completed must be deleted (or invalidated) from the notification execution list 202 (otherwise, the notification is executed redundantly on the issued event). Leads to that). In addition, with regard to the handling of listeners on the listener registration list 201, the event registration object 103C basically corresponds to the issued event because the listener registration timing is one of the dominant factors of event notification timing. As the listener to be copied is copied from the listener registration list 201 to the notification execution list 202, it is necessary to delete the listener from the listener registration list 201 as a copy source.

  However, when the notification frequency of the same event to the same listener is high, the notification destination candidate object 102J is more likely to retain the specific listener on the listener registration list 201 for a necessary period (or permanently). , 102K, and 102L do not need to issue notification requests one by one. In this case, the event processing object 103C, for a predetermined listener, copies the listener corresponding to the issued event from the listener registration list 201 to the notification execution list 202, and registers the listener as a copy source. It is constructed so as to be kept on the list 201. The listener registration state on the listener registration list 201 can be permanently set for some specific listeners. However, if it is desired to hold the listener registration state for a limited time, the event processing object 103C is set in advance. A specific listener among the defined listeners may be constructed so as to be deleted from the listener registration list 201 as a copy source when a deletion request from another object is received. In any case, for listeners kept on the listener registration list 201, the event notification timing is governed by the event issuance timing.

  Next, in the present embodiment, all notification destination candidate objects 102J, 102K, and 102L that can be registered in the listener registration list 201 are statically transferred to the auxiliary list 203 different from the listener registration list 201 regardless of the issuance of the event ( Registered). The event processing object 103C is the event processing object 103C only when the listener registered in the listener registration list 201 matches one of the notification destination candidate objects 102J, 102K, and 102L on the auxiliary list 203. Execute notification. As described above, the registration of the listener in the listener registration list 201 is dynamically performed every time a notification request is generated. Therefore, the listener registration list 201 itself needs to be created on a rewritable memory. Specifically, this memory is the memory 2 of FIG. 1 and is composed of a RAM, but there is always a risk that the stored contents are lost due to bugs, runaway or the like. However, as described above, by using the fixed auxiliary list 203 in combination, even if the stored contents of the memory in which the listener registration list 201 is written are destroyed due to a bug or runaway, the event notification destination listener can be It can be easily confirmed whether or not it is a thing.

  Hereinafter, examples in which the above embodiment is further applied to and deployed in an in-vehicle security system will be described. FIG. 5 is a block diagram showing a schematic hardware configuration of the security system 100 which is a specific example of the object-oriented vehicle control system. The security system 100 receives a microcomputer-controlled intrusion detection device 42, and receives detection information from the intrusion detection device 42, operates an alarm, and executes security processing such as in-vehicle image capturing by a surveillance camera by microcomputer control. The control unit 41 is configured as a system connected by a communication network (hereinafter also referred to as “security system 40”). Further, the security control unit 41 can wirelessly communicate with a mobile phone possessed by the user, an external security center, and the like, and can wirelessly transmit notification information, a captured image, and the like when an abnormality occurs.

  As shown in FIG. 6, consider a case where the user calls the security control unit 41 with the mobile phone 43 and instructs the security set. The security control unit 41 instructs the intrusion detection device 42 to set the security, receives the set completion status from the intrusion detection device 42, and notifies the user (the mobile phone 43) of the completion of the setting as the first operation. . The intrusion detection device 42 in the security set state detects the intrusion into the vehicle, and this is a second operation for notifying the user (the mobile phone 43) of an alarm. It is assumed that the app 1 that is the event issuer and the app 2 (and 3 and 4) that are candidates for the notification destination are installed in the intrusion detection device 42.

  As a pattern corresponding to the conventional example of FIG. 12, in the first operation, an event that returns “notification completed” is issued on the condition that a set completion status is received from the intrusion detection device 42. Then, it is assumed that an event that returns “notification completion” is issued on condition that intrusion detection is received from the intrusion detection device 42. In addition, it is assumed that the listener is fixedly registered in the application 2 (and 3, 4).

  When security set is completed, intrusion detection is made after a sufficient amount of time, and both notifications to the user's mobile phone 43 are successful, as shown in FIG. It can be seen that any event notification (set completion or intrusion detection notification completion) is made at an appropriate timing.

  However, when the user's mobile phone 43 is turned off, busy, or in a place where radio waves do not reach, wireless connection is impossible, so notification to the user using this fails. Sometimes. It is also possible that a bandit has already invaded the vehicle when the user sets security with the mobile phone 43. Then, a malfunction operation as shown in FIG. 7 occurs.

  In other words, since the intrusion detection device 42 is already in the state where the intrusion detection is activated when the security is set, the event notification in the first operation is executed without contradiction, and then the intrusion is performed without interruption. A detection notification is returned from the intrusion detection device 42. At this time, since the mobile phone 43 of the user is in a state where the vehicle side and the phone are connected for the security set, even if an attempt is made to call the user for intrusion notification from the vehicle side, the user's mobile phone 43 is in a “not connected” state, Notification will fail. However, if the event listener receives the intrusion detection from the intrusion detection device 42, the event listener immediately performs the “notification completion” event notification, which contradicts that the notification to the user has actually failed.

  However, by adopting the method of the present embodiment, this problem is solved as follows (FIG. 9 shows the flow of information between objects, and FIG. 8 shows security control related to the entire event notification processing. The flow of processing in the unit 41 is shown). As shown in FIG. 9, the application 2 (3, 4) side on the intrusion detection device 42 side makes an event notification request when an intrusion is detected (FIG. 8: S1), and is dynamically registered as a listener (FIG. 9: response). Prior setting (b) / FIG. 8: S2). On the other hand, the event management object 101C performs notification processing to the user (FIG. 9: (c) / FIG. 8: S3), and the event is validated only when this notification is completed normally. (FIG. 9: (e) / FIG. 8: S4 → S5).

  As shown in FIG. 10, in the event processing object 103C, as described above, the listener corresponding to the issued event is copied from the listener registration list 201 to the notification execution list 202, and further to the notification execution list 202. When the copied listener matches one of the listeners fixedly registered in the auxiliary list 203, a completion notification (event notification) is returned to the intrusion detection device 42 for the first time (FIG. 9: (f) / FIG. 8). : S6).

  FIG. 11 is a sequence diagram showing the result. That is, as described above, the user notification fails while the mobile phone 43 on the user side is in a call due to the security set. However, in this case, since an event is not issued, a completion notification (event notification) is sent to the intrusion detection device 42. Has not returned. Since the intrusion detection device 42 cannot receive the event notification, the intrusion detection notification is unavoidably retransmitted. At this time, if the user's mobile phone 43 is in a call waiting state and is in a call waiting state, the user notification will succeed, so an event that returns notification completion is issued for the first time, thereby realizing consistent processing. To do.

The figure which shows notionally the structure of the control main body in the object-oriented vehicle control system of this invention from a viewpoint of an object-oriented platform. The class diagram according to the UML notation which shows the structure of the program which the control main body of FIG. 1 performs. The sequence diagram corresponding to the class diagram of FIG. The figure which shows notionally a listener registration list with the usage. 1 is a block diagram showing a schematic hardware configuration of a security system which is a specific example of an object-oriented vehicle control system. The sequence diagram which shows the operation | movement at the time of normal in the conventional security system. The sequence diagram which similarly shows the operation | movement at the time of a malfunction. The flowchart which shows the flow of the process in the security control part concerning the whole event notification process. The conceptual block diagram which shows the flow of the information between the objects corresponding to FIG. The conceptual block diagram which shows the detail of the event process part of FIG. FIG. 9 is a sequence diagram corresponding to FIG. 8. The figure which shows the problem of the conventional system.

Explanation of symbols

1 Program execution device (CPU)
40 Control subject
101C Event management object 101J Event generation object 102C Event notification request reception object 102J, 102K, 102L Notification destination candidate object 103C Event processing object 201 Listener registration list 202 Notification execution list 203 Auxiliary list

Claims (9)

A vehicle control device including a CPU and having a control entity that controls operation of an in-vehicle electronic device by object-oriented program processing using the CPU, wherein the program is
An event management object that obtains an event that is generated when the event generation object is in a predetermined execution state and issues this as a currently valid event;
An event notification request receiving object that receives an event notification request from the event notification destination candidate object;
Each time the event notification request is accepted, the notification destination candidate object that has made the event notification request is registered as a listener dynamically in the listener registration list each time, and the listener registered in the listener registration list is registered. An event processing object for notifying the issued event, and
An object-oriented vehicle control system comprising:   The event processing object monitors registration contents of the listener registration list, and issues an event notification request from the notification destination candidate object by the event notification request reception object and an issue timing of the event from the event management object. The object-oriented vehicle control system according to claim 1, wherein a notification timing of the event is determined based on the timing, and the corresponding listener on the listener registration list is notified.   The event processing object copies a listener corresponding to an event issued by the event management object from the listener registration list to a notification execution list prepared separately from the listener registration list, and on the notification execution list, A listener that is a notification execution target is searched, notifications of the issued events are sequentially executed for the searched listeners, and a listener corresponding to the event for which the notification is completed is deleted from the notification execution list. The object-oriented vehicle control system according to claim 1 or 2.   The object-oriented vehicle according to claim 3, wherein the event processing object immediately copies a listener corresponding to the event from the listener registration list to the notification execution list as the event management object issues the event. Control system.   The listener registration list is individually prepared for each of a plurality of events of different instances, and when the event is issued, the event processing object sends the listener from the listener registration list corresponding to the event for the notification execution. 5. The object-oriented vehicle control system according to claim 3 or 4, wherein the object-oriented vehicle control system is sequentially copied to a list.   The event processing object deletes the listener from the listener registration list as a copy source as the listener corresponding to the issued event is copied from the listener registration list to the notification execution list. The object-oriented vehicle control system according to claim 5.   The event processing object, for a predetermined listener, copies the listener corresponding to the issued event from the listener registration list to the notification execution list, and registers the listener as a copy source. 6. The object-oriented vehicle control system according to claim 3, wherein the object-oriented vehicle control system is kept on the list.   The event processing object deletes the listener from the listener registration list as a copy source when receiving a deletion request from another object for a specific one of the predetermined listeners. Item 6. The object-oriented vehicle control system according to any one of Items5. All the notification destination candidate objects that can be registered in the listener registration list are statically registered in an auxiliary list different from the listener registration list regardless of the issue of the event,
The event processing object performs notification of the event issued to the listener only when the listener registered in the listener registration list matches any notification destination candidate object on the auxiliary list. The object-oriented vehicle control system according to any one of claims 1 to 8.

Images