JPH114241A - Network system for vehicle and recording medium recorded with program used therefor - Google Patents

Abstract

PROBLEM TO BE SOLVED: To reduce the burden of a CPU and increase the speed of a system by cyclically sending an ID data integration confirmation message to each local unit, waiting for a response, collecting node ID data of an operable local unit and allocating a next node ID. SOLUTION: Each of local units 2 to 4 automatically detects a next node ID and, when it is changed from a next node ID already registered, each local unit transmits a next node ID request to a management unit 1. The management unit 1 deletes a node ID of a local unit which stops operating with regard to objection table data for a node ID stored in an ID data memory and the next node ID or adds a node ID of the local unit which becomes operable in the middle and updates a new reference each node ID and table data of the next node ID corresponding to each node ID. Thus, the confirmation processing of an operable unit is unnecessitated.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

[0001] 1. Field of the Invention [0002] The present invention relates to a multiplex communication network system mounted on a vehicle and a recording medium storing a program used therein.

[0002]

2. Description of the Related Art Conventionally, as a vehicle network system for performing multiplex communication, a vehicle network system employing a token passing bus system having a configuration shown in FIG. 33 is known.
This conventional vehicular network system includes a management unit (MU) 1 and a plurality of local units, here, a navigation gating unit (NaviUnit).
2. A TV unit (TVUnit) 3 and a traffic information receiving unit (VICSUnit) 4 are connected by a LAN cable 5, both ends of the cable 5 are terminated by a terminator 6, and these management unit 1 and local units 2 to 4 are connected. This is a system that communicates with each other by the token passing bus method.

In order to realize the token passing bus system, a node ID (Node ID) is assigned to the management unit 1 and each of the local units 2 to 4, and the node of each station as shown in FIG. ID table data 7 indicating a comparison between the ID and the next node ID is held. Here, I
The D number is 8-bit data, and any number from 0 to 255 is assigned. The management unit MU1 has NodeID = 250, and the NaviUnit2 has No.
deID = 230, NodeID = for TVUnit3
240, NodeID = 220 for VICSUnit4
Are assigned respectively. Each of the local units 2 to 4 whose power is turned on has its own ID number as a next node ID (NextNodeID) indicating to which unit next to the own station a token indicating a data transmission right is passed. A smaller and larger ID number is set. Therefore, when the power of all units is on, the next node ID for NodeID = 220 is NextNodeID = 230, Node
NextNodeID = 240 for ID = 230,
NextNodeID = for NodeID = 240
250, the management unit 1 having the largest node ID
Since there is no node ID larger than NodeID = 250, the lowest ID number 220 is set as NextNodeID.

As described above, the node ID, the next node I
In the network system in which D is set, the token is sequentially transferred from the unit with the smaller ID number to the unit with the larger ID number in accordance with the next node ID, and the unit that has obtained the token obtains the right to send and receive data to and from other units and sends and receives data I do. Therefore, in the system shown in FIG. 33, the token is NodeID =
From the 250 management units 1
NodeID according to xtNodeID = 220
= 220 is set to VICSUnit4, and then N set to this VICSUnit4
According to extNodeID = 230, NodeI
It is passed to NaviUnit2 in which D = 230 is set, and then passed to TVUnit3 with NodeID = 240, from which management unit 1 with NodeID = 250
Will be passed to.

[0005] In such a vehicle network system, the management unit 1 has been disclosed in Japanese Patent Application Laid-Open No. 4-160934, and as shown in FIGS. Communication is performed individually with the local units 2 to 4, the power supply of the unit is determined by checking the response from each local unit, and the NodeID and Next in the ID data table are determined.
Registration with NodeID is performed. That is,
When the power of the system and the management unit 1 is turned on and all the power of the local units 2 to 4 are turned on, the management unit MU1 firstly operates the local units 2 to 4.
4 is sequentially transmitted to the ID No. 4 and if there is a response from the received local unit, the local unit is regarded as operable, and the ID data table 7 is stored in the Node.
The IDs are listed, an accumulation confirmation message is transmitted to all the local units 2 to 4, and at the stage where the response is received, for each NodeID of the NodeID group listed in the ID data table 7, Next, the NextNodeID is set and registered by the above-described algorithm. That is, for NodeID = 220, NextNodeID = 230 and NodeID =
For 230, NextNodeID = 240, ...,
NextNodeID for NodeID = 250
= 220 is registered. When the creation of the ID data table 7 is completed (as in the case of the table 7a in FIG. 35), as shown in FIG. NextNodeID is transmitted and held. And this NodeID and NextNodeI
When the data collection and setting registration of D are completed, FIG.
As shown in (1), data transmission by the token passing bus method is started between the units registered in the ID data table 7, and in this case, all the units 1 to 4.

