Patent Description:
A communication apparatus(device) generally includes a processor, a nonvolatile memory, a volatile memory, and the like. The nonvolatile memory stores in advance firmware, which is a program for implementing communication functions and the like in the communication apparatus. Upon activation of the communication apparatus, the firmware stored in the nonvolatile memory is deployed on the volatile memory. Then, by executing the firmware deployed on the volatile memory, the communication functions and the like are implemented in the communication apparatus. This provides desired communication service.

To add a new function or fix a bug in the communication apparatus that provides a communication service, it is necessary to update the firmware which is executed. To update the firmware, it is common to temporarily stop the firmware which has been deployed on the volatile memory and is being executed. Thereafter, the firmware stored in the nonvolatile memory is rewritten, and the communication apparatus is reactivated. Accordingly, the updated firmware which is stored in the nonvolatile memory is deployed on the reset volatile memory and executed due to the reactivation (e.g., Non Patent Literature <NUM>). <CIT> relates to a communication processing device and provides an optical access device capable of performing a firmware update without causing a communication interruption. The article "<NPL>, discloses a way of applying dynamic software updating to optical line terminals without service interruption. <CIT> relates to an embedded device and a program updating method performing updating using a differential program. <CIT> relates to techniques for updating and/or replacing program code dynamically, i.e. whilst the program is executing.

Because the communication functions cannot be utilized during the reactivation of the communication apparatus, the provision of the communication service is temporarily interrupted. Thus, the firmware update greatly affects a user of the communication service. However, if the firmware deployed on the volatile memory is rewritten directly without stopping the firmware being executed, the firmware may be rewritten incompletely. Firmware incompletely rewritten may possibly generate segmentation errors or memory errors or generate fatal failures for hardware in operation. Therefore, it has been known that it is difficult to update the firmware without interrupting the provision of the communication service.

For example, an optical line terminal (OLT), which is a communication apparatus at a station used in an optical access network, also has the above-described problem. It has been known that it is difficult to update firmware without interrupting a communication service in the OLT. As described above, firmware stored in a nonvolatile memory of the OLT is also deployed on a volatile memory and executed upon activation of the OLT. To update the firmware, by rewriting the firmware in the nonvolatile memory, the updated firmware is deployed on the volatile memory from the next activation.

For known techniques to make firmware update less affect an apparatus that requires reactivation after the firmware update, techniques to reduce update time of the firmware have been studied. For example, by storing in advance the firmware after the update in a nonvolatile memory, two types of firmware, the firmware before the update and the firmware after the update, are being held in the nonvolatile memory. Then, this technique allows activation with one of the two types of firmware selected upon activation of the apparatus. Although this known technique reduces the time required to write the firmware into the nonvolatile memory, reactivation of the apparatus is still required to deploy the firmware after the update on a volatile memory.

Moreover, for a method of preventing interruption of service during firmware update, a method of making an apparatus redundant is conceivable. For example, an optical switch or the like is used to change a physical communication path so that processing is switched to an apparatus different from a target apparatus in which the firmware is to be updated. Then, this method returns to the original communication path after the firmware update has been completed. In this case, it is expected that the firmware is more safely updated than in the above-mentioned method of directly rewriting the firmware deployed on the volatile memory. However, this method of making an apparatus redundant additionally requires an optical switch for switching the communication path and a spare OLT and leads to an increase in costs, which is a concern from an economical viewpoint.

In light of the above circumstances, an object of the present invention is to provide a technique capable of updating a program without interrupting a service while suppressing costs.

An aspect of the present invention is a communication apparatus as defined in the appended set of claims.

Further, an aspect of the present invention is an information processing method as defined in the appended set of claims.

According to the present invention, a program can be updated without interrupting a service while costs are suppressed.

Modes for carrying out the present invention will be described with reference to the drawings. The embodiments described hereinafter are merely examples, and embodiments to which the present invention is applied are not limited to the following embodiments.

Note that the same reference signs are used for those having the same functions in all the drawings used to describe the embodiments, and the descriptions will not be repeated.

Hereinafter, a first embodiment according to the present invention will be described.

<FIG> is a diagram showing one example of the configuration of an optical communication system <NUM> according to the first embodiment. The optical communication system <NUM> is a system that communicates using an optical signal. The optical communication system <NUM> includes an optical access apparatus <NUM>(communication device) and a control terminal <NUM>.

