JP2008146480A - Object-oriented vehicle control system and program loading support system - Google Patents

Abstract

The size of a RAM area allocated to a listener registration list is optimized according to the occupied size of an auxiliary list in a ROM.
An allocation area size on a RAM of a listener registration list is determined based on a data size of an auxiliary list of an auxiliary list corresponding to a vehicle to be mounted, and the determined allocation area size is set as a program mounting destination. Is set for the vehicle RAM.
[Selection] Figure 1D

Description

  The present invention relates to an object-oriented vehicle control system and a program loading support 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. Another object of the present invention is to provide an object-oriented vehicle control system that can effectively eliminate such problems and a program loading support system used therefor.

Means for Solving the Problems and Effects of the Invention

An object-oriented vehicle control system according to the present invention includes a microcomputer having a CPU, a ROM, and a RAM. An in-vehicle electronic device is executed by a CPU, an object-oriented program stored in the ROM is used as a work area. A vehicle control system having a control body that controls operation by executing a program,
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 that is allocated in the RAM and registered in the listener registration list. An event processing object that notifies the published event only to the listener that has been
In addition, in the ROM, all 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 area size on the RAM allocated to the listener registration list is determined to be a value corresponding to the occupied size of the auxiliary list in the ROM.

  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.

  In addition, the total number of notification destination candidate objects that can be registered in the listener registration list varies depending on the vehicle type that is the mounting destination. On the other hand, it is more efficient in manufacturing to share the program that manages the event notification among vehicle types. In this case, the size of the area on the RAM allocated to the listener registration list is also determined from the above sharing flow. At first glance, it seems desirable to set a constant value according to the vehicle type with a large total number of objects. However, the ECU for automobiles has limited memory resources from the viewpoint of cost reduction, and is required to make full use of a small-capacity RAM. Therefore, in a vehicle type in which the total number of notification destination candidate objects is small, the RAM area allocated to the listener registration list becomes excessive, which is very undesirable from the viewpoint of effectively using the RAM capacity. Furthermore, the number of notification destination candidate objects may increase or decrease due to design changes such as vehicle development progress or model changes, and there is a problem that the RAM area allocated to the listener registration list cannot be flexibly handled.

  However, in the present invention, all notification destination candidate objects that can be registered in the listener registration list are static auxiliary lists in the ROM (the contents of this auxiliary list have specific contents for each vehicle type, for example). Since the size of the RAM area allocated to the listener registration list is set to a value corresponding to the occupied size of the auxiliary list, the RAM allocation size of the listener registration list is optimized for each vehicle type, for example. Thus, the RAM area is not wasted. In addition, it can flexibly handle design changes due to vehicle development progress and model changes.

  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.

  The event processing object performs notification of an 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 described above. Can be built. 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.