Thereafter, the management unit 1 periodically repeats the data accumulation in the ID data table 7 in the above-described procedure, and always keeps the table data up to date. Therefore, as shown in FIG. 35 and FIG. 37 (a), one local unit (here, TV
Assuming that the power supply of the (Unit) 3 is turned off, the management unit 1 determines that the power is turned off in response to no response from the local unit 3 in the periodically executed NodeID accumulation processing. NodeID = 230 of the local unit 3 is deleted, and the listed NodeID = 220, 240, 2
NextNodeID is reset only in 50,
The contents of the ID data table 7 are updated (as in a table 7b in FIG. 35), and based on the updated table data, the local units 2, 4 which are enabled to operate as shown in FIG. NextNode
Let the ID be reset. Thereafter, as shown in FIG. 37 (c), only the units registered in the ID data table 7, that is, the management unit 1 and the local units 2 and 4 restart data transmission by the token passing bus method.

[0007]

However, in such a conventional vehicle network system, the management unit 1 individually communicates with each of the local units 2 to 4 to create the ID data table 7, and The response from the unit is checked to determine whether the operation of the unit is possible or not, and the NodeID and NextN in the ID data table are determined.
The following problem arises because registration with modeID is performed. That is, since the exchange of the signal of the inquiry processing of the operation enable / disable is performed through the LAN cable 5, the data transmission / reception operation by the normal token passing bus method is prohibited while the inquiry signal is flowing, and the LAN cable 5 There has been a problem that the load is increased and, as a result, speeding up of data transmission is hindered.

[0008] Further, a message for confirming whether or not each local unit is operable is performed by the management unit.
Since the management unit also determines the tNodeID and registers the settings in each local unit, a large load is imposed on the CPU of the management unit, which also hinders the speeding up of the system.

The present invention has been made in view of such conventional problems, and each local unit has its own Next Next.
An object of the present invention is to provide a vehicular network system capable of reducing the load on a management unit and a LAN cable by providing a function of acquiring a NodeID and increasing the speed of the system, and a recording medium recording a program used therein. I do.

[0010]

According to a first aspect of the present invention, in a vehicle network system in which a management unit and a local unit communicate with each other by a token passing bus system, the management unit includes: An ID data memory for storing target table data of the assigned node ID and the next node ID, and an ID for changing data in the ID data memory in response to a next node ID change request from any of the local units A table management unit, wherein each of the local units includes an ID storage unit of a node ID of the own station and a next node ID, a next node ID monitoring unit that monitors a next node ID, and a configuration in which the next node ID monitoring unit is a next node. When a change in node ID is detected, the management unit It is obtained by a next node ID change request unit for transmitting a change request of the next node ID on.

In the vehicle network system according to the first aspect of the invention, each local unit automatically detects the ID of a station that passes a token next to its own station, that is, the next node ID, and the newly detected next node ID is already detected. When the registered next node ID changes, a request for changing the next node ID is transmitted to the management unit. When the management unit receives the request for changing the next node ID from any of the local units, the management unit updates the target table data of the node ID and the next node ID assigned to each local unit held in the ID data memory. Node I of the local unit whose operation has stopped
D, or add the node ID of the local unit that has become operable from the stopped state.
And the comparison table data with the next node ID corresponding to each of them.

In this manner, the ID data accumulation confirmation message is periodically transmitted to the management unit to each local unit, and a response is waited. The node ID data of the local unit that is enabled to operate is collected, and the next node ID is collected.
This eliminates the need for a function of confirming the operable unit that assigns the data, reduces the load on the CPU, and also reduces the load on the LAN cable to increase the speed of the system.

According to a second aspect of the present invention, in the vehicular network system of the first aspect, the next node ID monitoring unit of the local unit starts with an ID number of the local station plus an ID number of another local station. The ID number is incremented by +1 from the unit to the ID number having a response, and the smallest ID number having received a response from the other local unit is determined as the next node ID.

In the vehicle network system according to the second aspect of the present invention, each local unit starts with an ID number of +1 assigned to its own station and increments the ID number by one from the other local unit to an ID number to which a response is made from another local unit. Is increased, and the smallest ID number that has received a response from another local unit is determined as the next node ID, and a next node change request is transmitted to the management unit when the newly detected next node ID changes.

According to a third aspect of the present invention, there is provided a recording medium storing a network program for a vehicle, wherein a network of a token passing bus system is constructed between a management unit and a plurality of local units, and the local unit is stored in the management unit. The target table data of the node ID and the next node ID assigned to the local unit are stored in the ID data memory, and the data of the ID data memory is changed in response to a change request of the next node ID from any of the local units. Each of the local units has its own node ID and next node ID as IDs.
The vehicle network program is stored in a storage unit, monitors a next node ID, and records a vehicle node program for transmitting a next node ID change request to the management unit when the change of the next node ID is detected.

In the recording medium storing the vehicle network program according to the third aspect of the invention, this is registered in the vehicle network hardware and executed, thereby realizing the vehicle network system according to the first aspect of the invention. can do.

[0017]

According to the vehicle network system according to the first and second aspects of the present invention, an ID data accumulation confirmation message is periodically transmitted to the management unit to each local unit, and a response is waited for. Collects the node ID data of the local unit, and eliminates the function of confirming the operable unit that assigns the next node ID, reducing the load on the CPU and the load on the LAN cable. Can be speeded up.

According to the recording medium storing the vehicle network program according to the third aspect of the present invention, the vehicle network program recorded on the recording medium is registered in the vehicle network hardware and executed, whereby: A high-speed vehicle network system can be realized.

[0019]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Embodiments of the present invention will be described below in detail with reference to the drawings. FIG. 1 shows a system configuration according to an embodiment of the present invention. As in the conventional example shown in FIG. 33, a management unit (MU) 1 and a navigation unit (Na) as a plurality of local units are provided.
viUnit) 2, TV unit (TVUnit) 3
And a traffic information receiving unit (VICSUnit) 4 by a LAN cable 5, both ends of the cable 5 are terminated by a terminator 6, and the management unit 1 and the local units 2 to 4 are interconnected by a token passing bus system. It is a communication system.

