|
|
|
| United States Patent | 5504801 |
| Link to this page | http://www.wikipatents.com/5504801.html |
| Inventor(s) | Moser; Laura E. (Newbury Park, CA);
Siu; Edward K. W. (Simi Valley, CA);
Kennedy; Michael (Ventura, CA);
Schillaci; Onofrio (Camarillo, CA) |
| Abstract | A remote test unit for testing and conditioning one or more telephone lines
includes multiple electronically erasable flash memory banks, which
contain respective versions of the operating system employed by the test
unit's micro-controller. An operating system modification routine employed
by the host processor of a remote site allows the functionality of the
remote test unit to be selectively modified by electronically installing
an upgraded or downgraded version of the operating system, or by
electronically selectively activating or deactivating one or more
operational features of the currently active operating system. |
|
|
|
Title Information  |
|
|
|
|
|
Drawing from US Patent 5504801 |
|
|
User-controlled electronic modification of operating system firmware
resident in remote measurement unit for testing and conditioning of
subscriber line circuits |
|
|
|
|
|
| Publication Date |
April 2, 1996 |
|
|
|
|
|
| Filing Date |
February 9, 1994 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Title Information  |
|
|
References  |
|
|
| *references marked with an asterisk below are user-added references |
|
U.S. References |
|
|
|
|
|
|
U.S. References |
|
|
Foreign References |
|
|
|
|
|
|
Foreign References |
|
|
Other References |
|
|
|
|
|
|
Other References |
|
|
|
|
|
References  |
|
|
|
|
|
| Market Size |
|
Estimate the gross annual revenues of the relevant market
sector:
|
| | |
| |
|
|
| Market Share |
|
Estimate the percentage of the relevant market sector this invention will capture:
|
| | |
| |
|
|
| Reasonable Royalty |
|
What percentage of gross sales should the inventor or assignee be paid?
|
| | |
| |
|
|
|
Public's "Guesstimation" of Royalty Value
|
| Market Size | N/A | [No votes] | | x | Market Share | N/A | [No votes] | | x | Reasonable Royalty | N/A | [No votes] |
| | N/A | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
Market Review  |
|
|
Technical Review  |
|
|
Claims  |
|
|
What is claimed:
1. For use with a communication system having a supervisory facility, and
one or more remote sites at which respective programmable test devices are
located, a respective programmable test device containing a resident test
routine operating system for monitoring and testing network lines and
subscriber termination equipment coupled thereto, said communication
system further including at least one data terminal unit which has the
capability of accessing said one or more remote test devices, a method of
modifying the test routine operating system resident in the programmable
test device of a remote site comprising the steps of:
(a) establishing a communication path between a data terminal unit and said
programmable test device;
(b) examining, via said data terminal unit, information stored in said
programmable test device, to determine the version level of the resident
test routine operating system currently being employed by said
programmable test device;
(c) via said data terminal unit, downloading to said programmable test
device an upgraded test routine operating system to be employed by said
programmable test device as a replacement for the test routine operating
system currently being employed by said programmable test device; and
(d) activating, via said data terminal unit, said upgraded test routine
operating system, that has been downloaded to said programmable test
device in step (b), in place of said resident test routine examined in
step (a), so that said upgraded test routine operating system may be
executed by said programmable test device.
2. A method according to claim 1, wherein step (a) includes the preliminary
step of verifying the availability and transferability of said upgraded
test routine operating system by way of said data terminal unit to said
programmable test device.
3. A method according to claim 1, wherein step (b) comprises communicating,
from said programmable test device to said data terminal unit, information
representative of the version level of the currently active test routine
operating system of said programmable test device.
4. A method according to claim 3, wherein said programmable test device
contains first and second memory systems, said first memory system having
stored therein said currently active resident test routine operating
system, and said second memory system having an inactive test routine
operating system stored therein, and wherein step (c) comprises
downloading said upgraded test routine operating system to said second
memory system, thereby replacing said inactive test routine operating
system stored in said second memory system with said upgraded test routine
operating system, and wherein step (d) comprises activating, via said data
terminal unit, said upgraded test routine operating system stored in
second memory system, in place of the test routine operating system stored
in said first memory system, so as to cause said upgraded test routine
operating system to be executed by said programmable test device.
5. A method according to claim 4, further including the step of (e)
communicating, from said programmable test device to said data terminal
unit, information representative of the version level of the replacement
test routine operating system resident in said second memory system of
said programmable test device.
6. A method according to claim 4, wherein step (e) comprises communicating,
from said programmable test device to said data terminal unit, information
representative of the contents of said first and second memory systems, so
as to verify the version level of the replacement test routine operating
system resident in said second memory system of said programmable test
device.
7. A method according to claim 4, further including the step (e) of
deactivating the replacement test routine operating system resident in
said second memory system currently being executed by said programmable
test device, and activating said inactive test routine operating system
stored in said first memory system for execution by said programmable test
device.
8. A method according to claim 4, wherein each of said first and second
memory systems is comprised of electronically reprogrammable flash memory.
9. For use with a communication system having a supervisory facility, and
one or more remote sites at which respective programmable remote test
units are located, a respective programmable remote test unit containing a
resident test routine operating system which, when executed, is
controllably operative to monitor and test network lines and subscriber
termination equipment coupled thereto, said communication system further
including at least one data terminal unit which has the capability of
accessing said one or more remote test units, a method of modifying a test
routine resident operating system in said respective programmable remote
test unit comprising the steps of:
(a) establishing a communication path between a data terminal unit and said
programmable remote test unit;
(b) examining analyzing, via said data terminal unit, information stored in
said programmable remote test unit to identify at least one disabled
operational feature and determine which operational features of said
active test routine operating system are currently enabled; and
(c) via said data terminal unit, activating at least one disabled
operational feature of said active test routine operating system of said
programmable remote test unit, so that said at least one activated
operational feature may be employed by the active test routine operating
system of said programmable remote test unit.
10. A method according to claim 9, wherein step (a) includes the
preliminary step of verifying the availability at and transferability from
said data terminal device of said disabled operational feature to said
programmable remote test unit.
11. A method according to claim 10, wherein step (b) comprises, in response
to determining that the test routine operating system currently active in
said programmable remote test unit lacks a prescribed operational feature,
deactivating the test routine operating system currently active in said
programmable remote test unit, and supplying to said programmable remote
test unit from said data terminal device signals which cause an upgraded
test routine operating system containing said prescribed operational
feature to be stored in memory in said programmable remote test unit as a
replacement for said test routine operating system currently active in
said programmable remote test unit, and activating said upgraded test
routine operating system, and wherein step (c) comprises enabling said
prescribed operational feature contained within said upgraded test routine
operating system in said programmable remote test unit, so that said
prescribed operational feature may be employed by the replacement test
routine operating system of said programmable remote test unit.
12. A method according to claim 11, wherein said programmable remote test
unit contains first and second memory systems, said first memory system
storing the currently active resident test routine operating system, and
said second memory system storing an inactive test routine operating
system, step (b) comprises downloading said upgraded test routine
operating system to said second memory system, thereby replacing said
inactive test routine operating system stored in said second memory system
with said upgraded test routine operating system containing said
prescribed operational feature to be employed by said programmable remote
test unit as a replacement for the test routine operating system currently
active in said programmable test device, and activating, via said data
terminal unit, said upgraded test routine operating system that has been
downloaded to said second memory system, whereby said upgraded test
routine operating system containing said prescribed operational feature is
executed by said programmable remote test unit.
13. A method according to claim 12, wherein step (b) further includes
communicating, from said programmable remote test unit to said data
terminal unit, information representative of the version level of the
upgraded test routine operating system replaced in said programmable
remote test unit.
14. A method according to claim 12, wherein each of said first and second
memory systems is comprised of electronically reprogrammable flash memory.
15. For use with a communication system having a supervisory facility, and
one or more remote sites at which respective programmable test devices are
located, a respective programmable test device containing a resident
operating system which is operative to monitor and test network lines and
subscriber termination equipment coupled thereto, said communication
system further including at least one data terminal unit which has the
capability of accessing said respective programmable test devices, a
respective programmable test device containing a first memory system which
stores a currently active version of a monitor and test operating system,
and a second memory system which stores an inactive version of a monitor
and test operating system, a method of deactivating an operational feature
contained within the currently active version of a monitor and test
operating system stored in said first memory system of said programmable
test device comprising the steps of:
(a) establishing a communication path between a data terminal unit and said
programmable test device; and
(b) via said data terminal unit, modifying the contents of the operating
system stored in said first memory system of said programmable test
device, so as to disable an operational feature and thereby prevent the
operational feature that has been disabled from being employed in the
course of execution of the currently active version of the monitor and
test operating system of said programmable test device.
16. A method according to claim 15, wherein step (b) comprises erasing a
portion of said second memory system containing said operational feature
of said inactive version of said monitor and test operating system,
writing, into said portion of said second memory system, a segment of the
operating system previously contained in said portion of said second
memory system, but with any operational features therein disabled, causing
the inactive version of the monitor and test operating system to become
the currently active version of the monitor and test operating system of
said programmable test device, while deactivating the active version of
the monitor and test operating system in said first memory system, and
selectively enabling said operational feature of the currently active
version of the monitor and test operating system.
17. A method according to claim 15, wherein step (b) comprises erasing a
portion of said second memory system containing said operational feature
of said inactive version of said monitor and test operating system,
writing into said portion of said second memory system a segment of the
operating system previously contained in said portion of said second
memory system but with any operational features therein not yet enabled,
causing the inactive version of said monitor and test operating system to
become the currently active version of the monitor and test operating
system routine of said programmable test device, while deactivating the
active version of the monitor and test operating system in said first
memory system, erasing a portion of said first memory system containing
said operational feature of said inactive version of said monitor and test
operating system, writing into said portion of said first memory system a
segment of the operating system previously contained in said portion of
said first memory system, but with any operational features therein not
yet enabled, and selectively enabling said operational feature.
18. A method according to claim 15, wherein each of said first and second
memory systems is comprised of electronically reprogrammable flash memory.
19. For use with a communication system having a supervisory facility, and
one or more remote sites at which respective programmable test devices are
located, a respective programmable test device containing a resident
communication path monitor and test operating system for monitoring and
testing network communication links and subscriber equipment coupled
thereto, said communication system further including at least one data
terminal unit which has the capability of accessing one or more respective
programmable test devices, a respective programmable test device
containing a first memory system which stores a currently active version
of said operating system, and a second memory system which stores an
inactive version of said operating system, a method of downgrading the
currently active version of said operating system comprising the steps of:
(a) establishing a communication path between a data terminal unit and said
programmable test device;
(b) via said data terminal unit, causing a prescribed invalid code to be
written into a prescribed portion of the operating system stored in said
first memory system within said programmable test device, which prescribed
invalid code is effective to declare the version of the operating system
stored in said first memory system invalid and prevent its use in the
course of an initial default condition of said programmable test device;
and
(c) via said data terminal unit, causing said programmable test device to
be reset to said initial default condition, in response to which the
previously inactive operating system stored in said second memory system
becomes a newly currently active operating system executed by said
programmable test device.
20. A method according to claim 19, further including the step of (d)
communicating, from said programmable test device to said data terminal
unit, information representative of the version level of said newly active
operating system in said programmable test device.
21. A method according to claim 19, wherein each of said first and second
memory systems is comprised of electronically reprogrammable flash memory.
22. For use with a communication system having a supervisory facility, and
one or more remote sites at which respective programmable test devices are
located, a respective programmable test device containing a resident test
routine operating system for monitoring and testing network lines and
subscriber termination equipment coupled thereto, said communication
system further including at least one data terminal unit which has the
capability of accessing said one or more remote test devices, a method of
modifying the test routine operating system resident in the programmable
test device of a remote site comprising the steps of:
(a) establishing a communication path between a data terminal unit and said
programmable test device;
(b) via said data terminal unit, examining information stored in said
programmable test device to determine the version of one or more test
routine operating systems currently stored in said programmable test
device;
(c) via said data terminal unit, replacing the currently active version of
a test routine operating system in said programmable test device by a
different version of said test routine operating system; and
(d) activating, via said data terminal unit, said different version of said
test routine operating system, so that different version of said test
routine operating system may be executed by said programmable test device.
23. A method according to claim 22, wherein step (a) includes the
preliminary step of verifying the availability and transferability of said
different version of said test routine operating system by way of said
data terminal unit to said programmable test device.
24. A method according to claim 22, wherein said programmable test device
contains first and second memory systems, said first memory system having
stored therein said currently active version of said test routine
operating system, and said second memory system having said different
version of said test routine operating system stored therein, and wherein
step (d) comprises activating said different version of the test routine
operating system resident in said second memory system in said
programmable test device, and causing said different version of said test
routine operating system to be executed by said programmable test device.
25. A method according to claim 24, wherein said step (c) comprises erasing
said second memory system and downloading, from said supervisory facility
to the erased second memory system, said different version of said test
routine operating system.
26. A method according to claim 25, wherein said step (d) comprises causing
said programmable test device to be reset and, upon being reset, to
default to said second memory system containing said different version of
said test routine operating system, so that different version of said test
routine operating system may be executed by said programmable test device.
27. A method according to claim 26, wherein each of said first and second
memory systems is comprised of electronically reprogrammable flash memory.
28. A method according to claim 26, wherein step (d) comprises marking the
version of the operating system stored in said first memory system with an
invalid code, so as to declare the version of the operating system stored
in said first memory system invalid and prevent its use in the course of
causing said programmable test device to be reset, whereby said
programmable test device, upon being reset, will default to said second
memory system containing said different version of said test routine
operating system, so that different version of said test routine operating
system may be executed by said programmable test device.
29. A method according to claim 22, wherein step (c) comprises replacing
the currently active version of a test routine operating system in said
programmable test device by an upgraded version of said test routine
operating system. |
|
|
|
|
Claims  |
|
|
Description  |
|
|
CROSS-REFERENCE TO RELATED APPLICATIONS
The present invention relates to subject matter disclosed in co-pending
application Ser. No. 08/194,203, filed coincident herewith, entitled:
"Local/Remote Modification of Electronically Alterable Operating System
Firmware Resident in Redundant Flash Memory of Remote Unit for
Testing/Conditioning Subscriber Line Circuits," by E. Siu et al, assigned
to the assignee of the present application and the disclosure of which is
herein incorporated.
FIELD OF THE INVENTION
The present invention relates in general to communication systems, such as
telephone systems, and is particularly directed to a mechanism for
controllably electronically modifying the functionality of measuring and
test routine, contained within a remote, programmable test device, which
is operative to monitor and test network lines and subscriber termination
equipment coupled thereto, without the need for on-site, physical access,
and removal and replacement of digital processor and memory circuitry of
the test device.
BACKGROUND OF THE INVENTION
Measuring and test equipment currently employed by telephone service
providers customarily contains a variety of conditioning and signal
generation functions which enable service and maintenance personnel to
apply a prescribed number of electrical stimuli to a line, such as a
(digital) subscriber loop, for the purpose of trouble-shooting the line
and measuring its performance. A non-limitative example of such equipment
is diagrammatically illustrated in FIG. 1, which shows the distribution of
a plurality of (microprocessor-controlled) remote measurement units (RMUs)
11, which are installed at a plurality of sites geographically remote with
respect to each other and a supervisory site 12.
An RMU 11 includes various components, such as tone generation and
electrical conditioning circuitry which, under the control of a
firmware-resident measurement and test mechanism contained in the resident
operating system employed by an on-board processor, selectively transmit
prescribed test signals to the line, and may also condition the line with
electrical circuit parameters, that allow an associated line measurement
unit to conduct line measurements and thereby determine the current state
of the line and its ability to successfully perform as intended.
For this purpose, each RMU 11 is typically of the type that conforms to
computer interface requirements defined in Issue 3 of AT&T Publication
KS-23253 and contains internal firmware, which is operative to perform
various diagnostic or test operations on network lines 13 and (subscriber)
termination equipment 15. The RMU may be accessed by means of one or more
video display terminals (VDTs), or data terminal units (DTUs) 21 at the
supervisory site 12, which have the capability of accessing the remote
test equipments 11 through attendant modem devices 23, such as industry
standard Hayes `AT`-compatible 300/1200 units, that are linked to a
central office 25.
Because test and conditioning parameters and customer-requested performance
features may differ among various pieces of equipment, whenever it is
necessary to perform a repair, or effect a change to the functionality of
the firmware (e.g. change an instruction set), it is customary practice
for a service technician (craftsperson) to travel to the site where the
equipment is installed, and either make a component or board replacement
in the field, or, as is more often the case, retrieve the unit, bring it
back to a servicing site, where a repair or retrofit is performed, and
then return the modified unit to the remote site, so that it may be placed
back in service.
SUMMARY OF THE INVENTION
In accordance with the present invention, the costs in labor and down time
required to service a remote test unit in the manner described above are
substantially reduced by configuring the firmware-memory architecture of
the unit's micro-controller of a pair of redundant, erasable flash memory
systems, that enable the operating system firmware of a remote monitoring
unit to be selectively, electronically modified, in particular erased,
replaced and features selectively turned on, from a supervisory device
(e.g. a data terminal coupled via an attendant modem to the central
office, or via a personal computer connection to a serial port (e.g.
RS-232 port) of the test unit).
More particularly, pursuant to the present invention, associated with the
resident control processor of the remote measurement and test unit (RMU)
are two memory systems, which respectively store electronically modifiable
active and inactive `quasi-redundant` versions of the micro-controller's
system software. By `quasi-redundant` is meant that each memory system
contains a version of the operating system firmware that is potentially
capable of operating the RMU. To provide for remote electronic
reprogrammability each memory system is configured of one or more flash
memory devices. When an RMU is powered up or reset, a reset routine
described in detail in the above-identified co-pending application ensures
that the `correct` one of the two quasi-redundant systems available to the
RMU's microcontroller will become the operating system.
Normally, after a modification, the `correct` system is the previously
off-line system that has been changed. However, should this modified
inactive system contain an anomaly that will prevent successful operation
of the test device, it is necessary that the inactive system remain
off-line and the unit continue to operate with the currently running
version of the firmware. In accordance with the invention described in the
above-identified co-pending application, these objectives are achieved by
the use of a prescribed reset routine and by structuring the contents of
the modified inactive memory system to include a precursor set of
instruction code that prevents an accidental boot-up from the off-line
system (in which one or more memory systems have been erased) and thereby
avoids anomalous operation of the RMU.
For this purpose, a precursor section of common code memory space is loaded
with an instruction sequence that forces the off-line system, if accessed,
to perform a continuous no operation loop. Whenever the RMU begins
executing the firmware in either system, a time-out clock is started.
Unless the operating system code, which is PG,7 located in memory address
space immediately following the no operation loop, begins executing prior
to expiration of the time-out, a switch to the other operating system is
performed.
Once transfer of modified (e.g. upgraded) software to the designated
bank(s) of the inactive system has been completed, the host processor in
the user's data terminal unit commands the RMU to reset itself. With the
RMU containing two different versions of the operating system, one of
which is the newer version and the other of which is the previously active
routine which is to go off-line, the reset routine described in the
above-referenced co-pending application is executed to ensure that the
`correct` one of the two quasi-redundant systems available to the RMU's
microcontroller will become the operating system.
When an RMU is initially installed, each of its flash memory systems
contains the same firmware version of the operating system, so that the
operating system firmware in each memory system is a duplicate of the
other. Except for activating an installed feature, when a modification is
to be made to the RMU's firmware, it is the off-line or inactive version
in the redundant memory system that is changed. After a change has been
completed, the system is reset and the changed version is activated, while
the previously running version is deactivated.
In accordance with a first aspect of the present invention, which involves
remotely, electronically performing an `upgrade` of operating system
firmware in an RMU, it is necessary to install a newer version of the
operating system firmware than the one currently running. Since an upgrade
involves an enhancement to equipment functionality, for each RMU user, a
functionality/use descriptor file, which contains information as to what
firmware version a unit currently contains and what features it is
permitted to use, is initially accessed. The functionality/use descriptor
file is effectively a permission and capability file that tells the
installer what may and what may not be installed for a particular RMU.
Access to this file allows an upgrade installer to determine whether a
requested upgrade may be performed. If an upgrade to a specified RMU is
permitted, a communication is established between the (host processor of
the) accessing terminal unit and the RMU.
Once connectivity with the destination RMU has been established, the host
processor requests a copy of a bank descriptor table contained in the RMU.
The bank descriptor table details the contents of the firmware versions
currently stored in the respective flash memory systems of the RMU. The
contents of the bank descriptor table are analyzed by the remote control
(host) processor in order to facilitate the transfer or downloading of
only those portions of firmware that are necessary to effect the requested
upgrade.
Since modification of the contents of flash memory requires an erasure of a
complete block or bank of memory and then a rewriting of new data into the
erased memory space, the host processor next proceeds to erase each block
of flash memory of the `inactive` operating system which is to receive a
`target` firmware upgrade. The upgrade software is then written into the
erased blocks of the inactive memory. Once the transfer of the upgraded
software to the designated blocks of inactive system is completed, the RMU
is commanded to activate the newly downloaded software upgrade in the
inactive system and deactivate the currently active system containing the
previous version.
After the operational feature set available for use by the RMU is
turned-on, the RMU is commanded to reset itself, which causes its internal
processor to default to that memory system which is not marked invalid and
contains the highest version of operating system firmware, that the reset
routine has determined is operationally valid and not in downgraded
status. At any given time, only one memory system can be marked invalid.
After being reset, the RMU begins executing the upgraded version of its
operating system, and the host processor terminates the connection to the
RMU. The final step of an upgrade is for the host processor to reconnect
with the RMU and request a copy of the bank descriptor table contained, in
order to verify that the RMU is currently running the upgraded firmware.
A second aspect of the invention is directed to performing a `downgrade` of
existing RMU firmware, whose purpose is to invalidate the currently
running version of the operating system in the active memory system and to
activate the `quasi-redundant` version of the operating system resident in
the inactive memory system. Downgrading an operating system version
implies that an upgrade has previously taken place, the currently running
version of operating system firmware being the upgraded version, and the
inactive memory system containing an earlier version of the operating
system.
As is the case with an upgrade, once a communication has been established
between the host processor of the accessing terminal unit and an addressed
RMU, the host processor commands the RMU processor to mark the currently
running system as invalid and commands the RMU to reset itself, whereby
the RMU's control processor defaults to that memory system which contains
the previously inactive version of its operating system, which is not
marked invalid. After transmitting a reset and terminating the connection,
the host processor re-establishes a connection with the RMU and requests a
copy of the bank descriptor table to verify that the RMU is currently
running the previously inactive firmware version.
Pursuant to a third aspect of the invention, one or more features of the
firmware may be selectively activated. To activate a feature (which is
similar to an upgrade in that it involves an enhancement to the
functionality of the currently active program), it is necessary to turn on
one or more programmable features contained within the active system, but
not currently allowed to be used by the RMU. Until activated, operational
features are invisible to the RMU processor. Associated with each
operational features of a respective firmware version is a status bit,
which is one (`1`) when the firmware is initially installed. Activation of
a feature involves switching the state of the feature bit from a first
logical state (e.g. a logical `1`) to a second logical state (e.g. a
logical `0`).
Each remotely switchable feature status bit is preferably contained in a
feature status table stored in a prescribed portion of memory. For
example, to accommodate up to sixteen features, a pair of sequential
feature bytes may be employed. Via a virtual to physical map associated
with the feature byte, the user may delineate which feature or features
are to be selectively enabled in the active system. With flash memory,
programming a memory bank involves first erasing the entire bank and then
changing the erased states of selected memory cells. Thus, when a feature
is to be enabled or switched on, it's status bit in the feature table is
changed from its original reset state `1` to an active state `0`.
Like an upgrade, since the routine employed for feature activation involves
an enhancement to equipment functionality, the functionality/use
descriptor file is first examined to whether a requested feature is
available. If activation of the requested feature is not permitted or if
the feature is not available the routine is terminated. If the requested
feature is available a communication is established between the accessing
terminal unit and the RMU. The host processor requests a copy of the bank
descriptor table contained in the RMU and analyzes the table in order to
determine whether the currently running firmware version contains the
requested feature(s). If the currently running version does not contain
the feature to be activated, then an upgrade to a software version
containing the requested feature is performed. If the currently active
system contains the requested feature(s), the host processor commands the
RMU to activate the feature by changing the logic state of the appropriate
feature switch bit, thereby making the feature available for use in the
currently active system. Once the requested feature activation is
complete, the host processor goes back on-hook.
A further aspect of the invention involves the ability to selectively
`deactivate` one or more features of a currently running system. This
aspect of the invention may be employed when it is necessary to turn off
or disable a feature that has been previously enabled, for example in the
case of a feature that was inadvertently turned on when the operating
system was originally installed.
For this purpose, once connectivity with the destination RMU has been
established, the host processor commands the RMU to erase each block of
flash memory of the `inactive` system which contains a feature to be
deactivated. It then commands the RMU to rewrite the software (with no
features turned on) into its associated blocks of flash memory of the
RMU's inactive operating system. Once a rewrite of the software to the
designated blocks of inactive bank has been completed in the inactive
memory bank, the host processor commands the RMU to reset itself and
reverses the states of the two memory systems, thereby making the inactive
system where the reset features reside active, and the currently running
system inactive.
The host processor next commands the RMU to erase each block of flash
memory of the `inactive` system, which contains a feature to be
deactivated, and commands the RMU to rewrite the software (with no
features turned on) into its associated blocks of flash memory of the
RMU's inactive bank. The host processor then commands the RMU to activate
selected features (excluding those to remain deactivated) by changing the
logic state of the appropriate feature switch bit from its initially
erased state to an opposite logical state, thereby making the
non-deactivated features available for use in the currently active system.
Once the requested feature activation is complete, the host processor
terminates the connection.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 diagrammatically shows the distribution of a plurality of
microprocessor-controlled remote measurement units installed at a
plurality of sites geographically remote with respect to each other and a
supervisory site;
FIG. 2 diagrammatically illustrates the architecture of the
micro-controller of an RMU having system bus, control processor, random
access memory, an input/output interface unit, and firmware flash
memories;
FIG. 3 is a process flow routine of the steps carried out for upgrading the
existing firmware in an RMU;
FIG. 4 is a process flow routine of the steps carried out for downgrading
the existing firmware in an RMU;
FIG. 5 is a process flow routine of the steps carried out for activating
one or more features of the currently running firmware in an RMU; and
FIG. 6 is a process flow routine of the steps carried out for deactivating
one or more features of the currently running firmware in an RMU.
DETAILED DESCRIPTION
Before describing in detail the test routine modification mechanism in
accordance with the present invention, it should be observed that the
present invention resides primarily in what is effectively the
installation of a pair of flash memory systems in a remote test unit, in
which respective active and inactive quasi-redundant versions of operating
system firmware are stored, together with an augmentation of the control
software employed by a `master` test system controller (host processor)
and the micro-controller within a programmable monitor and test unit,
which permit a host processor to selectively establish a control link with
and selectively alter the functionality of a subscriber line measuring and
test operative system contained within a `slave` test device, without the
need for on-site, physical access, and removal and replacement of digital
processor and memory circuitry of the test device.
Consequently, the configuration of such a remote test unit and the manner
in which it is interfaced with other communication equipment of the
telephone network have been illustrated in the drawings by readily
understandable block diagrams, which show only those specific details that
are pertinent to the present invention, so as not to obscure the
disclosure with details which will be readily apparent to those skilled in
the art having the benefit of the description herein. Thus, the block
diagram illustrations of the Figures are primarily intended to illustrate
the major components of the system in a convenient functional grouping,
whereby the present invention may be more readily understood.
Various aspects of the test routine modification mechanism of the present
invention will be described with reference to FIGS. 3-6, which show
respective operating system modification flow routines, the execution of
which is operative to modify the functionality of a measuring and test
operating system, contained within an RMU, without the need for on-site,
physical access, and removal and replacement of digital processor and
memory circuitry of the test device.
As pointed out above, in order to enable the present invention to
controllably modify, electronically from a remote site, the operating
system firmware employed by the telephone line monitor and test unit, the
architecture of the processor board within the test unit contains a
plurality (pair) of flash memory systems, which store respective
electronically modifiable active and inactive versions of the
micro-controller's firmware (as opposed to the conventional use of a
single dedicated read-only memory module to store a non-modifiable version
of the unit's firmware).
For this purpose, as diagrammatically illustrated in FIG. 2, coupled with
the test unit's system bus 41 are a control processor 43, attendant random
access memory (RAM) | | |