Note that the optical communication system <NUM>, which includes the optical access apparatus <NUM> to communicate with a different communication apparatus such as an optical network unit (ONU) by using an optical signal, is described as one example herein, but there is no limitation thereto. The optical communication system <NUM> may be a different communication apparatus or a communication system, which communicates in a different way other than optical communication.

The optical access apparatus <NUM> includes a nonvolatile memory <NUM>, an activation processing unit <NUM>, a volatile memory <NUM>, a processor <NUM>, a communication unit <NUM>, and a writing unit <NUM>.

The control terminal <NUM> is an information processing apparatus such as a personal computer. The control terminal <NUM> stores after-update firmware <NUM>. The after-update firmware <NUM> and a before-update firmware <NUM> described later are, for example, firmware for the optical access apparatus <NUM> to execute optical communication.

If the control terminal <NUM> has accidentally written the after-update firmware <NUM> to the volatile memory <NUM> while before-update firmware <NUM> is being used by the processor <NUM>, unexpected abnormality may occur in the optical access apparatus <NUM>. Thus, the optical access apparatus <NUM> writes the after-update firmware <NUM> as after-update firmware <NUM> in a free region of the volatile memory <NUM> so that the before-update firmware <NUM> stored in the volatile memory <NUM> is not rewritten. Writing the after-update firmware <NUM> in a free region of the volatile memory <NUM> allows the optical access apparatus <NUM> to write the after-update firmware <NUM> in the volatile memory <NUM> even while the before-update firmware <NUM> is being used by the processor <NUM>.

Moreover, the optical access apparatus <NUM> updates the firmware by changing the call destination of the functions (first data) of the before-update firmware <NUM> to the functions (secondary data) in the after-update firmware <NUM>. Note that a target whose callee is changed is not limited to function data and may be, for example, other data such as programs. In the following description, a case where the callee of a function is changed will be described as one example.

Hereinafter, the details of the optical access apparatus <NUM> will be described. The activation processing unit <NUM> is implemented using hardware such as a large scale integration (LSI) or an application specific integrated circuit (ASIC). The activation processing unit <NUM> writes the before-update firmware <NUM> stored in the nonvolatile memory <NUM> into the volatile memory <NUM> as the before-update firmware <NUM> when the optical access apparatus <NUM> is activated and before the processor <NUM> is activated.

The before-update firmware <NUM> is, for example, firmware for the optical access apparatus <NUM> to execute optical communication.

The activation processing unit <NUM> also writes platform firmware <NUM> stored in a nonvolatile recording medium such as the nonvolatile memory <NUM> into the volatile memory <NUM> when the optical access apparatus <NUM> is activated and before the processor <NUM> is activated. The description of a case where the nonvolatile memory <NUM>, serving as one example of a nonvolatile recording medium, is applied is continued hereinafter.

The platform firmware <NUM> is, for example, firmware such as an operating system.

The nonvolatile memory <NUM> is, for example, a read-only recording medium such as a read-only memory (ROM). Alternatively, the nonvolatile memory <NUM> may be a rewritable flash ROM. The nonvolatile memory <NUM> stores the before-update firmware <NUM>. The nonvolatile memory <NUM> does not store the after-update firmware <NUM>. Hereinafter, even when the before-update firmware <NUM> is referred to from the processor <NUM> in a state where the before-update firmware <NUM> is stored in the nonvolatile memory <NUM>, the before-update firmware <NUM> is stored in the nonvolatile memory <NUM> in a state where the processor <NUM> can operate. That is, binary data of the before-update firmware <NUM> is the same as binary data of the before-update firmware <NUM>.

The volatile memory <NUM> is, for example, a volatile recording medium such as a random access memory (RAM) capable of being read from and written to. The volatile memory <NUM> stores the platform firmware <NUM> in accordance with a write operation by the activation processing unit <NUM> when the optical access apparatus <NUM> is activated. The volatile memory <NUM> stores the before-update firmware <NUM> in accordance with the write operation by the activation processing unit <NUM> when the optical access apparatus <NUM> is activated and before the processor <NUM> is activated. The volatile memory <NUM> has a free region with sufficient capacity even when the platform firmware <NUM> and the before-update firmware <NUM> are stored in the volatile memory <NUM>. The sufficient capacity means capacity which enables at least the after-update firmware <NUM> to be stored. After the processor <NUM> is activated, the volatile memory <NUM> stores the after-update firmware <NUM> output by the control terminal <NUM> in the free region of the volatile memory <NUM> as the after-update firmware <NUM>.

The before-update firmware <NUM> includes a reference destination of a function. The function is associated with a head address of the function in the volatile memory <NUM>.