The management unit 1 and each local unit 2
4 is assigned a node ID (NodeID) in advance. Here, it is assumed that the ID number is 8-bit data and any number from 0 to 255 is assigned, and the management unit 1 has the largest Node among the units connected to this network system.
ID = 250 is assigned, and NodeID = 220, 230, 240 is assigned to each of the local units 2-4.

As shown in FIG. 2, the management unit 1 includes a browser unit M1, an I / O management unit M2, a network interface M3, and a network interface M3.
The packet decompression and coordination function unit M that deciphers a packet (Packet) arriving from the server and manages the operation of each of the function units M1 to M3
4 is provided.

The browser section M1 of the management unit 1
(1) Servers addressing facilitator (Serv) for addressing local units 2 to 4
er's Addressing Facilitat
or) function, (2) browser change processing function M1.1 when the next node ID changes in its own unit, and (3) browser change processing function M1.2 when the next node ID changes in any of local units 2 to 4. It is configured.

The network interface M3 is
(1) a packet transmitting function for transmitting a packet, (2) a packet receiving function for receiving a packet, and (3) a next ID change detecting function M3.1 for generating an interrupt request when the next node ID changes in the own unit. ing.

Further, the packet decryption and coordination function unit M4 provides (1) a packet decryption function M4.2 for decrypting a packet arriving from any of the local units 2 to 4, and (2) a packet decryption function M4 for any of the local units 2 to 4. And transmission request function M for packetizing the data of
4.3, (3) A coordination function M4.1 that determines which function is to be activated when a message is delivered to a predetermined destination inside the unit and an interrupt occurs.

Then, as shown in FIG. 3, the management unit 1
Browser change processing M when the next node ID changes in the own unit
1.1 includes a browser change-related data generation process M1.1.1 and a browser change process M1.1.2, and the browser change process M1.1.2 includes a node ID delete range setting process M1.1.2.1 and a function. Delete processing M1.1.2.2 is included. Similarly, in the browser change processing when the next node ID changes for any of the local units 2 to 4, the processing M1.2.1 for restoring the change data from the next node ID change request from the corresponding local unit and the browser The processing of the change processing M1.2.2 is included. The browser change process M1.2.2 further includes a node ID delete range setting process M1.2.2.1 and a function delete process M1.2.2.2.

On the other hand, as shown in FIG. 4, each of the local units 2 to 4 has a specific function unit S1 for executing a specific function of its own unit, and an addressing facilitator (Add) for supporting addressing of its own unit to its own function.
lessing Facilitator) Function S
2. A network interface S3 for connecting to a network, a browser change request generating function unit S4 for generating a browser change request, and a message arriving from the network interface S3 is decrypted, and each function unit S1
A packet decryption and coordination function unit S5 for managing the operation of S4 is provided. As the specific function unit S1,
The navigation unit (NaviUnit) 2 draws a map, a route guidance function, and a television unit (TVUn).
it) 3, screen switching function, traffic information unit (V
ICSUnit) 4 has a traffic information providing function.

The network interface S3 of each of the local units 2 to 4 detects (1) a packet transmitting function for transmitting a packet, (2) a packet receiving function for receiving a packet, and (3) a change in the next node ID for the own unit. , A next ID change detection function S3.1 for generating an interrupt request.

The browser change request generation function unit S4 collects change data when detecting a change in the next node ID for its own unit, issues a packetization command, and issues a packet transmission command.
It has one.

The packet decryption and coordination function unit S5 includes (1) a packet decryption function S5.3 for decrypting a packet arriving from another unit, and (2) a packetization and transmission request function for packetizing data and issuing a transmission instruction. S5.2, (3) a coordination function S5.1 that determines which function is to be activated when a message is passed to a predetermined destination inside the unit and an interrupt occurs.

