Ever-increasing numbers of technologies are converging into the simplest of devices, technologies that expand these devices beyond their main function. A good example is Apple’s iPhone, which combines the functionality of multiple devices into a single compact unit.

The iPhone’s flexible user interface changes based on the function, whether it involves making a phone call or listening to music. Here, we can clearly see the underlying technology that makes this possible—software, and how it integrates with hardware.

By employing a technique known as graphical system design, engineers and scientists developing electronic systems can be more involved throughout the development cycle from design, through prototyping and verification, to final deployment and functional test. Graphical system design integrates software developed in a flexible graphical development environment, a target computing engine, either real-time or based on a general-purpose operating system, and mandatory associated I/O and communications.

GET MORE FROM YOUR SOFTWARE
Let’s take a step back and look at some elements of software design that are limiting factors, especially for embedded systems. A large proportion of people developing embedded systems don’t specialise in writing code for embedded systems; they are domain experts in their own field. For example, a machine builder developing a system to improve retinal disease treatment would have detailed knowledge of ophthalmology, but not how to write embedded C code. However, for those individuals who are experts at integrating embedded systems, some elements of development remain non-trivial. For instance, writing driver-level code to interface with I/O points, managing threads of execution, timing, synchronisation, and resource scheduling all take up a large amount of project time. Lest we not forget the explosion of multicore processors onto the marketplace.

A method to abstract the complexity of programming embedded systems, both in single processor and multicore designs, is to choose a software-tool flow based on a graphical approach. The advantage of this methodology is that many graphical-based tools, such as National Instruments’ LabVIEW graphical development environment, include native functionality to handle complex programming and timing.

Therefore, rather than deal with low-level details, the embedded developer can focus on the critical pieces of code, such as the intellectual property (IP) of the application itself. This ultimately differentiates it from other embedded designs.

Various high-level views within NI LabView help design the IP. For example, an engineer could describe control tasks using a model-based view, digital-signalprocessing tasks using data flow, and mathematical formulae textually. NI LabVIEW accommodates these different views by including text-based math, continuous time simulation, state diagrams, and graphical dataflow models all within the same development environment.

Dr. Edward Lee, a leading researcher for embedded software platforms at the University of California at Berkeley, refers to these various design views as models of computation. Such models match the way system designers view their system and, thus, help minimise the complexity of translating system requirements into a software design.

HARDWARE—LET’S TALK TO THE REAL WORLD
From early on in a project, seamless integration with realworld signals is extremely important. Initially, it may involve taking measurements from a target system that’s to be controlled and feeding the time-domain signals into a software simulation containing in-work versions of mathematical algorithms.

Moving forward, easier integration of the developing software into the real-world to quickly test out “what if” scenarios will reduce time spent in these early development stages. On top of that, it will identify problems earlier in the design flow, saving on what would be costly corrections later in the cycle.

As modules of the software become complete, it’s possible to move into a rapid-control-prototyping (RCP) phase, with certain provisions. Prerequisites for RCP include the productive graphical development environment that we’ve been discussing, along with commercial-off-the-shelf (COTS) processors and I/O modules.

An example of such a system is National Instruments’ CompactRIO (Fig. 1), a low-cost reconfigurable control and acquisition system designed for applications that require high performance and reliability. The system combines an open embedded architecture with small size, extreme ruggedness, and hotswappable industrial I/O modules. NI CompactRIO is powered by reconfigurable I/O (RIO) FPGA technology.

Using such a prototyping phase, custom hardware isn’t needed until later in the design cycle. This gives software developers more licence to make design changes that directly effect hardware requirements.

Continued on Page 2