Virtual Instrumentation

Simulated Physical Instruments

are called virtual instruments
Scientific Computing or Computational Science:
The use of computers for solving problems related to science and Engineering.

In scientific computing problems are solved by experimental or applied research, modelling

and simulation.

Scientific computing applications usually follow three step process: Data Acquisition, Data
Analysis and Data Visualization/Presentation.

Virtual Instrumentation Model (1980)

Virtual Instrumentation Model
 NI Graphical System Design (GSD) Model

Main Focus of GSD model:

1. Accelerate the research and development cycle.
2. Delivering mathematical models to embedded real time computers faster and easier

The design flow acceleration is achieved by using NI LabVIEW software and its G
programming language as a common system level design tool for all the different phases in
the design-to-deployment flow.
 Graphical System Design Model

The Virtual instrumentation model is applied in each of the three phases of the graphical
system design model because data acquisition, analysis and presentation functions are used
in the design, prototyping and deployment phases.
Design phase of the Graphical System Design Model
Design Phase – A Virtual Plant/Process is going to be created in this phase
1. A Mathematical model of the system including sensors, actuators, plants and controllers
is developed.
2. The simulation is carried out under a variety of initial conditions and constraints.
3. Different numerical methods is used with the objective of validating the performance of
the model and optimising the model.

This is usually a software centric process with strong focus on numerical methods/analysis
and mathematics.

For complex or computationally intensive models high performance computing using Grid
computers, Standard computers with Graphical processing Units (GPU) and multicore based
computers is a key factor in this phase.

LabVIEW supports the multicore processors and parallel programming.

Prototyping phase of the Graphical System Design Model
Prototype Phase – Hardware In the Loop (HIL) test to optimise the model.
1. The virtual plant/process model can be used for HIL tests.
2. Signal processing and analysis as well as visualisation can be implemented online while
data is measured and acquired or while the process is being controlled.

Hardware in the Loop

The prototyping is executed on standard PC’s or PXI computers.
PXI- PCI eXtensions for Instrumentation (PXI)

The NI PXIe-8135 embedded

controller features a 2.3 GHz
quad-core Intel Core i7-
3610QE processor.
Signal conditioning involves
amplification, linearization, isolation, attenuation, level shifting, filtering and other operations
that are applied to a signal prior to acquisition. Signal conditioning can also prepare output
signals created by signal generation hardware.

In most cases, some form of signal conditioning is required between the data acquisition
hardware and the sensors/actuators. Some data acquisition devices already include built-in
signal conditioning; however, in those cases where the built-in functionality already
incorporated in the data acquisition device may not be sufficient or when it is simply absent,
some type of external signal conditioning is required.

For this purpose, researchers can choose from several options, including external signal
conditioning devices that they can add to the data acquisition device (SCC, SCXI) and build in
where the data acquisition device and the SC circuitry are integrated in the same device (NI C
Series, SC Series, and Compact FieldPoint devices).
Curve fitting
Interpolation and extrapolation
Optimization
Linear algebra
Probability and statistics
Differential equation solvers
Signal processing
Integration and differentiation
Deployment phase of the Graphical System Design Model
Deployment Phase –Software is transferred into hardware.

Finally, the model (controller, analyser, or both) is deployed in the field or lab using
1. PC (desktop, server, or industrial) or
2. PXI or
3. It can be downloaded to a dedicated embedded controller such as CompactRIO, which
usually operates as a stand-alone mode and in real-time (deterministic) mode.

When using the LabVIEW Real-Time Module, symmetric multiprocessing (SMP) techniques
can be easily applied.

For large systems, with high-channel counts or involving modular instruments such as
scopes, digital multimeters (DMMs), RF vector signal analyzers, and dynamic signal
acquisition (DSA) devices, the PXI platform is more appropriate.

The transition from the prototyping phase to the deployment phase can be very fast and
efficient because the same set of tools used for prototyping can, in most cases, be applied
to the final deployment of the system in the field.
In many cases, the system is deployed as a headless system (no monitors or interfaces to
the user), executing the analysis/control algorithms in real time as a dedicated device.

If on-the-field graphical user interfaces (GUIs) or operator interfaces (OIs) are needed,
the LabVIEW Touch-Panel Module and industrial-grade monitors with touch-sensitive
screens can be used locally.