As shown in FIG. 5, as a calculation process executed by each functional unit of each of the local units 2 to 4, the browser change request function S4.1 when the next node changes to its own unit includes browser change related data. Generation processing S
4.1.1 and a process S4.1.2 for writing to the browser change request message buffer.

Next, the processing functions of the management unit 1 and the processing functions of the local units 2 to 4 will be described with reference to flowcharts. First, the processing functions of the management unit 1 will be described. As shown in FIG. 6, the next node ID change detection processing M3.1 in the own unit is executed as follows. Network interface M
3 monitors the NextID Flag, and during normal operation, the NextID Flag is “0”. However, when the NextID Flag changes to “1”, the NextID change processing interrupt processing (Interrupt) is performed.
Routine).

As shown in FIG. 7, the packet decoding and coordination function unit M4 executes an interrupt process M4.1 in the management unit 1 for a change in the next node ID as follows. When you start interrupt processing,
The interrupt is disabled (Disable) so as not to accept another interrupt (step S101), and an activation request for the browser change processing M1.1 when the next node ID changes in the management unit 1 is generated to the browser M1 (step S102). Then, the interrupt processing is returned to enable (Enable) and the process returns (step S103).

The browser change process M1.1 for changing the next node ID by the browser M1 in the management unit 1 is based on the flowcharts of FIGS. As shown in FIG. 8, first, a browser-related data generation process M1.
1.1 is started (step S111), the browser change processing M1.1.2 is performed after the next node ID is determined (step S112), and the process returns.

As shown in the flowchart of FIG. 9, in the browser-related data generation processing M1.1.1, first, the current node ID of the management unit 1 itself and the next node ID are read and set as The_ID and The_NextID.
The w NextID Flag is cleared once (step S121). Then, NextID is incremented by +1 every 39 μs until NextID is found (step S122). If NextID is found, it is set as New NextID, and New New is set.
Ne if xtID is the same as Previous NextID
w NextID Flag is set to '0', and if it is different from the previous NextID, NewNextID is used.
Flag is set to '1' (step S123). If the New NextID Flag is '1', the process returns to step S121 to repeat the same process, and finally sets the newly detected New NextID to the regular next node ID (The_NextID), and sets the ID of the own station ( The ID is registered in association with (The_ID), and the process ends (steps S124 and S125).

Subsequently, the actual browser change processing M1.1.2 in the browser change processing M1.1 in the management unit 1
In this process, as shown in FIG. 10, a delete range setting process M1.1.2.1 for determining a node function and a range of node devices to be deleted from the data of the browser M1 is performed (step S11). S131) Then, a function Delete process M1.1.2.2 for actually deleting the node function and the node device within the determined range is executed (step S132).

As shown in FIG. 11, the Delete range setting process M1.1.2.1 is performed by the ID of the management unit 1 itself, T
Start from the ID number of he_ID + 1 (Start_Deletion
_at_ID) (step S141), and the newly detected next node ID (The_NextID) is Del.
This is the process of setting the end point (Stop_Deletion_at_ID) of the et range (step S142).

When the node deletion (Delete) range is determined in this manner, the actual deletion (Delete) shown in FIG.
te). First node I of the deletion range
D (Start_Deletion_at_ID) is set (step S
151), the deletion is executed while incrementing the node ID by +1 (steps S152 and S153), and the end point of the deletion (Delete) range (Stop_Deletion_at_ID)
), The deletion is stopped (step S15).
4).

As described above, when the browser M1 of the management unit 1 detects a change in the next node ID for its own station, it detects a new next node ID and updates and registers it with the node ID of its own station.

When the browser M1 of the management unit 1 receives from the corresponding local unit that the next node ID for each of the local units 2 to 4 has been changed, the browser M1 shown in FIG. Execute In the browser change process M1.2, first, a process M1.2.1 of restoring changed data from an arriving packet is executed (step S161), and thereafter, a browser registration data change process M1.2.2 is executed (step S162).

As shown in FIG. 14, in the process of restoring changed data from a packet M1.2.1, the node ID (The_ID) of the unit that has requested the change of the next node ID is first extracted from the packet message (step S171). , Followed by the newly detected next node I
D (The_NextID) is extracted (step S1)
72).

The browser registration data change processing M1.2.2 shown in FIG. 15 is the same as the processing procedure shown in FIG. 10, except that the function of the node which must be deleted from the data of the browser M1 and the range of the node device De for deciding
The let range setting process M1.2.2.1 is performed (step S
181) Then, a node function and a function for actually deleting the node device within the determined range Delete process M1.
2.2.2 is executed (step S182).

