1601 Data Fig1a

SOM for embedded DAQ targets IIoT applications

For sensor-based applications that require real-time acquisition and control, an embedded data acquisition (DAQ) solution offers substantial benefits, including cost-savings, less complexity, and the flexibility that open source provides.

Embedded solutions also are suitable for Industrial Internet of Things (IIoT) applications where intelligent, IIoT-capable devices allow remote monitoring and control of processes and data. In the oil industry, for example, the digital oilfield has been advocated to enhance greater uptime and productivity. IIoT-capable devices have helped to provide operational efficiencies and thus greater profitability by leveraging the latest technological advances, including smarter sensors and improved connectivity. In an industry where the push to cut costs and increase production in the face of falling oil prices is the mandate, the move to IIoT-capable devices is an urgent one, making embedded DAQ solutions increasingly compelling.

So which embedded DAQ solution is best for IIoT applications?

For many users, a system-on-module (SOM) solution is ideal since it provides ample processing power and connectivity, low power consumption, and lots of I/O capability in a small form. Because it combines an off-the-shelf processor module (processor, memory, and all peripheral connections) with specialized DAQ circuitry, the SOM operates as a small, standalone computer that can acquire, analyze, and control data and send data to other devices as needed.

Combining processor with I/O

While many processors are available for use in embedded applications, ARM processors, with their small size, reduced complexity, low power consumption, and large developer community, are ideally suited for SOM solutions. The Texas Instruments (TI) Sitara AM335x family of processors is popular among system designers and used on many products, including smart communication devices, the Beaglebone Black development board, and SOM DAQ products.

Most SOM devices available today are intended to operate as embedded PCs and lack the capability to interface to real-world signals. However, some manufacturers have taken the concept of a SOM one step further by combining the ARM processor with high-performance analog input and output circuitry, direct sensor interfaces, and DAQ support features such as external triggers and clocks, counter/timers, and tachometer inputs.

For example, Data Translation’s DT7837 (Figure 1a) combines the AM3552 ARM processor with four 24-bit IEPE inputs, a tachometer input, a 24-bit stimulus analog output, digital I/O, and counter/timer functionality, making it suitable for use in sound and vibration applications where dynamic signals must be measured (automobile testing, disk drive failure analysis, speaker testing, and so on).

Similarly, Data Translation’s DT7816 (Figure 1b) combines the AM3552 ARM processor with eight simultaneously sampled 16-bit analog inputs, two 16-bit analog outputs, digital I/O, and counter/timer functionality and can achieve throughputs at up to 400 kHz, making it suitable for a wide variety of applications where real-world parameters must be measured.

(a)

(b)

Figure 1. DT7837 SOM for embedded sound and vibration applications (a) and DT7816 SOM for a variety of embedded DAQ applications (b)

Embedded architecture for DAQ

This architecture combines a processor with precision analog, mixed-signal, and sensor interface circuitry to provide a complete measurement and data-processing solution.

The processor section enables real-time signal processing and control, signal and data analysis, data storage, and communications with external devices. It contains the ARM processor, memory, flash, and typically Ethernet, USB (client and host), and serial connections.

The I/O section has the capability to interface to real-world sensors. It includes the I/O circuitry required for high-performance measurements such as precision analog and sensor interface circuitry that, in the case of some SOM solutions, rivals the I/O capability of the best of today’s dedicated-purpose measurement instruments.

The FPGA is the interface between the processor and the I/O circuitry and provides the logic, timing, control, and data buffering for all I/O operations. Figure 2 shows an example of the embedded architecture for DAQ.

Figure 2. Embedded architecture for DAQ

When choosing an embedded solution, users must be mindful of their I/O requirements. What sensors will be used? How fast must data be collected? Does the application require stimulus or control? What kind of accuracy is needed? The best solution not only will have powerful processing capabilities, but also will offer the best I/O performance for the intended application.

Developing application programs

Application programs for the AM3552 ARM processor are based on Linux, a free, open-source operating system that provides a powerful and flexible infrastructure for developing embedded software. Because Linux is supported by an open-source community, developers can decrease development time by leveraging freely available source code and reduce costs by using software that does not require licensing or distribution fees.

When writing application programs for an ARM-based SOM solution, two different models of embedded Linux development are possible:

Self-hosted development

In a self-hosted development model, the compiler, linker, and make tools must be installed and running on the embedded “target” device. The developer then can write a C program on the embedded device directly, save the file, and compile and link it. The resultant binary file can be executed on the target. Self-hosted development is recommended only when developing simple applications.

