NASA Driver

Understanding the NASA drivers

NASA drivers and their new features

Understanding the NASA drivers and their new features

NASA stands for New Adroit Scanning Architecture and describes a sub-class of protocol drivers that are specifically written to take advantage of the scanning improvements and enhancements provided by NASA, such as demand scanning and highly optimized scan tasks. While many of these improvements are “under-the-hood”, this document aims to describe the new features that these NASA drivers provide and how they can benefit you.

Note: The NASA driver DLLs are differentiated from the legacy drivers by being prefixed by a “d_” e.g. d_opcua_cl.

Optimized scan tasks

Typically when scanning process values to and from Adroit, the legacy drivers would create separate scan jobs for different:

  • Agent types, such as:  Analog, Digital, Integer, String, Marshal, and Multistate and their
  • Data type formats, such as:  longs, words, and dwords.

This would, therefore, increase the total number of scan jobs and therefore the overhead required to communicate your process values. For this reason, less than optimum scan rates were typically attained.

With NASA drivers, both different Agent types and data type formats can co-exist within a single scan job, which ensures that the minimum number of separate transactions transmit the data to and from the front-end devices. This means that you will achieve improved throughput as the communication overhead is kept to an absolute minimum.

Improved multi-channel performance

Previously, only specific legacy drivers supported multi channels, such as Modbus EMC or Modbus Radio. All NASA drivers provide support for multi channels although this feature is off by default.

When enabled, NASA drivers can support up to 8 channels, which are utilized as needed to service the required transactions to achieve parallel communication on a single device.

Dynamic configuration

Legacy drivers would only attempt to reload the primary and secondary configuration from the registry during an outright failure of the device, once the maximum number of retries were exceeded.

NASA drivers also reload the primary and secondary configuration from the registry when the device is started and/or stopped to make it possible for online or runtime changes to running devices without needing to restart the Agent Server in order for these changes to take effect.

Examples of possible runtime changes are adding additional debug information to the Datascope or to correct configuration errors like IP address typos etc.

Improved Performance Monitoring

NASA drivers provide support for up to 16 new counters that are common amongst all NASA drivers to facilitate their improved debugging
and analysis.

Demand Scanning

Demand scanning is only supported by NASA drivers that are specifically written to support it, legacy drivers do not provide this feature.

Process values (tags) configured to be demand scanned are only communicated when they are being used (when there are one or more subscriptions
or references to these tags).
Note: In Adroit, a subscription to a process value essentially means that something else is using it. For instance, if this process value is being: alarmed; actively logged; used by another Adroit agent or viewed by an operator.

Therefore, demand scanning can reduce the number of process values that are communicated, which are especially useful in the following

  • when you are communicating process values over networks where there is an expense attached to the amount of data that is being
    transferred like a telemetry system using a GSM network or possibly satellite communications or
  • as a means to improve the throughput (communication speeds) of a belabored network.

But demand scanning can ONLY be used for any READ-ONLY process value that is typically ONLY displayed on a mimic (graphic form) or is used by any of its graphic form components like a behavior or spider on the graphic form. In other words, a process value that is NOT alarmed or logged or used by any other agent.

In this case, when the graphic form is opened that contains or references this process value, then the NASA driver will become aware that
this graphic form requires this process value and so it will communicate (scan) this value from its front-end device.

When this graphic form is closed, then the NASA driver will become aware that this process value is no longer being used and so it will stop
communicating (scanning) this value from its front-end device.

Note: There is a fair amount of overhead involved for each demand scanned process value, since the NASA driver has to constantly query the Agent Server to determine when this process value is being used.

Therefore due to this implicit overhead only configure process values to be demand scanned that will benefit from demand scanning, in other
words, do not configure process values for demand scanning that will NEVER make use of this mechanism (e.g. those that are logged or

WARNING: If you configure ALL your process values to be demand scanned then you could experience SLOWER system performance and not experience any other benefits since all the process values NOT used by ONLY one thing will ALWAYS be scanned anyway!
Tip: You can determine which other agents are using (subscribed to) a tag, by opening the Agent Server Configurator and clicking the
Used by… button.

Usage scenarios NOT recommended for demand scanning:

  • Demand scanning is NOT recommended for process values that are being alarmed or actively logged or used by another Adroit agent.
  • Furthermore, any such tag configured for demand scanning could degrade the overall system performance due to the implicit overhead involved in constantly querying the Agent Server to determine when this process value is being used.
  • Currently when a process value has the Output Enabled scanning setting configured then it is CONSTANTLY being scanned and therefore CANNOT be demand scanned.
  • Demand scanning cannot be used as a strategy to “reuse” your scan points, since as explained above a scanned point license is not relinquished by a demand scanned tag when its tag is not being scanned, since the NASA driver has to constantly query the Agent Server to determine when this process value is being used.

We do also NOT recommend the use of demand scanning for a clustered Agent Server that uses shadow scanning and a proxy server to handle requests for its tags from remote clients. Since this could return INCORRECT VALUEs. Therefore use the parallel clustering scanning strategy instead.

Firstly, when a clustered pair of Agent Servers use shadow scanning, only the Master Agent Server performs the scanning and the Standby Agent Server does not.

Secondly, when a client requests a tag from the proxy Agent Server, this proxy Agent Server it is UNABLE to specify which Agent Server partner it retrieves the requested tag from and only retrieves the tag from the first Agent Server in the list, as long as it is in a healthy state.

Thirdly, demand scanning is the only type of scanning that requires at least one subscription to exist to the referenced tag before the tag is scanned.

For this reason, if a remote client opens a mimic that has a demand scanned tag on it, it is possible for the proxy server to source the requested tag from the Standby Agent Server partner that is NOT being physically scanned (when its name is first in the list), which results in the WRONG VALUE being returned because:

  • the Standby Agent Server is given the subscription to this demand scanned tag, but is unable to service this request because it is NOT performing any scanning and
  • the Master Agent Server does NOT have a subscription to this demand scanned tag (since this subscription was made with the standby Agent Server) and so this tag will NOT be demand scanned!

For this reason use parallel scanning instead, which ensures that BOTH the Standby and Master Agent Server scan all the tags and so
the value would be demand scanned regardless of which clustered partner is selected by the proxy Agent Server.

Lets Talk

Fill in the form and we will call you back.
  • We need to know where you are from so we can allocate the correct resources.
  • This field is for validation purposes and should be left unchanged.