The after-update firmware <NUM> includes a new reference destination of the function. The function is associated with a head address of the function in the volatile memory <NUM>.

The volatile memory <NUM> further stores a function table <NUM>. The function table <NUM> is data in table format in which functions are associated with head addresses of the functions in the volatile memory <NUM>. Note that the function table <NUM> may be alternatively included in any one of the platform firmware <NUM>, the before-update firmware <NUM>, or the after-update firmware <NUM>.

The writing unit <NUM> is implemented using hardware such as an LSI or an ASIC. The writing unit <NUM> may be implemented by software. In this case, for example, a program for implementing the functions of the writing unit <NUM> is included in the platform firmware <NUM> (OS), and the software is implemented in accordance with a system call of the OS. Based on a writing request output by the control terminal <NUM>, the writing unit <NUM> determines whether the after-update firmware <NUM> can be written into the free region of the volatile memory <NUM>. Herein, the writing request includes information indicating the size of the after-update firmware <NUM>.

Specifically, the writing unit <NUM> determines whether the free region of the volatile memory <NUM> is equal to or larger than the size of the after-update firmware <NUM> based on the size of the after-update firmware <NUM> included in the writing request. The writing unit <NUM> writes the after-update firmware <NUM> into the volatile memory <NUM> when the free region of the volatile memory <NUM> is equal to or larger than the size of the after-update firmware <NUM>. On the other hand, the writing unit <NUM> does not write the after-update firmware <NUM> into the volatile memory <NUM> when the free region of the volatile memory <NUM> is smaller than the size of the after-update firmware <NUM>. Note that the writing unit <NUM> may notify of that the free region of the volatile memory <NUM> is less than the size of the after-update firmware <NUM> when the free region of the volatile memory <NUM> is smaller than the size of the after-update firmware <NUM>.

The writing unit <NUM> also rewrites a value of the head address included in the function table <NUM> based on the writing request output by the control terminal <NUM>.

The processor <NUM> executes operation based on the platform firmware <NUM> stored in the volatile memory <NUM>. The processor <NUM> also executes operation in accordance with the before-update firmware <NUM> or the after-update firmware <NUM> based on the function table <NUM>. Specifically, the processor <NUM> refers to the function table <NUM> to retrieve the head address of the function included in the before-update firmware <NUM>. Then, the processor <NUM> executes the function positioned at the retrieved head address.

The communication unit <NUM> communicates with a different communication apparatus, such as an ONU, by using an optical signal in response to control by the processor <NUM> that executes the operation in accordance with the before-update firmware <NUM> or the after-update firmware <NUM>.

<FIG> is a diagram showing one example of indirect reference in the optical access apparatus <NUM> according to the first embodiment.

The volatile memory <NUM> stores the function table <NUM> in advance. The function table <NUM> is generated, for example, by the processor <NUM> using a function pointer and stored in the volatile memory <NUM>. Accordingly, information indicating the head address of each function included in the before-update firmware <NUM> is stored in the function table <NUM>.

If a function is called by the program being executed, the processor <NUM> refers to the function table <NUM> to retrieve the head address of the called function. The processor <NUM> shifts the processing to the retrieved head address.

When updating the firmware, the writing unit <NUM> rewrites the value of the head address of the function defined in the function table <NUM> in response to the writing request from the control terminal <NUM>.

As shown in <FIG>, "function_A" and "0x00001500, which is the head address of "function_A", are stored in association with each other in the function table <NUM>. Similarly, in the function table <NUM>, "function_B" and "0x00001200", which is the head address of "function_B", are stored in association with each other, and "function_C" and "0x00001300", which is the head address of "function_C", are stored in association with each other.

As shown in <FIG>, "0x00001500", which is the head address of "function_A" and is defined in the function table <NUM>, is a value rewritten by the writing unit <NUM> from "0x00001100". That is, the head address of the function "function_A" included in the before-update firmware is "0x00001100", and the head address of the function "function_A" included in the after-update firmware is "0x00001500".

With the configuration above, the optical access apparatus <NUM> updates the firmware by performing indirect processing for calling the desired function via the function table <NUM>. Accordingly, the optical access apparatus <NUM> can change the processing without overwriting the program in operation. Thus, according to the optical access apparatus <NUM>, it is possible to ensure stability during the firmware update because the data in the volatile memory <NUM> is rewritten while the memory protection function of the basic software (operating system (OS)) is avoided.

<FIG> is a flowchart showing one example of the operation of the optical access apparatus <NUM> according to the first embodiment.

