MODAQ Technical Reference

This section will discuss specific MODAQ:Field technologies in greater detail and is provided for the curious end user to better understand how MODAQ:Field works and why certain design decisions were made. Over the course of MODAQ:Field development many options and challenges had presented and there was often often more than one way to achieve similar results. As always, options have trade-offs and a different design team may have made different decisions.

In some cases, options, shortcomings, and/or suggestions will be presented and since MODAQ:RD is offered in the public domain as "open source", experienced LabVIEW developers are encouraged to modify or improve this code base and perhaps implement features in a more efficient and performant manner. It would be appreciated if such improvements are made, that the developers contribute back to this project.

Hardware

The MODAQ:RD utilizes DAQmx which allows for a more user friendly experience when setting up. Running DAQmx on a cRIO requires that a certain subprocessor is installed. Currently only the 904X and 905X series cRIOs include this subprocessor. In order to run this MODAQ:RD, you must have a cRIO from one of these series .

If you already have an older model cRIO, you will have to leverage the FPGA in order to make the measurements this DAQmx based reference design is making. If this is essential for you please reach out to learn more about the FPGA based reference design.

RAD Configuration Utility

The Replication and Deployment (RAD) Utility allows for users to directly image a cRIO with all the necessary software (drivers and MODAQ:Field executables) to run the system. However, this utility is unable to be flexible to any departure from the current release of the MODAQ:RD. We would only recommend users looking to directly deploy the MODAQ:RD on a cRIO to use this tool. Additonally, it may benefit users who want to skip the following steps in target configuration as it does also include all the drivers necessary to run a modified MODAQ:RD. A image titled similarly to "MODAQ_RD_9049_Image1_0_0.lvappimg" is included in the repo. This may be deployed to a cRIO using instructions described here.

Target Configuration

cRIO's are typically configured using the utility from NI called Measurement and Automation Explorer or MAX. To program a cRIO to use the MODAQ:RD, you must configure the network settings properly and install the necessary software. A brand new cRIO will have no software on it besides the base NI-Linux operating system. The steps to setting up the cRIO to program are as follows: 1. Connect the cRIO to your host machine's ethernet port 2. Configure your host machine to use DHCP and not a static IP in order to see the cRIO 3. Open NI MAX and expand the "Remote Systems" tree. You should see your cRIO in the list that appears 4. Select the cRIO in the tree and select the "Network Settings" tab 5. If you are using an older version of NI MAX, you may need install Microsoft Silverlight to be able to view the Network Settings 6. We recommend setting the cRIO to a static IPv4 address such as 192.168.0.10 with a subnet mask of 255.255.255.0 and a blank gateway. Once you save this setting you will no longer be able to connect to the cRIO until you change your host PC's IP address to something in the same subnet such as 192.168.0.9 with a subnet mask of 255.255.255.0.

ip-settings

  1. With your cRIO and Host PC on the same subnet, you can install the necessary software by right clicking "Software"

add-software

  1. Add the software stack described below to the cRIO
  2. You may also wish to change the hostname of the cRIO to something more useful and add a password by clicking "Set Permissions." This is highly recommended if you are going to enable SSH.

Software Stack

MODAQ:RD cRIO software stack:

NI-MAX cRIO Software

All of these packages are needed or a dependency of a package needed by the the MODAQ:RD. You may wish to add more packages if you plan on adding more functionality to the reference design.

Tech Note: The procedure described above for installing software packages and dependencies should not be confused with addons and dependencies for LabVIEW on the Host computer (for instance, your Windows development laptop). These are necessary to enable the needed functionality on the cRIO target. In the interest of keeping the target as lean as possible and not bloat the system with unused services, users should install only the necessary packages. If a needed package is not installed on the cRIO, there may be runtime errors reported or unexpected behavior.

Network Layout

The MODAQ:RD does not include any network connected instruments but there may be a need to include a Cradlepoint Router to enable 4G connectivity to the cRIO and other components of MODAQ:Field during field deployments. If a Cradlepoint is used, the network must be configured properly so the cRIO is on the Cradlepoint's LAN and uses the Cradlepoints IP address as the default gateway.

Software Architecture

