An Easier Way for Cross-Platform Data Acquisition Application Development

An Easier Way for Cross-Platform Data Acquisition Application Development

For industrial automation and measurement system developers, software technology continues making rapid progress. Software engineers or system integrators need to change their system, including hardware and software, to fulfill the different requirements of various applications.

PC-based programmers can select different operating systems, or different programming tools, depending on their application requirements and their development resource. Therefore, the ability to develop and deploy within different commonly-used operating systems and integrated development environments (IDE) becomes more and more important to build PC-based data acquisition system. To achieve this, data acquisition solution providers need to carefully build it into their design concept.

Let’s   talk   about   compatibility,   the   ability   to   work   across   multiple   operating   systems   and   be   known as cross-platform - first. For native code programming such as C/C++ within Visual Studio or BCB, programmers need to implement system call for memory and thread management, UI implement, graph, file management, communication, device management, etc.

Each operating system offer different system calls, and corresponding calling flows are also

different.

Figure 1: Native Code Programming on Different Operating System

Programmers need to learn different programming methods on different operating systems. In other words, you cannot execute compiled native code (binary codes) based on system calls from one operating system on another. For example, if you want to change your program from Windows 7 to Windows CE, if you have implemented system calls, you cannot use the existing source code, meaning it needs to be re-written. It forces programmers to learn and become familiar with the different system calls on multiple operating systems, and even may lead to re-defined program architecture. All this extra work takes a lot of time and effort, and will make migration between different operating systems difficult, which may limit the programmer when choosing a suitable operating system.

To overcome this obstacle, more developers are choosing to use .NET for programming..NET

technology offers an intermediate architecture and once programmers have completed their

source code, the compiler helps to generate an intermediate binary code (aka Common

Intermediate Language, CIL), instead of platform-depended binary code.

Figure 2: .NET Programming on Different Operating System

On different operating systems, different installed runtime engines (Common Language Runtime (CLR)) will be responsible for making sure the intermediate binary code can be executed on that operating system. Actually, it offers one class loader and one JIT compiler, which will include necessary class libraries, as well as translate CIL to platform-depended binary code and execute it. For Microsoft Visual Studio programmers, this runtime engine is called .NET framework. For the system developers, their program code for different operating system can be the same, and the CLR engine will take care of execution issues related to OS.

Java leverages similar architecture. Java source code will become an intermediate byte code

after Java compiler. Then, different Java engines (aka Java Virtual Machine, JVM) are needed

for different operating system. These engines also have the same functionality as CLR engines,

to execute the same source code on different operating systems. System developers can

benefit from a single program code that can be executed on different operating systems (like Windows and Linux), without any modification.

Figure 3: Java Programming on Different Operating System

Qt is another programming environment which is ideal for deploying on multiple operating systems. It offer a set of standard C++ class libraries, which will take care of many system-related tasks like graphic view, database, network, XML, thread management, etc. For programmers,  they  don’t  need  to  worry  about  low  level  system-related programming, that they can leverage Qt unified cross-platform class libraries. Therefore, unlike .NET and Java mechanism, programmers include Qt class libraries within their source code. Then, using different compilers, the same source code can be compiled to different execution code on many common OSs. Unlike CLR or JVM there is no virtual machine needed to deploy the binary code on different OSs.

Figure 4: Qt Programming on Different Operating System

