Wegener Communications 6420 user manual Miscellaneous Functions, File Return for Audit

iPump 6420 User’s Manual

3.5.3.File Return for Audit

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

3.6.1.Application Management

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,

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