The processor <NUM> determines whether or not to update the firmware (Step S001). When new functions are added the firmware in operation, when existing functions are changed in the firmware in operation, or when bugs are fixed in the firmware in operation (YES in Step S001), the processor <NUM> determines to update the firmware. If not (NO in Step S001), the processor <NUM> determines not to update the firmware and ends the processing shown by the flowchart.

When the processor <NUM> has determined to update the firmware (YES in Step S001), the writing unit <NUM> retrieves the after-update firmware <NUM> output from the control terminal <NUM> (Step S002). Note that, to generate the after-update firmware <NUM> in the control terminal <NUM> and the like, it is necessary to generate in advance additional information such as a memory map of the after-update firmware <NUM>, which will be required later, and then retrieve the additional information together with the after-update firmware <NUM> by the optical access apparatus <NUM>.

The writing unit <NUM> writes the retrieved after-update firmware <NUM> into the free region of the volatile memory <NUM> as the after-update firmware <NUM> (Step S003). As previously mentioned, the after-update firmware <NUM> is written into the free region of the volatile memory <NUM>, thereby preventing the before-update firmware <NUM> being executed from being overwritten.

In order to complete the firmware update without failure, the processor <NUM> confirms whether or not the deployment of the after-update firmware <NUM> in the volatile memory <NUM> has been completed without errors, before the processing is shifted from the before-update firmware <NUM> to the after-update firmware <NUM> (Step S004). When it has been confirmed that an error has occurred (YES in Step S004), the processor <NUM> again writes the retrieved after-update firmware <NUM> into the free region of the volatile memory <NUM> as the after-update firmware <NUM> (Step S003).

When it has been confirmed that no error has occurred (NO in Step S004), the processor <NUM> determines whether or not it is timing at which the firmware can be updated (Step S005). To safely execute firmware update, it is necessary to check the processing status of the program in operation and appropriately determine the timing at which the firmware is updated. Note that the criteria for determining whether or not it is timing at which the firmware can be updated will be described in detail later.

The update timing is determined at an updating point that is incorporated into the firmware in advance. For each cycle in which the program is executed, the processor <NUM> checks the presence or absence of an update flag at the updating point.

When it has been determined based on the update flag that it is not the timing at which the firmware can be updated (NO in Step S005), the processor <NUM> ends the processing shown by the flowchart. When it has been determined based on the update flag that it is the timing at which the firmware can be updated (YES in Step S005), the writing unit <NUM> rewrites the value of the head address of the function defined in the function table <NUM> (Step S006). Then, the processor <NUM> ends the processing shown by the flowchart.

The flowchart shown in <FIG> is a flowchart showing the more detailed operation of the optical access apparatus <NUM> in the processing of rewriting the head address defined in the function table <NUM> (i.e., the processing of Step S006 in <FIG>).

When updating the firmware, it is necessary to rewrite the value of the head address of the function defined in the function table <NUM> stored in the volatile memory <NUM>. However, if the value of the rewritten head address is incorrect, the program may stop abnormally. Thus, before rewriting the value of the head address, the writing unit <NUM> confirms that the rewriting location (the position of the head address of the function to be updated in the volatile memory <NUM>) is present in a rewritable area (Step S601).

The writing unit <NUM> rewrites, in order, the value of the head address of the function to be updated in the function table <NUM> (Step S602). When there are a plurality of functions to be updated, the writing unit <NUM> rewrites, one by one in order, the values of the head addresses of the functions to be updated.

When there is a function to be updated in which the rewriting of the value of the head address of the function has not been completed (NO in Step S603), the writing unit <NUM> continues the processing of rewriting the value of the head address of the function to be updated in the function table <NUM> (Step S602).

When the rewriting of the value of the head address has been completed for all the functions to be updated (YES in Step S603), the writing unit <NUM> checks whether or not the value of the head address of the function, which is to be updated and deployed on the volatile memory <NUM>, matches the value of the head address, which is associated with the function and rewritten in the function table <NUM>.

When the values of both of the head addresses do not match (NO in Step S604), the processor <NUM> again executes the processing of rewriting the head address defined in the function table <NUM> (i.e., the processing of Step S006 in <FIG>). When the values of both of the head addresses match (YES in Step S604), the processor <NUM> ends the processing shown by the flowchart.

Hereinafter, the criteria for determining whether it is the timing at which the firmware can be updated will be described.

