Wegener Communications 6420 User Manual
iPump 6420 User’s Manual
www.wegener.com
800070-01 Rev B
Chapter 3, Page 88
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.
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
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.
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
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.
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
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,
and it is downloaded to the /u/user/.system/dlfiles directory, which is a “hot folder”.* There,