WO2006072987A1 - 通信装置 - Google Patents

通信装置 Download PDF

Info

Publication number
WO2006072987A1
WO2006072987A1 PCT/JP2005/000081 JP2005000081W WO2006072987A1 WO 2006072987 A1 WO2006072987 A1 WO 2006072987A1 JP 2005000081 W JP2005000081 W JP 2005000081W WO 2006072987 A1 WO2006072987 A1 WO 2006072987A1
Authority
WO
WIPO (PCT)
Prior art keywords
program data
frame
communication device
version
received
Prior art date
Application number
PCT/JP2005/000081
Other languages
English (en)
French (fr)
Inventor
Kiyoshi Miyano
Original Assignee
Fujitsu Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Limited filed Critical Fujitsu Limited
Priority to PCT/JP2005/000081 priority Critical patent/WO2006072987A1/ja
Publication of WO2006072987A1 publication Critical patent/WO2006072987A1/ja

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems

Definitions

  • the present invention relates to a communication device, and more particularly to a communication device in which a network is configured by a plurality of devices.
  • FIG. 14 shows a version upgrade operation example (1) of the conventional communication devices 100a_l-100a_7 (hereinafter may be collectively referred to as reference numeral 100a).
  • These communication devices 100a constitute a network together with the control terminal 200a, and each communication device 100a is connected to the control terminal 200a by a control line 300 separately from a main signal line (not shown). .
  • each communication device 100a is upgraded.
  • FIG. 15 shows an example of the version upgrade operation (2), which shows a conventional communication device 100b_l—
  • the control terminal 200b and the control terminal 200b constitute a network.
  • Each communication device 100b and the control terminal 200b are connected by a main signal line, and a control signal (for example, a version upgrade start command 800) is transmitted and received in this line.
  • a control signal for example, a version upgrade start command 800
  • the procedure for this version upgrade operation example (2) is described below.
  • Step S400 The viewer of the control terminal 200b gives a version upgrade start command 800 including program data to the communication device 100b_l via the main signal line.
  • Step S410 Authentication device 100b 1 executes version upgrade of its own device based on the received program data.
  • Step S440 '" Thereafter, the communication devices 100b_3 to 100b_7 execute version upgrade in the same manner.
  • each communication device has the same program as itself on the network. Search for communication devices of the same model that operate, obtain program version information of the searched communication devices, compare the version of the acquired program with the old and new versions of its own program, and If it is newer than the version of the program, there is one that downloads the communication device capability program and updates its own program (for example, see Patent Document 1).
  • Patent Document 1 JP 2000-215034
  • the supervisor of the control terminal 200a needs to give a version upgrade start command 800 for each communication device 100a. This could result in human error (for example, forgetting to upgrade). Also, in order to confirm the completion of the upgrade of all communication devices 100a, it was necessary to read all the communication devices one by one and check the status.
  • an object of the present invention is to reduce the time for transmitting program data to all communication devices and to reduce the retransmission time for program data in a communication device in which a network is configured by a plurality of devices. To do.
  • a communication apparatus sequentially receives a program data frame including a received frame storage area and each of program data divided into a plurality of pieces, and the received program data is received.
  • a unique frame processing unit that stores the program data frame in the received frame storage area and sequentially transfers the program data frame to a downstream communication device is provided. / Speak.
  • the program data (program file) is divided into a plurality of program data, and each divided program data is included in each program data frame.
  • the unique frame processing unit sequentially receives program data frames and stores the received program data in the received frame storage area.
  • the unique frame processing unit sequentially transmits each program data frame to the downstream communication device before receiving all program data frames corresponding to the program data.
  • the method for storing the program data in the received frame storage area may store only the program data or the entire program data frame.
  • the communication apparatus can store all program data (program files) in the reception frame storage area and can receive all program data frames. It is possible to transfer the program data frame to the downstream communication device (if there is a downstream communication device) before the transmission (for example, each time the program data frame is received). As a result, a plurality of communication devices (upstream communication device and its downstream communication device) can receive all program data (program files) almost simultaneously.
  • the unique frame processing unit transmits the received program frame to the downstream communication device before receiving all program data frames. It is possible.
  • the present invention is the above-described present invention, wherein the received frame storage area power stores program data in units of the program data frame, and the unique frame processing unit is stored in the received frame storage area. !, NA! /, The missing program data can be requested to the upstream communication device or control terminal.
  • Program data is stored in units of program data frames, that is, in the entire program data frame.
  • the unique frame processing unit requests, for example, a powerful program data frame that cannot be received from an upstream communication device or control terminal. Thus, for example, due to a reception error of one program data frame, it is necessary to request retransmission of all program data frames.
  • the unique frame processing unit can change the division unit of the program data.
  • the program data can be transmitted in an appropriate division unit corresponding to the communication device, the communication line, and the like.
  • the present invention may further include a control unit that upgrades the version of the own communication device using the received program data. That is, the program data is program data for upgrading the communication device, and the control unit can upgrade the communication device with this program data.
  • the unique frame processing unit transmits a version upgrade completion notification to an upstream communication device or control terminal when the version upgrade of the own device is completed. It is possible. As a result, the upstream communication device or the control terminal can know the end of the upgrade of the downstream communication device.
  • the present invention is the above-described present invention, wherein the unique frame processing unit is connected to the own device.
  • the upstream communication device or the control terminal is a specific communication device (communication device that manages the downstream communication device, hereinafter referred to as a communication device that does not receive any version upgrade completion notification).
  • This communication device may be referred to as a master communication device), and it is possible to know that the upgrade of all communication devices has been completed only by notification of upgrade completion from all of them.
  • the present invention is the above-described present invention, wherein the unique frame processing unit receives a version of the program data from an upstream communication device, and the program has a newer version than the version of the program data of the own device. Only program data files containing data can be received. As a result, the communication device can receive only the latest program data.
  • the received frame storage area can be set to a nonvolatile memory.
  • the system goes down for some reason during program data transfer, it becomes possible to receive the program data from the middle again when the connection with the upstream communication device is established.
  • the program data order can be associated with the program data frame. As a result, even if the transfer order of program data is reversed, it is possible to restore the normal order.
  • program data is transmitted to all communication devices almost simultaneously, and the time for transmitting program data to all communication devices is shortened. It becomes possible. Therefore, it is possible to upgrade all communication devices almost simultaneously.
  • a control terminal that transmits program data to a communication device can upgrade all communication devices only by transmitting program data or the like to one communication device. In addition, even if the upgrade is resumed due to interruption of the power supply during the upgrade process, the loss time other than the interruption time is eliminated. Also, the control terminal only needs to manage the master communication device, and the version upgrade It becomes easier.
  • FIG. 1 shows a configuration example of a communication device lOOx (lOOy) according to the present invention.
  • the communication device ⁇ includes a main signal control unit 10, a frame transmission / reception unit (LAN driver) 11, a unique frame processing unit 12, a volatile memory 13, and nonvolatile memories 14 and 15.
  • the volatile memory 13 includes a reception frame storage area 13a and a device control program 13b.
  • the nonvolatile memory 14 includes a reception frame storage area 13a and a backup program 14b, and the nonvolatile memory 15 includes setting contents 15a.
  • FIG. 2 shows a version upgrade operation embodiment (1) in a network provided with a communication device 100x (general name 100x_l—100x_ll) and a control terminal 200x according to the present invention.
  • a control terminal 200x and communication devices 100x_l—100x_4 are connected in cascade.
  • Each communication device 100x_2—100x_4 has communication devices 100x_8 and 100x_9, communication devices 100x_5, 100x_10, and 100x_ll, and communication.
  • Devices 100x_6 and 100x_7 are connected.
  • FIG. 3 shows a version upgrade operation embodiment (2).
  • a master is provided in the network shown in FIG. 2, instead of the communication devices 100x_l—100x_4 and the control terminal 200x.
  • a communication device 100y_l—100y_4 (hereinafter may be collectively referred to as a reference numeral 100y) and a control terminal 200y are connected.
  • the master communication device 100y_l—100y_4 unlike the communication device 100x_l—100x_4, is set to be the master, for example, in setting content 15a (see FIG. 1). Further, unlike the control terminal 200x, master communication devices 100y_l-100y_4 are registered in the control terminal 200y.
  • the upgrade operation of the embodiment (1) and the upgrade operation of the embodiment (2) are the same as the operations of the communication device 100x_l-100x_4 and the control terminal 200x. Since these are different, the operation of the embodiment (1) will be described below based on the operation of the embodiment (2).
  • FIG. 4 is a flowchart (1) showing the operation procedure of the embodiment (2).
  • Figure 5 Figure 10 Transmission / reception between the control terminals 200y, 200x (hereinafter sometimes collectively referred to as the reference numeral 200) and the communication devices lOOx, lOOy, and between the upstream communication devices lOOx, 100y and the downstream communication devices lOOx, 100y. Shows the frame to be played. Note that the descriptions in FIGS. 5 to 10 particularly show frames transmitted and received between the upstream communication device 100x_l and the downstream communication device 100x_2.
  • the control terminal 200 (the communication device upstream of the communication device 100_1) monitors and controls each communication device 100y, lOOx as before, and all the communication devices 100y, lOOx are controlled by the control signal flowing in the main signal line. Communication with the control terminal 200 is possible.
  • the control terminal 200 stores program data (program file) to be upgraded in advance. Further, MAC addresses are set in the control terminal 200 and the communication devices 100y and lOOx, respectively. As a result, layer 2 level communication is possible (if there is a main signal line).
  • Step S100 The control terminal 200 transmits a version-up broadcast frame 700 to search for adjacent communication devices lOOx and 100y.
  • FIG. 5 shows an upgrade broadcast frame 700.
  • Step S110 In the communication device 100 1, the unique frame processing unit 12 receives the frame 700 via the frame transmission / reception unit 11, knows the start of version upgrade, and determines the transmission source MAC address. For example, it is stored in the setting content 15a as the address of the upstream communication device. Then, the unique frame processing unit 12 returns a broadcast response 710 to the upstream control terminal (communication device) 200.
  • Step S120 The control terminal 200 determines that the communication device 100_1 is not “BUSY”, the communication device
  • An upgrade start instruction 720 for checking the version number of the software is transmitted to 100_1, and the unique frame processing unit 12 receives this.
  • FIG. 7 shows a version upgrade start instruction 720.
  • FIG. 8 shows a version number check result response 730.
  • the program file is divided into a plurality of program data, and a program data frame 740 including each program data is sequentially transmitted to the communication device 100_1.
  • the division size of the program data may be, for example, “64 kb”. It can be arbitrarily determined according to the device or line.
  • FIG. 9 shows a program data frame 740.
  • Step S150 The unique frame processing unit 12 sequentially stores the received program data frame 740 in the reception frame storage area 13a in the volatile memory 13 or the reception frame storage area 14a in the nonvolatile memory 14.
  • This storage may store the entire program data frame as it is, or the present invention in which only the program data in the program data frame may be stored does not define the storage method.
  • a method for storing the entire program data frame as it is will be described later with reference to FIG.
  • the communication device 100_1 when stored in the received frame storage area 14a in the non-volatile memory 14, the communication device 100_1 does not lose the program data due to the communication device 100-1 being interrupted or the like. It is only necessary to request retransmission from the control terminal 200.
  • Steps S160. S170 When all program data frames are received, the unique frame processing unit 12 updates the program backup area 14b with all program data (program files) stored in the received frame storage area 13a. The program in this program backup area 14b is switched to the operation program. This completes the version upgrade.
  • Step S180 In the communication device lOOx 1 (see FIG. 2), the unique frame processing unit 12 transmits a version up end notification 750 to the control terminal (upstream communication device) 200.
  • Master One communication device 100y_l (see FIG. 3) transmits a version upgrade end notification 750 in step S300 described later.
  • FIG. 10 shows a version upgrade end notification 750.
  • Step S300 This step particularly shows the operation when the communication device 100_1 is the master communication device 100y_l (see FIG. 3).
  • the communication device 100x_l (see Fig. 2) does not jump and execute this step S300.
  • the unique frame processing unit 12 transmits the upgrade completion notification 750 to the control terminal 200y (see FIG. 3) when all the downstream communication devices ⁇ have been upgraded.
  • All the master communication devices 100y_l-100y_4 are registered in the control terminal 200y, and only when the upgrade completion notification 750 is received from all the master communication devices 100y_l-100y_4, all the communication devices 100y, ⁇ It is possible to know that the upgrade has been completed.
  • FIG. 11 is a flowchart (1) showing the above step S300 in more detail. Details of step S300 will be described below with reference to FIG.
  • 100x_l ends the version upgrade of its own device. Since the communication device 100x_l is not the “master”, the communication device 100x_l proceeds to step S370, ends this processing sequence, and returns to the upstream communication device sequence. Since the master communication device 100y_l is the “master” and there are communication devices 100x_8 and 100x_9 managed by the own device downstream, the process proceeds to step S330.
  • Step S330 Master communication device ⁇ 1! / Next, the unique frame processing unit 12 waits for the upgrade completion notification 750 from the downstream communication device ⁇ and waits for a certain period of time until all downstream. If the communication device power upgrade end notification 750 is not received, the control terminal After sending a notice of occurrence of abnormality at the end 200y, return to normal normal operation (step S370).
  • the control terminal 200y When receiving the upgrade completion notification 750 from all the master communication devices 100y_l-100y_4, the control terminal 200y knows that the upgrade of all the communication devices 100y and ⁇ has been completed.
  • Steps S210 to S280 in FIG. 4 show a procedure in which the upstream communication devices 100y and 100x transmit the program file (all program data) to the downstream communication devices 100y and ⁇ .
  • This procedure is the same as the operation of the control terminal 200 described in steps S110 to S180.
  • the upstream communication device is the master communication device 100y_2 (see FIG. 3)
  • the downstream communication devices are the communication devices 100x_8, 100x_9 (hereinafter collectively referred to as the symbol ⁇ ), and the communication device 100y_3. To do.
  • Steps S100 and S210 In the master communication device ⁇ 2, the unique frame processing unit 12 receives the upgrade broadcast frame 700 (see FIG. 5) from the upstream master communication device 100y_l. Then, the unique frame processing unit 12 transmits an upgrade broadcast frame 700 for searching for a downstream communication device.
  • Steps S220—S240 In the master communication device 100v2, the unique frame processing unit 12 receives the other communication device 100y, the ⁇ force broadcast response 710 (see FIG. 6), and includes Stores downstream communication device lOOx, 100y_3. Then, the unique frame processing unit 12 sends a No. 1 update (version number check) command 720 (see FIG. 7) to the communication device lOOx, 100y_3, and the version number check result response 730 (see FIG. 7). 8) is received from communication device lOOx, 100y_3.
  • S190 The unique frame processing unit 12 transmits all program data frames 740 (see FIG. 8) to the communication device lOOx, 100y_3 that needs to be upgraded, and then transmits the communication device lOOx, 100y_3 force Upgrade completion notification 750 (see Fig. 9) is received, the processing sequence is terminated, and normal operation is restored.
  • master communication devices 100y_3 and 100y_4 respectively transmit all program data frames 740 and the like to downstream communication devices and receive upgrade completion notification 750. This makes it possible to complete the upgrade of all communication devices 100y and ⁇ .
  • FIG. 12 shows, in FIG. 2, a bar graph from the time at which each communication device 100x (reference numerals 100x_l to 100x_ll) starts the version-up operation to the time (seconds) to end. .
  • each communication device ⁇ has started version upgrade almost simultaneously with the start of the upgrade of the upstream communication device ⁇ (before the end of version upgrade), so all communication devices 100y, ⁇ Version Upgrade Time Power Compared with the conventional version up method, it is significantly shortened.
  • FIG. 13 particularly shows the nonvolatile memory 14 of the communication devices 100y and 100x shown in FIG. 1 in more detail.
  • the nonvolatile memory 14 includes areas 20_1-20_n for storing the program data frame 740 in units of frames.
  • the unique frame processing unit 12 can recognize the total number of frames from the data stored in the total number of frames area 740g when one program data frame 740 arrives. Therefore, even when the unique frame processing unit 12 receives the program data frame 740 with the number n-1 by skipping (see FIG. 13), for example, the delayed frame data is received (for example, a delayed frame). Until it is received).
  • the unique frame processing unit 12 does not delete the received program data even if the system goes down for some reason during program data transfer or the connection between the upstream communication devices is disconnected. The data may be kept as it is, and when the connection with the upstream communication device is established, the program data may be received on the way again. In addition, when the unique frame processing unit 12 re-receives a frame of the same number that has been received, the unique frame processing unit 12 discards the frame unconditionally.
  • the unique frame processing unit 12 uses the signature stored in the data 740h of the last frame 740 to ensure that all program data (software information) is not corrupted. Confirm. When data corruption occurs
  • the unique frame processing unit 12 re-replies with the version number check result response 730 (see FIG. 8) and receives all the program data frames 740.
  • FIG. 1 is a block diagram showing a configuration example of a communication apparatus according to the present invention.
  • FIG. 2 is a block diagram showing an embodiment (1) of version upgrade operation in a network configured with communication apparatuses according to the present invention.
  • FIG. 3 is a block diagram showing an operation example (2) of version upgrade in a network composed of communication apparatuses according to the present invention.
  • FIG. 4 is a flowchart (1) showing an operation embodiment (2) of the communication apparatus according to the present invention.
  • FIG. 5 is a diagram showing an example of an upgrade broadcast frame transmitted and received by the communication apparatus according to the present invention.
  • FIG. 6 is a diagram showing an example of a broadcast response transmitted and received by the communication device according to the present invention.
  • FIG. 7 is a diagram showing an example of a version upgrade start (version number check) command transmitted and received by the communication apparatus according to the present invention.
  • FIG. 8 is a view showing a version number check result response example transmitted and received by the communication apparatus according to the present invention.
  • FIG. 9 is a diagram showing an example of a program data frame transmitted and received by the communication apparatus according to the present invention.
  • FIG. 10 is a diagram showing an example of a version upgrade end notification transmitted and received by the communication apparatus according to the present invention.
  • FIG. 11 is a flowchart (2) showing an operation embodiment (2) of the communication device according to the present invention.
  • FIG. 12 shows each operation timing of the communication apparatus according to the present invention.
  • FIG. 13 is a block diagram showing in more detail a received frame storage area in the communication apparatus according to the present invention.
  • FIG. 14 is a block diagram showing an example of version upgrade operation (1) in a conventional communication device.
  • FIG. 15 is a block diagram showing an example of version upgrade operation in a conventional communication device (2).
  • Main signal control unit 11 Frame transmission / reception unit, LAN driver
  • Nonvolatile memory 14a Receive frame storage area

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

