Professional Documents
Culture Documents
4, OCTOBER 1991
360
I. INTRODUCTION
0364-9059/91/1000-0360$01.00
01991 IEEE
361
wicrooontro1l.r
with on-chip
300 Baud
9600 Baud
EIA-485
Signals
MOS
s.ria1
n.tt.ry
etack
I
Resynchronization
waul.
pouer
W M BACKPLANE
100 Baud
9600 Baud
Fig. 1 . Block diagram of the primary components of the HSBB. The HSBB
provided an intelligent interface between the 300-Bd digital data stream
output by the serial card of a standard VMCM and a 9600-Bd SAIL link to a
controlling computer. An accompanying resynchronization module interrupted power to the VMCM upon command to allow a synoptic reset of
instrument clocks.
362
automatically send its data string at the VMCM switch-selectable sample rate. The HSBB stored the data string in RAM
as it arrived and listened for commands from the SAIL/485
controller. Upon receipt of the SAIL/485 synoptic set command ( # 79), the microcontroller froze (made unavailable
for filling) the most recently acquired VMCM buffer. Each
HSBB then transmitted its data over the communications
cable after recognizing its address on the SAIL/485 link.
During each sample interval it was necessary to have one
buffer that was being filled by incoming VMCM data, a
second buffer that had been filled and was ready to be
frozen, and a third that had been frozen and was ready
to be transmitted. This triple buffering scheme made data
available to the shipboard computer with minimal delay while
ensuring that data in the HSBB RAM would not be overwritten during the time between the synoptic set command and
the receipt of the data request from each instrument (Fig. 2 ) .
As the HSBB received successive set and transmit commands, information on the status of each buffer was saved.
This information was returned as part of the data stream and
allowed the data acquisition computer to monitor the triple
buffering sequence of each instrument.
The SAIL/485 controller could initiate a synchronous reset
of all the VMCMs on the EIA-485 link by issuing a
SAIL/485 command, #20. When the HSBB recognized this
command it triggered a monostable multivibrator (one-shot)
on a resynchronization module in line with the connector
between the VMCM battery pack and the backplane. The
one-shot interrupted the power to the instrument causing a
hardware reset. This direct approach was taken because
resetting the VMCM processor using existing internal software commands via the SAIL/485 interface proved unreliable. The resynchronization capability was used to counteract
drift between the VMCM clocks, which could cause the data
records frozen by a given synoptic set command to come
from incommensurate VMCM sample intervals. The synchronization accuracy was typically better than one second.
fry,
huller3
send
Fill Buffer 2
butler 3
yj
utter?
smd
bull?! 1
!se;dfr,
hul 2 bul 3
Ire7
huller2
Fill Buffer 4
I
controller
ie,t,;,
Fill Buffer 3
controller
ni te;,
controller
inteyl
controller
interqval
>
Time (seconds)
Fig. 3 . A block diagram of the shipboard data acquisition software package. Each symbol represents a software program that is resident in the
computer memory. The central timing program generated a 2-s pulse and
managed the activation of programs via ASTs. The acquisition or input
programs (upper right) collected data from the deployed instruments and
stored data in shared memory. The output programs (upper left) archived,
processed, and displayed data obtained from shared memory. A conversion
routine managed the shared memory buffers and converted raw binary data
to scientific units by applying calibration constants. A menu program provided the user with the ability to select instrument sampling schemes and
processing and graphical display parameters. Each process was assigned a
priority with the acquisition and disk archiving receiving the highest priority,
graphics and processing an intermediate priority, and the tape archive the
lowest priority.
instrument sampling scheme, graphical display, and archiving. Six different programs were used to sample data from
separate SAIL/485 links containing one or more instruments.
The configuration used for the 1990 SWAPP experiment
consisted of two VMCM links, one with 13 instruments and
the other with six, and four other links connecting single
SAIL/485 addressable instruments at 14-, 28-, and 56-s
sample periods. A seventh program was used to obtain
time-of-day information from the WWV universal time clock.
Interprocess communication allowed other programs to be
started and stopped at any time without interfering with the
basic timing and archiving of data. Theoretically, data from
38 instruments transmitting 42 characters each at 2-s intervals
could be collected and archived at 9600 Bd. In practice, the
upper limit of 19 VMCMs was due to the additional processing demands placed on the CPU by the graphical display and
data processing programs.
The RTU multitasking operating system allowed the assignment of real-time priorities to competing software programs which guaranteed that time-critical resident programs
would not be preempted by less important programs. Individual programs could also be locked into memory reducing the
amount of time it took to swap the programs to and from the
disk. During SWAPP, the central timing program running at
363
the highest real-time priority received the 2-s pulse from the
real-time clock and determined which programs to wake up
at what priority via an AST. Data collection software programs ran at the next highest real-time priority and transmitted raw data to the first buffer in shared memory (Fig. 3). If
an instrument failed to respond within a specified amount of
time (0.1 s for VMCMs), a software alarm clock expired,
which allowed the process to continue, avoiding a deadlock
condition. The second raw data buffer was read by an archive
program executing at a real-time priority equivalent to the
collection programs. These data were then stored to a contiguous disk file that always contained the most recent seven
days of collected data. The central timing program and the
disk archiving program always executed regardless of how
many instruments were sampled, and the archive record size
was fixed to the maximum number of instruments. The raw
data buffer was then changed from a packed binary format to
floating point scientific units and stored in another double
buffer in shared memory by a conversion program. The
conversion program used pre-set calibration data matched to
each instruments SAIL/485 address to provide data in scientific units.
Programs running at the lowest real-time priority included
an averaging program that read the converted data from
shared memory and stored 1-min averages to a second contiguous disk file, and two graphical display programs. Data
for the primary graphical display program were read from
the converted data in shared memory, processed with a
user selectable filter, and displayed on a color graphics
terminal. This terminal utilized dual frame buffers and
alternated the display every 15 minutes. One frame buffer
was filled by all of the high-speed VMCM data, while the
other frame buffer was filled with data from other lower
speed instruments. The second graphical display program read data from the 1-min averaged disk file, manipulated the data further, and displayed the results on a
second color graphics terminal. Since this program obtained
data from a disk file rather than the temporary shared
memory buffer, synchronization with the central timing pulse
was not required. The magnetic tape archiving program operated in a similar manner, tracking the progress of the
seven-day raw data file on disk and updating the tape archive
every 15 min.
Extensive testing was done to verify the synchronization
and proper communication between the data acquisition package and the HSBB modified VMCMs. A core package that
contained only the data acquisition and archive programs was
initially developed and tested. As additional software programs were added, the ability of the computer to keep up
with the overall task was checked by examining incoming
record numbers from the instruments. Missing records could
indicate improper prioritization and scheduling of the programs. As the load on the system increased due to extensive
floating point manipulations and graphical display, double
buffering and careful tuning of AST delivery and scheduling
priorities was required. This distributed the processing load
and allowed all programs to complete their tasks in the
specified interval.
364
365
-0
P
CM37
,2
-16-
CM32
-"-
CM17
t
g. -
CM 21
24
12
0
-12
-24 -
CM 35
E
N
-<
v
-24
-I
24
24
o
-12
28-
CM 16
(W-VMCM)
RTPO
32
CM39
36 -
<
12
-12 -
-24 -
-40 -
CM 41
CM07
'"L
'\__-_..\~__,..._..._I_____________
06
67
d8
d9
1'0
1'1
1'2
1's
1'4
1'5
1'6
117
Fig. 6. Simulation of the real-time display from the first frame buffer of the
primary graphics terminal. The actual displays presented data averaged with
a typical filter length of 1-3 min on a high-resolution graphics screen and
used color to distinguish traces from the multiple instruments shown in each
panel. Numerical values of the data for each instrument were shown for each
frame and updated with each sample. The data shown here are for a 12-hour
interval on March 5 , 1990 and have been averaged to 6-min intervals to aid
in distinguishing lines in the relatively low-resolution monochrome display
simulation. The first frame buffer displayed data from the 19 HSBB-equipped
VMCM's. The upper two panels in the display simulation show east (U) and
north ( U ) velocity components for the instruments on string 1, the next two
panels show U and U for the instruments on string 2, and the bottom panel
shows the temperature data for all instruments together. One instrument
(VMCM 12) is not shown in the string 2 display since it was not working
reliably during this period and an instrument with a bad thermistor (VMCM
38) is not shown in the temperature display. Velocities from instruments that
are above 50 m (solid lines), are tightly grouped, indicating that little shear
was supported in this region of weak stratification. The three instruments
below 50 m on string 1 (dashed) are clearly distinguishable. Note the
increasingly homogenized near-surface temperature field indicated by the
convergence of the temperature traces for the instruments above 50 m
between 0500 and 1200 hours.
366
to the deployment of several drifting and profiling instruments in a coordinated fashion during the experiment [9].
V. SUMMARY
- 1
,U
13.0
12.8
I
i 4
-4
-8
05
06
07
08
09
March
10
11
12
13
14
15
16
17
Fig. 7. Simulation of the real-time display from the second frame buffer of
the primary graphics terminal for the same time period as Fig. 6. The second
frame buffer displayed data from the two RTPs and the specially modified
VMCM. The upper two panels of the simulation show the pressure and
temperature, respectively, from the RTPs, the third panel shows the two
estimates of vertical velocity ( w )from the profiling RTP (RTPl), the fourth
panel shows w from the fixed depth RTP on string 1 (RTPO), and the bottom
panel shows w from the modified VMCM on string 2 (WVM). The data
shown here have been averaged over 1-min intervals. Inspection of the
pressure trace shows that the profiling RTP was moved during this period
from about 22-m depth up to 12 m, and then back down to 20 m. Strong
downward (upward) spikes in the vertical velocity can be seen corresponding
to the upward (downward) movement of the instrument. An increase in the
frequency and amplitude of downward vertical velocity pulses can be seen
between 0930 and 1430 hours.
[l]
361
Robert A . Weller received the B.A. in engineering and applied physics from Harvard University
in 1968 and the Ph.D. in oceanography from
Scripps Institution of Oceanography at the University of California, San Diego in 1978. In 1979 he
joined the scientific staff of Woods Hole Oceanographic Institution where he is presently an Associate Scientist in the Physical Oceanography department. His work has involved making high quality
measurements in the upper ocean and at the air-sea
interface. Previously, the Vector Measuring Current Meter (VMCM), US Patent 4 152934 was developed in collaboration
with Russ Davis.