Remotely, data can be shared and visualized via Ethernet with applications developed
using LabVIEW and the LabVIEW Data logging and Supervisory Control Module running
on one or more PCs distributed in a network.
Why we Need Graphical System Design ?
Nearly 50% of designs are late or never to market and nearly 30% fail after release .

Many of these challenges are a direct result of embedded systems becoming more complex
as average code size has increased nearly 10X over the last 5 years .

Additionally, with embedded systems becoming more common place, many domain
experts, such as machine builders, test engineers, or control engineers, need embedded
technologies to develop their systems and do not currently have the expertise required to
develop embedded systems.

With the increase in system complexity and with more and more non-embedded experts
needing this technology, there is a strong need for a new approach to embedded design.

Graphical system design is a revolutionary approach to solving design challenges that

blends intuitive graphical programming and flexible commercial-off-the-shelf (COTS)
hardware to help engineers and scientists more efficiently design, prototype, and deploy
embedded systems.

Using the graphical system design approach will enable us to use a single environment
across all stages of design to increase productivity, save money and bring embedded
technology to the domain expert.
Another key requirement for embedded system design is that the software platform
addresses the various algorithm design views common in real-time embedded design
 Typical embedded system software and hardware design flow

Drawbacks:

If we are creating custom hardware for final deployment, it is difficult to have the software
and hardware developed in parallel as the software is never tested on representative
hardware until the process reaches the system integration step.

Additionally, we do not want the software development to be purely theoretical, because

waiting until the system integration test to include I/O and test the design with real signals
may mean that we discover problems too late to meet design deadlines.
Solution 1:
Use an evaluation board to prototype the systems.
Drawback:
1. These boards often only include a few analog and digital I/O channels and rarely include
vision, motion, or ability to synchronize I/O.
2. Additionally, designers often have to waste time developing custom boards for sensors or
specialized I/O, just to complete a proof of concept.

Solution 2:
Using flexible COTS prototyping platforms instead can truly streamline this process and
eliminates much of the work required for hardware verification and board design.

Stream-lined development flow with Graphical System Design

Typical components of an embedded system

1. For most systems, a prototyping platform must incorporate the same components of
the final deployed system.

2. These components are often a real-time processor for executing algorithms

deterministically, programmable digital logic for high-speed processing or interfacing
the real-time processor to other components, and varied types of I/O and peripherals.

3. Finally, as with any system, if the off-the-shelf I/O doesn’t serve all of your needs, the
platform should also be extensible and customizable when needed.
NI CompactRIO

1. National Instruments offers several types of prototyping platforms including NI

CompactRIO that contain all of the basic building blocks of an embedded system.
2. The controller contains a 32-bit processor running a real-time operating system.

3. The CompactRIO backplane contains an FPGA that can implement high-speed

processing and actually configures and provides interfaces to the I/O modules which
include options for analog input and output, digital input and output, and
counter/timer functionally.

4. Each of the modules includes direct connectivity to sensors and actuators as well as
built-in signal conditioning and isolation. A module development kit is also available
that allows developers to expand the platform to include custom modules – all
plugging into this COTS framework.
Virtual Instrumentation Using LabVIEW
National Instruments LabVIEW, a premier virtual instrumentation graphical development
environment, uses symbolic or graphical representations to speed up development.

The software symbolically represents functions. Consolidating functions within rapidly

deployed graphical blocks further speeds development.

Another virtual instrumentation component is modular I/O, designed to be rapidly

combined in any order or quantity to ensure that virtual instrumentation can both monitor
and control any development aspect.

Using well-designed software drivers for modular I/O, engineers and scientists quickly can
access functions during concurrent operation.

The third virtual instrumentation element – using commercial platforms, often enhanced
with accurate synchronization – ensures that virtual instrumentation takes advantage of
the very latest computer capabilities and data transfer technologies.

This element delivers virtual instrumentation on a long-term technology base that scales
with the high investments made in processors, buses, and more.
What is a virtual instrument and how is it different from a
traditional instrument?
Virtual instruments are defined by the user while traditional instruments have fixed,
vendor-defined functionality.

