Electronic system-level design is an electronic design methodology that is defined as “the utilization of appropriate abstractions in order to increase comprehension about a system, and to enhance the probability of a successful implementation of functionality in a cost-effective manner.” The basic premise is to model the behavior of the entire system using a high-level language such as C, C++, LabVIEW or MATLAB, or by using graphical ‘model-based’ design tools. It is a graphical programming platform that helps engineers scale from the design to test stage, for both small and large systems.
LabVIEW (Laboratory Virtual Instrument Engineering Workbench) is a graphical programming language that uses icons instead of lines of text to create applications. In contrast to text-based programming languages, where instructions determine the order of program execution, LabVIEW
uses dataflow programming, where the flow of data through the nodes on the block diagram determines the execution order of the VIs and functions. VIs, or virtual instruments, are LabVIEW programs that imitate physical instruments.
You can use LabVIEW to communicate with hardware such as vision, data acquisition and motion control devices as well as GPIB, VXI, PXI, RS-232 and RS-484 devices. It also has built-in features for connecting your application to the Web using the LabVIEW Web Server and software standards such as ActiveX and TCP/IP networking.
LabVIEW lets you create test and measurement, data acquisition, data logging, measurement analysis and report generation applications. It is also possible to create stand-alone executables and shared libraries, like DLLs. LabVIEW contains a comprehensive set of tools for acquiring, analysing, displaying and storing data as well as tools to help you troubleshoot your code
According to NI, the USP of LabView is that even people with limited coding experience can write programs and deploy test solutions in a reduced time frame when compared to working with more conventional or competing systems.
LabVIEW programs are called virtual instruments, or VIs, because their appearance and operation imitate physical instruments, such as oscilloscopes and multimeters. Every VI uses functions that manipulate input from the user interface or other sources and display that information or move it to other files or other computers.
The VIs contain three components—a front panel, a block diagram, and the icon and connector pane.
• Front panel—Serves as the user interface.
• Block diagram—Contains the graphical source code that defines the functionality of the VI.
• Icon and connector pane—Identifies the interface to the VI so that you can use the VI in another VI. A VI within another VI is called a subVI. A subVI corresponds to a subroutine in text-based
In LabVIEW, you build a user interface by using a set of tools and objects. The user interface is known as the front panel. In LabVIEW, you build a user interface, or front panel, with controls and indicators. Front panel objects appear as terminals on the block diagram. The most common controls are knobs, dials, push buttons and other input devices. The most common indicators are graphs, LEDs and other displays.
Nodes are objects on the block diagram that have inputs and/or outputs and perform operations when a VI runs. They are analogous to statements, operators, functions, and subroutines in text-based programming languages.
Structures are graphical representations of the loops and case statements of text-based programming languages. Use structures on the block diagram to repeat blocks of code and to execute code conditionally or in a specific order.
After you build the user interface, you add code using VIs and structures to control the front panel objects. You then add code using graphical representations of functions to control the front panel objects. This graphical source code is also known as G code or block diagram code. The block diagram contains this code. In some ways, the block diagram resembles a flowchart.
Flowchart, which is the back panel of the program, realizes the function design of the software. It includes control signal acquisition, the overall architecture of the software, calculations and so on. By editing the program of the back panel, the program icons of the back panel are
corresponding to the control program of the front panel. Only some built-in functions and program frames are running in the background independently.
Control System Design
The control design is a process that involves developing mathematical models that describe a physical system, analyzing the models to learn about their dynamic characteristics, and creating a controller to achieve certain dynamic characteristics.
Simulation is a process that involves using software to recreate and analyze the behavior of dynamic systems. Simulation provides insight into the behavior of dynamic system
LabVIEW has several additional modules and Toolkits for Control and Simulation purposes, e.g., “LabVIEW Control Design and Simulation Module”, “LabVIEW PID and Fuzzy Logic Toolkit”, “LabVIEW System Identification Toolkit” and “LabVIEW Simulation Interface Toolkit”
Model-based design (MBD) is an emerging development methodology for modern software systems. Its efficiency has been demonstrated in the development of safety-critical embedded software systems in industry. MBD promotes the use of graphical domain-specific notations to create executable design models. Automated code generation from design models to implementation is an important feature of MBD.
MBD methodology consists of Five basic phases from requirement analysis, system design, implementation, integration to continuous verification. In the MBD, the design specification should be formulated in terms of executable models. . It can unambiguously model the entire system functionality, including the environment, physical component and design algorithm. Compared with text-based design specifications, these models have one distinguished benefit of supporting early validation and testing via models simulation.
Model-based validation and verification (V&V)
Moreover, continuous model-based verification and validation as another feature of the MBD enable early identifying design flaws so as to avoid costly late-stage design fixes. Model-based V&V represents a set of V&V techniques continuously applied through the MBD
process. All of them contribute to three important benefits: (1) Detect errors early in the development; (2) Reuse test throughout development process. (3) Reduce use of physical prototypes. More graphical system modeling tools started supporting MBD, such as LabVIEW from National Instruments (NI).
Validation targets at answering the question “Are we developing the right system?”, while verification aims at answering a different question “Are we developing the system right?” Formal method and testing are two kinds of verification approaches. In mission-critical systems, where bugs may incur disastrous effects, formal methods are employed to guarantee the correct behavior with respect to the system requirements.
In comparison, testing is scalable and easy to apply although it is limited to detect bugs, but cannot ensure the correctness. Unit testing, integration testing and system testing are three common testing practices in software systems development.
Many V&V techniques are applied at different MBD steps. During the initial requirement analysis step, a validator is applied to ensure that extracted requirements correctly match the intended use. In the design step, a model tester or a simulator can be utilized to check whether the executable design specification satisfies the requirements obtained in the first step. Unit testing is typically applied to check if the implementation is consistent with design models. Integration testing and system testing are initiated from the integration step.
Formal methods are applied to check critical components in both design and implementation. Model checking is one of the most commonly used formal techniques. Model checking can be fully automatic without much expertise in formal logic reasoning. It differs from testing as it aims at an exhaustive exploration of the state space of the model, thereby providing a correctness guarantee that is rarely achieved by means of testing. More importantly, when the models under verification fail to satisfy a given specification, counterexamples (i.e.,error traces) can be generated, which illustrate the erroneous behaviors of the system design. This information
can be very valuable for debugging.
Automated code generation
Increasing number of automated code generation tools has been created in past ten years. LabVIEW C Generator. It allows users to quickly develop design algorithms graphically in LabVIEW, create the C code that translates from the algorithms, and integrate the C code into any third-party embedded toolchain to download, run and debug it.
As most embedded systems design efforts in industry have moved to from simple 8-bit MCUs to modern 32-bit MCUs with real-time computing and networking capabilities, the software development became more complicated. NI supports using LabVIEW to directly program various microcontrollers from 8-bit microprocessor on the Ardunio, to 32-bit ARM Cortex-M and ARM Cortex-A series microprocessors
The University of Arizona used Labview to Design a Payload Control System
Stephen Horan and others have developed a combined ground station and flight computer control software package using LabVIEW. These computer systems are used to acquire data from sensors, control communications links, provide automatic data acquisition capabilities, and provide a user interface.
The LabVIEW environment provides the following benefits • LabVIEW has built-in tools to assist with the development of the state machine that forms the basis for the control program
• LabVIEW has libraries of analysis functions to make code development easier; for example, there is a library of routines for manipulating digital images including making JPEG formats and reducing the picture size to make thumbnail images
• LabVIEW has a library of widgets to assist in the construction of the user interface for
the ground station computers.
There are two computer systems required in this system: one comprising the flight computer and one in the ground station. The operating system chosen for the system is Windows 2000. This provides the necessary support for development software and its size is compatible with the constraints of the 4 GB flash drive. A design goal is to have the operating system take up no more than 25% of the available drive.
The ground station is designed to operate completely with laptop computers. The laptops chosen are standard laptops running Windows XP.
The design control software for the payload was based on LabVIEW and is run as an executable in both the ground station and the flight computer. Software is designed as a state machine in both elements. The software also has the ability to initiate timing loops so that the operator does not need to explicitly command selected operations at each instance. Rather, the operator can set the flight computer to take actions autonomously. This includes both selected data acquisition and sequences of discrete commands.
Software is designed as a state machine
As mentioned above, the control programs in the flight computer and the groundstation are based
on state machines. This method is used as a way to structure the program and it allows for easy
code development because each function is compartmentalized and can be independently
verified. This method also allows the code developer to build up the entire control program from
basic functions to the final configuration by adding new states to the overall design. As the code
is developed, modules for specific functions such as configuring communications ports are used
in both the flight computer and ground station code.
The basic control methodology is to first configure the operational parameters in the “Init” state, then initialize the command and telemetry communications RS-232 ports, radio, and modem in the “Port” state, and then go into a wait look for the groundstation to initiate communications in the “Connect” state. Once communications are established with the groundstation, the Flight Computer enters a continuous loop of states until a termination command is received.
“We were able to use the LabVIEW programming to develop the programs for the flight computer
and groundstation and ground station to control a payload over a radio link. To date, these
programs have been used in payload check-out and training. The state machine capabilities in
LabVIEW greatly assist in the code development. The LabVIEW environment facilitates code
sharing between the flight computer and groundstation programs. The environment also
facilitates the development of the user interface.”