As shown in FIG. 16, in the delete range setting process M1.2.2.1, the ID (The_ID) of the local unit that issued the request for changing the next node ID is started from the ID number incremented by 1 (Start_ID). _Deletion _a
t_ID) (step S191), and the newly detected next node ID (The_NextID) is deleted.
The end point of the te range (Stop_Deletion_at_ID) is set (step S192).

When the node deletion (Delete) range is determined in this manner, the actual deletion (Delete) shown in FIG.
te). First node I of the deletion range
D (Start_Deletion_at_ID) is set (step S
1001), the deletion is executed while incrementing the node ID by +1 (steps S1002 and S100).
3), the end point of the deletion (Delete) range (Stop_Deletio)
n_at_ID), the deletion is stopped (step S).
1004).

As described above, the browser M1 of the management unit 1 corresponds to the case where one of the local units 2 to 4 detects a change in the next node ID for its own station and transmits a request for changing the next node ID. The new next node ID for the local unit is updated and registered.

A packet decoding process M4.2 for a next node ID change request from any of the local units 2 to 4 executed by the packet decoding and coordination function unit M4 of the management unit 1 is shown in the flowchart of FIG. Procedure. That is, a packet message (Message Connect) is specified by specifying the node ID of the management unit 1 from any of the local units.
xt) is received (step S1011), the packet message is extracted (step S101).
2) It is passed to the browser M1 (step S101)
3).

Next, the processing functions of the local units 2 to 4 will be described. As shown in FIG. 19, the next node ID change detection processing in its own unit S3.1
Is executed as follows. The network interface S3 monitors the NextID Flag, and during normal operation, the NextID Flag is "0". However, when the NextID Flag changes to "1", the interrupt processing of the NextID change processing is interrupted.
start Routine).

As shown in FIG. 20, the packet decoding and coordination function unit S5 of the local unit executes an interrupt process S5.1 for the change of the next node ID for its own station as follows. When the interrupt processing is started, first, the interrupt is disabled (Disable) so as not to accept another interrupt (step S2).
01), an instruction to start the browser change request processing S4.1 is given to the browser change request generation function unit S4 (step S4).
202) After that, the interrupt processing is enabled (Ena
1be) and returns (step S203).

Browser change processing S for changing the next node ID in the browser change request generation function unit S4
4.1 is based on the flowcharts of FIGS. As shown in FIG. 21, first, a browser-related data generation process S
4.1.1 is started (step S211), and after determining the next node ID, processing S4.1.2 of writing the next node ID change request message to the buffer is performed (step S212), and the process returns.

As shown in the flowchart of FIG. 22, in the browser-related data generation processing S4.1.1, the local node that has detected the change of the next node ID reads the node ID of its own station and the next node ID to read The_ID,
The Next_ID F
The flag is temporarily cleared (step S221). And Next39 every 39μs until NextID is found
The tID is incremented by +1 by the hardware of the apparatus (step S222). If a NextID is found, it is set as a New NextID and Ne is also set.
If w NextID is the same as the previous NextID, the New NextID Flag is set to “0”, and if different from the previous NextID, New New
xtIDFlag is set to “1” (step S22)
3). If the New NextID Flag is “1”, the process returns to step S221 to repeat the same processing, and finally the newly detected New NextID.
Is the regular next node ID (The_NextID)
, And registered in association with the ID of the own station (The_ID), and this processing is completed (steps S224 and S22).
5).

When the local unit detects a new next node ID in this manner, the processing shifts to the processing S4.1.2 for writing in the change request message buffer shown in FIG. First,
The newly detected next node ID (The_Next
ID) in the buffer, and the own node ID
(The_ID) is written (steps S231 and S2).
32) Then, after writing an identification indicating that the next node has been changed (step S233), the packet decryption and coordination function unit S5 executes packetization and transmission processing S5.2 (step S234).

As shown in FIG. 24, in the packetization and transmission process S5.2, the data in the message buffer is converted into packet data (step S241), and the management unit 1
(Step S242).

Thus, any one of the local units 2
When the management unit 1 receives the next node ID change request from the management unit 1, the browser change process M1.2 for the next unit ID change on the local unit side shown in FIGS. 13 to 17 is executed.

Next, the operation of the vehicle network system having the above configuration will be described.

<Case 1> Based on FIG. 25 to FIG. 28, one of the local units 2 to 4, in this case, the television unit 3 to which the node ID (Node ID) 240 is assigned is turned off from power on, The node ID of this television unit 3 is the next node ID.
The operation when the navigation unit 2 with the node ID (NodeID) = 230 registered as (NextNodeID) detects a change in the next node ID will be described.

The management unit 1 and all the local units 2
In a state where all the power supplies are turned on, the management unit 1 has the node ID = 2 by the next node ID detection function.
50, NextNodeID = 220, and the navigation unit 2 also has NodeID = 2
30, NextNodeID = 240 is registered, and the TV unit 3 registers NodeID = 240, NextNode.
ID = 250 is registered, and the traffic information unit 4 is Node
ID = 220 and NextNodeID = 230 are registered. The comparison between the node ID and the next node ID is performed by the data table 7 in the browser M1 of the management unit 1.
a is registered.