The MODAQ:Field software was developed using National Instruments' LabVIEW 2019 32 bit. We recommend starting with the 2019 Release of Embedded Control and Monitoring Suite which includes all the necessary packages (minus the Electric Power Toolkit) plus several that are unnecessary.

LabVIEW Addons

JKI

JKI's VI Package Manager (VIPM) is a utility installed automatically with LabVIEW for downloading and installing free packages developed by NI and Third-parties that can be used within LabVIEW. The MODAQ:RD includes the following packages which are free to download:

  1. OpenG Toolkit
  2. LabVIEW Interface for Amazon S3

Electrical Power Toolkit

The Electric Power Toolkit is a software add-on for LabVIEW developed by NI for completing analysis on power measurements. This toolkit is useful for taking measured voltage and current data and determining useful parameters of power such as RMS Voltage/Current, Active Power, Apparent Power, Reactive Power, Harmonics and Flicker. Currently, this software add-on is listed at $687.00 as of 2023. This package is necessary if you would like to do on-board real-time power measurements and it can be removed from the code if not necessary and to avoid the license cost.

NREL has also developed MHKiT which includes similar functions for completing power quality assessments but not in real-time. Usually this would be done on the cloud after the raw data has been uploaded.

Initialization

When MODAQ:RD is started, it performs the following initialization steps: 1. Sets some important flags 2. Starts the System Messenger queue 3. Checks for a PTP time server on the subnet 4. Loads the configuration file and sets configuration globals 5. Checks for previous clean shutdown 6. Checks and repairs data folder structure 7. Starts watchdog timer

Assuming no critical errors occurred up to this point, the rest of the system is allowed to start up.

I/O

Voltage Input Reads

MODAQ:RD uses the NI-9239 analog input card for high-performance analog to digital conversion. This card exceeds most requirements for ADC quality but has historically been very reliable and accurate therefore justifying its cost. The card specifications are as follows [Source]:

Parameter Value
# of Inputs 4
Bitness 24 Bit
Range +/- 10V
Max Sample Rate 50 kS/s
Type of ADC Delta Sigma (with analog prefiltering)
Sampling Mode Simultaneous
Isolation Ch - Ch and Ch - Earth

Filtering [Source]:

The NI-9239 uses a combination of analog and digital filtering to provide an accurate representation of in-band signals and reject out-of-band signals. The filters discriminate between signals based on the frequency range, or bandwidth, of the signal. The three important bandwidths to consider are the passband, the stopband, and the anti-imaging bandwidth.

The NI-9239 represents signals within the passband, as quantified primarily by passband ripple and phase nonlinearity. All signals that appear in the alias-free bandwidth are either unaliased signals or signals that have been filtered by at least the amount of the stopband rejection.

Passband

The signals within the passband have frequency-dependent gain or attenuation. The small amount of variation in gain with respect to frequency is called the passband flatness. The digital filters of the NI-9239 adjust the frequency range of the passband to match the data rate. Therefore, the amount of gain or attenuation at a given frequency depends on the data rate.

Stopband

The filter significantly attenuates all signals above the stopband frequency. The primary goal of the filter is to prevent aliasing. Therefore, the stopband frequency scales precisely with the data rate. The stopband rejection is the minimum amount of attenuation applied by the filter to all signals with frequencies within the stopband.

Alias-Free Bandwidth

Any signals that appear in the alias-free bandwidth are not aliased artifacts of signals at a higher frequency. The alias-free bandwidth is defined by the ability of the filter to reject frequencies above the stopband frequency. The alias-free bandwidth is equal to the data rate minus the stopband frequency. Data Rates

The frequency of a master timebase (fM) controls the data rate (fs) of the NI-9239. The NI-9239 includes an internal master timebase with a frequency of 12.8 MHz, but the module also can accept an external master timebase or export its own master timebase. To synchronize the data rate of an NI-9239 with other modules that use master timebases to control sampling, all of the modules must share a single master timebase source.

However, the data rate must remain within the appropriate data rate range. When using the internal master timebase of 12.8 MHz, the result is data rates of 50 kS/s, 25 kS/s, 16.667 kS/s, and so on down to 1.613 kS/s, depending on the value of n. When using an external timebase with a frequency other than 12.8 MHz, the NI-9239 has a different set of data rates.e