The updating point is incorporated at any of the timing described below in the periodic processing executed in the platform firmware <NUM>. Then, at every cycle or periodically, confirmation is made as to whether it is necessary to update the firmware at the timing of the incorporated update point. When it is necessary to update the firmware, the firmware is updated.

<FIG> is a schematic diagram for explaining the correspondence between the processing status of the process and the update timing. Note that the process referred herein corresponds to, for example, the function included in the firmware.

For example, in a case where only a "process A" shown in <FIG> is to be updated, the following three types of update timing are conceivable. In the firmware, an updating point is incorporated in advance at any one or a plurality of the following types of update timing:.

To fix a small bug, fix a patch, or the like, the update range can be narrowed by updating the firmware for a single process. Accordingly, the firmware update for the single process can advantageously reduce the range that the firmware update affects.

When the firmware has been updated by rewriting indirect reference before or after the single process (i.e., the timing of <NUM>-(<NUM>) or <NUM>-(<NUM>) shown in <FIG>), the firmware update is reflected from the next process execution. Moreover, when the firmware is updated during the execution of the process to be updated (i.e., the timing of <NUM>-(<NUM>) shown in <FIG>), the firmware update is reflected from the next process execution after the process, which is being executed and is to be updated, is completed.

Note that the change is reflected before the execution of the process so that the firmware update by rewriting the indirect reference destination advantageously does not affect the process during the execution.

For example, in a case where two processes, the "process A" and a "process B" shown in <FIG>, are to be updated, the following two types of update timing are conceivable. In the firmware, an updating point is incorporated in advance at any one or both of the following types of update timing:.

When the head address defined in the function table <NUM> has been rewritten during the execution of the plurality of processes, there is the possibility of not being able to hand over normal data between the processes.

Thus, by updating the firmware collectively before all of the plurality of processes to be updated are executed or after all of the plurality of processes to be updated are executed, the operation of the optical access apparatus <NUM> before and after the firmware update can be stabilized.

To change the entire program to be updated (e.g., when the "process A", the "process B", and a "process C" shown in <FIG> are all to be updated), the update is preferably performed before the execution of all the processes or after the execution of all the processes as described below from the viewpoint of preventing failures during the update.

Rewriting the data in the volatile memory <NUM> during the execution of the program causes memory errors, with a possibility of crashing the program becoming very high. On the other hand, the possibility of the occurrence of memory errors can be relatively low if the timing is before the execution of all the processes of the program to be updated or after the execution of all the processes of the program to be updated. Therefore, updating the firmware at the above timing of <NUM>-(<NUM>) and <NUM>-(<NUM>) enables safe shift to the after-update firmware.

As described above, the optical access apparatus <NUM> according to the first embodiment includes the volatile memory <NUM> and the processor <NUM>. The volatile memory <NUM> stores the function (first data) included in the before-update firmware <NUM>, the function (second data) included in the after-update firmware <NUM>, and the function table <NUM>. The function table <NUM> is a table in which the function included in the before-update firmware <NUM> or the function included in the after-update firmware <NUM> is associated with the address where the function included in the before-update firmware <NUM> or the function included in the after-update firmware <NUM> is positioned in the volatile memory <NUM>. Moreover, the processor <NUM> executes the processing based on the function included in the before-update firmware <NUM> or function included in the after-update firmware <NUM>, which are positioned at the address defined in the function table <NUM>.

Furthermore, the optical access apparatus <NUM> according to the first embodiment further includes the writing unit <NUM>. The writing unit <NUM> rewrites the address, which is associated with the function included in the before-update firmware <NUM> in the function table <NUM>, to the address where the function included in the after-update firmware <NUM> is positioned in the volatile memory <NUM>.

The writing unit <NUM> also rewrites the address in accordance with the update timing defined in the before-update firmware <NUM>.

The writing unit <NUM> further writes the after-update firmware <NUM> into the free region of the volatile memory <NUM>.

The above configuration enables the optical access apparatus <NUM> according to the first embodiment to update the firmware without interrupting the provision of the communication service by incorporating indirect processing (indirect reference) into the firmware. The above configuration also enables the optical access apparatus <NUM> according to the first embodiment to realize the firmware update without interrupting the communication service at lower costs than the known method of making an apparatus redundant.

Hereinafter, a second embodiment according to the present invention will be described.

As shown in <FIG>, in the first embodiment described above, the optical access apparatus <NUM> is configured to rewrite, one by one in order, the value of the head address defined in the function table <NUM> for each function to be updated. With this configuration, when there are many functions to be updated, it takes time to update the firmware in some cases.