As shown in FIG. 27, in the token passing communication in this state, the management unit 1 uses a token, issues a token transfer request to NextNodeID = 220, and sets a predetermined time of 3
The LAN is monitored for 9 μs, and when the traffic information unit 4 as the next node responds, the traffic information unit 4
Pass the token to. The traffic information unit 4, which is the next node receiving the token, uses the received token and
navigation unit 2 with xtNodeID = 230
The token is passed to and the LAN is monitored for 39 μs. The next node, the navigation unit 2, receives the token, uses the token, and sends the NextNodeI
The token is passed to the television unit 3 with D = 240, and the token is passed from this television unit 3 to the management unit 1 with NextNodeID = 250. Thereafter, this token passing communication is continued.

Here, one of the local units, Nod
When the power of the television unit 3 assigned with eID = 240 and NextNodeID = 250 is turned off, next node detection and browser registration change processing are executed as follows. The NodeI whose NodeID = 240 is registered as the NextNodeID
In the navigation unit 2 with D = 230, Ne
xtNodeID change is detected, NextNodeID = 250 is detected as a new next node ID,
This change of the next node ID is notified to the management unit 1 by a browser change request, and the management unit 1 executes a browser change process M4.1 to update the data table 7b of node ID-next node ID.

That is, as shown in FIG. 25, in the navigation unit 2, the network interface S3
By the NextID change detection function S3.1
By detecting the change of the NodeID, the packet decoding and coordination function unit S5 gives an instruction to start the interrupt processing S5.1 (), and the packet decoding and coordination function unit S5 executes the browser change request generation function unit in the interrupt processing S5.1. In S4, a command to start the browser change request function S4.1 when the NextID changes is given ().

The browser change request generation function unit S4 activates the change-related data generation function S4.1.1 to collect the change data, and then activates the browser change request function S4.1.2 to activate the browser change request function S4.1.2. Node ID (The_I
D) and the newly detected next node ID (The_
NextNodeID) is written to the message buffer.

Thereafter, the browser change request generation function unit S4
Causes the packet decoding and coordination unit S5 to activate the packetizing and transmitting function S5.2 (). The packet decoding and coordination unit S5 packetizes the data written in the message buffer, activates the packet transmission function on the network interface S3 (), and the network interface S3 receives the token and sends the management unit 1 through the LAN cable 5. (2) transmits data related to the change of the next node ID to the side as packet data.

On the management unit 1 side, the packet data is received by the network interface M3 and transferred to the packet decoding and coordination unit M4 (). The packet decryption and coordination unit M4 executes packet decryption processing M4.2 to decrypt the packet message, and activates the browser change function M1.2 when the next node ID of another unit changes in the browser unit M1. Apply ().

In the browser section M1, a browser change function M
1.2, first, a change data restoration function M1.2.1 from a change request is executed to restore data relating to a change from a message, and then a browser change function M1.
Execute 2.2. In this browser change function M1.2.2,
The deletion range is determined by the setting function M1.2.2.1 of the deletion range, deleted by the deletion function M1.2.2.2, and the data is updated from the registered data table 7a to 7b.

The detection of the change of the next node ID and the browser change request operation in the local unit 2 are described below.
This will be described with reference to FIGS. Node at some point
If the TV unit 3 with ID = 240 is turned off,
Navigation unit 2 with NodeID = 230,
Look at the registered NextNodeID = 240,
During 39 μs of passing the token to the TV unit 3 with NodeID = 240 and monitoring the LAN, the TV unit 3 stops using the token.

Therefore, in the navigation unit 2, Ne is used.
NewNextID is the ID obtained by adding +1 to xtNodeID
Then, the token is passed to NodeID = 241, the interrupt processing S5.1 at the time of detecting the change of the next node ID is started, and the LAN is monitored for 39 μs. Next until the node ID that receives the token is found.
The token passing and the LAN monitoring for 39 μs are repeatedly performed while incrementing the NodeID by +1.

In this embodiment, NodeID = 25
Since the management unit 1 of “0” is operating, when the navigation unit 2 passes the token with NextNodeID = 250, the management unit 1 uses the token and transfers the token to the management unit 1.

In parallel with this, the navigation unit 2 registers the newly detected NextNodeID = 250 in its own station, changes the NextNodeID,
A browser change request message for notifying the management unit 1 of the xtNodeID value is created, and the system waits for the next token to arrive.

When a token is received from the traffic information unit 4, a browser change request message is transmitted to the management unit 1 using the token. Upon receiving the browser change request message, the management unit 1 performs the above-described browser change process, and updates the node ID-next node ID data table 7b.