Serial Port Configuration

Serial devices are connected to the cRIO through the RJ50 (10p10c) ports on the main controller or through an optional 9870 card. In LabVIEW, the different serial ports are available through the NI-VISA driver and can be configured using that driver's library. The serial port is selected through the constant and specified as an ASRL#.

ASRL1 is the rs232 port and ASRL2 is the rs485 port on the cRIO. ASRL 3-6 are the additional ports on the NI-9870 card. There is also the possibility to add USB-to-Serial converters to the cRIO which will also appear as ASRL references. You must specify the serial port parameters for the serial devices that are connected. If using the unmodified MODAQ:RD, there is no need to change the serial port parameters.

GPS/INS/IMU

As mentioned in the Reference Design Section, NREL tends to use higher-end positioning and inertial instruments. While these can get pricey, the benefits are better stability, error correction, and accuracy. They also tend to have better filtering and data fusion algorithms.

  • IMU - An instrument with typically a three-axis accelerometer and three-axis gyroscope in a package often referred to as 6-DOF (for 6 Degrees Of Freedom). These may also include a three-axis magnetometer, making it a 9-DOF device. There is often little to no filtering or data fusion with these devices and rarely has any correction for drift.
  • GPS - Global Positioning System that relies on telemetry from an orbiting constellation of purpose-built satellites to calculate its position on earth. GPS is sort of a generic term, however technically it refers to only the North American "GPS" constellation.
  • GNSS - GNSS can receive GPS data, as well as data from constellations maintained by other countries, such as China (Baidu), Russia (GLONASS), EU (GALILEO), among others.
  • AHRS - Attitude and Heading Reference System is a step up from a basic IMU and offers some onboard processing to estimate roll, pitch, heading (yaw), and heave.
  • INS - An Inertial Navigation System combines an AHRS with a GPS/GNSS and depending on the model, quality, and/or price, can also include higher-performance sensors and algorithms to produce attitude/orientation estimates and useful transforms (such as quaternions).

Tech Note: Six degrees of freedom (6-DOF) are surge, sway, and heave for accelerations and roll, pitch, and yaw for rotations. It's important to note that an IMU does not output the actual roll, pitch, and yaw angles, but the rate of change of those angles. The interested reader might check out this brief introduction to IMUs, key specifications, and the different sensing technologies at use.

Xsens MTI

The Xsens used in the MODAQ:RD is an MTi-G-710 which can be configured using the MT Manager software available from Xsens. We also provide a working example configuration called "MODAQ_Xsens_Config.xsa" which contains the setting seen below and is compatible with the curent version of MODAQ:RD. You can upload that configuration to the device by selecting the "Load Settings" button in MT Manager. If you need other outputs from the Xsens, some modification of the code may be necessary. The MODAQ:RD configuration of the Xsens is shown in the following images:

xsens_config_1 xsens_config_1 xsens_config_1

Hemisphere V104

The V104 is a marine grade GPS system that outputs NMEA messages through a serial connection to the cRIO. It is a dual GPS device with a pair of antennas in a single enclosure and because of the dual design, it can estimate heading.

CONFIGURATION SETTINGS COMING SOON

Timing and Synchronization

PTP

The DAQmx version of the MODAQ:RD supports PTP, or more precisely IEEE 1588-2008 v2. PTP works off a client-server architecture where a master clock serves as the time reference for all capable clients on a network subnet. While there's numerous networking topologies that can be considered, different ways to propagate the time reference, and alternative (non-compatible) implementations such as IEEE 802.1AS, it can get complicated real fast. This discussion will be high-level and basic- please google for a deep-dive.

The promise of PTP is that all connected PTP-aware devices will be synchronized and reference-time accurate to 100's, if not 10's of nanoseconds- without drift. By comparison, Network Time Protocol (NTP), which is what most consumer computers and laptops use as a time reference, can at best achieve 10's of milliseconds accuracy. While NTP accuracy might be perfectly acceptable to some and often better than a real time clock (which can drift several seconds a day), it's a ~6 order of magnitude difference in accuracy as compared to PTP. If a quality time reference is not available, samples taken from input modules on the same DAQ controller will be disciplined by the same clock (usually) and will likely be precisely timestamped relative each other, but may not be accurate to actual time (i.e. UTC) .