On the other hand, when an optical access apparatus <NUM>(communication device) according to the second embodiment described hereinafter updates firmware, values of head addresses of functions to be updated are collectively updated in units of function tables. Accordingly, the values of the head addresses of all the functions to be updated are collectively rewritten in single processing. Thus, in the case where there are many functions to be updated in particular, the optical access apparatus <NUM> can further reduce the time required to update the firmware compared with the optical access apparatus <NUM> according to the first embodiment described above.

<FIG> is a diagram showing one example of the configuration of an optical communication system <NUM> according to the second embodiment. Similar to the optical communication system <NUM> according to the first embodiment described above, the optical communication system <NUM> is a system that communicates using an optical signal. The optical communication system <NUM> includes the optical access apparatus <NUM> and a control terminal <NUM>.

Note that, among the functional blocks of the optical communication system <NUM>, functional blocks common in function with the functional blocks of the optical communication system <NUM> according to the first embodiment described above are denoted by the same reference signs, and will not be further described.

The volatile memory <NUM> stores platform firmware <NUM>, before-update firmware <NUM>, after-update firmware <NUM>, a function table <NUM>, and a function table value <NUM>.

Based on a writing request output from the control terminal <NUM>, the writing unit <NUM> causes the volatile memory <NUM> to store the after-update firmware <NUM>, the function table <NUM>, and the function table value <NUM>.

Unlike the function table <NUM> described in the first embodiment in which the head address of each function is defined for only one function group, the function table <NUM> is a table in which a head address of each function of each function group for each function table value that could be set for the function table value <NUM> is defined. Note that the configuration of the function table <NUM> and the function table value <NUM> are described in detail later.

By referring to the function table <NUM> and the function table value <NUM>, the processor <NUM> retrieves the head address value of the function to be executed in the volatile memory <NUM> and executes the firmware.

<FIG> is a set of diagrams showing an example of indirect reference in the optical access apparatus <NUM> according to the second embodiment.