After transmitting the message, the navigation unit 2 passes the token to NextNodeID = 250, monitors the LAN for 39 μs, and thereafter, the communication of the token passing bus method is continued between the units 1, 2, and 4 in the power-on state. .

<Case 2> The operation when the management unit 1 detects a change in the next node ID will be described with reference to FIGS. 29 to 32. When the power of the management unit 1 and all the local units 2 to 4 are all turned on, the management unit 1 is No.
deID = 250, NextNodeID = 220 are registered, and the navigation unit 2 sets NodeID = 23.
0, NextNodeID = 240 is registered, and the TV unit 3 registers NodeID = 240, NextNodeI.
D = 250 is registered, and the traffic information unit 4 is NodeI
D = 220 and NextNodeID = 230 are registered. The comparison between the node ID and the next node ID is performed by the data table 7 in the browser M1 of the management unit 1.
c is registered.

As shown in FIG. 31, in the token passing bus system communication in this state, the token is passed from the management unit 1 to the traffic information unit 4 of NextNodeID = 220, and the traffic information unit 4 sends the token to the next traffic information unit.
The token is passed to the navigation unit 2 with deID = 230, and NextNo is sent from the navigation unit 2.
The token is passed to the television unit 3 with deID = 240, and the NextNodeID =
The communication of passing the token to the 250 management units 1 is repeatedly continued.

Here, one of the local units, Nod
When the power of the television unit 3 to which eID = 220 and NextNodeID = 230 are assigned is turned off, this NodeID = 220 is changed to NextNodeID.
In the management unit 1 registered as, next node detection and browser registration change processing are executed as shown in FIG.

NodeID = 220 is NextNode
Ne by the NextID detection function M4.1 of the management unit 1 with NodeID = 250 registered as ID
xntNodeID change is detected, NextNodeID = 230 is detected as a new next node ID,
The packet decoding and coordination function unit M4 is given an instruction to start the interrupt processing M4.1 (FIG. 4), and the packet decoding and coordination function unit M4 performs the interrupt processing M4.
At 1, the browser section M1 gives an activation command for the browser change function M1.1 when the next node ID change is detected in its own station ().

In the browser section M1, a browser change function M
1.1, the change data generation function M1.
1.1 is started to collect browser change related data, and then the browser change function M1.1.2 is executed. In the browser change function M1.1.2, a setting function M1.1.2.
The deletion range is determined by 1 and deleted by the deletion function M1.1.2.2, and the data is updated from the registered data tables 7c to 7d.

The detection of the change of the next node ID and the browser change operation in the management unit 1 will be described with reference to FIGS. 31 and 32. NodeID = 2 at some point
If 20 traffic information units 4 are powered off, Nod
The management unit 1 with eID = 250 is registered N
Looking at extNodeID = 220, NodeID = 2
During 39 μs, passing the token to 20 traffic information units 4 and monitoring the LAN, the traffic information unit 4 does not use the token.

Then, in the management unit 1, NextNod
No ID is added to eID plus NewNextID
Pass the token to deID = 221, and send the next node I
Activate interrupt processing M4.1 when D change is detected.
Monitor the LAN for μs. Then, until the node ID that receives the token is found, NextNodeID
Is incremented by +1 and the token passing and LAN monitoring for 39 μs are performed repeatedly.

In this embodiment, NodeID = 23
Since the navigation unit 2 of 0 is operating, when the management unit 1 passes the token with NextNodeID = 230, the navigation unit 2 uses the token and transfers the token to the navigation unit 2.

At the same time, the management unit 1 sets the NextNodeID = 23 newly detected in the above-described procedure.
0 is updated and registered in the data table 7d of the browser section M1, and the arrival of the next token is awaited.

Thereafter, when a token arrives from the television unit 3, the management unit 1 sets the newly registered Next
Pass the token to NodeID = 230, L for 39μs
The AN is monitored, and thereafter, the units 1, 2, 2,
The communication of the token passing bus method is continued among the three.

In the above embodiment, three local units 2 to 4 are used. However, the number is not particularly limited. Also, the LAN monitoring time 39 μs may be changed by the system.

When the management unit 1 is powered on and starts up the system, the management unit 1 makes an inquiry to all connected local units 2 to 4,
It is assumed that the local units that are powered on are detected and registration processing of the node ID and the next node ID of those units in the ID data table 7 is performed.

[Brief description of the drawings]

FIG. 1 is a system block diagram according to an embodiment of the present invention.

FIG. 2 is a functional block diagram of a management unit in the embodiment.

FIG. 3 is an explanatory diagram of an arithmetic processing function of a management unit in the embodiment.

FIG. 4 is a functional block diagram of a local unit in the embodiment.

FIG. 5 is an explanatory diagram of an arithmetic processing function of a local unit in the embodiment.

FIG. 6 is a flowchart of a next node ID change detection process of the management unit in the above embodiment.