Where the real power of PTP is realized is in synchronizing samples taken by disparate systems. These can be DAQs on the same subnet, sharing the same master clock or systems completely disconnected from each other and separated miles apart. As long as each system is disciplined to a healthy PTP reference clock, the samples will be synchronized to the aforementioned nanosecond time precision. This is a boon for distributed architectures and system design flexibility, allowing multi-controller synchronization without physical interconnections.

In our experience, PTP implementation either works magically or is a real bear. It does help to have some knowledge of networking and configuring managed switches. However, a simple, one controller implementation can be achieved by connecting the time server directly to the cRIO's secondary network port.

Configuration

This MODAQ:RD code has been tested on a cRIO-9049 with a Time Machines TM2000B time server on a common subnet. To get the best performance out of PTP, any switches or routers that sit between the PTP server and the clients should explicitly support PTP (at least IEEE-1588v2) and will probably require configuration by someone with more than casual networking experience. Because of this, and the fact that switches from different manufacturers (even among different models from the same manufacturer) can have different procedures for PTP configuration, this topic will not be covered in this documentation.

However, assuming a properly configured network, we will provide some guidance to configuring the TM2000B and getting the cRIO disciplined to the time server. The image to the right is a screencap of how we have configured the PTP parameters in the Time Machine. This is obviously not the only way the device can be configured and it might not even be the optimal configuration, but it works with the cRIO-9049 and other Linux devices on the subnet with PTP support.

Tech Note: The IPv4 UDP setting on the TM2000B under Packet Output is IEEE-1588v2, while the 802.1AS (gPTP) option is obviously IEEE 802.1AS. Also, for the Post-Holdover Behavior, we selected Clock Class=52 instead of FAULTY state. This is because Clock Class 52 advertises to the subnet that it is still the primary reference clock, but it is currently degraded. This would happen in situations where the GPS signal was lost. Since the TM2000B has an OCXO (Oven Controlled Crystal Oscillator) with 20 ppb drift, even with loss of GPS, it's still probably still the best clock in the system, by several orders of magnitude.

LabVIEW includes some example code for inspecting and configuring the PTP/TSN setting on the cRIO and cDAQ chassis on the subnet. Search for TimeSync in the NI Example Finder (from LabVIEW: Help>Find Examples...). Launch the project: "Verify IEEE 1588-2008 Synchronization.lvproj" Please assure that NI-Sync has been installed on the cRIO target, otherwise, the example code will probably fail. For convenience, we've included these helpful utilities in the MODAQ:RD project in the Testers folder.

PTP Enable

We've renamed the files to begin with 1, 2, or 3, which makes them easier to reference in this discussion. They perform the following functions:

  1. Detailed information on status of IEEE 802.1AS-2011 or IEEE 1588-2008 on the selected system and allows the user to change the client/server and priority settings. Of special note here: if the Clock ID and GM Clock ID are the same, then the selected resource is acting as the master clock. Or in other words, it's not detecting a better PTP time reference on the subnet. The GM Clock ID should display the MAC address of the time server.
  2. This utility (shown in the image above), allows the user to select which PTP protocol is active on each of the built-in NICs (ethernet ports) on the cRIO. Only one protocol can be active on a single port at any given time. The screen capture above shows that both ethernet ports are set to IEEE 1588v2 and enabled.
  3. Quickly shows the PTP status of the ethernet ports, much like #2 does, however it also indicates if a time reference has been selected.

We typically start with #2 to setup the ports, then switch to #3 to see if correct reference clock has been selected. If the MAC address of the reference clock is not correct, then it could mean that: - The network is not properly configured for PTP - The reference clock in not on the same subnet as the cRIO - The reference clock scored lower in the automated BMCA (Best Master Clock Algorithm) than the selected clock. This can usually be remedied by changing the priority levels of the clocks.

cDAQs and Other PTP-Aware Gear

When building systems that outgrow the 8 slots available on a cRIO, the system can be extended by using one or more cDAQ chassis. NI offers 8 (NI-9189) and 4 slot (NI-9185) cDAQ options that support PTP/TSN. However, this is not your only option: you could choose to use additional cRIOs or a 3rd party solution.