For data acquisition application developers, the most important factor to make their program usable across multiple operating systems is that the DAQ device driver needs to support program languages or environments, which deliver cross-platform   mechanism.   Advantech’s   latest driver package, DAQNavi, supports native code compiler such as Visual C/C++, Borland C++, Delphi and VB. To help engineers able to develop cross-platform source code, DAQNavi also supports .NET (such as C# and VB .NET), Java (with Eclipse IDE) and Qt programming. It can help programmers to come out with a cross-platform binary code.

DAQ functionality implementation usually involves system calls which are affected by the

operating system. If the DAQ driver supplier  doesn’t  include  related  system  calls  into  their  DAQ  

libraries,  it  might  become  a  nightmare  for  system  developers,  who  want  to  use  supplier’s  DAQ  

driver to develop a cross-platform DAQ program, because programmers need to be familiar

with the programming differences between different operating system.

Take   one   example,   a   “Buffered   AI”   library   will   leverage   system   calls   for   memory   and   thread   management,  which  will  vary  on  different  operating  system.  If  the  “Buffered  AI”  library  doesn’t   take care of memory and thread management by itself, then the programmer needs to handle the programming issues caused by different operating systems. The development will become more complicated and need more programming experience. Based on this, Advantech DAQNavi has been particularly designed to handle system calls by its libraries, making the program calling flow become the same for Windows, Linux, and WinCE.

In summary, DAQNavi wants to help engineers concentrate on their domain application

development, and not worry about many programming issues relating to cross-platform

development.

Speed Up Data Acquisition Project Development with Rapid Application Development (RAD)

Rapid Application Development (RAD) is a software methodology for application software development, developed in the mid- 1970s. Compared to RAD, there is another well-known software development process called waterfall, which requires programmers to prepare a lot of development planning as well as system or architecture analysis before coding.

For mammoth development projects, such as enterprise resource planning (ERP) system establishment or developing a powerful and complicated commercial software such as an office software suite or web browser software, the development needs to be done by a software team. Total development work will be cut out into segments and delegated to different software engineers. Overall software architecture, each segment definition and relationship between segments need to be clarified at the beginning. This will result in the adaption of the waterfall development process.

Figure 1: Waterfall Software Development Process

For other development projects which have a clear application target and can usually be done by a single or a few software engineers, the RAD process can be adapted to achieve a faster development time. Industrial applications development like factory automation, production line testing system and laboratory measurement are typical examples.

RAD involves iterative development and the construction of prototypes. Basically, Programmers will quickly build a draft program with a user interface (UI) as a prototype, and then the prototype program will be evaluated to see what needs to be modified. Then programmers will generate a second generation of prototype program, and the second evaluation is followed.

This repeated procedure will continue until the development is done. Therefore, it can be prevented from spending a lot of time performing software architecture analysis at the beginning, and programmers can benefit from the fast development process.

Figure 2: RAD Software Development Process

Nowadays, for many data acquisition system developers in automation and measurement field,

their application development needs to be done in short time, so they don’t have too much

time for software architecture analysis. In this case, RAD methodology is suitable for them to

adapt, which can help them to short development time.

During their iterations, data acquisition programmers need to continue modifying their prototype programs. Those engineers need to call many libraries from drivers offered by the data acquisition hardware suppliers within their program. The coupling means the dependency relationship between those libraries. When the coupling increases, it brings more complicated relationship between the libraries, making the programmer more difficult to maintain their program during the iterations.

To decrease programming complexity, interfaces of libraries need to be more independent, to make the program low coupling that it can fit in RAD application development methodology.

This can be achieved if the libraries and IDE which if programmers choose can support RAD methodology.

DAQNavi, Advantech data acquisition driver software, is designed with object-oriented programming (OOP) and component-based development (CBD) concept. It offers many software components with an encapsulated mechanism that hides data acquisition detail behavior (operation process), and only shows data acquisition functionality (operation purpose).

These software components are class libraries, which we call it component style class libraries (CSCL). The encapsulated mechanism of these software components will contribute to lower program coupling, helping programmers more easily adapt RAD in their programming.

To define the encapsulated mechanism of data acquisition software component, DAQNavi has designed a series of application Scenarios from most popular data acquisition applications, and defined suitable interfaces including properties, methods and events for the corresponding software component.

For example, an application scenario “Buffered AI” means data acquisition devices will acquire a segment of analog input data by a specific sampling rate, and save them into a block of memory.

So Advantech designed a dedicated software component, which supports a series encrypted

interface for programmers. Programmers can utilize this software component directly without knowing the detailed operations behind it, such as memory allocation, system DMA and interrupt configuration, DAQ device mode configuration, timing initialization, data read operation start and stop, DAQ device reset, system resource release, etc. In summary, using the

“Buffer AI” component, programmers don’t need to take care of the operational details, and only need to define the interfaces.

Moreover, current data acquisition devices are empowered by more and more functionality, making it more difficult to learn. Programmers may spend a lot of time to get used to these DAQ devices and find the necessary functionality they need. Advantech has design a series of mechanisms, called Design-time Support, to help programmers easily understand how to work with DAQNavi by a series of interactive and user-guided wizard, called DAQNavi wizard. This is extremely important for RAD programming because programmers don’t have too much time for program prototyping. It is especially obvious when programmers are handling powerful software components.

The DAQNavi wizard will launch a pop-up window when related DAQ libraries are used (as the component “BufferedAiCtrl” in the figure below), and programmers can intuitively follow the step-by-step instructions to quickly complete the parameters (properties) configuration.

Programmers can then concentrate on their expertise domain for their application, helping to

achieve RAD development process.

Figure 3: DAQNavi Wizard Pop-Up Window for Programming

These parameter configurations need to be saved, in order that the program will follow the configurations every time the program executes. It means the configuration results need to become part of the program. This mechanism is called Persistence. There are several ways to do this. The first is to generate a session of code representing the configuration. The second method is using Serialization and Deserialization, to save configuration value into static data (binary data base) within the program, and read the static data when the program launches.

DAQNavi has developed the persistence mechanism based on different IDE environment that programmers don’t need to take care of it, that it can help to save the program size during development.

In summary, to leverage benefits of RAD programming methodology, data acquisition

programmers need to choose suitable IDE and components. Advantech DAQNavi is a good

example which can achieve this. It helps programmers to decrease program coupling, and easily

follow the concept of RAD programming methodology. Many built-in software designs such as

component-style class library, scenarios, and persistence mechanism help programmers

develop their prototype program in short time, to achieve the shortest time-to-market in their

field.

Ensured Thread-Safe Programming For Reliable Data Acquisition Development

Thread-safety is a computer programming concept used when developing a multi-thread program. It is a computer science methodology. When a program is thread-safe, it can be safely performed from multiple threads, even if the calls happen simultaneously on multiple threads.

When you use thread-safety within your programming, it ensures your program can execute multiple threads at the same time without any problems, such as data overwrite, memory conflict and resource allocation mistake. The importance of thread-safety becomes more and more significant with rise of multi-thread software environments and multi-core CPU platform usage.

Why Thread-Safe Is Important In DAQ Applications?

Without considering thread-safety methodology in your programming, a race condition may occur, which causes unexpected data write/read behavior. Let’s take one example, if there are two threads and will access a same memory address, there will be two possible results as below (the integer value may become 1 or 2, which you cannot predict). This kind of phenomenon is called a race condition.

Figure 1: Race Condition for Multi-Thread Programming

Programmers will always want to avoid race condition because it will make their program out of control. Race conditions are notoriously difficult to reproduce and debug, because the end result is nondeterministic, and highly dependent on the relative timing between interfering threads. So, it will be best to prevent it happening at the begging of the programming. For DAQ applications, if thread-safety is not properly implemented in driver, system will become worse, such as system crashes or shared memory corrupting, when the programmer is designing a multi-thread program.

How to Implement Thread-Safety In DAQ Application?

For industrial automation and measurement applications, DAQ hardware suppliers, such as Advantech, will offer drivers and an SDK for engineers to develop their program. Multi-thread programming becomes more and more popular because people want to leverage powerful computing ability of latest processor, which significantly enhances control and measurement system performance. With this trend, software developers need to take the thread-safety mechanism into consideration, because of the requirement that system reliability needs to be kept the same, as well as the system processing ability to increase with a multi-core and multi-thread environment.

If the hardware driver is not based on thread-safety methodology, then the real users – engineers who develop programs with DAQ hardware, need to think about how to implement thread-safety in their programming. We call it “doing thread-safety in user mode” (or called application level), contrasted against performing thread-safety with a well-designed driver, which called kernel mode (aka kernel level). There are several commonly used ways to perform thread-safety by user mode:

1. Thread-Local Storage

Variables in program are localized so that each thread has its own private copy. These variables

retain their values across subroutines and other code boundaries. This can make the program

thread-safe because variables are local to each thread even the code accessing the variables

may be executed simultaneously by another thread. Thread-local storage is to protect the shared data or variables being used.

2. Mutual Exclusion

Mutual exclusion means access to shared resources (data or device) is serialized; using programming mechanism that ensures only one thread reads or writes to the shared data or device at any time. Semaphore and mutex are two popular methods of achieving this methodology. Both of them are like traffic lights to monitor the usage of the shared resource, and prevent two threads from accessing a shared resource concurrently. However, programmers need to be experienced and careful, as improper usage can cause side-effects such as deadlocks.

3. Atomic Operations

All shared data or variables can only be accessed by atomic operations which cannot be interrupted by other threads. This operation refers to a critical section, which is a piece of code that accesses the shared resource (data or device) that must not be concurrently accessed by more than one thread of execution.

What Is The Difference When Implementing Thread-Safety By User Mode And Kernel Mode?

For DAQ application developers, it might be a nightmare to create thread-safe programs

themselves (through user mode). It’s much better that the DAQ hardware supplier can do

thread-safety by kernel mode. First, DAQ hardware suppliers are usually more familiar with

their own products than the application developers, and suppliers can quickly understand

which part of the code is important for thread-safety consideration. Besides, a lot of evaluation

testing (for example, the program should be tested on different platforms, or the testing period

should be long enough, to ensure reliability) is needed after the thread-safe program is

complete, and this is easier for the DAQ hardware supplier to perform the mass testing and

verification.

For kernel mode implement, it can involve many priority management tasks which can contribute to thread-safety. In general, using kernel mode to implement thread-safety is much easier than using user mode, and will save application developers a lot of programming time.

Moreover, using kernel mode to implement thread-safety will have better execution performance than the user mode in most cases. Thread-safe methodology through user mode usually decreases program execution efficiency.

Advantech, as a global leader in industrial measurement and automation application, can

leverage latest industry technology trend and understand most developers’ need. To help

system developers shorten their programming time and effort, Advantech’s DAQNavi driver,

has been well designed to guarantee its thread-safety through kernel mode. Developers no

longer need to worry about the thread-safe issue using user modes during their development.