Traditional instruments (left) and software based virtual instruments (right) largely share the
same architectural components, but radically different philosophies
One Application -- Different Devices
Many Applications, One Device
Role of Hardware in Virtual Instrumentation
I/O plays a critical role in virtual instrumentation. To accelerate test, control, and design, I/O
hardware must be rapidly adaptable to new concepts and products. Virtual instrumentation
delivers this capability in the form of modularity within scalable hardware platforms.

National Instruments modular I/O covers diverse I/O types so that engineers and scientists
can select I/O across many categories including analog, digital, counter/timer, image, and
motion.

Modular I/O also includes modular instruments such as oscilloscopes, meters, arbitrary
function generators, LCR meters, and more. With the wide variety of excellent I/O, engineers
can randomly select any I/O type required by the application. Careful engineering ensures
that these diverse I/O types work seamlessly together, meaning they can efficiently share
backplane and timing resources.

Standard hardware platforms that house the I/O are important to I/O modularity. Laptop and
desktop computers provide an excellent platform where virtual instrumentation can make
the most of existing standards such as the USB, PCI, Ethernet, and PCMCIA buses. Using
these standard buses, National Instruments can focus on measurement hardware innovation
while benefiting from inevitable PC platform innovation (for example, USB 2.0 and PCI
Express).
Benefits of Ethernet for virtual instrumentation

Virtual instrumentation systems frequently use Ethernet for remote test system control,
distributed I/O, and enterprise data sharing. The primary benefit in using Ethernet is cost.
Ethernet provides a low-cost, moderate-throughput method for exchanging data and
control commands over distances.

However, due to its packet-based architecture, Ethernet is not deterministic and has
relatively high latency. For some applications, such as instrumentation systems, the lack of
determinism and high latency make Ethernet a poor choice for integrating adjacent I/O
modules. These situations are better served with a dedicated bus such as PXI, VXI, or GPIB.

Often, a virtual instrumentation system uses other buses in conjunction with Ethernet.
Typically, a network node consists of modular I/O clusters. Each cluster uses a high-speed,
low-latency bus to exchange data between different I/O modules. To communicate with
neighboring nodes, transfer data to a remote location, or accept commands from a remote
location, the network nodes use the Ethernet network.
Benefits of Ethernet for virtual instrumentation

Example of Ethernet/LAN based virtual instrumentation system

 Role of Software in Virtual Instrumentation
Every virtual instrument is built upon flexible, powerful software by an innovative engineer
or scientist applying domain expertise to customize the measurement and control
application. The result is a user-defined instrument specific to the application needs.

Virtual instrumentation software can be divided into several different layers.

Application Software: This is the primary development environment for building an
application. It includes software such as LabVIEW, LabWindows/CVI (ANSI C), Measurement
Studio (Visual Studio programming languages), SignalExpress, and VI Logger.
Test and Data Management Software: Above the application software layer the test
executive and data management software layer. This layer of software incorporates all of
the functionality developed by the application layer and provides system-wide data
management.

Measurement and Control Services Software: The last layer is often overlooked, yet critical
to maintaining software development productivity. The measurement and control services
layer includes drivers, such as NI-DAQmx, which communicate with all of the hardware. It
must access and preserve the hardware functions and performance. It also must be
interoperable –it has to work with all other drivers and the many modular I/O types that
can be a part of the solution.
Virtual Instrumentation Software
Data Flow Vs Control Flow
Graphical Programming Vs Text based Programming
 Text-based Programming
Syntax must be known to do programming
The execution of the program is from top to bottom.
To check for the error the program has to be compiled
or executed.
Front panel design needs extra coding or needs extra
work.
Text based programming is non interactive.
This is text based programming where the
programming is a conventional method.
Logical error finding is easy in large programs.
Program flow is not visible
It is text-based programming
Passing parameters to subroutine is difficult
Graphical Programming
Syntax is knowledge but it is not required for programming
The execution of program is from left to right.
Errors are indicated as we wire the blocks.
Front panel design is a part of programming.
Graphical programming is highly interactive.
The programming is data flow programming.
Logical error finding in large programs is quite
complicated.
Data flow is visible
It is Icon based programming and wiring
Passing parameters to Sub VI is easy.