Tech Note: The primary difference between a cRIO and cDAQ other than cost is that a cRIO is complete controller that runs the DAQ code locally on its own resources, while a cDAQ must be tethered to a controller or PC which is running the DAQ code- and a cRIO can run entirely headless or embedded. There are also some NI I/O modules that cannot be used on a cDAQ.

Global Variables

MODAQ:Field makes extensive use of LabVIEW's implementation of global variables. In general, there is much hate for globals, since their misuse can result in race conditions, unexpected behavior, and poor understanding of data flow control. These are indeed sound reasons, but not enough to outright ban globals as a programming tool.

In MODAQ:Field, globals are generally used for propagating configuration items, status flags/signaling, constants, and snapshot data. We avoid using globals to transport measurement data and instead use queues, FIFOs, channel wires, and direct wiring. We also centralize our globals into special subVIs (one for configuration and one for runtime globals), which allows for easy management of those globals.

Data Destinations

Data Destinations is a catchall term for where data are shuffled off to once acquired. For instance, will the data be stored locally and in what format? Does data need to be sent to a remote location in near-real-time? MODAQ:Field provides several options that can be used alone or together.

TDMS

While there are lots of binary data storage formats, including NetCDF and HDF5, MODAQ:Field uses TDMS (Technical Data Management Streaming) for the simple reason that it is baked into LabVIEW and relatively easy to use. Even though it is not as widely adopted as those other formats, it does have readers for Excel, MatLab, and python.

Due to the modular nature of MODAQ:Field, each process saves to its own TDMS file. While this might seem inefficient, since TDMS can be organized into tables for separate datatypes, channel groups, or sampling rates, we prefer to parallelize the process and encapsulate the TDMS saving function within a particular I/O code module.

TDMS Metadata

Metadata can be written to the TDMS file so that it never gets separated from the measurement data. In MODAQ:RD, the metadata includes the channel group name, channel names, channel units, and data types. These are written whenever a new TDMS file is created.

In MODAQ:RD, the TDMS save subVIs can accept three string arrays for the channel names, units, and data types. The order of each must reflect the physical channel order.

TDMS File Management

While TDMS files can be allowed to grow quite large, we provide the option to close files and start new ones at user-selectable intervals. This was done for two reasons:

  1. To reduce data loss in the event of a file corruption (rare)
  2. To reduce file sizes for uploading or network transfers

After MODAQ:Field closes a TDMS file, it renames the file extension to .done. We do this so that uploading scripts do not attempt to grab actively written files.

MODAQ:RD TDMS file naming convention is as follows:

YYYY_MM_DD_hh_mm_[group name].tdms

Each TDMS group is written to its own folder on the storage drive.

Summary Files

Summary files is a term we use to describe files that contain sub-sampled, statistical, or otherwise summarized data. These data serve as proxies for the original raw data and are concise enough to transmit over limited bandwidth communications paths, while providing sufficient information to be operationally useful. Summary files may also contain diagnostic, health, or snapshot data to keep tabs on things like system memory, available storage space, CPU utilization, and system states.

Currently, the summary files are plain text in a comma separated value format. These files have a static filename, such as pow_now.txt and since the contents are derived from data stored elsewhere, no effort is made to serialize the filenames or archive the contents. If summary file creation is enabled in the configurator, AWS S3 or FTP uploads should also be enabled. We usually set the summary files to be locally deleted after they have been successfully uploaded. The processes that write to summary files will start a new file if the previous one has been deleted.

AWS/S3

MODAQ:RD includes functionality to upload both the summary and TDMS files to an S3 bucket. Users can configure whether to upload the summary or TDMS or both in the Configurator. This requires an AWS account and a set of Access and Secret keys created for the desired upload bucket. These keys are to be copied to the MODAQ Configurator and automatically loaded when MODAQ:Field starts.

