MVB Driver

ESF defines a Driver and Asset model acting as a digital twin for fields devices and a data source for Wires. The Driver API consists of:
• A Channel Descriptor modeling the protocol data attributes, such as the MVB port address and period or the data type of a variable
• Channel read and write operations
• Channel update notifications

A Driver is typically used by an Asset. The Asset provides a list of channels. For example, an Asset for the MVB IDL can define all the ports of a locomotive or only the ports with the same period. It can also define a data set, such the variables contained in a port telegram.

MVB Driver Configuration

In order to interface the ESF framework with a Duagon Read-Only MVB adapter, and from there to the Locomotive’s MVB bus, an ESF MVB driver has been implemented.

The driver’s configurator consists of:

• Device Filename: name of the MVB adapter filename on the OS’s filesystem;
• Bus Channels: channels configuration to be used (LINE A, B or both);
• Bus Speed: speed of the MVB bus, in bits per second;
• Polling Speed: interval in microseconds between every consecutive read on the bus;
• Buffer Depth: depth of the read’s buffer;
• Dump Stats: if set to true allows to read the stats for each cycle;
• Logger Priority: allows to set the driver verbosity to use upon writing on the logfiles.

MVB Driver Listening Mechanism

The MVB driver supports the listening mechanism; the implementation will start the application execution once a particular MVB variable is received; the MVB variable, represented by a single channel, of course needs to have the “listen” option enabled.

When all of the variables with the same sampling rate are grouped together in an asset, it is possible to set one of them in listen; what this will allow to do is to read or emit in a Wire Graph all of the variables with the same sampling rate at the end of their sampling cycle.

If multiple channels are listening in an asset, each of them can start the execution of the ESF Wires Application, if the asset is used in a graph.
Because of this reason, if multiple channels of the same sample rate are set to listen in a single asset, and an MVB frame containing both the channels arrives, application execution of that MVB flow will start twice.

If instead the “listen” is enabled on only one channel, the Asset will emit its variables once and only once when a sampling cycle finishes; this of course allows for sampling-cycle-driven ESF Wires applications to be developed.

MVB Asset Configuration

An Asset is equivalent to a spreadsheet defining the MVB ports and variables of a locomotor that is usually provided by the Customer. As such an Asset definition can be imported and exported in CSV format. ESF applications written can interact with the Java Assets APIs. Alternatively, Asset can be configured to push process data to a Wires dataflow, for example at a rate matching one of the MVB periods.

Each MVB variable is defined as an Asset Channel
• name represents the name of the MVB variable as defined in the CSV spreadsheets provided by the customer
• PortSize is the size of the MVB port, containing the variable, in bits
• PortId is the address of the MVB port in decimal notation
• PortCycle is the MVB period of the port in milliseconds
• PortFreshness is a timeout in ms used to determine if a port value has not been updated
• PvBitOffset determines the offset of a variable in the MVB port (ignored for raw port)
• PvType is the type of the MVB variable

For each channel, representing an MVB variable, an optional conversion factor can be defined in the PvGain column and can be used by downstream Gain components to scale the variable.
It is important to note that the configuration of an Asset can be changed remotely, by simply sending an XML document through an MQTT message. The same applies to an entire Wires graph whose definition can be exported and imported from an XML document.

A sample MVB Asset configuration can look like in the following diagram (note that the definition may span multiple pages):

MVB Asset in Wires

Through the use of ESF Wires, the developer can focus on creating the basic building blocks (Wire Components) of his own use case and link the blocks together with the use of a visual programming tool, resulting in a Wire Graph. Blocks can be reused among the Wire Graph and each block can be configured on its own, both locally and remotely through Everyware Cloud IoT Platform Device Management.

ESF and ESF Wires are leveraged in the MVB Application. In such project, ESF Wires has been used to create many concurrent processing dataflows which acquire data from the MVB bus. The following diagram provide an illustration for a possible data pipeline that can be used to implement the requested MVB functions.

For example, the MVB edge application for Continuous Sampling and Sampling on Demand of MVB the signals has been achieved by defining the digital twin for a set of MVB variables. The Assets S3_AS_1 and S3_AS_30 contains the definition of the MVB variables whose time series must be processed. The definition can be imported from CSV files that are provided by the Customer.

Then, two pipelines represent the continuous sampling of two sets of MVB variables, represented by the Assets S3_AS_1 and S3_AS_30. The two sets are sampled with a period of 1 and 30 seconds respectively using the Timers S3TMR1 and S3TMR30 Timers. Finally, the variables are published to the remote IoT Cloud platforms/servers

MVB Driver Limitations

The implementation of the MVB driver has some limitations, due to the nature of the adapter used, and of the software stack on top of it. These limitations however will not represent a problem if correctly handled.

The two main limitations the user has to keep in mind are:
• Access Times to the Duagon MVB Adapter;
• Channel Definitions sampling rates.

Regarding the Access Times to the Duagon MVB Adapter, the user has to keep in mind that there are some limitations related to the speed that the OS (and ESF on top of it) accesses the underlying driver and the hardware;

With the current implementation, the time spent to read a port is 40 microseconds; this means that a theoretical maximum of 400 individual ports can be read simultaneously with a 16ms sampling rate.

Keep in mind however that we are referring to individual MVB ports, not variables: if the same port is read by multiple channels as variables (e.g. with different bit offsets), or read in multiple assets, only one read will be performed on the MVB bus.

Regarding the Channel Definition sampling rates, the user has to keep in mind that in order to correctly work with the MVB Driver, he should keep consistent the channel definitions of a variable throughout various assets.

The underlying MVB driver and MVB adapter do not support for multiple port cycle definitions for the same MVB port; for this reason, if a Channel is defined in different Assets with different sampling rates (e.g. 16ms on one channel and 32ms on the other), the actual sampling rate that will be set on the underlying driver and adapter is unpredictable and arbitrary.
Keep in mind that the port cycle has nothing to do with the frequency of interrogations performed by ESF: the problem regards MVB ports definitions, not assets and channel usage in Wire Applications at different intervals.

With a thoughtful planning of the MVB ports and variables to use, and consistency both with the Locomotive’s MVB ports specification and between assets, this will not represent a problem.