Next, the program mounting support system of the present invention is a system for supporting mounting of an object-oriented program for realizing the function of the object-oriented vehicle control system of the present invention on a vehicle,
Auxiliary list storage means for storing an auxiliary list prepared individually for each vehicle to be mounted;
An allocation area size determining means for specifying an auxiliary list of vehicles to be mounted on the auxiliary list storage means and determining an allocation area size on the RAM of the listener registration list based on the data size of the auxiliary list;
And an allocation area size setting means for setting the determined allocation area size in the RAM of the vehicle as a program mounting destination.

  When the program loading support system of the present invention is used, the allocation area size on the RAM of the listener registration list is determined based on the data size of the auxiliary list corresponding to the vehicle to be mounted, and the determined allocation area size is programmed. Since the setting is made for the RAM of the vehicle as the mounting destination, the size of the RAM area allocated to the listener registration list is optimized in accordance with the occupied size of the auxiliary list in the ROM. Control system can be easily obtained.

  The allocation area size setting means includes a template program storage means for storing a template program in which the allocation area size on the RAM of the listener registration list of the program to be installed is undetermined, and the allocation area determined by the allocation area size determination means An allocation area size complementing unit that complements the size with the template program to be a mounting target program, and a mounting target program transfer unit that transfers the mounting target program to the vehicle can be configured. A RAM program allocated to the listener registration list is prepared by preparing a template program in which the allocation area size on the RAM of the listener registration list is undetermined and supplementing the template program every time the allocation area size is determined. The size optimization of the area can be executed very simply.

  In this case, the template program in the template program storage means may be described in a form including an allocation area size as an undefined constant by a compiled language. The allocation area size complementing means compiles the undefined constant rewriting means for rewriting the undefined constant indicating the allocation area size of the template program with the determined allocation area size, and the rewritten template program as the installation target program. It can be constructed as having a target program compiling means. The mounting target program transfer means can be configured to transfer the compiled mounting target program to the vehicle side. By adopting a compiled language, the control program and the auxiliary list can all be compiled into machine language and then installed in the actual vehicle, and the program (application) operating environment on the actual vehicle can be reduced in weight. By adopting the above configuration of the program loading support system of the present invention, the allocation area size can be easily rewritten in the state of the template program before compilation.

  As programming languages suitable for object-oriented programming, C, C ++, Java, and the like are known, but in consideration of the fact that they can be installed in machine language when installed in an actual vehicle, C or C ++ can be used in particular. Desirable (in the case of Java, it is necessary to mount a virtual machine for constructing a Java operating environment on the actual vehicle side).

  In this case, the allocation area size determination unit calculates the memory occupation size of the auxiliary list after compilation by analyzing the source code of the auxiliary list in the non-compiled state stored in the auxiliary list storage unit, and the calculated value The allocation area size on the RAM of the listener registration list can be determined based on the above. By using the memory occupancy size of the auxiliary list calculated by the source code analysis of the non-compiled auxiliary list, the RAM allocation area size of the listener registration list can be determined more appropriately. In the case of adopting C, the preprocessor serves as an undefined constant rewriting means, and the preprocessor generates a header file in which the calculated allocation area size value is described, and uses this to generate a pre-compiled template program. Rewrite the undefined constant corresponding to the allocated area size.

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 the present embodiment, the control subject 40 is configured as an arithmetic processing unit (ECU: hereinafter also referred to as ECU 40) that executes information processing based on a program written in C language. The program execution device 1 is a CPU in which a circuit that executes byte codes in C language 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 bytecode execution program compiled from a C language 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.

  FIG. 1B shows an example in which the control main body 40 is configured by an ECU 40 mainly including a microcomputer. The program execution device 1 is a CPU 1, and the memory 2 includes a RAM 2A and a ROM 2B. In the RAM 1A, a listener registration list 201 and a notification execution list 202 described later are formed. The ROM 2B stores the program data 6, the search data table 7, and the auxiliary list 203. The CPU 1, RAM 2A, ROM 2B and input / output unit 102 are interconnected by an internal bus.

  The ECU 40 is connected to other ECU groups on the vehicle via a serial interface 107 and a reception buffer 107a via a serial communication bus 30 that constructs an in-vehicle network (communication protocol: CAN (Controller Area Network), for example). Yes. A connector 109 for connecting an external device is also connected to the serial communication bus 30, and the adjustment tool 10 is connected to the connector 109.

  The adjustment tool 10 constitutes a main part of the program loading support system of the present invention. FIG. 1C is a block diagram showing an electrical configuration of the adjustment tool 10. The adjustment tool 10 is mainly a microcomputer in which a CPU 113, a RAM 114, a ROM 115 (consisting of a non-volatile memory such as a flash memory), and an input / output unit 112 are connected via an internal bus. A keyboard 116 and a monitor 117 including a liquid crystal panel are connected to the input / output unit 112. The ROM 115 includes a C language compiler 121, a preprocessor 122, an analysis firmware 123 for analyzing the allocation area size of the listener registration list 201 on the RAM 2A, and the allocation area size of the execution program described above in the listener registration list 201. Is stored in a library form. The template program 123 and the auxiliary list 124 used in various vehicle types are stored. In addition, the RAM 114 includes a work area 131 of the analysis firmware 123, a header file storage area 132 for storing a header file in which the analysis result is described, a work area 133 of the preprocessor 122, and a compilation area 134. ing. When the operator appropriately inputs a command from the keyboard 116 according to the instruction content displayed on the monitor 41, the adjustment tool 10 analyzes the content of the auxiliary list of the target vehicle model by the analysis firmware 123 and assigns the listener registration list 201. The allocation area size process for determining the area size, the preprocessor 122 complementing the allocation area size with the template program (before compilation) to make the installation target program, the installation target program compiled into machine language, and the ECU 40 The process of transferring to the ROM 2B is sequentially performed.