FIG. 7 is a flowchart of interrupt processing of the management unit in the embodiment.

FIG. 8 is a flowchart of a browser change process at the time when a change of the next node ID is detected in the local station of the management unit in the above embodiment.

FIG. 9 is a flowchart of generation of browser change-related data of the management unit in the embodiment.

FIG. 10 is a flowchart of a browser change process at the time when a change of the next node ID is detected in the local station of the management unit in the above embodiment.

FIG. 11 is a flowchart of setting a deletion range in the browser change process.

FIG. 12 is a flowchart of a range and a function deletion in the browser change process.

FIG. 13 is a flowchart of a browser change process performed by another station of the management unit in the above embodiment when a change in the next node ID is detected.

FIG. 14 is a flowchart of a process of restoring browser change data from a packet of the management unit in the embodiment.

FIG. 15 is a flowchart of a browser change process performed by another station of the management unit in the above embodiment when a change in the next node ID is detected.

FIG. 16 is a flowchart of setting a deletion range in the browser change process.

FIG. 17 is a flowchart of deleting a range and a function in the browser change process.

FIG. 18 is a flowchart of a packet decryption process of the management unit in the above embodiment.

FIG. 19 is a flowchart of next node ID change detection processing of the local unit in the above embodiment.

FIG. 20 is a flowchart of interrupt processing of a local unit in the embodiment.

FIG. 21 is a flowchart of generating a browser change request of the local unit in the above embodiment.

FIG. 22 is a flowchart of generation of browser change-related data of the local unit in the embodiment.

FIG. 23 is a flowchart of a process of writing a browser change request message of the local unit in the above embodiment.

FIG. 24 is a flowchart of a packetization and transmission process of the local unit in the embodiment.

FIG. 25 is an explanatory diagram of a communication operation at the time of detecting a change of the next node ID on the local unit side in the embodiment.

FIG. 26 is a flowchart of a communication operation at the time of detecting a change of the next node ID on the local unit side in the above embodiment.

FIG. 27 is a more detailed flowchart of the first half of the communication operation when the change of the next node ID on the local unit side is detected in the above embodiment.

FIG. 28 is a more detailed flowchart of the latter half of the communication operation when the change of the next node ID on the local unit side is detected in the above embodiment.

FIG. 29 is an explanatory diagram of an operation when a change of the next node ID on the management unit side is detected in the embodiment.

FIG. 30 is a flowchart of a communication operation at the time of detecting a change of the next node ID on the management unit side in the above embodiment.

FIG. 31 is a more detailed flowchart of the first half of the communication operation upon detection of a change in the next node ID on the management unit side in the above embodiment.

FIG. 32 is a more detailed flowchart of the latter half of the communication operation upon detection of a change of the next node ID on the management unit side in the above embodiment.

FIG. 33 is a system block diagram of a conventional example.

FIG. 34 is an ID data table of a browser unit of the management unit in the conventional example.

FIG. 35 is a flowchart of a communication operation of a conventional example.

FIG. 36 is an operation explanatory view of a conventional example.

FIG. 37 is an operation explanatory view when one of the local units in the conventional example is turned off.

[Explanation of symbols]

 Reference Signs List 1 management unit 2 navigation unit 3 television unit 4 traffic information unit 5 LAN cable 6 terminator 7, 7a, 7b, 7c, 7d ID data table

 ────────────────────────────────────────────────── ─── Continued on the front page (72) Inventor Takashi Ueno Nissan Motor Co., Ltd., 2 Takaracho, Kanagawa-ku, Yokohama-shi, Kanagawa

Claims (3)

[Claims] 1. A vehicular network system in which a management unit and a local unit communicate with each other by a token passing bus method, wherein the management unit includes a node ID and a next node ID assigned to each of the local units. An ID data memory for storing target table data, and an ID table management unit for changing data in the ID data memory in response to a next node ID change request from any of the local units. Is an ID storage unit of the node ID of the own station and the next node ID, and a next node ID
And a next node ID change request unit that transmits a next node ID change request to the management unit when the next node ID monitor unit detects a change in the next node ID. Network system for vehicles. 2. The next node ID monitoring unit of the local unit includes an ID number assigned to the own station,
Starting with the ID number of 1 and increasing the ID number by +1 from the other local unit to the ID number having a response from the other local unit, and determining the smallest ID number having a response from the other local unit as the next node ID. The vehicle network system according to claim 1, wherein: 3. A token passing bus network is constructed between a management unit and a plurality of local units, and a target table of a node ID and a next node ID assigned to each of the local units is provided to the management unit. The data is stored in the ID data memory, and in response to a change request of the next node ID from any of the local units, the data of the ID data memory is changed. A storage medium storing a vehicle network program for storing a node ID in an ID storage unit, monitoring a next node ID, and transmitting a next node ID change request to the management unit when the change of the next node ID is detected. .