Wegener Communications 6420 3.6. Miscellaneous Functions

iPump 6420 User’s Manual

www.wegener.com 800070-01 Rev B Chapter 3, Page 88

As the captured OAR files accumulate on field i6420s, the Compel system may regularly

request that they be returned so that they are available for auditing. This is done through the

Return Path OAR file return report. This will cause the field iPump6420 to upload all OAR

files, by HTTP POST, to the CSM function in the Compel system. The CSM function, in turn,

will place the files to a directory for that unit serial number. After the request has been accepted

and executed, the iPump6420 will move the OAR files that were sent to a hidden folder

/u/user/.system/oar/.to_be_deleted. All files therein are watched by another internal

maintenance process. When their age exceeds the automatic deletion time, then they are quietly

deleted.

The relevant user controls are:

1. OAR Return Path request

2. OAR file auto-deletion time, in days

3. OAR file auto-deletion time of day

3.6. Miscellaneous Functions

The Linux OS and the linux application that implements the Local Controller, per Figure 1-

3, both have their code stored in a flash memory card. The code is stored there, rather than the

hard-drive (HDD), so that the unit will function, albeit as a more limited “IRD”, in the event that

the unit’s HDD fails. Storage of the application software is done in two redundant locations.

This allows the network operator some measure of security when trying to control many remote,

field iPump6420s, especially when local users are unable to, unwilling to, or restricted from

assisting in the proper management of the unit.

Redundant Application Images

Normally, the unit holds two versions of the application code and one is specified to be the

“commanded” application. At unit reboot, a boot loader function evaluates the non-volatile

instructions specifying which application to load, and the stored flags indicating the status of

those application images. If an application image is known to be “good”, and it is the currently

commanded (or “primary”) version, then it is loaded and run without further qualification. If

the currently commanded (primary) application image is not known to be good, for any of

several reasons, then the boot loader will load the alternate (“backup”) version, if it is known to

be good. Also, if the boot loader attempts to load and run the commanded application, and if, for

any reason, the application cannot be run, then the boot loader, after a few attempts, can revert to

the backup application, loading and running that. It will also mark the failing application image

as “bad”, avoiding later re-attempts to load and run it. The exceptions to these scenarios can be

discussed shortly, after describing the application upgrade process.

Software Upgrade process

To upgrade software in unit, Compel, or the local web user, may download a new

application image to the running system. This is in a special format which uses a *.dl extension,

and it is downloaded to the /u/user/.system/dlfiles directory, which is a “hot folder”.* There,