Tech Note: Currently, both the summary and TDMS S3 upload processes delete the local files after successful upload. While this is an intentional decision for summary files, it's not necessarily the right choice for TDMS files. Since TDMS files can be large, depending on sample rate and number of channels, they require fast internet or network access to transfer them faster than they are made. Since we rarely upload TDMS files in real time ourselves, this code has not been revised to preserve the TDMS files after upload. We plan to issue an update to disable the auto-delete. At this time, we advise to modify the code yourself or refrain from using the TDMS S3 uploader.

S3 Key Updater

Some organizations with managed AWS services, such as here at NREL, rules are enforced that expire S3 Access and Secret keys after so many weeks or months. Since MODAQ:Field loads the keys from the configuration file on startup and since we don't necessarily want to interrupt a deployment with a maintenance restart, we developed a method to 'hot update' the AWS keys.

The AWS key updater runs continuously in the background during MODAQ:Field operation and watches the /AWS/incoming/ folder. If a file appears, the updater state machine will fail the file if it is not named 'aws.txt' and move it to the /AWS/error/ folder. Otherwise, the parser state expects the file contents formatted:

Access_Key:youraccesskeyhere
Secret_Key:yoursecretkeyhere
Bucket:yourbucketnamehere

There currently is no validation for the file contents, so if the fields are out of order or incomplete it will not successfully update the keys. Since updating the keys using this method only persists until a MODAQ:Field restart, it is recommended to change the keys in the configuration file on MODAQ:Field as well. Also, hot changes for S3 Bucket names have not been enabled in this version of MODAQ:RD.

SFTP/FTP

MODAQ:RD does not support SFTP at this time due to limitations in LabVIEW 2019. However, the underlying RT Linux operating system does. Users familiar with SFTP and the Linux command line could develop solutions for automated file transfers. For manual transfers, client software such as WinSCP, Bitvise, FileZilla could be used.

Due to the inherent lack of security, FTP in not included by default in MODAQ:RD. NREL, like most other organizations with managed IT departments, prohibits the use of FTP. Users willing to accept the risk, can request the MODAQ:Field FTP module- or write their own.

Logs and Alerts

MODAQ:Field provides a system-wide service that can write specific events to a log file and/or send alerts to an email list. The System Message Destinations service runs upon MODAQ:Field startup and is the sole reader for a message queue FIFO. At various points within the MODAQ:Field code, messages can be generated that are intercepted by this service.