<FIG> shows the association between the version of each function and the value of the head address. From the left, a function group consisting of functions of Version <NUM> (Ver. <NUM>), a function group consisting of functions of Version <NUM> (Ver. <NUM>), and a function group consisting of functions of Version <NUM> (Ver. <NUM>) are shown. That is, the functions of Version <NUM> (Ver. <NUM>) are functions included in the before-update firmware <NUM>, and the functions of Version <NUM> (Ver. <NUM>) and Version <NUM> (Ver. <NUM>) are functions included in the after-update firmware <NUM>. Note that the functions of Version <NUM> (Ver. <NUM>) may be included in firmware that further updates the after-update firmware <NUM>, not in the after-update firmware <NUM> that includes the functions of Version <NUM> (Ver.

For example, the leftmost function group includes a function "function_A" of Version <NUM>, a function "function_B" of Version <NUM>, and a function "function_C" of Version <NUM>. As shown in <FIG>, in the volatile memory <NUM>, the value of the head address of the function "function_A" of Version <NUM> is "0x00001100", the value of the head address of the function "function_B" of Version <NUM> is "0x00001200", and the value of the head address of the function "function_C" of Version <NUM> is "0x00001300".

<FIG> shows an example of the configuration of the function table <NUM>. As shown in the drawing, the head addresses of the respective functions ("function_A", "function_B", and "function_C") of the function groups are each defined for the respective function table values ((<NUM>) to (<NUM>)) in the function table <NUM>.

As shown in <FIG>, for example, if the value set to the function table value <NUM> is (<NUM>), the value of the address in the volatile memory <NUM>, which is referred by the processor <NUM> when the function "function_A" is called, is "0x00001100". That is, the processing of the function "function_A" of Version <NUM> is executed. Similarly, if the value set to the function table value <NUM> is (<NUM>), the processing of the function "function_B" of Version <NUM> is executed when the function "function_B" is called, and the processing of the function "function_C" of Version <NUM> is executed when the function "function_C" is called.

Moreover, as shown in <FIG>, for example, if the value set for the function table value <NUM> is (<NUM>), the value of the address in the volatile memory <NUM>, which is referred by the processor <NUM> when the function "function_A" is called, is "0x01001100". That is, the processing of the function "function_A" of Version <NUM> is executed. Similarly, if the value set to the function table value <NUM> is (<NUM>), the processing of the function "function_B" of Version <NUM> is executed when the function "function_B" is called, and the processing of the function "function_C" of Version <NUM> is executed when the function "function_C" is called.

That is, for example, a case where the value of the function table value <NUM> is changed from (<NUM>) to (<NUM>) indicates that only the function "function_A" is changed from Version <NUM> to Version <NUM>, the function "function_B" and the function "function_C" of Version <NUM> remain, and the processing will be executed.

Furthermore, as shown in <FIG>, for example, if the value set to the function table value <NUM> is (<NUM>), the value of the address in the volatile memory <NUM>, which is referred by the processor <NUM> when the function "function_A" is called, is "0x02001100". That is, the processing of the function "function_A" of Version <NUM> is executed. Similarly, if the value set to the function table value <NUM> is (<NUM>), the processing of the function "function_B" of Version <NUM> is executed when the function "function_B" is called, and the processing of the function "function_C" of Version <NUM> is executed when the function "function_C" is called.

That is, for example, a case where the value of the function table value <NUM> is changed from (<NUM>) to (<NUM>) indicates that all the functions "function_A", "function_B", and "function_C" are changed from Version <NUM> to Version <NUM>, and the processing will be executed.

The three arrows shown in <FIG> are illustrated to show the respective functions executed when (<NUM>) is set to the value of the function table value <NUM>, when (<NUM>) is set to the value of the function table value <NUM>, and when (<NUM>) is set to the value of the function table value <NUM>.

As described above, the function table <NUM> includes information (first information), in which the functions included in the before-update firmware <NUM> are associated with the addresses, and information (second information), in which the functions included in the after-update firmware <NUM> are associated with the addresses. In addition, the function table value <NUM> corresponds to identification information for identifying whether to execute the functions included in the before-update firmware <NUM> or to execute the functions included in the after-update firmware <NUM>.

By using the function table <NUM> and the function table values <NUM> having the configurations described above, the optical access apparatus <NUM> can collectively rewrite the values of the head addresses of all the functions to be updated in single processing.

<FIG> is a flowchart showing one example of the operation of the optical access apparatus <NUM> according to the second embodiment.

Note that the processing in the optical access apparatus <NUM> according to the second embodiment is similar to the processing of Steps S001 to S005 in the flowchart showing the operation of the optical access apparatus <NUM> according to the first embodiment as shown in <FIG>, and thus the description thereof will be omitted. Accordingly, the flowchart shown in <FIG>, which is described below, is a flowchart showing the more detailed operation of the optical access apparatus <NUM> in the processing of rewriting the head address defined in the function table <NUM> (i.e., the processing corresponding to Step S006 in <FIG>).

The writing unit <NUM> checks the value of the function table value <NUM> stored in the volatile memory <NUM> (Step S611). The writing unit <NUM> determines whether the value of the set function table value <NUM> matches the function table value (not shown) in the processing to be executed (Step S612). The function table value (not shown) in the processing to be executed is stored in, for example, a storage medium including the volatile memory <NUM> or the like.

When the value of the set function table value <NUM> matches the function table value in the processing to be executed (YES in Step S612), the processor <NUM> ends the processing shown by the flowchart. When the value of the set function table value <NUM> does not match the function table value in the processing to be executed (NO in Step S612), the writing unit <NUM> updates the function table <NUM> (Step S613). Note that only the difference may be alternatively added or changed instead of updating the entire function table <NUM>.

The writing unit <NUM> rewrites the function table value (not shown) in the processing to be executed to the value set to the function table value <NUM> (Step S614). The writing unit <NUM> checks whether the value set to the function table value <NUM> matches the function table value (not shown) in the processing to be executed (Step S615).

When the value set to the function table value <NUM> does not match the function table value (not shown) in the processing to be executed (NO in Step S615), the writing unit <NUM> again performs the processing of updating the function table <NUM> and the function table value <NUM>. When the value set to the function table value <NUM> matches the function table value (not shown) in the processing to be executed (YES in Step S615), the processor <NUM> ends the processing shown by the flowchart.

As described above, the optical access apparatus <NUM> according to the second embodiment includes the volatile memory <NUM> and the processor <NUM>. The volatile memory <NUM> stores the functions (first data) included in the before-update firmware <NUM>, the functions (second data) included in the after-update firmware <NUM>, the function table <NUM>, and the function table value <NUM>. The function table <NUM> includes the first information, in which the functions included in the before-update firmware <NUM> are associated with the addresses where the functions included in the before-update firmware <NUM> are positioned, and the second information, in which the functions included in the after-update firmware <NUM> are associated with the addresses where the functions included in the after-update firmware <NUM> are positioned. The function table value <NUM> is a value for identifying the functions included in the after-update firmware <NUM> and the functions included in the after-update firmware <NUM>. The processor <NUM> executes the processing based on the functions included in the before-update firmware <NUM> or the functions included in the after-update firmware <NUM>, which are positioned at the addresses defined in the first information or the second information identified by the function table value <NUM> stored in the volatile memory <NUM>.

The configuration above makes the optical access apparatus <NUM> according to the second embodiment collectively update the values of the head addresses of the functions to be updated in units of function tables when the firmware is updated. Accordingly, the values of the head addresses of all the functions to be updated are collectively rewritten in single processing. Thus, in the case where there are many functions to be updated in particular, the optical access apparatus <NUM> can further reduce the time required to update the firmware compared with the optical access apparatus <NUM> according to the first embodiment described above.

The above-described configuration enables the optical communication system according to each of the embodiments to update the firmware without interrupting the provision of the communication service by incorporating indirect processing (indirect reference) within the firmware.

As an approach to updating firmware by indirect reference, an approach to directly rewriting the beginning memory address saved in the function table has been described in the first embodiment. Moreover, as a more effective approach when there are many functions to be updated in particular, an approach to holding a plurality of function table values in the function table and changing the function table values to change versions of the functions to be executed has been described in the second embodiment.

For the application of the above-described approaches, the configuration, in which the updating point is incorporated in advance into the firmware to appropriately determine the update timing of the firmware in the optical communication system according to each of the embodiments, has been described. This configuration enables the optical communication system according to each of the embodiments described above to update the firmware without interrupting the service and without causing an abnormal stop or the like of the program.

For example, by enabling firmware to be updated without interrupting the service, functional additions and functional changes involved in fixing a bug in the firmware and the provision of new service can be facilitated.

Furthermore, in the known case of updating firmware, service providing operators have to notify users of the service in advance or perform update work at night to less affect the users. However, enabling the firmware to be updated without interrupting the service makes the work described above unnecessary for the operators. Accordingly, for example, a cost reduction effect related to maintenance and operation of the communication facilities is expected.

The firmware update methods described in the above respective embodiments can realize a firmware update without interrupting the communication service at lower costs than the known method of making an apparatus redundant.

Note that part or all of the optical access apparatus <NUM> or the optical access apparatus <NUM> according to the embodiments described above may be implemented by a computer. In such a case, part or all of the optical access apparatus <NUM> or the optical access apparatus <NUM> may be implemented by recording a program for implementing their functions in a computer-readable recording medium, and causing a computer system to read and execute the program recorded in the recording medium. Note that the "computer system" as used herein includes an OS and hardware such as a peripheral device. The "computer-readable recording medium" refers to a portable medium such as a flexible disk, a magneto-optical disk, a ROM, and a CD-ROM, and a storage apparatus such as a hard disk installed in a computer system. Further, the "computer-readable recording medium" may also include such a medium that stores programs dynamically for a short period of time, one example of which is a communication line used when a program is transmitted via a network such as the Internet and a communication line such as a telephone line, and may also include such a medium that stores programs for a certain period of time, one example of which is volatile memory inside a computer system that functions as a server or a client in the above-described case. Further, the above program may be a program for implementing a part of the above-mentioned functions. The above program may be a program capable of implementing the above-mentioned functions in combination with another program already recorded in a computer system. The above program may be a program to be implemented with the use of a programmable logic device such as a field programmable gate array (FPGA).

Claim 1:
A communication apparatus, comprising:
a memory (<NUM>) that stores first data on firmware before update (<NUM>), second data on firmware after the update (<NUM>) and a table (<NUM>) in which the first data or the second data is associated with an address where the first data or the second data is positioned;
a processor (<NUM>) that executes processing based on the first data or the second data positioned at the address defined in the table (<NUM>);
further comprising:
a writing unit (<NUM>) that determines, for each cycle in which the firmware before the update (<NUM>) is executed, whether or not the update of the firmware before the update (<NUM>) is required at an
update timing corresponding to processing status of a process of a program of the firmware before the update (<NUM>), based on the presence or absence of an update flag at an updating point which is incorporated in advance into the firmware before the update (<NUM>), and rewrites the address associated with the first data in the table (<NUM>) to the address where the second data is positioned when it is determined that the update is required,
wherein the updating point is incorporated in advance at a plurality of points including before an execution of a single process, during the execution of the single process, and after the execution of the single process, when the single process corresponding to a function included in the program of the firmware before the update (<NUM>) is to be updated.