Technical Insights ƵŐƵƐƚ, 20ϭ3 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.
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Technical Insights �ƵŐƵƐƚ, 20ϭ3
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.
Technical Insights
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.
�ƵŐƵƐƚ, 20ϭ3
Technical Insights
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
�ƵŐƵƐƚ, 20ϭ3
Technical Insights
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.
�ƵŐƵƐƚ, 20ϭ3
Technical Insights
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.
�ƵŐƵƐƚ, 20ϭ3
Technical Insights
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.
�ƵŐƵƐƚ, 20ϭ3
Technical Insights
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
�ƵŐƵƐƚ, 20ϭ3
Technical Insights
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.
�ƵŐƵƐƚ, 20ϭ3
Technical Insights
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
�ƵŐƵƐƚ, 20ϭ3
Technical Insights
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.
August, 2013
Technical Insights
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
August, 2013
Technical Insights
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.
August, 2013
Technical Insights
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
August, 2013
Technical Insights
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
August, 2013
Technical Insights
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.
August, 2013
Technical Insights
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.
August, 2013
Related Documents
