Virtual Instrument and Traditional Instrument

Traditional Instrument
Collect data from environment, display, analyze, store. Eg.
Oscilloscope, Spectrum Analyzer
Virtual Instrument
Industry Standard Computer with application Software +
Hardware Boards( like DAQ) + Driver Software, performs
functions same as that of traditional instruments
User defined Instruments, Can be modified according to user
needs
Engineer can customize the acquisition, analysis, storage,
sharing and presentation functionality.
Traditional instruments and vis largely uses same
architectural components, but radically different
philosophies.
 Traditional Instrument VI
 Hardware and Software in VI
Role of Hardware in VI
Laptops and Desktops with existing standards such as USB, PCI,
Ethernet etc,
Data Acquisition
Role of software in VI
Engineers can create their own applications
Can create their own user interface
VI software can be divided into several different layers.
Application Software
Test and Data Management Software
Measurement and Control service Software
 Application Software:
Most people think immediately of the application software
layer. This is the primary development environment for
building an application. It includes software such as
LabVIEW
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 measurement and control services layer includes drivers,
such as NI-DAQmx, which communicate with all of the
hardware.
 Data Flow Programming
Data Flow is the software architecture
changing the value of a variable should automatically force
recalculating the values of all dependent variables.
Features
Flow-based
Following a flow chart
Cell-based
ability to program individual cells to recalculate the output based
on changes in the contents of the cells.
Reactive
automatic recomputing of the output whenever any of the input
values change.
 Graphical Programming
Represents applications as a directed graph, similarly to a
dataflow diagram.
Applications are represented as a set of nodes (also called
blocks) with input and/or output ports in them.
Nodes are connected by directed edges that define the flow of
information between them.
Each node is an executable block that has data inputs,
performs transformations over it and then forwards it to the
next block.
Most visual programming languages that use a block-based
architecture for representing their workflow are indeed based
on DFP
Eg. LabVIEW, VHDL
 Dataflow Programming v/s Conventional
Programming
Execution not possible unless the Execution can occur without all inputs,
program is designed start-to-end resulting in a run-time error
No coupling-related problems when Using dependent variables has to be
using variables that depend on other checked manually or by program and
variables
cannot happen automatically or
dynamically.
Continuous execution mode and run-
time editing of any inputs possible Continuous execution and run-time
editing of inputs cannot be done once
Every input change can be dynamically
observed as a corresponding change in the execution has started
the output No input change possible once
Inputs need not be known until run- execution has started
time Programs must know the inputs and
Benefits a lot from graphical how to handle them before execution
programming, since the flow of data Involves a lot of programming code to
can actually be visual be able to see dynamic flow of data
 Real Time Systems(RTS)
A system is said to be real-time if the total correctness of an
operation depends not only upon its logical correctness but
also upon the time in which it is performed.
predictability of the system behavior is the most important
concern.
Eg. Defense systems, Space systems, Networked multimedia
systems etc
 Classification of RTS
By characteristic and application:
Hard RTS
Missing time dead line causes total system failure
Dead line-The time at which a real-time systems has to
produce a specific result
Eg. Airline traffic system
Soft RTS
Missing some time dead lines are tolerable, value for a result
after its deadline, is not zero
Eg. Streaming audio video
Firm RTS
Missing some time dead lines are tolerable, value for a result
after its deadline, is zero
Eg. Storm forecasting System
 Fail Safe RTS
has a safe state in the environment that can be reached
in case of a system failure , (e.g., train signaling)
Fail Operational
no safe state can be reached in case of a system failure
(e.g., a flight control system of airplane).
Computer system has to provide a minimum level of
service, even after the occurrence of a fault.
By design and implementation:
Guaranteed-timelines/Best-effort
Resource-adequate/Resource-inadequate
 Real Time Operating System(RTOS)

Operating system (OS) is responsible for managing the

hardware resources of a computer and hosting applications that
run on the computer
RTOS performs these tasks, but is also specially designed to
run applications with very precise timing and a high degree of
reliability.
Bounded latency
Loop prioritization
Eg. RT Linux, LabVIEW RT
 Embedded Controllers

commonly microcontrollers that have real-time computing

capabilities
Digital Signal Processors (DSP) are a common class of
dedicated, real time embedded controllers.
Advantages
Better performance
better reliability
smaller size
lesser complexity
 Open Connectivity
Open standards which can be adopted by any provider of
control systems, instrumentation, and process control for
multi-vendor interoperability.
Object Linking and Embedding(O.L.E)
compound document standard developed by Microsoft
Corporation
It enables you to create objects with one application and then
link or embed them in a second application
The concept of OLE was extended to process control and
eventually led to the founding of OLE for Process Control
(OPC)
aim was to create a communication standard that is widely
acceptable such that it enables data exchange among
devices/control applications manufactured/developed by
different vendors.
 OPC Classic Architecture
Standards are specified for the acquisition and control of
process data, alarm and event records, historical data, and
batch data to multi-vendor enterprise systems and between
production devices"
Eg. Sensors, instruments, PLCs, RTUs, DCSs, HMIs,
historians, trending subsystems, alarm subsystems and more as
used in the process industry, manufacturing
Windows only
Low security
OPC Classic Architecture
 OPC Unified Architecture(OPC UA)

Is an industrial M2M communication protocol for

interoperability developed by the OPC Foundation
Enables vendors to implement OPC on non-Microsoft systems
and embedded devices.
Enable enterprise wide data sharing and communication across
embedded systems, controllers, mobile phones, workstations,
servers, and other enterprise-standard hardware
Multi-platform implementation, including portable ANSI C,
Java and .NET implementations
High Security
OPC .NET Architecture
OPC UA