Next, the execution program 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. 4A as a listener that receives an event notification each time an event notification request 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. 4A 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. That is, in the event processing object 103C, as shown in FIG. 4A, a listener corresponding to the event issued by the event management object 101C is prepared from the listener registration list 201 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, in order to be able to smoothly notify the corresponding listener of events, as shown in FIG. 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. 4A 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). As shown in FIG. 4B, when the event processing object 103C receives the event issuance request (T51), the listener registered in the listener registration list 201 makes one of the notification destination candidate objects 102J and 102K on the auxiliary list 203. , 102L, whether or not it is a regular listener is determined (T52), and only when it is a regular listener, notification of an event issued to the listener is executed (T53, T54). 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, the process of mounting the execution program on the vehicle side using the adjustment tool 10 will be described. The adjustment tool 10 is connected to the serial communication bus 30 on the vehicle side shown in FIG. Next, the specific information of the vehicle to be mounted with the execution program is input from the keyboard 116 of the adjustment tool 10 in FIG. 1C. Thereby, the auxiliary list corresponding to the vehicle type is specified on the ROM 115.

  Subsequently, the analysis firmware 123 starts up, and the allocation area size on the RAM of the listener registration list is determined based on the data size of the specified auxiliary list. Specifically, as shown in FIG. 1D, by analyzing the source code on the auxiliary list 203 in a non-compiled state (using the analysis work area 131 in FIG. 1C), the event listener specific information is shown. Extract data (Object 1, Object 2, ...). Then, the number of bytes after compilation of the extracted source code (that is, the memory occupation size of the auxiliary list) is calculated, and the calculated value is assigned to the allocation area size on the RAM of the listener registration list 201 (constant name: Rom Table Size). Determine as.

  The determined allocation area size is written in the header file 221 as a definition value of the constant Rom Table Size and stored in the header file storage area 132 of FIG. 1C. Subsequently, the preprocessor 122 starts up and opens the source code of the template program 123 (using the preprocessor work area 133). This template program 123 is common among vehicle types, and the allocation area size (Rom Table Size) on the RAM of the listener registration list 201 is described in a form in which no constant is defined. The preprocessor 122 reads the definition value of the constant Rom Table Size from the header file 221 and writes it in the undefined constant of the template program 123 to complement it.

  By complementing the definition value of the allocation area size, the template program 123 becomes an execution program for the corresponding vehicle type. Next, the compiler 121 is started up, and the execution program is compiled into a machine language using the compilation area 134. The compiled execution program is written into the flash ROM 2B of the target ECU 40 via the serial communication bus of FIG. 1B, and the actual vehicle mounting process is completed.

  Hereinafter, examples in which the present invention is 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 detection information from the intrusion detection device 42, activates an alarm, and executes security processing such as in-vehicle image capturing by a surveillance camera by microcomputer control. The security 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 block diagram which shows an example of the microcomputer hardware structure of a control main body. The block diagram which shows an example of a structure of an adjustment tool. The operation explanatory view of the program loading support system of the present invention. 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. The flowchart which shows the usage method of an auxiliary | assistant list. 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)
10 Adjustment tool (Program installation support system)
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 115 ROM (auxiliary list storage means)
121 Compiler (on-board program compilation means)
122 Preprocessor (allocation area size setting means, undefined constant rewriting means)
123 Analysis firmware (assignment area size determination means)
201 Listener registration list 202 Notification execution list 203 Auxiliary list

Claims (13)

A control entity configured to include a microcomputer having a CPU, a ROM, and a RAM, and to control the operation of an in-vehicle electronic device by executing the object-oriented program stored in the ROM using the RAM as a work area. A vehicle control system comprising:
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 in which an area is secured on the RAM, and the listener registration list An event processing object for notifying the issued event only to listeners registered in
And in the ROM, 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,
An object-oriented vehicle control system, wherein an area size on the RAM allocated to the listener registration list is set to a value corresponding to an occupied size of the auxiliary list in the ROM.   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 claim 1.   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 or 2, wherein notification timing of the event is determined based on timing and notification is made to a corresponding listener on the listener registration list.   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 any one of claims 1 to 3.   5. The object-oriented vehicle according to claim 4, 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. 6. The object-oriented vehicle control system according to claim 4, wherein the object-oriented vehicle control system is one that is sequentially copied to a list.   5. 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 any one of claims 6 to 6.   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. The object-oriented vehicle control system according to any one of claims 4 to 6, wherein the object-oriented vehicle control system is kept on the list.   5. 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 7. The object-oriented vehicle control system according to any one of Items6. A system for supporting the mounting of the object-oriented program for realizing the function of the object-oriented vehicle control system according to any one of claims 1 to 9 on the vehicle,
Auxiliary list storage means for storing the auxiliary list prepared individually for each vehicle to be mounted;
Allocation area size determining means for specifying the auxiliary list of vehicles to be mounted on the auxiliary list storage means and determining an allocation area size on the RAM of the listener registration list based on the data size of the auxiliary list; ,
An allocation area size setting means for setting the determined allocation area size in the RAM of the vehicle as a program mounting destination;
A program loading support system characterized by comprising: The allocation area size setting means includes:
A template program storage means for storing a template program in which the allocation area size on the RAM of the listener registration list of the program to be installed is undetermined;
An allocation area size complementing means that complements the allocation area size determined by the allocation area size determination means to the template program to be an installation target program;
Mounting target program transfer means for transferring the mounting target program to the vehicle;
The program mounting support system according to claim 10, comprising: In the template program storage means, the template program is described by a compiled language in a form including the allocation area size as an undefined constant,
The allocation area size complementing means includes: an undefined constant rewriting means for rewriting the undefined constant indicating the allocation area size of the template program with the determined allocation area size;
Mounting target program compiling means for compiling the rewritten template program as the mounting target program;
12. The program loading support system according to claim 11, wherein the loading target program transfer means transfers the compiled mounting target program to the vehicle side.   The allocation area size determination means calculates the memory occupation size of the auxiliary list after compilation by analyzing the source code of the auxiliary list in the non-compiled state stored in the auxiliary list storage means, and the calculated value 13. The program loading support system according to claim 12, wherein an allocation area size on the RAM of the listener registration list is determined based on the program.

Images