　複数の装置でネットワークを構成した通信装置に関に関し、全通信装置にプログラムデータを送信する時間を短縮すること、また、プログラムデータの再送時間を短縮する。独自フレーム処理部12が、複数に分割したプログラムデータの各々を含むプログラムデータフレームを順次受信して、該受信したプログラムデータを受信フレーム格納エリア14aに格納すると共に、該プログラムデータフレームを下流の通信装置に順次転送する。

Description

通信装置
技術分野
[0001] 本発明は通信装置に関し、特に、複数の装置でネットワークを構成した通信装置に 関するものである。
[0002] 近年、通信技術の発達に伴い、各通信装置が搭載している自装置監視 ·制御用ソ トワークを経由して各通信装置に送信されるようになって来ている。このような場合に おいては、全通信装置にプログラムデータを送信するための全時間を短くすることは 、通信装置が多くなるほど重要である。
背景技術
[0003] 図 14は、従来の通信装置 100a_l— 100a_7(以後、符号 100aで総称することがある。 ) のバージョンアップ動作例 (1)を示している。これらの通信装置 100aは、制御端末 200a と共にネットワークを構成しており、各通信装置 100aは、制御端末 200aに主信号用の 回線 (図示せず。）とは別に制御回線 300で接続されている。
[0004] 制御端末 200aの監視者が、プログラムデータを含むバージョンアップ開始命令 800 を制御回線 300を経由して各通信装置 100aに順次与えることにより、各通信装置 100a はバージョンアップされる。
[0005] 図 15は、バージョンアップ動作例 (2)を示しており、従来の通信装置 100b_l—
100b_7 (以後、符号 100bで総称することがある。）及び制御端末 200bは、ネットワークを 構成している。各通信装置 100b及び制御端末 200bは、主信号回線で接続されており 、この回線内で、制御信号 (例えば、バージョンアップ開始命令 800)は送受信されて いる。以下に、このバージョンアップ動作例 (2)の手順を説明する。
[0006] ステップ S400：制御端末 200bの 視者が、プログラムデータを含むバージョンアップ 開始命令 800を主信号回線経由で通信装置 100b_lに与える。
[0007] ステップ S410 :诵信装置 100b 1は、受信したプログラムデータに基づき自装置のバ 一ジョンアップを実行する。 [0008] ステップ S420 :诵信装置 100b 1は、バージョンアップ終了後、プログラムデータを含 むバージョンアップ開始命令 800を主信号回線経由で通信装置 100b_2に与える。
[0009] ステップ S420. S430 :ステップ S410及びステップ S420と同様に、通信装置 100b_2は、 受信したプログラムデータに基づき自装置のバージョンアップを実行し、その後、ノ 一ジョンアップ開始命令 800を通信装置 100b_3に与える。
[0010] ステップ S440' " :以後、同様にして通信装置 100b_3— 100b_7は、バージョンアップを 実行する。
[0011] 通信装置 (印刷装置)のバージョンアップ動作例 (3)として、ネットワークを経由して接 続された複数の通信装置にお 、て、各通信装置がネットワーク上に自分自身と同じ プログラムで動作する同一モデルの通信装置を検索し、検索した通信装置のプログ ラムのバージョン情報を取得し、その取得したプログラムの版数と自分自身のプログ ラムの版数の新旧を比較して、自分自身のプログラムの版数より新し 、ものである場 合、その通信装置力 プログラムをダウンロードして自身のプログラムを更新するもの がある (例えば、特許文献 1参照。 ) o
特許文献 1：特開 2000-215034号
発明の開示
発明が解決しょうとする課題
[0012] 上述したバージョンアップ動作例 (1)においては、制御端末 200aの監視者は、通信 装置 100a毎にバージョンアップ開始命令 800を与える必要がある。このために、人為 的なミス (例えば、バージョンアップ忘れ)が発生する可能性があった。また、全通信装 置 100aのバージョンアップ終了を確認するために、全通信装置を 1台づっ読み出し てその状態を確認する手間が必要であった。
[0013] また、バージョンアップ動作例 (2)にお 、ては、ネットワークの規模や通信装置数が 多いほど、全通信装置 100bのバージョンアップ終了までの時間は長くなる恐れがあり 、その時間が明確でない。
[0014] 同様に、バージョンアップ動作例 (3)にお 、ても、最新バージョンのプログラムで動 作する通信装置から、そのプログラムを他の通信装置が、 1台ずつ順次取得してバ 一ジョンアップする方法であって、全通信装置が同時にバージョンアップする方法で ない。したがって、ネットワークの規模や通信装置数が多いほど、全通信装置のバー ジョンアップ終了までの時間は長くなる。
[0015] すなわち、動作例 (1)一 (3)ともに、ネットワークの環境が大きくなればなるほど、また 通信装置数が多くなればなるほど、全通信装置のバージョンアップ終了までの時間 が長くなつてしまう。これに伴って、最初の通信装置のバージョンアップ終了時間と最 後の通信装置のバージョンアップ終了時間との差が大きくなり、一時的に異なったバ 一ジョンの通信装置が動作する。また、ソフトウェアのバージョンアップ中に、例えば、 通信装置の再開が発生した場合、最初力 プログラムデータを転送してバージョンァ ップを開始する必要があった。
[0016] 従って本発明は、複数の装置でネットワークを構成した通信装置において、全通信 装置にプログラムデータを送信する時間を短縮すること、また、プログラムデータの再 送時間を短縮することを課題とする。
課題を解決するための手段
[0017] 上記の課題を解決するため、本発明に係る通信装置は、受信フレーム格納エリアと 、複数に分割したプログラムデータの各々を含むプログラムデータフレームを順次受 信し、該受信したプログラムデータを受信フレーム格納エリアに格納すると共に、該 プログラムデータフレームを下流の通信装置に順次転送する独自フレーム処理部と を備えたことを特徴として！/ヽる。
[0018] すなわち、プログラムデータ (プログラムファイル)は複数のプログラムデータに分割さ れ、分割された各プログラムデータは各プログラムデータフレームに含まれている。独 自フレーム処理部は、プログラムデータフレームを順次受信し、受信したプログラムデ ータを受信フレーム格納エリアに格納する。独自フレーム処理部は、プログラムデー タに対応した全プログラムデータフレームを受信する前に、各プログラムデータフレー ムを下流の通信装置に順次送信する。なお、受信フレーム格納エリアにプログラムデ ータを格納する方式は、プログラムデータのみを格納してもよいし、プログラムデータ フレーム全体を格納してもよ 、。
[0019] これにより、通信装置は、受信フレーム格納エリアに全プログラムデータ (プログラム ファイル)を格納することが可能になるとともに、全プログラムデータフレームを受信す る前 (例えば、各プログラムデータフレームを受信する毎)に、下流の通信装置 (下流 の通信装置がある場合)にプログラムデータフレームを転送することが可能になる。こ の結果、複数の通信装置 (上流通信装置及びその下流通信装置)は、ほぼ同時に全 プログラムデータ (プログラムファイル)を受信することが可能になる。
[0020] また、本発明は、上記の本発明にお 、て、該独自フレーム処理部は、該受信したプ ログラムフレームを、全プログラムデータフレームを受信する前に該下流の通信装置 に送信することが可能である。
[0021] また、本発明は、上記の本発明において、該受信フレーム格納エリア力 該プログ ラムデータフレーム単位でプログラムデータを格納し、該独自フレーム処理部が、該 受信フレーム格納エリアに格納されて!、な!/、欠落したプログラムデータを上流の通信 装置又は制御端末に要求することが可能である。
[0022] すなわち、受信フレーム格納エリア力 プログラムデータフレーム単位、すなわち、 プログラムデータフレーム全体で、プログラムデータを格納している。独自フレーム処 理部は、例えば、受信できな力つたプログラムデータフレームを、上流の通信装置又 は制御端末に要求する。これにより、例えば、 1つのプログラムデータフレームの受信 エラーのために、全プログラムデータフレームの再送を要求する必要がなる。
[0023] また、本発明は、上記の本発明において、該独自フレーム処理部は、該プログラム データの分割単位を変更することが可能である。これにより、通信装置、及び通信回 線等に対応した適切な分割単位でプログラムデータを送信することが可能になる。
[0024] また、本発明は、上記の本発明にお 、て、該受信したプログラムデータで自通信装 置のバージョンアップを行う制御部をさらに備えたことが可能である。すなわち、プロ グラムデータは、通信装置のバージョンアップ用のプログラムデータであり、このプロ グラムデータで制御部は、自通信装置のバージョンアップを行うことが可能である。
[0025] また、本発明は、上記の本発明において、該独自フレーム処理部が、 自装置のバ 一ジョンアップが終了したとき、上流の通信装置又は制御端末にバージョンアップ終 了通知を送信することが可能である。これにより、上流の通信装置又は制御端末は、 下流の通信装置のバージョンアップ終了を知ることが可能になる。
[0026] また、本発明は、上記の本発明において、該独自フレーム処理部が、 自装置が管 理する下流の全通信装置力もバージョンアップ終了通知を受信したとき、上流の通 信装置又は制御端末にバージョンアップ終了通知を送信することが可能である。これ により、上流の通信装置又は制御端末は、全てのバージョンアップを必要とする通信 装置力 バージョンアップ終了通知を受信することなぐ特定の通信装置 (下流の通 信装置を管理する通信装置、以後、この通信装置をマスター通信装置と称すること がある。）の全てからのバージョンアップ終了通知のみで全通信装置のバージョンアツ プが完了したことを知ることが可能になる。
[0027] また、本発明は、上記の本発明において、該独自フレーム処理部が、上流の通信 装置から該プログラムデータのバージョンを受信し、 自装置のプログラムデータのバ 一ジョンより新しいバージョンのプログラムデータを含むプログラムデータファイルの みを受信することが可能である。これにより、通信装置は、最新のプログラムデータの みを受信することが可能になる。
[0028] また、本発明は、上記の本発明において、該受信フレーム格納エリアを不揮発メモ リに設定することが可能である。これにより、例えば、プログラムデータ転送中に何ら かの理由でシステムダウンした場合、上流通信装置との接続が確立したとき再度途 中からのプログラムデータを受信することが可能になる。
[0029] さらに、本発明は、上記の本発明において、該プログラムデータフレームに該プロ グラムデータ順が対応付けることができる。これにより、プログラムデータの転送順序 が反転しても正規の順序に直すことが可能になる。
発明の効果
[0030] 以上説明したように、本発明に係る通信装置によれば、全通信装置にプログラムデ ータをほぼ同時に送信することになり、全通信装置にプログラムデータを送信する時 間を短縮することが可能になる。したがって、全通信装置のバージョンアップをほぼ 同時に行うことが可能になる。また、通信装置にプログラムデータを送信する制御端 末は、 1台の通信装置にプログラムデータ等を送信するだけで、全通信装置のバー ジョンアップが可能になる。また、バージョンアップ作業中に電源断等で中断され、バ 一ジョンアップ作業が再開された場合においても、中断時間以外のロス時間が無くな る。また、制御端末は、マスター通信装置の管理のみでよくなり、バージョンアップ管 理が容易になる。
発明を実施するための最良の形態
[0031] m^, m
図 1は、本発明に係る通信装置 lOOx(lOOy)の構成実施例を示している。この通信装 置 ΙΟΟχは、主信号制御部 10、フレーム送受信部 (LANドライバ) 11、独自フレーム処理 部 12、揮発性メモリ 13、不揮発性メモリ 14, 15を備えている。揮発性メモリ 13は、受信 フレーム格納エリア 13a及び装置制御プログラム 13bを備えている。不揮発性メモリ 14 は，受信フレーム格納エリア 13a及びバックアッププログラム 14bを備え、不揮発性メモ リ 15は、設定内容 15aを備えている。
[0032] 動作 ¾施例 (1)及び (2)
図 2は、本発明に係る通信装置 100x(符号 100x_l— 100x_llの総称。）及び制御端末 200xを備えたネットワークにおけるバージョンアップ動作実施例 (1)を示して 、る。この ネットワークでは、制御端末 200x、及び通信装置 100x_l— 100x_4が縦列接続されて おり、各通信装置 100x_2— 100x_4には、それぞれ、通信装置 100x_8及び 100x_9、通 信装置 100x_5, 100x_10,及び 100x_ll、並びに通信装置 100x_6及び 100x_7が接続さ れている。
[0033] 図 3は、バージョンアップ動作実施例 (2)を示しており、この実施例 (2)では、図 2に示 したネットワークにおいて、通信装置 100x_l— 100x_4及び制御端末 200xの代わりにマ スター通信装置 100y_l— 100y_4 (以後、符号 100yで総称することがある。）及び制御端 末 200yが接続されている。マスター通信装置 100y_l— 100y_4は、通信装置 100x_l— 100x_4と異なり自装置がマスターであることが、例えば、設定内容 15a (図 1参照。）に 設定されている。また、制御端末 200yには、制御端末 200xと異なりマスター通信装置 100y_l— 100y_4が登録されている。
[0034] 実施例 (1)のバージョンアップ動作と実施例 (2)のバージョンアップ動作は、マスター 通信装置 100y_l— 100y_4及び制御端末 200yのみの動作が通信装置 100x_l— 100x_4 及び制御端末 200xの動作と異なるので、実施例 (2)の動作を基本として、実施例 (1)の 動作を共に以下に説明する。
[0035] 図 4は、実施例 (2)の動作手順を示したフローチャート図 (1)である。図 5—図 10は、 制御端末 200y, 200x(以後、符号 200で総称することがある。）と通信装置 lOOx, lOOyと の間、及び上流の通信装置 lOOx, 100yと下流の通信装置 lOOx, 100yとの間で送受 信されるフレームを示している。なお、図 5—図 10中の説明は、特に、上流の通信装 置 100x_lと下流の通信装置 100x_2との間で送受信されるフレームを示している。
[0036] 図 4一図 10を参照して、実施例 (1)及び (2)の動作手順を以下に説明する。
[0037] まず、図 4において、通信装置 100y_l, 100x_l (以後、符号 100_1で総称することがあ る。）の動作手順例を以下に説明する。制御端末 200(通信装置 100_1の上流の通信 装置)は、従来通り、各通信装置 100y, lOOxの監視 ·制御を行っており、全通信装置 100y, lOOxは、主信号回線内に流れる制御信号によって制御端末 200と通信可能で ある。制御端末 200は、バージョンアップすべきプログラムデータ (プログラムファイル） を前もって格納している。また、制御端末 200及び通信装置 100y, lOOxには、それぞ れ、 MACアドレスを設定されている。これにより、レイヤ 2レベルの通信が可能な状態 となる (主信号回線があれば良 、)。
[0038] ステップ S100：制御端末 200は、隣接する通信装置 lOOx, 100yを探すためにバージョ ンアップブロードキャストフレーム 700を送出する。
[0039] 図 5は、バージョンアップブロードキャストフレーム 700を示している。このフレーム 700は、フレームタイプ 700a = "ブロードキャスト"、送信元 MACアドレス 700b = "制御 端末 200の MACアドレス"、送信先 MACアドレス 700c = "FF- FF- FF- FF- FF- FF (全通 信装置指定)"、オペレーションタイプ 700d = "バージョンアップ"、フレームサイズ 700e 、フレーム番号 700f= "0"、全フレーム数 700g= "0"、及びデータ 700h= "無じ，で構 成されている。
[0040] ステップ S110 :诵信装置 100 1において、独自フレーム処理部 12は、フレーム 700を、 フレーム送受信部 11を経由して受信して、バージョンアップの開始を知ると共に、送 信元 MACアドレスを上流通信装置のアドレスとして、例えば、設定内容 15aに記憶す る。そして、独自フレーム処理部 12は、上流の制御端末 (通信装置) 200にブロードキ ャスト応答 710を返信する。
[0041] 図 6は、ブロードキャスト応答 710を示しており、このブロードキャスト応答 710は、フレ ームタイプ 710a = "ブロードキャスト応答"、送信元 MACアドレス 710b = "通信装置 100—1の MACアドレス，，、送信先 MACアドレス 710c = "制御端末 200の MACアドレス，，、 オペレーションタイプ 710d= "正常動作（自装置 = "BUSY"の場合、 "BUSY") "、フレ ームサイズ 710e、フレーム番号 710f= "0"、全フレーム数 710g = "0"、及びデータ 710h = "無し"で構成されて!、る。
[0042] ステップ S120：制御端末 200は、通信装置 100_1が" BUSY"でない場合、通信装置
100_1に対して、そのソフトウェアの版数をチェックするためのバージョンアップ開始命 令 720を送信し、これを独自フレーム処理部 12が受信する。
[0043] 図 7は、バージョンアップ開始命令 720を示している。このバージョンアップ開始命令 720は、フレームタイプ 720a= "データフレーム"、送信元 MACアドレス 720b = "制御 端末 200の MACアドレス"、送信先 MACアドレス 720c= "通信装置 100_1の MACァドレ ス"、オペレーションタイプ 720d = "版数チェック"、フレームサイズ 720e、フレーム番号 720f= "l'\全フレーム数 720g='T，、及びデータ 720h= "01- 02- 03(版数)"で構成さ れている。
[0044] ステップ S130 :バージョンアップ開始命合 720を^信した诵信装置 100 1の独自フレ ーム処理部 12は、この命令 720に含まれる版数 = "01-02-03"と、例えば、自装置の 装置制御プログラム 13b又はバックアッププログラムの 14bの"版数"を比較してその結 果を示す版数チェック結果応答 730を制御端末 200に返信する。
[0045] 図 8は、版数チェック結果応答 730を示して ヽる。この版数チェック結果応答 730は、 フレームタイプ 730a= "データフレーム"、送信元 MACアドレス 730b = "通信装置 100—1の MACアドレス，，、送信先 MACアドレス 730c = "制御端末 200の MACアドレス，，、 オペレーションタイプ 730d= "版数チェック結果"、フレームサイズ 730e、フレーム番号 730f='T，、全フレーム数 730g='T，、及びデータ 730h= "バージョンアップの必要あ り〃よし、動作中の版数 = "01- 01- 05"で構成されている。
[0046] ステップ S140：この版数チェック結果応答 730を受信した制御端末 200は、バージョン アップ = "必要あり"の場合、版数 = "01-01-05"のソフトウェアに対応したバージョン アップ用のプログラムファイルを複数のプログラムデータに分割し、各プログラムデー タを含むプログラムデータフレーム 740を順次、通信装置 100_1に送信する。なお、プ ログラムデータの分割サイズを、例えば、 "64kb"してもよいが、このサイズは、通信装 置や回線等に適合して任意に決定することが可能である。
[0047] 図 9は、プログラムデータフレーム 740を示している。このプログラムデータフレーム 740は、フレームタイプ 740a= "データフレーム"、送信元 MACアドレス 740b = "制御 端末 200の MACアドレス"、送信先 MACアドレス 740c= "通信装置 100_1の MACァドレ ス"、オペレーションタイプ 740d = "プログラムデータ転送"、フレームサイズ 740e = " 128バイド，、フレーム番号 740f= "23(この例では、バージョンアップ開始命令用フレー ム 720を含めて 23番目の送信されたプログラムデータフレーム 740であることを示して いる。）"、全フレーム数 740g= "35293"、及びデータ 740h= "22番目のプログラムデ ータ、なお、第 35293目の最後のプログラムデータの後には、 "終了コード"ど'シグネ チヤ (CRC32等)"が挿入される"で構成されている。
[0048] 独自フレーム処理部 12は、フレーム送受信部 11を経由して、フレーム番号 740f= "2 "一" 35293"のプログラムデータフレーム 740を順次受信する。
[0049] ステップ S150 :独自フレーム処理部 12は、受信したプログラムデータフレーム 740を 揮発性メモリ 13内の受信フレーム格納エリア 13a又は不揮発性メモリ 14内の受信フレ ーム格納エリア 14aに順次格納する。なお、この格納は、プログラムデータフレーム全 体をそのまま格納してもよいし、プログラムデータフレームの内のプログラムデータの みを格納してもよぐ本発明では、その格納方式を規定しない。プログラムデータフレ ーム全体をそのまま格納する方式は、後述する図 13で説明する。また、不揮発性メモ リ 14内の受信フレーム格納エリア 14aに格納した場合、通信装置 100— 1が中断等によ つてプログラムデータが消失することが無ぐ通信装置 100_1は、中断されたプロダラ ムデータの再送を制御端末 200に要求するだけでよい。
[0050] ステップ S160. S170：全プログラムデータフレームを受信した場合、独自フレーム処 理部 12は、受信フレーム格納エリア 13aに格納された全プログラムデータ (プログラム ファイル)でプログラムバックアップエリア 14bを更新した後、このプログラムバックアツ プエリア 14bのプログラムを動作プログラムに切り替える。これにより、バージョンアップ は終了する。
[0051] ステップ S180 :诵信装置 lOOx 1(図 2参照 )において、独自フレーム処理部 12は、バ 一ジョンアップ終了通知 750を制御端末 (上流通信装置) 200に送信する。なお、マスタ 一通信装置 100y_l(図 3参照。）は、後述するステップ S300でバージョンアップ終了通 知 750を送信する。
[0052] 図 10は、バージョンアップ終了通知 750を示している。このバージョンアップ終了通 知 750は、フレームタイプ 750a = "データフレーム"、送信元 MACアドレス 750b = "通 信装置 100— 1の MACアドレス"、送信先 MACアドレス 750c = "制御端末 200の MACアド レス"、オペレーションタイプ 750d = "バージョンアップ終了"、フレームサイズ 750e、フ レーム番号 750f='T，、全フレーム数 750g = 'T，、及びデータ 750h = "版数 = 01- 02- 03"で構成されて!ヽる。
[0053] このバージョンアップ終了通知 750を受信した制御端末 200は、通信装置 100_1が版 数 = "01-02-03"のプログラムファイルのバージョンアップが終了したことを認識する。
[0054] ステップ S300：このステップは、特に、通信装置 100_1がマスター通信装置 100y_l (図 3参照。）である場合の動作を示している。通信装置 100x_l(図 2参照。）は、このステツ プ S300をジャンプして実行しない。マスター通信装置 100y_lにおいて、独自フレーム 処理部 12は、全下流の通信装置 ΙΟΟχがバージョンアップ終了した場合、バージョン アップ終了通知 750を制御端末 200y (図 3参照。）に送信する。
[0055] 制御端末 200yには、全マスター通信装置 100y_l— 100y_4が登録されており、全マス ター通信装置 100y_l— 100y_4からバージョンアップ終了通知 750を受信したことのみ で、全通信装置 100y, ΙΟΟχのバージョンアップ終了したことを知ることが可能である。
[0056] 図 11は、上記のステップ S300をより詳細に示したフローチャート図 (1)である。以下に 、同図を参照してステップ S300の詳細を説明する。
[0057] ステップ S300— S320：マスター诵信装置 100v 1. 100x_lは、自装置のバージョンアツ プを終了する。通信装置 100x_lは、 自装置が"マスター"でないので、ステップ S370に 進みこの処理シーケンスを終了して上流の通信装置のシーケンスに戻る。マスター 通信装置 100y_lは、自装置が"マスター"であり、下流に自装置が管理する通信装置 100x_8, 100x_9が存在するのでステップ S330に進む。
[0058] ステップ S330：マスター诵信装置 ΙΟΟν 1にお!/ヽて、独自フレーム処理部 12は、下流 通信装置 ΙΟΟχからのバージョンアップ終了通知 750を待ち、一定時間を経過後まで に、全下流の通信装置力 バージョンアップ終了通知 750を受信しない場合、制御端 末 200yに異常発生通知を送出した後、通常の正常運転 (ステップ S370)に戻る。
[0059] ステップ S340— S370 :独自フレーム処理部 12は、下流の全通信装置 100xからのバー ジョンアップ終了通知 750を受信した場合、マスター通信装置 100yのバージョンアツ プ終了通知 750を制御端末 200yに送信する。その後、独自フレーム処理部 12は、上 流通信装置のシーケンスに戻る (図 4参照。；)。
[0060] 制御端末 200yには、全マスター通信装置 100y_l— 100y_4からバージョンアップ終了 通知 750を受信したとき、全通信装置 100y, ΙΟΟχのバージョンアップ終了したことを知 る。
[0061] 図 4のステップ S210— S280は、上流の通信装置 100y, 100xが下流の通信装置 100y , ΙΟΟχにプログラムファイル (全プログラムデータ)を送信する手順を示している。この 手順は、ステップ S110— S180で説明した制御端末 200の動作と同様である。以下に、 上流通信装置がマスター通信装置 100y_2(図 3参照。）であり、その下流通信装置が 通信装置 100x_8, 100x_9 (以後、符号 ΙΟΟχで総称する。 ),及び通信装置 100y_3である 場合について説明する。
[0062] ステップ S100. S210 :マスター诵信装置 ΙΟΟν 2において、独自フレーム処理部 12は、 上流のマスター通信装置 100y_lからバージョンアップブロードキャストフレーム 700(図 5参照。）を受信する。そして、独自フレーム処理部 12は、下流通信装置を検索するた めのバージョンアップブロードキャストフレーム 700を送信する。
[0063] ステップ S220— S240：マスター诵信装置 100v 2にお ヽて、独自フレーム処理部 12は 、他の通信装置 100y, ΙΟΟχ力 ブロードキャスト応答 710(図 6参照。）を受信し、その 内の下流通信装置 lOOx, 100y_3を記憶する。そして、独自フレーム処理部 12は、ノ 一ジョンアップ開始 (版数チェック)命令 720(図 7参照。）を通信装置 lOOx, 100y_3に送 信し、その応答である版数チェック結果応答 730(図 8参照。）を通信装置 lOOx, 100y_3 から受信する。
[0064] ステップ S250— S280. S190 :独自フレーム処理部 12は、バージョンアップが必要であ る通信装置 lOOx, 100y_3に全プログラムデータフレーム 740(図 8参照。）を送信した後 、通信装置 lOOx, 100y_3力 バージョンアップ終了通知 750(図 9参照。）を受信し、処 理シーケンスを終了して、正常動作に戻る。 [0065] 同様に、マスター通信装置 100y_3, 100y_4は、それぞれ、下流の通信装置に全プロ グラムデータフレーム 740等を送信してバージョンアップ終了通知 750を受信する。こ れにより、全通信装置 100y, ΙΟΟχのバージョンアップを完了させることが可能になる。
[0066] 図 12は、図 2において、各通信装置 100x(符号 100x_lから 100x_llの総称。）が、バー ジョンアップ動作を開始する時間から終了する時間 (秒)までを棒線グラフで示してい る。この棒線グラフによれば、各通信装置 ΙΟΟχは、その上流の通信装置 ΙΟΟχのバー ジョンアップ開始とほぼ同時 (バージョンアップの終了前)にバージョンアップを開始し ているので、全通信装置 100y, ΙΟΟχのバージョンアップ時間力 従来のバージョンァ ップ方式と比較して大幅に短縮されている。
[0067] 図 13は、特に、図 1に示した通信装置 100y, 100xの不揮発性メモリ 14をより詳細に 示している。不揮発性メモリ 14は、プログラムデータフレーム 740をフレーム単位で格 納する領域 20_1— 20_nを備えている。独自フレーム処理部 12は、 1つのプログラムデ 一タフレーム 740が届けばその全フレーム数領域 740gに格納されたデータで全フレ 一ム数を認識できる。そこで、独自フレーム処理部 12は、例えば、番号 n-1のプロダラ ムデータフレーム 740を飛ばして受信した場合においても (図 13参照。；)、それが揃うま で (例えば、遅れて来たフレームを受信するまで)、格納し続けるようにしてもよい。
[0068] また、独自フレーム処理部 12は、プログラムデータ転送中に何らかの理由でシステ ムダウンした場合や、上流通信装置間の接続が切れた場合でも、受信したプログラム データを削除することなぐ受信したプログラムデータをそのまま確保し続け、上流通 信装置との接続が確立したとき再度途中力 のプログラムデータを受信し続けるよう にしてもよい。また、独自フレーム処理部 12は、受信済みの同一番号のフレームを再 受信したときは、そのフレームを無条件で破棄する。
[0069] 独自フレーム処理部 12は、全プログラムデータフレーム 740を受信したとき、最後の フレーム 740のデータ 740hに格納されたシグネチヤを用いて、全プログラムデータ (ソ フトウェア情報)にデータ破壊がないことを確認する。データ破壊が発生している場合
、独自フレーム処理部 12は、版数チェック結果応答 730(図 8参照。）を再返信して全プ ログラムデータフレーム 740を受信する。
図面の簡単な説明 [0070] [図 1]本発明に係る通信装置の構成実施例を示したブロック図である。
[図 2]本発明に係る通信装置で構成されたネットワークにおけるバージョンアップ動作 実施例 (1)を示したブロック図である。
[図 3]本発明に係る通信装置で構成されたネットワークにおけるバージョンアップの動 作実施例 (2)を示したブロック図である。
[図 4]本発明に係る通信装置の動作実施例 (2)を示したフローチャート図 (1)である。
[図 5]本発明に係る通信装置が送受信するバージョンアップブロードキャストフレーム 例を示した図である。
[図 6]本発明に係る通信装置が送受信するブロードキャスト応答例を示した図である
[図 7]本発明に係る通信装置が送受信するバージョンアップ開始 (版数チェック)命令 例を示した図である。
[図 8]本発明に係る通信装置が送受信する版数チェック結果応答例を示した図であ る。
[図 9]本発明に係る通信装置が送受信するプログラムデータフレーム例を示した図で ある。
[図 10]本発明に係る通信装置が送受信するバージョンアップ終了通知例を示した図 である。
[図 11]本発明に係る通信装置の動作実施例 (2)を示したフローチャート図 (2)である。
[図 12]本発明に係る通信装置の各動作タイミングを示した図である。
[図 13]本発明に係る通信装置における受信フレーム格納エリアをより詳細に示したブ ロック図である。
[図 14]従来の通信装置におけるバージョンアップ動作例 (1)を示したブロック図である [図 15]従来の通信装置におけるバージョンアップ動作例 (2)を示したブロック図である 符号の説明
[0071] 100a, 100a— 1— 100a— 7, 100b, 100b— 1— 100b— 7, ΙΟΟχ, ΙΟΟχ— 1— ΙΟΟχ— 11, lOOy, 100y— 1— 100y— 4 通信装置
10 主信号制御部 11 フレーム送受信部、 LANドライバ
12 独自フレーム処理部 13 揮発性メモリ
13a 受信フレーム格納エリア 13b 装置制御プログラム
14 不揮発性メモリ 14a 受信フレーム格納エリア
14b バックアッププログラム 15 不揮発性メモリ
15a データベース (設定内容）
20— 1— 20— n フレーム番号 1一番号 n格納エリア
200a, 200b, 200x, 200y 制御端末 300 制御回線
700 バージョンアップブロードキャストフレーム
710 ブロードキャスト応答
720 バージョンアップ開始 (版数チェック)命令
730 版数チェック結果応答 740 プログラムデータフレーム
750 バージョンアップ終了通知 800 開始命令
図中、同一符号は同一又は相当部分を示す。

Claims

請求の範囲
[1] 受信フレーム格納エリアと、
複数に分割したプログラムデータの各々を含むプログラムデータフレームを順次受 信し、該受信したプログラムデータを受信フレーム格納エリアに格納すると共に、該 プログラムデータフレームを下流の通信装置に順次転送する独自フレーム処理部と
を備えたことを特徴とする通信装置。
[2] 請求項 1において、
該独自フレーム処理部が、該受信したプログラムフレームを、全プログラムデータフ レームを受信する前に該下流の通信装置に送信することを特徴とした通信装置。
[3] 請求項 1において、
該受信フレーム格納エリア力 該プログラムデータフレーム単位でプログラムデータ を格納し、
該独自フレーム処理部が、該受信フレーム格納エリアに格納されていない欠落した プログラムデータを上流の通信装置又は制御端末に要求することを特徴とした通信 装置。
[4] 請求項 1において、
該独自フレーム処理部は、該プログラムデータの分割単位を変更することが可能で あることを特徴とした通信装置。
[5] 請求項 1において、
該受信したプログラムデータで自通信装置のバージョンアップを行う制御部をさら に備えたことを特徴とする通信装置。
[6] 請求項 5において、
該独自フレーム処理部が、自装置のバージョンアップが終了したとき、上流の通信 装置又は制御端末にバージョンアップ終了通知を送信することを特徴とした通信装 置。
[7] 請求項 5において、
該独自フレーム処理部が、自装置が管理する下流の全通信装置力 バージョンァ ップ終了通知を受信したとき、上流の通信装置又は制御端末にバージョンアップ終 了通知を送信することを特徴とした通信装置。
[8] 請求項 5において、
該独自フレーム処理部が、上流の通信装置力 該プログラムデータのバージョンを 受信し、 自装置のプログラムデータのバージョンより新し 、バージョンのプログラムデ ータを含むプログラムデータファイルのみを受信することを特徴とした通信装置。
[9] 請求項 1において、
該受信フレーム格納エリアが不揮発メモリに設定されていることを特徴とした通信装 置。
[10] 請求項 1において、
該プログラムデータフレームに該プログラムデータ順が対応付けることを特徴とした 通信装置。
PCT/JP2005/000081 2005-01-06 2005-01-06 通信装置 WO2006072987A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2005/000081 WO2006072987A1 (ja) 2005-01-06 2005-01-06 通信装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2005/000081 WO2006072987A1 (ja) 2005-01-06 2005-01-06 通信装置

Publications (1)

Publication Number Publication Date
WO2006072987A1 true WO2006072987A1 (ja) 2006-07-13

Family

ID=36647475

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2005/000081 WO2006072987A1 (ja) 2005-01-06 2005-01-06 通信装置

Country Status (1)

Country Link
WO (1) WO2006072987A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7788379B2 (en) 2006-08-10 2010-08-31 Fujitsu Limited Network system and information processing method

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07334436A (ja) * 1994-06-06 1995-12-22 Mitsubishi Electric Corp ソフトウエア自動配布方式
JPH10262093A (ja) * 1997-03-19 1998-09-29 Hitachi Ltd 伝送制御方法
JP2000039989A (ja) * 1998-07-23 2000-02-08 Nec Corp プログラムの自動配布システム、プログラムの自動配布方法およびプログラムの自動配布用プログラムを記録した記録媒体
JP2002111720A (ja) * 2000-09-26 2002-04-12 Hitachi Kokusai Electric Inc データ伝送システム

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07334436A (ja) * 1994-06-06 1995-12-22 Mitsubishi Electric Corp ソフトウエア自動配布方式
JPH10262093A (ja) * 1997-03-19 1998-09-29 Hitachi Ltd 伝送制御方法
JP2000039989A (ja) * 1998-07-23 2000-02-08 Nec Corp プログラムの自動配布システム、プログラムの自動配布方法およびプログラムの自動配布用プログラムを記録した記録媒体
JP2002111720A (ja) * 2000-09-26 2002-04-12 Hitachi Kokusai Electric Inc データ伝送システム

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7788379B2 (en) 2006-08-10 2010-08-31 Fujitsu Limited Network system and information processing method

Similar Documents

Publication Publication Date Title
CN105426198B (zh) 车载双控制芯片系统及其辅助控制芯片程序更新方法
US7321936B2 (en) System for and method of streaming data to a computer in a network
US8352624B2 (en) System for and method of streaming data to a computer in a network
EP1087294B1 (en) Method and apparatus of remotely updating firmware of a communication device
WO2017149825A1 (ja) プログラム更新システム、プログラム更新方法及びコンピュータプログラム
CN102089753B (zh) 用于在网络上安全地更新瘦客户机操作系统的系统和方法
US20140053149A1 (en) Fast and automatic deployment method for cluster system
US20010044934A1 (en) Computer and computer readable recording medium on which program is recorded
CN101426077A (zh) 通过Internet在线升级电视机软件的方法
CN112947977B (zh) 一种软件在线升级方法及系统
JP2007122601A (ja) 分離型処理装置及びそのソフトウエアの版更新方法
JP2002152821A (ja) 携帯端末装置のプログラム更新方法および携帯端末装置
US7222342B2 (en) Execution on a machine, the start of an auxiliary downloader when storage of new software memory fails during execution of a first downloader
JP2009020886A (ja) Ｏｔａプログラミングのためのシステム及び方法
JP3612043B2 (ja) 執行中のプログラムファイルをアップデートすることができるシステムおよびその方法
WO2006072987A1 (ja) 通信装置
CN116382753A (zh) 一种基于网络的设备固件高可靠性远程升级方法
CA2482617C (en) System for and method of streaming data to a computer in a network
JP2003263323A (ja) ダウンロード装置及びダウンロード方法
KR20090041060A (ko) 자가 복구가 가능한 ｉｐｔｖ 시스템 및 이를 이용한 자가복구 방법
JP2003228490A (ja) ネットワークに接続される端末装置およびこれを用いたネットワークシステム
JP2003309485A (ja) ソフトウェア更新装置及びソフトウェア更新方法
JP2004157753A (ja) ファームウェアダウンロードシステム
JP4862346B2 (ja) ダウンロードシステム及びプログラム
JP2004157767A (ja) ソフトウェア更新システム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 05703349

Country of ref document: EP

Kind code of ref document: A1

WWW Wipo information: withdrawn in national office

Ref document number: 5703349

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP