Abstract:
An apparatus is provided for managing communication among a plurality of process means respectively operating on given control programs realizing functions necessary for a vehicle. The plural process means includes a first process means issuing requesting messages for requesting a function and a second process means receiving the requesting message, performing a process requested by each requesting massage, and sending back a response indicating results of the process to the first process means. In the apparatus, storage means stores therein, of the requesting massages issued, only response-waiting messages issued by the first process means and received by the second process means. A measuring component measures an elapse of time from a time when the request stored in the storage is received by the second process means. A determining component determines whether or not the elapse of time measured by the measuring component reaches a preset value.

Description:
CROSS REFERENCES TO RELATED APPLICATION 
       [0001]    The present application relates to and incorporates by reference Japanese Patent application No. 2006-208444 filed on Jul. 31, 2006. 
       BACKGROUND OF THE INVENTION 
       [0002]    1. Field of the Invention 
         [0003]    The present invention relates to a distributed type of on-vehicle control system in which a plurality of electronic control programs communicate with each other on massages and responses transmitted and sent thereamong, and in particular, to an apparatus for administrating the massages and responses transmitted and sent among the plurality of control programs. 
         [0004]    2. Description of the Related Art 
         [0005]    Recently many vehicles are full of electronic devices, which require a control system to control such electronic devices. One type of such control systems is a distributed type of control system with a plurality of application components (hereinafter abbreviated as “APs”) assigned to each function necessary for driving a vehicle. 
         [0006]    Specifically, “AP” is a control program (also called “application program”) to achieve an objective function, and, in detail, is software consisting of program codes composing a control program and data referred while the control program is executed. In the present specification, for the sake of convenience, an expression whose subject is a program, such as “AP does . . . ,” is used in some occasions. Such an expression means the performance of functional means achieved by the CPU&#39;s execution, or more simply, by contents of the function of the program. 
         [0007]    In this kind of control system for vehicles (on-vehicle control system), a plurality of APs work together using messages communicated among the application components, whereby each predetermined function for driving a vehicle is achieved. For example, when some AP sends a requesting message to request another AP to carry out a certain process, the AP which receives the requesting message carries out a corresponding process to the requesting message and sends back the processing result. 
         [0008]    In terms of a hardware configuration, each AP is mounted in a separate electronic control unit (ECU), the plurality of ECUs communicate each other via a network build in the vehicle. This is, for example, set forth in Japanese Patent Laid-open (unexamined) No. 2001-270399. As another type, respective APs are mounted in one ECU, in which messages and correspondences are exchanged in the ECU. 
         [0009]    In the known on-vehicle control systems one of which is disclosed in the above reference document, it is preferred that the systems are able to carry out a process, called “deadline monitor.” This process is prepared for monitoring whether or not a process requested by a massage issued from one AP has been completed within a preset period of time. However, in the known on-vehicle control systems, an amount of processing load to perform the deadline monitor is forced to rise. 
         [0010]    Simply, the reason is that, since the response-waiting message is searched among all request messages by checking the message status of each of all request messages recorded in the message information administration table, some process is executed to messages which are not issued from an AP, thus not waiting for responses. This reason will be exemplified later in detail together with the description of the preferred embodiment. 
       SUMMARY OF THE INVENTION 
       [0011]    The present invention has been completed with the above problem in mind and has an object to reduce processing load for the deadline monitor process. 
         [0012]    In order to achieve the object, as one aspect, the present invention provides a communication administrating apparatus, which is used for an on-vehicle control system. In the on-vehicle control system, a plurality of process means which execute processes in cooperation with each other in order to achieve predetermined functions of the vehicle while each process means operates according to each control program. The process means are means functionally achieved by a CPU(s) executing control programs, and are substantially composed of the control programs. Each process means may be achieved by a different CPU respectively, or may be achieved by a single CPU. 
         [0013]    As one aspect of-the present invention, there is an apparatus for managing communication among a plurality of process means respectively operating on given control programs realizing functions necessary for a vehicle, the plurality of process means including a first process means issuing requesting messages for requesting a function and a second process means receiving the requesting message issued by the first process means, performing a process requested by each of the requesting massages, and sending back a response indicating results of the process to the first process means. 
         [0014]    The managing apparatus comprises storage means, a measuring component, and a determining component. Of these, the storage means stores therein, of the requesting massages issued, only response-waiting messages issued by the first process means and received by the second process means, wherein the response-waiting messages stored in the storage require that the second process means perform the process requested by the response-waiting massages and send back responses to the first process means, but the responses are not sent back from the second process means to the first process means yet. 
         [0015]    The measuring component measures an elapse of time from a time when the request stored in the storage is received by the second process means. And the determining component determines whether or not the elapse of time measured by the measuring component reaches a preset value. These measuring and determining processes correspond to part of the deadline monitor processing, where the deadline means the longest elapse of time equivalent to the preset value. 
         [0016]    According to the administrating apparatus, the measuring and determining components execute processes (measuring process and deciding process) only to response-waiting message which is actually accepted and waiting completion of the process, whereby a processing load for the deadline monitor process can be reduced. Consequently, even if the measuring and determining components are configured to be achieved by CPU(s) also achieving another process means, hindrances to processes carried out by other process means can be avoided. 
         [0017]    Preferably, in the administrating apparatus, the storage means is configured to store information indicative of a sequence of the response-waiting messages stored in the storage means; the measuring component is configured to measure, in the sequence, the elapse of time for each of the response-waiting massages stored in the storage means; and the determining component is configured to determine, in the sequence, whether or not the elapse of time measured for each of the response-waiting messages stored in the storage means reaches the preset value. 
         [0018]    According to this configuration, the sequence of the response-waiting message which is an object being processed of the measuring and determining components (i.e., process sequence) can be arbitrarily set. 
         [0019]    It is preferred that the information indicative of the sequence shows an order in which the second process means receives the response-waiting messages from the first process means. 
         [0020]    Accordingly, the renewal and memorization of sequence information can be executed easily. This is because newly accepted request messages can be simply set at the end of the sequence. 
         [0021]    The longer the elapsed time since a response-waiting message, which is the request message outputted at an early stage, is outputted, the earlier in the sequence on which the process of the deadline monitor (i.e., measuring process and deciding process) is executed to the response-waiting message. Therefore, if a preset value used in the deciding process is the same among all request messages, the higher the possibility that a response-waiting message exceeds deadline, the earlier in the sequence on which the process of the deadline monitor is executed to the response-waiting message. Thus the occurrence of the deadline excess is detected at an early stage. 
         [0022]    In the meantime, it is preferred that the preset value is defined for every type of the requesting massages and the information indicative of the sequence is information indicative of a sequence of the response-waiting messages each having the elapse of time which is closer to the preset value. 
         [0023]    Accordingly, even if the preset value is stipulated per kind of the response-waiting message, the higher the possibility that a response-waiting message exceeds deadline, the earlier in the sequence on which the process of the deadline monitor is executed to the response-waiting message. Thus the occurrence of the deadline excess is detected at an early stage. 
         [0024]    In the above message administrating apparatus, it is preferred that the storage means is configured to store the information indicative of the sequence in a data structure with a two-way list. In the two-way list data structure, each element of the list has not only a pointer to an element just behind, but also a pointer to an element just ahead. 
         [0025]    According to the two-way list data structure, processes to add and to delete an element or to shuffle the sequence becomes easier. A process becomes easier to delete a response-waiting message from the response-waiting message memory means when a response is obtained corresponding to the response-waiting message, and to add and memorize a request message as a response-waiting message when a new request message is accepted. For example, there is a case where a response corresponding to the response-waiting message which is neither at the top nor the end in the sequence is obtained, and the response-waiting message is deleted from the response-waiting message memory means. In this case, from pointers of an element corresponding to the response-waiting message which is an object being deleted, elements just ahead and just behind of the element may be identified to change the pointers, which are just ahead and just behind the identified elements. 
         [0026]    Preferably, the data structure with the two-way list includes an area (hereinafter called “number area”) in which data indicative of the number of response-waiting massages stored in the storage means is recorded, an area in which an index identifying a response-waiting massage standing at a forefront of the sequence is recorded, and first and second pointer areas which are set respectively for every identifier of each requesting massage. In the first pointer area corresponding to the index of each response-waiting massage, an index of a response-waiting massage preceding the corresponding response-waiting massage by one in the sequence is recorded, while, in the second pointer area corresponding to the index of each response-waiting massage, an index of a response-waiting massage following the corresponding response-waiting massage by one in the sequence is recorded. 
         [0027]    According to the data structure, the measuring and determining components can decide whether the number of response-waiting messages is 0 or not from the information recorded in the number area. In a case where the number of response-waiting messages is 0, the measuring and determining components need not do anything, whereby wasted processing energy can be efficiently reduced. 
         [0028]    As another aspect of the present invention, there is an on-vehicle control system equipped with the above described communication administrating apparatus. According to the on-vehicle control system, the above described effects of the communication administrating apparatus are accomplished. 
         [0029]    The on-vehicle control system may be configured as follows. That is, the first process means is provided by a first electronic control unit mounted in the vehicle and the second process means is provided by a second electronic control unit mounted in the vehicle, the first electronic control unit being different from the second electronic control unit, and the communication managing apparatus is arranged in the first electronic control unit. 
         [0030]    The first and second electronic control units are communicably connected with each other via a network built in the vehicle such that the requesting messages and the responses are transmitted and received via the network. 
         [0031]    According to the control system for vehicles, the above described effects of the communication administrating apparatus are accomplished. 
         [0032]    The message administration section may be set both in a requesting-side apparatus (i.e., the first electronic control unit) and in a requested-side apparatus (i.e., the second electronic control unit). In this case, the request message output by the requesting-side process means in the requesting-side apparatus is conveyed from the communication administrating apparatus of the requesting-side apparatus via inside vehicle network to the administrating apparatus of the requested-side apparatus then to the requested-side process means of the requested-side apparatus. Similarly, the response output by the requested process means of s the requested-side apparatus is conveyed from the administrating apparatus of the requested-side apparatus via inside vehicle network to the administrating apparatus of the requesting-side apparatus then to the requesting side process means of the requesting-side apparatus. 
     
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0033]    In the accompanying drawings: 
           [0034]      FIG. 1  is a schematic diagram showing the configuration of a remote control system as an example of a control system for a vehicle of prior art; 
           [0035]      FIG. 2  shows contents of the message information administration table of prior art; 
           [0036]      FIG. 3  is a flowchart outlining the deadline monitor process containing problem which the present invention is to solve; 
           [0037]      FIG. 4A  is a schematic diagram showing the configuration of the on-vehicle control system of the embodiment; 
           [0038]      FIG. 4B  is a schematic diagram showing the configuration of the message information administration section of the embodiment; 
           [0039]      FIGS. 5A and 5B  Illustrate a message process sequence regulation section; 
           [0040]      FIG. 6  illustrates transition of the message status; 
           [0041]      FIG. 7  illustrates executing timing of each task which is a component of the message information administration section; 
           [0042]      FIG. 8  is a flowchart outlining the message information transmission process; 
           [0043]      FIG. 9  is a flowchart outlining the message information reception process; and 
           [0044]      FIG. 10  is a flowchart outlining the deadline monitor process. 
       
    
    
     DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 
       [0045]    An embodiment of an on-vehicle distributed control system with a plurality of ECUs, which is according to the present invention, will now be described with reference to the accompanying drawings. This on-vehicle distributed control system functionally includes a message administrating apparatus corresponding to a communication administrating apparatus according to the present invention. 
         [0046]    The following description is given in a two-stage manner, which is composed of the first description for a system corresponding to a conventional art and the second description for a system according to the present embodiment in which the present embodiment is reduced in practice. It is thus easier to understand a conventional system, the problem with the conventional system, and how the problem is solved by the system according to the present invention. 
       (i) Conventional System 
       [0047]    Now, Referring to  FIGS. 1-3 , one example of a conventional on-vehicle distributed control system comprising a plurality of ECUs will now be described. In this on-vehicle distributed control system, there is provided a massage administrating apparatus functionally embedded in the control system. 
         [0048]    The on-vehicle control system exemplified in  FIG.1  is a remote control system which enables a user of the vehicle to perform various actions such as locking doors from a remote place. 
         [0049]    The remote control system shown in  FIG. 1  comprises an external communication ECU  10  which communicates by wireless directly or via a base station with a user terminal, such as a mobile phone which the user takes along, in addition to a remote security ECU  11 , a checker ECU  12 , a driver&#39;s seat door ECU  13 , a passenger&#39;s seat door ECU  14 , a rear-right seat door ECU  15 , and a rear-left seat door ECU  16 . The checker ECU  12  performs a user authentication process. The driver&#39;s seat door ECU  13  controls lock/unlock and open/close actions of the window of a driver&#39;s seat door of the vehicle. The passenger&#39;s seat door ECU  14  controls lock/unlock and open/close actions of the window of a passenger&#39;s seat door of the vehicle, the rear-right seat door ECU  15  controls lock/unlock and open/close actions of the window of rear-right seat door of the vehicle, and the rear-left seat door ECU  16  controls lock/unlock and open/close actions of the window of a rear-left seat door of the vehicle. These ECUs  10 - 16  are communicably connected to each other via a communication line (not shown) serving as an in-vehicle network. 
         [0050]    In this remote control system, the user terminal sends a requesting message requesting a door lock, for example. Responsively, the requesting message is received by the remote security ECU  11  via the external communication ECU  10 . 
         [0051]    In the remote security ECU  11 , in order to confirm if the requesting message received from the external communication ECU  10  is sent from the user terminal of the normal user, an AP  1  mounted in the ECU  11  outputs a requesting message requesting processing for user authentication (hereinafter called “user authentication request”) to an AP  2  mounted in the checker ECU  12 , and the user authentication request is sent to the checker ECU  12 . 
         [0052]    When the checker ECU  12  receives the user authentication request, the AP  2  processes user authentication and outputs a response indicating a processed result (in other words, a response indicating whether authentication is OK or not, hereinafter called “authentication result response”). Then the authentication result response is sent from the checker ECU  12  to the remote security ECU  11 . 
         [0053]    The requesting message contains an identification code of the user terminal. This identification code may be contained in the user authentication request from the remote security ECU  11  to the checker ECU  12 . The AP  2  of the checker ECU  12  performs, as user authentication processing, a judgment whether the identification s code from the remote security ECU  11  is identified with the identification code previously stored in the checker ECU  12 . If it is identified, the AP  2  executes a process to decide that the checking is OK. 
         [0054]    In the remote security ECU  11 , the AP  1  judges the authentication result response from the checker ECU  12 . If the authentication result response indicates that the authentication is OK, the AP  1  outputs a request message requesting a door lock action (hereinafter called “door lock request”) to each of APs  3 - 6  mounted in door ECUs  13 - 16  respectively, whereat each door lock request is sent to each of corresponding door ECUs  13 - 16  from remote security ECU  11 . 
         [0055]    When each of the door ECUs  13 - 16  receives a door lock request addressed to its own ECU from the remote security ECU  11 , each of the APs  3 - 6  executes a door lock process to lock each door in response to the door lock request. After that, each of the APs  3 - 6  outputs a response indicating results of the door lock process (in other words, a response indicating that the door lock process has been completed; hereinafter this process is called “door lock completion response”), whereat the door lock completion response is sent from each of the door ECUs  13 - 16  to the remote security ECU  11 . 
         [0056]    In the remote security ECU  11 , in response to the door lock completion response, the AP  1  recognizes the lock of each door has been completed. Then the door lock completion response is sent from the remote security ECU  11  to the user terminal via the external communication ECU  10 . 
         [0057]    When, for example, a request message requesting a window close action is sent from the user terminal, the window of the each door is closed by each of the door ECUs  13 - 16 , with the same procedure done as described above. 
         [0058]    Each of the ECUs  11 - 16  is equipped with a message information administration section which controls exchanges of messages (request messages and responses) among the APs, and equipped with a transmission section and a reception section both for communicating with other ECUs. 
         [0059]    The message information administration section makes the transmission section of its own ECU send a request message and a response outputted by the AP of its own ECU to the destination, i.e., another ECU. 
         [0060]    For example, when the AP  1  outputs a request message (user authentication request), the message information administration section of the remote security ECU  11  accepts the request message and makes the transmission section of the ECU  11  send the request message to the ECU  12 . When the reception section of the ECU  11  receives a response to the request message from the AP  2  (authentication result response), the message information administration section of the remote security ECU  11  acquires the response and supplies it to the AP  1 . 
         [0061]    The message information administration section will now be detailed. The message information administration section has a message Information administration table as shown in  FIG. 2 . 
         [0062]    In the message information administration table, with respect to each index which is an identifier of a plurality of request messages exchanged among the APs, a route of the request messages, a message status, a deadline counter and a deadline value are recorded. 
         [0063]    The index, the route, and the deadline value are statically defined information in advance. The route indicates that from which AP to which AP a pertinent request message is sent (i.e., it indicates a requesting AP which outputs a request message and a requested AP which responds to the request message). The deadline value is a value equivalent to the maximum time allowed to wait from when the request message is outputted to when the response is returned. For, example, in the message information administration table shown in  FIG. 2 , to the request message with index  1  (driver&#39;s seat door lock request), information that the requesting AP is the AP  1  and the requested AP is the AP  3  is recorded as the route, and as the deadline, a value of 1000 is recorded. 
         [0064]    On the other hand, the message status and the deadline counter are dynamically changed information. 
         [0065]    The message status is set up as “waiting request” as the initial status when a pertinent requesting message is outputted from APs. And during the period from when the message information administration section accepts the pertinent request message outputted from the requesting AP to when the message information administration section obtains corresponding response from the requested AP, the message status is set up as another status such as “requested” or “waiting response”. After then, when the message information administration section obtains a response from the requested AP and outputs it to the requesting AP, the message status is set back to “waiting”. 
         [0066]    The deadline counter measures the above period concerning the pertinent requesting message. Specifically, when the message status of the pertinent request message changes from “waiting request” to another status, the above deadline value determined concerning the request message is set up as the initial status of the deadline counter. Then, until the above period ends, the deadline counter is decremented by −1 at a certain time period. After that, when the deadline counter measures 0, it is decided that the deadline excesses (i.e., that the requested process requested by the request message has not been completed within the expected time period). 
         [0067]    Such renewal of message status in the message information administration table, setting up of the initial status, and the decrement of the deadline counter and decision of deadline excess are executed by the message information administration section, 
         [0068]    With reference to  FIG. 3 , a description will now be made about a deadline monitor process executed by the message information administration section in order to monitor whether the requested process requested by the request message has been completed within the expected time period or not (i.e., deadline monitor). 
         [0069]    In the deadline monitor process shown In  FIG. 3 , first at step S 110 , the top request message in the message information administration table (the request message with index  1  in the example in  FIG. 2 ) is set as an inquiry object. 
         [0070]    At step S 120 , the request message, which Is the inquiry object, is decided as to whether this is in acceptance or not. When this request message is in acceptance, it means that the processing is within the above period. In other words, it means that the message status in the message information administration table is “requested” or “waiting response”. 
         [0071]    If the request message, which is the inquiry object, is not in acceptance (S 120 : NO), the process moves to step S 160  without change. But if the request message is in acceptance (S 120 : YES), the deadline counter corresponding to the request message of inquiry object is decremented at next step S 130 . The request message is outputted from the AP and accepted by the message information administration section, but its response has not been obtained yet. Hereinafter, the massage in this situation may simply be called “response-waiting message.” In the deadline counter corresponding to the request message which is the inquiry object, as described before, the deadline value determined concerning the request message is set up as the initial status of the deadline counter when the request message is outputted from the requesting AP and obtained by the message information administration section. At this step S 130 , the decrement of the deadline counter is made. 
         [0072]    Then at next step S 140 , a decision is made whether the decremented value of deadline counter is 0 or not. If not 0 (S 140 : NO), the process moves to step S 160  without change. If the value of deadline counter becomes 0 (S 140 : YES), the process moves to step S 150  and the deadline excess process is executed, then the process moves to step S 160 . Concerning the request message which is the inquiry object, the deadline excess process sets up the message status in the message information administration table concerning the request message as a “deadline excess,” for example. And concurrently, the deadline excess process notices the error to the requesting AP which outputs the request message, whereat the requesting AP no longer waits a response to the request message, whereby a further standstill of the process can be prevented. 
         [0073]    At step S 160 , a decision is made whether an inquiry to all request messages recorded in the message information administration table has been completed or not. If not completed (S 160 : NO), the current request message is set up as the next request message in the message information administration table at the next step S 170 , then the process returns to step S 120 . 
         [0074]    At the above step S 160 , if the inquiry to all request messages is completed (S 160 : YES), this deadline monitor process ends without change. 
         [0075]    In other words, in the deadline monitor process shown in  FIG. 3  by deciding whether each of all request messages recorded in the message information administration table (i.e., all request messages which the AP can output) is in acceptance or not based on its message status, the response-waiting message is searched (S 110 , S 120 , S 160 , S 170 ). And, as concerning the searched response-waiting massage, the time measuring process to decrement the deadline counter (S 130 ) and the deciding process whether the value of the deadline counter is 0 or not (S 140 ) are executed. 
         [0076]    In the example in  FIGS. 1-3 , the message information administration section is actually configured by software. A CPU (central processing unit) is provided to execute given programs for achieving the functions of the above message information administration section. 
         [0077]    By the way, as described before, in the above described on-vehicle control system, the message information administration section executes the deadline monitor process shown in  FIG. 3 . Thus there is a problem that processing load for the deadline monitor process is increased. 
         [0078]    Specifically, since the response-waiting message is searched among all request messages by checking the message status of each of all request messages recorded in the message information administration table, some processes are executed to the messages which are not in acceptance. For example, in the example shown in  FIG. 2 , the message status of the request messages with indexes  3  and  5  is a “waiting request”, therefore, these request massages are not essentially objects for the deadline monitor, but they are involved in the objects to be processed. Especially, in a case where the message status of all request messages is a “waiting request” (i.e., there is no response-waiting message), all the processes for the search come to nothing. As the number of messages exchanged among the APs increases, the processing load for the deadline monitor increases. This situation may interfere with control processes that require real-time performance. 
       (ii) System According to the Present Embodiment 
       [0079]    As a preferred embodiment of the present, the following new configuration, which is combined with the foregoing known configuration, is provided, so that the combined configurations create a new on-vehicle control system according to the present invention. In this new control system, a communication administrating apparatus according to the present invention is functionally formed as a message administrating apparatus. 
         [0080]    Compared with the known on-vehicle control system described with  FIGS. 1-3 , the on-vehicle control system of this embodiment differs only in the message information administration section comprised in the ECU. Thus, hereinafter, the message information administration section will be mainly described. For the sake of the simplified explanation, while an attention is focused on the remote security ECU  11  and the driver&#39;s seat door ECU  13 , a description will be made assuming that the ECU  11  is the requesting ECU which outputs a request message, and the ECU  13  is the requested ECU which receives the request message and responds thereto. 
         [0081]    First, as shown in  FIG.4A , the ECU  11  comprises the AP  1 , the message information administration section  21 , the transmission section T 1 , and the reception section R 1 , and the ECU  13  comprises the AP  3 , the message information administration section  23 , the transmission section T 3 , and the reception section R 3  in the on-vehicle control system of this embodiment. The ECU  11  and the ECU  13  are connected with lines with each other whereby they can communicate. 
         [0082]    The message information administration sections  21 ,  23  mounted in the ECUs  11 ,  13  respectively are actually configured by software as well as the AP  1  and AP  3  as the processing means, CPUs (not shown) mounted in the ECUs  11 ,  13  execute programs for achieving the function of the above message information administration sections  21 ,  23 . Since the configuration and the functions of the message information administration sections  21 ,  23  mounted in the ECUs  11 ,  13  are essentially the same as those described, an explanation is made hereinafter by taking the message information administration section  21  as an example. 
         [0083]    As shown in  FIG. 4B , the message information administration section  21  comprises a message process sequence regulation section  32  in addition to the message information administration table previously described with  FIG. 2 , which is marked by “31” in this embodiment. 
         [0084]    The message process sequence regulation section  32  is a list that the message information administration section  21  uses to memorize an accepting request message (response-waiting message) and a sequence of a process (process sequence) to the response-waiting message. Specifically, its data Is structured in a two-way list form as shown in  FIGS. 5A and 5B . 
         [0085]    Hereinafter, the request message with an index number N (integer) is notated as the request message N. In  FIGS. 4B and 5A , for example, the request message  2  (rear-left seat door lock request) and the request message  4  (passenger&#39;s seat door lock request) outputted from the AP  1  of the ECU  11  have been already memorized in the message process sequence regulation section  32  as the response-waiting message. And in  FIGS. 4B and 5B , the request message  1  (driver&#39;s seat door lock request) is newly outputted from the AP  1 , the request message  1  is to be memorized in the message process sequence regulation section  32  as the response-waiting message. In this embodiment, in the message process sequence regulation section  32 , as a process sequence of the response-waiting message, the sequence of the message outputted from an AP and accepted by the message information administration section  21  (i.e., the sequence of the acceptance of the message) is memorized. 
         [0086]    As shown in  FIGS. 5A and 5B , the message process sequence regulation section  32  comprises an “MSG #” area where the numbers of the messages presently in acceptance are memorized, a “TOP” area where the index of a request message which is at the top of the process sequence, and both “AHEAD” and “BEHIND” areas which are allocated to each index of the request message. In the “AHEAD” area corresponding to the index of the response-waiting message, an index of the response-waiting message “one number” ahead of the response-waiting message in the process sequence is memorized. And in the “BEHIND” area corresponding to the index of the response-waiting message, an index of the response-waiting message “one number” behind of the response-waiting message in the process sequence is memorized. In this embodiment, the “AHEAD” area corresponds to the first pointer area, and the “BEHIND” area corresponds to the second pointer area. And those areas are for memorizing sequence information indicating the process sequence. 
         [0087]    Therefore, in the case that, for example, while the request message  2  and the request message  4  are memorized as the response-waiting message, sequences “2 to 4” are memorized as their process sequences in the message process sequence regulation section  32 , the record status is as shown in  FIG. 5A . In the “AHEAD” area corresponding to the top requesting response-waiting message of the sequence (the request message  2  in  FIG. 5A ), “0” is recorded as the default value. In the “BEHIND” area corresponding to the last requesting response-waiting message of the sequence (the request message  4  in  FIG. 5A ), “100” is recorded as the default value. 
         [0088]    In the status shown in  FIG. 5A , when the request message  1  is newly outputted, the record status of the message process sequence regulation section  32  changes to as shown in  FIG. 5B . In other words, while the value recorded in the “MSG #” area changes from “2” to “3”, the value recorded in the “BEHIND” area corresponding to the index  4  changes from “100” to “1”, while, in the “AHEAD” area and the “BEHIND” area corresponding to the index  1 , “4” and “100” are newly recorded respectively. 
         [0089]    The flow of the message communication between the ECU  11  and the ECU  13 , and the transition of the message status will be described with referring to  FIGS. 4A and 6 , hereupon the numbers in &lt; &gt; in  FIGS. 4A and 6  correspond to &lt;1&gt; to &lt;10&gt; in the following explanation. The following explanation will be made with an example that the request message  2  and the request message  4  outputted from the AP  1  have been already memorized in the message process sequence regulation section  32  as the response-waiting message, and the request message  1  is newly outputted from the AP  1 , then a corresponding process to the request message  1  (i.e., driver&#39;s seat door lock process) is executed before each of corresponding processes to the request messages  2  and  4 . 
         [0090]    &lt;1&gt; First of all, in the ECU  11 , when the AP  1  requests to lock a driver&#39;s seat door, the AP  1  outputs the request message  1 , which requests to lock a driver&#39;s seat door, to the message information administration section  21 . 
         [0091]    Then, when accepting the request message  1 , the message information administration section  21  adds and memorizes the request message  1  as the response-waiting message in the message process sequence regulation section  32  of the message information administration section  21 . In addition, the message information administration section  21  adds and memorizes the process sequence of the request message  1 . Specifically, the message information administration section  21  changes the record status of the message process sequence regulation section  32  from as shown in  FIG.5A  to in  FIG. 5B . 
         [0092]    The message information administration section  21  renews its own message information administration table  31 . Specifically, the message status of the request message  1  accepted this time is changed from “waiting request” to “requested”. 
         [0093]    &lt;2&gt; In order to send the request message  1  to the ECU  13  which mounts the AP 3  therein, the message information administration section  21  then outputs the request message  1  accepted this time and the destination information indicating the destination AP (the AP 3 , in this example) of the request message  1  to the transmission section T 1 . Since an index is added to the request message outputted from the AP, the message information administration section  21  identifies the destination of the request message by reading out a route corresponding to the index of the request message from its own message information administration table  31 . 
         [0094]    Further, the message information administration section  21  renews the message information administration table  31 . Specifically, the message status of the request message  1  is changed from “requested” to “waiting response” since the delivery process of the request message  1  has been completed. 
         [0095]    &lt;3&gt; Then the transmission section T 1  sends the request message outputted from the message information administration section  21  to the ECU  13  via the communication line L. Since the transmission section T 1  comprises an information table indicating which AP is mounted in which ECU for example, the transmission section T 1  identifies the destination ECU by applying the destination information from the message information administration section  21  to the information table. 
         [0096]    &lt;4&gt; On the other hand, the reception section R 3  of the ECU  13  receives the request message from the ECU  11  (the AP  1 ) and sends it to the message information administration section  23 . 
         [0097]    Also in the ECU  13 , when accepting the request message  1 , the message information administration section  23  adds and memorizes the request message  1  as the response-waiting message in its own message process sequence regulation section  32 . In addition, the message information administration section  23  adds and memorizes the process sequence of the request message  1 . If the request message  1  is the only memorized request response-waiting message, for example, in the message process sequence regulation section  32 , the value recorded in the “MSG #” area is changed from “0” to “1”, the value recorded in “TOP” area is changed from “0” to “1”, and in each of the “AHEAD” and “BEHIND” areas corresponding to the index  1 , “0” and “100” are recorded respectively. 
         [0098]    Further, the message information administration section  23  renews its own message information administration table  31 . Specifically, the message status of the request message  1  accepted this time is changed from “waiting request” to “requested”. 
         [0099]    &lt;5&gt; Then, while outputting the request message  1  accepted this time to the AP  3 , the message information administration section  23  renews its own message information administration table  31 . Specifically since the delivery of the request message  1  to the AP  3  has been completed, the message status of the request message  1  accepted this time is changed from “requested” to “waiting response”. 
         [0100]    &lt;6&gt; When accepting the request message  1 , the AP  3  executes driver&#39;s seat door lock process corresponding to the request message, and after the completion of the process, the AP  3  outputs a driver&#39;s seat door lock completion response indicating a driver&#39;s seat door lock process has been completed to the message information administration section  23 . 
         [0101]    The message information administration section  23  then obtains the driver&#39;s seat door lock completion response and deletes the request message  1  from its own message process sequence regulation section  32 . If the request message  1  is the only memorized request response-waiting message, for example, in the message process sequence regulation section  32 , the value recorded in the “MSG #” area is changed from “1” to “0”, the value recorded in the “TOP” area is changed from “1” to “0”, and in each of the “AHEAD” and “BEHIND” areas corresponding to the index  1 , the recorded number is deleted. 
         [0102]    The message information administration section  23  then renews its own message information administration table  31 . Specifically, the message status of the request message  1  whose response has been obtained is changed from “waiting response” to “responded”. 
         [0103]    &lt;7&gt; Then, in order to send the driver&#39;s seat door lock response obtained from the AP  3  to the ECU  11  which mounts the AP  1  therein, the message information administration section  23  outputs the driver&#39;s seat door lock completion response and the destination information indicating the destination AP (the AP 1 , in this example) of the driver&#39;s seat door lock completion response to the transmission section T 3 . Since the index is added to the response outputted from the AP, the message information administration section  23  identifies the destination of the response (i.e., the origin of the request message corresponding to the response) by reading out a route corresponding to the index of the response from its own message information administration table  31 . 
         [0104]    Further, the message information administration section  23  renews its own message information administration table  31 . Specifically since the delivery of the response corresponding to the request message  1  has been completed, the message status of the request message  1  is changed from “responded” to “waiting request” as the initial status. 
         [0105]    &lt;8&gt; The transmission section T 3  then sends the driver&#39;s seat door lock completion response outputted from the message information administration section  23  to the ECU  11  via the communication line L. Since the transmission section T 3  comprises an information table indicating which AP is mounted in which ECU for example, the transmission section T 3  identifies the destination ECU by applying the destination information from the message information administration section  23  to the information table. 
         [0106]    &lt;9&gt; The reception section R 1  of the ECU  11  receives the driver&#39;s seat door lock completion response from the ECU  13  (the AP  3 ) and sends it to the message information administration section  21 . 
         [0107]    Then, the message information administration section  21  obtains the driver&#39;s seat door lock completion response from the reception section R 1  and deletes the request message  1  from its own message process sequence regulation section  32 . Specifically, the record status of the message process sequence regulation section  32  is rewritten from as shown in  FIG. 5B  to in  FIG. 5A . 
         [0108]    Furthermore, the message information administration section  21  renews its own message information administration table  31 . Specifically, the message status of the request message  1  whose response is obtained from the AP  3  is changed from “waiting response” to “responded”. 
         [0109]    &lt;10&gt; Then, while outputting the driver&#39;s seat door lock completion response from the AP  3  to the AP  1 , the message information administration section  21  renews its own message information administration table  31 . Specifically since the delivery process of the response corresponding to the request message  1  has been completed, the message status of the request message  1  is changed from “responded” to “waiting request” as the initial status. And the AP  1  recognizes from the driver&#39;s seat door lock completion response that the driver&#39;s seat door lock process by the AP  3  of the ECU  13  has been completed. 
         [0110]    Each process executed by the message information administration section  21  of the ECU  11  will now be described referring to  FIGS. 7 to 10 . 
         [0111]    First,  FIG. 7  illustrates executing timing of each task which is a component of the message information administration section  21 . 
         [0112]    The message information administration section  21  comprises a task of message information transmission process, a task of message information reception process, and a task of deadline monitor process. The task of message information transmission process is raised at a given time period T 1 . The task of message information reception process is raised when information from the other ECU is received by the reception section R 1 . The task of deadline monitor process is for executing the deadline monitor concerning a request message and raised at a given time period T 2  shorter than the time period T 1 . 
         [0113]    As shown in  FIG. 8 , in the message information transmission process, first at step S 210 , a request message outputted by the AP  1  is accepted. The request message outputted by the AP  1  is memorized in the predetermined memory area of the memory mounted in the ECU  11 . At step S 210 , the request message is accepted by reading the request message outputted by the AP  1  from the memory area. 
         [0114]    Next, at step S 220 , as described in &lt;1&gt;, while the request message accepted this time is add to and memorized in the message process sequence regulation section  32  as the response-waiting message, the process sequence of the request message is added and memorized. Furthermore, at step S 220 , concerning the request message accepted this time, a deadline value recorded in the message information administration table  31  is set as the initial value of the deadline counter. For example, in a case where the request message  1  is accepted, “100” which is the deadline value of the request message is set as the initial value to the deadline counter of the request message  1  (refer to  FIG. 4B ). 
         [0115]    Then at succeeding step S 230 , as described in &lt;1&gt; and &lt;2&gt;, while the message status of the request message undergoes a transition from “waiting request”, via “requested”, to “waiting response” by rotation, by renewing the message information administration table  31 , the transmission process of the request message accepted this time is executed. After this, the message information transmission process is ended. 
         [0116]    As shown in  FIG. 9 , in the message information reception process, first at step S 310 , the response outputted by an AP of another ECU (process result) is obtained from the reception section R 1 . 
         [0117]    Second at step S 320 , as described in &lt;9&gt;, the request message corresponding to the response obtained this time is deleted from the message process sequence regulation section  32 . 
         [0118]    Then at succeeding step S 330 , as described in &lt;9&gt; and &lt;10&gt;, while the message status of the request message undergoes a transition from “waiting response”, via “responded” to “waiting request” by rotation, by renewing the message information administration table  31 , the response obtained this time is outputted (noticed) to the AP  1 . Then the message information reception process is ended. 
         [0119]    Next, as shown in  FIG. 10 , in the deadline monitor process, first at step S 410 , it is decided whether a request response-waiting message is memorized in the message process sequence regulation section  32  with referring to the “MSG #” area in the message process sequence regulation section  32 . In other words, if the value in the “MSG #” is “0”, it is decided that no response-waiting message is memorized. 
         [0120]    In a case where it is decided that no response-waiting message is memorized (S 410 : NO), the deadline monitor process is ended without change. 
         [0121]    In a case where is decided that response-waiting messages are still memorized (S 410 : YES), the processing goes to step S 420 , where among response-waiting messages memorized with their process sequences in the message process sequence regulation section  32 , a top message of the process sequence is set as an object being processed. In other words, the request message whose index is recorded in the “TOP” area in the message process sequence regulation section  32  is set as an object being processed. 
         [0122]    Then at succeeding step S 430 , a deadline counter corresponding to the request message, which is the object being processed, is decremented in the message information administration table  31 . The value of the deadline counter corresponding to the request message is initialized at the deadline value corresponding to the request message when the request message is accepted by the message Information administration section  21  through the process at step S 220  shown in  FIG. 8 . 
         [0123]    At step S 440 , it is decided whether the value of the deadline counter which is decremented at above described step S 430  is 0 or is not. If not 0 (S 440 : NO), the process goes to step S 460  without change. If the value is 0 (S 440 : YES), the process goes to step S 450  where the deadline excess process is executed, then the process goes to step S 460 . The deadline excess process in the requesting ECU sets, as described before, the message status of the request message in the message information administration table  31  as a “deadline excess” (refer to  FIG. 6 ). In the deadline excess process, by noticing an error to the AP (the AP  1  in this example) outputting the request message, the AP is stopped to wait, any more, a response corresponding to the request message which has underwent the deadline excess. 
         [0124]    At step S 460 , it is decided whether the processes at steps S 430  and S 440  are completed or not to all the response-waiting messages memorized in the message process sequence regulation section  32 . If not completed (S 460 : NO), at succeeding step S 470 , among response-waiting messages memorized in the message process sequence regulation section  32 , the message whose process sequence is next to the present object being processed is set as a new object being processed. Then the process returns to step S 430 . 
         [0125]    For example, assuming that the request message  2 , the request message  4 , and the request message  1  are memorized with the process sequence from 2 via 4 to 1 in the message process sequence regulation section  32  as shown in  FIG. 5B , at step S 420 , the request message  2  whose index=2 is recorded in the “TOP” area in the message process sequence regulation section  32  is set as the first object being processed. Then at succeeding step S 470 , the request message  4  whose index=4 is recorded in the “BEHIND” area corresponding to the index=2 in the message process sequence regulation section  32  is set as the next object being processed. Furthermore, at next step S 470 , the request message  1  whose index=1 is recorded in the “BEHIND” area corresponding to the index=4 in the message process sequence regulation section  32  is set as the next object being processed. 
         [0126]    Then at above described step  5460 , if it is decided that the processes to all response-waiting messages have been completed (S 460 : YES), the deadline monitor process is ended without change. 
         [0127]    Meanwhile, in the requested ECU  13 , the message information administration section  23  executes the same process as shown in  FIGS. 8-10 . 
         [0128]    For example, in the ECU  13 , the message information administration section  23  executes message information transmission process as shown in  FIG. 8 , when a request message from other ECU is received by the reception section R 3 . In the message information transmission process, the message information administration section  23  accepts the request message received by the reception section R 3  at step S 210 . Then at succeeding step S 220  as described in &lt;4&gt;, the message information administration section  23  adds and memorizes the request message accepted this time as the response-waiting message in the message process sequence regulation section  32 , and in addition, the message information administration section  23  adds and memorizes the process sequence of the request message. Furthermore, the message information administration section  23  sets the value of the deadline counter corresponding to the request message accepted this time to the deadline value corresponding to the request message. Then at succeeding step S 230  as described in &lt;4&gt; and &lt;5&gt;, while making the message status undergo a transition, the message information administration section  23  outputs the request message accepted this time to the AP  3 . 
         [0129]    And in the ECU  13 , when a response to the request message is outputted, the message information administration section  23  executes the message information reception process as shown in  FIG. 9 . In the message information reception process, the message information administration section  23  obtains a response (process result) outputted by the AP  3  first at the step S 310 . Next at step S 320 , as described above &lt;6&gt;, the message information administration section  23  deletes the request message corresponding to the response obtained this time from the message process sequence regulation section  32 . At succeeding step S 330  as described in &lt;6&gt; and &lt;7&gt;, while making the message status undergo a transition, the message information administration section  23  executes a process to send the response obtained this time to the origin which sent the request message corresponding to the response. 
         [0130]    Further, in the ECU  13 , the message information administration section  23  executes the deadline monitor process as shown in  FIG. 10  at regular intervals. In the deadline excess process at step S 450  in the deadline monitor process in the ECU  13 , the message status of the request message, which is the object being processed, is only set as the “deadline excess” in the message information administration table. 
         [0131]    That is, while receiving the request message from the AP  1  within the ECU  11  and supplying the request message to the AP  3  via communication line L, the message information administration section  21  of the ECU  11  receives from the ECU  13  a response outputted by the AP  3  via the communication line L. Therefore, the message information administration section  21  executes the deadline monitor process during the targeted period from &lt;1&gt; to &lt;9&gt; as shown in  FIG. 4A . 
         [0132]    On the contrary, while receiving the request message outputted by the requesting AP  1  via the communication line L, and supplying the request message to the AP  3 , the message information administration section  23  of the ECU  13  receives a response within the ECU  13  and supplies the response to the AP  1  via the communication line L. Therefore, the message information administration section  23  executes the deadline monitor process during the targeted period from &lt;4&gt; to &lt;6&gt; as shown in  FIG. 4A . 
         [0133]    By the way, in the above embodiment, the ECU  11  is equivalent to the requesting-side apparatus of the present invention, the ECU  13  is equivalent to the requested-side apparatus. The AP  1  is equivalent to requesting-side process means, the AP  3  is equivalent to the requested-side process means, the message information administration sections  21 ,  23  are equivalent to the message administrating apparatus. And the message process sequence regulation section  32  is equivalent to response-waiting message memory means, the deadline monitor process is equivalent to the measuring and determining components. Furthermore, in the deadline monitor process as shown in  FIG. 10 , the process at step S 430  is equivalent to the measuring process, and the process at step S 440  is equivalent to the deciding process. 
         [0134]    In the on-vehicle control system of the above described embodiment, among the plurality of kinds of request messages (request messages recorded in the message information administration table  31 ), the message information administration sections  21 ,  23  memorize the request response-waiting messages in the message process sequence regulation section  32 . And only to the request response-waiting messages memorized in the message process sequence regulation section  32 , the deadline monitor process shown in  FIG. 10  is executed In a case where the request message is not memorized in the message process sequence regulation section  32 , the deadline monitor process is not substantially executed, whereby the process load for the deadline monitor process can be reduced. 
         [0135]    In other words, compared with the deadline monitor method which periodically searches for messages with the status of “requested” or “waiting response” among all messages statically recorded in the message information administration table  31 , the process and time for periodical search can be saved. 
         [0136]    Thus, according to the embodiment, hindrances to the process of an AP in the ECU (in the above example, the control process to realize the remote control-system) can be avoided. 
         [0137]    In the embodiment, the process sequence of the response-waiting message is also memorized in the message process sequence regulation section  32 , the data structure of the message process sequence regulation section  32  is therefore structured in a two-way list format as shown in  FIGS. 5A and 5B . 
         [0138]    Thus, the process to delete the request message of which obtaining response has been completed from the message process sequence regulation section  32 , and the process to add and memorize newly accepted request messages to the message process sequence regulation section  32  are simplified. 
         [0139]    Furthermore, according to the data structure as shown in  FIGS. 5A and 5B , by referring to the value recorded in the “MSG #” area, it can be immediately decided whether the number of response-waiting messages is 0 or not. In a case where the number of response-waiting messages is 0, it is not necessary to execute the processes after step S 420  as shown in  FIG. 10 , whereby processes in vain can be effectively reduced. 
         [0140]    One embodiment of the present invention is described above, but the present invention is not limited to the above embodiment, the present invention may be embodied in several other forms without departing from the spirit thereof. 
         [0141]    For example, the message information administration sections  21 ,  23  of each ECU may be performed as follows. At step S 220  in  FIG. 8 , after setting the value of the deadline counter corresponding to the request message accepted this time as a deadline value corresponding to the request message, or just before executing the deadline monitor process as shown in  FIG. 10 , the sections  21 ,  23  may execute the process to set the process sequence of the response-waiting message memorized in the message process sequence regulation section  32  (specifically, the value of “AHEAD” and “BEHIND” in the message process sequence regulation section  32  as shown in  FIGS. 5A and 5B ) as the sequence of the response-waiting message whose value of the deadline counter is near 0. In other words, the message information administration sections  21 ,  23  memorize sequence information of the response-waiting message whose time measured by the countdown at step S 430  In  FIG. 10  is near the deadline value (equivalent to the preset value) as sequence information indicating process sequence in the message process sequence regulation section  32 . 
         [0142]    Accordingly, the response-waiting message which has a higher possibility that the value of the deadline counter becomes 0 (i.e., exceeds the deadline), is processed at steps S 430  and S 440  in the deadline monitor process as shown in  FIG. 10  at earlier sequence. As a result, an occurrence of the deadline excess can be detected at an earlier stage. 
         [0143]    On the other hand, the message information administration sections  21 ,  23  may be installed only either in the ECU  11  of the requesting side or in the ECU  13  of the requested side. 
         [0144]    As the conformation of the on-vehicle control system, a plurality of APs may be mounted in one ECU, and each AP may exchange request messages and responses via the message information administration section  21  (or  23 ) within the same ECU. 
         [0145]    In addition, the transmission section and the reception section may be configured to consist of hardware circuits only, or may be configured to employ in part software implement. 
         [0146]    The present invention may be embodied in several other forms without departing from the spirit thereof. The embodiment and modifications described so far are therefore intended to be only illustrative and not restrictive, since the scope of the present invention is defined by the appended claims rather than by the description preceding them. All changes that fall within the metes and bounds of the claims, or equivalents of such metes and bounds, are therefore intended to be embraced by the claims.