Cross-platform development

The cross-platform model is the preferred development model for most applications and SOMs for DAQ. In this model, application programs are written on a Linux host development system, and the resultant binary is copied to the target for execution. The host system provides much more power and flexibility when writing applications as it offers faster processing capability, more memory and disk space, display functionality, and so on, than an embedded device.

Many Linux distributions are available for installation on the host development system. For instance, Data Translation supports and recommends the Ubuntu distribution.

For SOM solutions that use the AM3552 processor, the free TI AM335x SDK Essentials package provides a stable Linux kernel and the Linaro GCC cross-compilation toolchain. Developers need the software development kit (SDK) to develop custom applications, modify the Linux kernel, or modify a kernel mode driver.

The manufacturer of the SOM also must provide its device-specific source code. For Data Translation SOMs, complete source code (kernel device drivers, device tree, and examples) for each SOM product is installed in the TI SDK directory of the host system to provide programmers with a seamless development environment.

Developers can write their applications using any integrated development environment that can recognize and parse C/C++ keywords, such as Netbeans or Code Composer Studio. In addition, all source code can be modified and used without restriction, so programmers can modify the example programs rather than starting from scratch to speed development.

Application programming interface (API)

To write an application for an embedded DAQ device, the device manufacturer must define the API for performing I/O and other operations. In the case of Data Translation’s SOMs, kernel device drivers expose the functionality of the hardware to Linux user space applications through well-documented virtual file interfaces (Figure 3).

Figure 3. Embedded application software architecture showing virtual file interfaces

User applications perform standard file operations, such as open, close, read, and write, on the virtual files to perform I/O operations, send data to the USB host through an IN endpoint, and receive data from the USB host through an OUT endpoint. For operations that require configuration, device-specific commands called IOCTLS are needed. For instance, to perform an analog input operation, the application program opens the virtual file for the analog input subsystem; uses the IOCTLs to configure the analog input channels, clock frequency, and so on; performs a read operation to asynchronously acquire the data; and closes the file when done.

The open nature of Linux allows all kinds of software interfaces to be defined, but finding information about how to use these interfaces can be challenging. Therefore, it is important that the API for the SOM is well-documented to allow successful implementation.

Getting up and running

While SOM DAQ solutions provide tremendous power and flexibility, getting up to speed does not have to be difficult. The time to get up and running largely depends on the software and support that are provided for the device.

For example, Data Translation SOM DAQ devices are shipped with Linux and all drivers installed in flash. Therefore, on power up, each SOM is a fully functioning Linux computer with network and USB connectivity. Many sample programs, which show how to sample data, process data, and communicate with external devices, come pre-installed so that users can get up and running right out of the box.

Because all code is open source, users can modify the examples as needed on their development system and then deploy them on the SOM to monitor and control their processes.

An IIoT application using SOM

Figure 4 shows an example of a SOM DAQ solution in an IIoT application. In this example, the SOM is running an application program that acquires analog input data, performs an FFT to process the data, stores the results onboard, and then serves the results to the Internet through a web server. Any client with a web browser (PC, Android phone/tablet, or Apple iPhone/iPad) then can view the results; no plug-ins are required. An Android tablet is shown in Figure 4; notice that the data from the SOM matches the data that was acquired with an oscilloscope as verification.

Figure 4. IIoT application using a SOM for embedded DAQ

Developers can easily create embedded, networked client-server applications for the SOM and leverage the advantages of IIoT to monitor and control external equipment. For example, by incorporating a web server, a SCPI server, and network services discovery functionality such as Bonjour or Avahi, the SOM becomes an LXI-compliant instrument. As evidenced by these examples, the developer has tremendous power and flexibility with a SOM solution for embedded DAQ.

Deciding on an embedded solution

For applications, such as IIoT, that require real-time acquisition and control, an embedded DAQ solution using SOM is a viable choice. When choosing a SOM solution, a user must consider the processor power and connectivity of the device as well as its I/O capability, programming tools and support, and ease of startup.

About the author

Linda Letourneau is a principal technical writer for Data Translation. She has more than 25 years of experience writing about data acquisition products and their use and has authored numerous papers, technical articles, user manuals, and online help systems for Windows- and Linux-based hardware and software products.

* Fred Molinari, president, and Debashis Ghosh, principal software design engineer, contributed to this article.

Sponsored Recommendations

Comments

To join the conversation, and become an exclusive member of Electronic Design, create an account today!