To write a message to the system messenger, enqueue the properly formatted cluster containing:

  1. The sending process name (e.g. Bearing Temperature)
  2. Details about the message (e.g. Over threshold, currently 135°C)
  3. T/F whether to write this to the system log (NOTE: default is TRUE, so this is only necessary to set if it's not desired to write to the log)
  4. Whether to send an email alert or not (NOTE: Default is 0 (no mail), so this only needs to be set if it is desirable to issue an email for this alert)

System Log

The system log is a comma-separated-value text file that contains all messages generated by MODAQ:Field processes. Example:

2023-10-26 19:21:57.504 UTC,PTP Time Acquired,IEEE 1588-2008_1
2023-10-26 19:21:57.511 UTC,PTP offset (ns),29
2023-10-26 19:21:57.514 UTC,System Time Update,System Clock Synced to PTP Reference
2023-10-26 19:21:57.516 UTC,Configuration,Loaded
2023-10-26 19:21:57.518 UTC,STARTUP,Clean Shutdown Passed
2023-10-26 19:21:57.521 UTC,Watchdog,Enabled
2023-10-26 19:21:57.523 UTC,SysStats,Uptime:   0d  0h  0m
2023-10-26 19:21:57.540 UTC,SysStats Summary,1992.4,99.6,88.2,1.2,13807.8
2023-10-26 19:22:58.008 UTC,SysStats,Uptime:   0d  0h  1m
2023-10-26 19:23:58.008 UTC,SysStats Summary,1992.3,99.6,88.1,2.9,13807.8

The log files are written to the /Logs/ off the configuration file path set in the Configurator. The naming convention is as follows: 

SystemLog_2023_10_26_19_21.txt

Once the file reaches 100Mb in size, it will be closed and a new file created. A new file is always created on system start.

Email Notifications

The MODAQ:Field System Messenger can issue emails for events or alerts placed on the message queue as discussed above. This Reference design allows for two distribution lists that are set in the Configurator. The Send Email flag (illustration above) that is set at the point of event/alert generation has four possible settings:

  1. No email
  2. Send to distro 1
  3. Send to distro 2
  4. Send to both distros

It may be desirable to have specific messages routed to different groups. For instance, operationally relevant alerts might go to distro 1, while debugging or health related alerts go to distro 2. In this case, distro 1 is the client team, while distro 2 is the MODAQ development team.

Tech Note: While it may seem desirable to issue an email for every event and alert, our experience is that people grow 'email-fatigued' and either ignore the message or create an email rule that shuffles the alerts off to a folder. It is recommended to use emails judiciously and reserve them for critical or time-sensitive events. Alternatively, the distribution lists can be used to route those critical messages to the right people, while developers get the firehose option.

Snoozer

Often, when a condition triggers an alert, such as if a temperature exceeds a defined threshold, the trigger condition will often persist for some period of time. This presents an issue for logging and email alerts, since it may not be desirable to repeatably log or issue emails at the process loop rate. With most processes looping many times a second, the system log and user's inboxes can get flooded quickly.

To address this, MODAQ:RD includes the ability to 'snooze' alerts for a configurable amount of time. If the snoozer is enabled, any repeating alerts from the same Message Tag will get ignored until the Snooze Time has elapsed. If the condition is still occurring, or reoccurs after the snooze time has reset, the message will be actioned as configured (meaning, it will get logged and/or issue an email).

Message snoozing is not global, rather based on the Message Tag at the point of origin. There are two ways to enable message snoozing for an event:

  1. Set the Snooze Alert? and Snooze Time (s) property when the message is enqueued.
  2. Use MODAQ:RD's "Snooze Check Map (SubVI).vi" utility at the point of origin to either (okay) disable the monitoring loop for the snooze duration or (better option) prevent writing to the message queue during the snooze duration.

Rules Based Alerts

The discussions thus far in this section should make it obvious, but MODAQ:Field has great flexibility for monitoring states, events, and measurement parameters in real time and provides multiple options on how to respond to those instances. While it was not included in this Reference Design distribution, the messaging subsystem serves at the heart of Control and Automation in MODAQ:Field.

Using a rules-based approach, systems developers can have if-then, or condition-response type logic that monitors a particular process or parameter for a condition violation and trigger some response to that event. Possible use cases:

  1. Event logging and alerting (as discussed above)
  2. Quality Control (QC) filters
  3. Control actions
  4. Automation state machines, PID logic, or complex supervisory logic

Watch Circle

Since MODAQ:Field was originally designed around DAQ for MRE devices, location monitoring is an intrinsic function. Users can define 'Watch Circles' to geo-fence a device in the field. While the use case was for moored surface devices, the Watch Circle monitor can be used for any mobile platform.

Users can define up to 3 radii from a setpoint (deployment coordinates) in the configurator and MODAQ:Field will log and/or issue emails if the device moves outside of those radii.

Radii definitions:

  1. Yellow Alert - Smallest of the three allowed radii and should be just beyond the movement expected considering the mooring scope. A Yellow Alert could mean the device is experiencing extreme metocean conditions or the mooring is "walking".
  2. Red Alert - Next largest radii which should indicate a clear issue with station keeping. This might be due to an anchor drag or parted mooring line.
  3. AWOL Alert - If the device exceeds the AWOL radius, it has clearly separated from its mooring and is adrift.

MODAQ:Field determines the distance from the setpoint and the current real-time GPS derived coordinates using the Haversine Formula.

Tech Note: The Haversine Formula calculates the distance between two points on a sphere. While earth is (an oblate) spheroid, it's not a perfect sphere and therefore there will be some error in the Haversine distance estimate and we make no geoid corrections in MODAQ:Field. The error introduced over these small distances is likely insignificant and much less than the uncertainty of the GPS position estimate.

Remote Access

SSH

Watchdog Timer

MODAQ:RD uses the RT Watchdog Timer feature built into the cRIO hardware. The watchdog is a service that needs to be pinged (or pet or fed) before a user configurable time interval expires. If the watchdog is not pet before the timer expires, then the assumption is that the real time application has locked up or has become unresponsive and the watchdog hardware will force a system reboot.