Five Steps to Define Your Next Real-Time Embedded Control System

Publish Date: Sep 05, 2014

Table of Contents

1.
2.
3.
4.
5.
6.

Step 1: Create and document a long-term plan for hardware reuse.

Step 2: Consider higher-level design tools.
Step 3: Explain your solution for driver-level embedded middleware.
Step 4: Focus on design reuse, configuration, and simulation.
Step 5: Make tough decisions and understand the financial costs of embedded design.
Do More with Fewer Resources

In these tough economic times, can you risk being over budget or late to market because your real-time systems embedded
middleware software was unreliable? While deployment hardware manufactured cost-of-goods and development tool costs appear
obvious when designing an embedded system, the person-hours for development, integration, and test costs are often forgotten
when calculating the total investment of releasing a product. Explore the new NI product introduction process and the five steps to
defining your next real-time embedded control system to gain an explanation of the need for proven embedded middleware drivers
and common hardware architectures in addition to insight into the traditional selection process of hardware and software
development design tools all which save you time and money on the bottom line.
1. Step 1: Create and document a long-term plan for hardware reuse.

National Instruments, an ISO 9001-certified company, uses a quality management system framework to define, communicate,
measure, and improve its processes to deliver high-quality, reliable products to its customers. NI uses a new product introduction
(NPI) process to take products from concept to delivery, specifying the required steps that are followed in research, design,
development, quality assurance, marketing, manufacturing, sales, and support. Figure 1 lists some of the process steps design
teams should follow when building an embedded system. It is important to limit the actual development cost and understand that it
includes not only direct material and costs of goods sold (COGS), but also the costs and time needed for parts procurement,
design, production, software, and operating system adaptation. Development issues and associated costs do not end with the final
manufacturing of hardware circuitry. Test, support, warranty, and maintenance are downstream issues that you also must address.

Figure 1. Designing a reliable product requires a documented design process that is traceable from start to finish.
2. Step 2: Consider higher-level design tools.

After developing a documented process for the hardware life cycle, you can evaluate which software development tools you need.
Real-time embedded software design is a task you should not underestimate because the combination of multitasking, real-time
determinism, concurrency, synchronization, memory management, and restrictive timing presents challenges even for specialists.
Many of todays real-time embedded hardware platforms, described in Figure 2, require not only complex microprocessor
technologies, but also reconfigurable hardware such as field-programmable gate arrays (FPGAs). Complex architectures such as
these are required for many of todays medical, industrial, and clean technology deployments due to the needs of real-time
software, high-performance I/O feedback, FPGA parallelism, and tight control strategies. Software complexities to solve these
tasks are not linear but exponential.

1/5

www.ni.com

Figure 2. This diagram shows the software execution flow for a real-time plus reconfigurable FPGA control system architecture.
Figures 3 and 4 show how you can abstract kernel complexities with a graphical tool like NI LabVIEW software while allowing for
low-level control. In addition to underlying multitasking frameworks, you need board support packages (BSP) and threadsafe
middleware functions to ensure real-time behavior in microsecond slices of program execution.

Figure 3. Graphical development tools help abstract real-time kernel services while still allowing for complete application control.

Figure 4. This example application of a large-scale subsea pipeline-monitoring system shows the interaction of multitasking,
timing, process I/O, and signal processing with LabVIEW. (Courtesy of Schmid Engineering)
3. Step 3: Explain your solution for driver-level embedded middleware.

Development tools, real-time operating systems (RTOSs), programming languages, compilers, debuggers, and libraries are just
the starting point to ensure your embedded design process is successful. Booting issues alone require significant design
considerations such as which boot method you should use. Thorough evaluation of any needed industrial extensions, an
understanding of how the boot-loader hands off to a stand-alone application or an OS loader, loader porting, and software update
management are all items you must consider. Many design teams underestimate these challenges as well as the software
integration challenges that todays real-world analog I/O connectivity and associated real-time multithreaded drivers present.
For example, Figure 5 describes the embedded middleware software design hierarchy used for the industrial automation and
design prototyping product NI CompactRIO. These middleware drivers and system services are deployed by thousands of
applications and customers. The NI new-product-introduction goal reused these same drivers when NI repackaged CompactRIO
into the board-level form factor NI Single-Board RIO. NI Single-Board RIO is used as a starting reference design platform for
2/5

www.ni.com

applications and customers. The NI new-product-introduction goal reused these same drivers when NI repackaged CompactRIO
into the board-level form factor NI Single-Board RIO. NI Single-Board RIO is used as a starting reference design platform for
OEMs and embedded design engineers. Designers can easily add custom circuitry to NI Single-Board RIO to fit their application
need, while still taking advantage of NI R&D roadmap investments in drivers and services.

Figure 5. Embedded middleware components must be designed, validated, and supported to ensure system deployment success.
Oftentimes, embedded designers ensure the safety of multithread-safe libraries by locking resources meaning when one
thread calls the function, that function or even the entire library is locked so that no other thread can call it. In a parallel situation, if
two different paths of your code, or threads, are attempting to call into the same library or function, the lock forces one of the
threads to wait, or block the thread, until the other one completes. Such coding architectures can limit performance and
functionality. Combining parallel programming techniques with reentrancy in your functions can help drive code performance.
Parallel and multithread-safe embedded middleware drivers are an integral part of CompactRIO and NI Single-Board RIO, as
shown in Figure 6. You can call both multithread-safe and reentrant functions by multiple threads at the same time and still
operate correctly without blocking. This is an important feature for writing parallel code and optimizing performance. If you are
using or writing code that does not have reentrant execution embedded middleware drivers, it could cause your performance to
decrease, or worse crash. Your code has to wait until the other threads are done using each function before it can access them.
Reentrancy is an important consideration to eliminate any unnecessary dependencies in your code.

Figure 6. This chart shows the CompactRIO and NI Single-Board RIO driver and services architecture.
4. Step 4: Focus on design reuse, configuration, and simulation.

It is best to architect your hardware design for reuse. For example, with a common hardware architecture similar to Figure 7, a
design team can change the I/O subsystems to meet an application need while having minimal effect on low-level and middleware
drivers. A design team can also build on top of this foundation with utilities to allow easy redeployment to new applications.

3/5

www.ni.com

Figure 7. This diagram illustrates the NI Single-Board RIO hardware architecture.

NI built configuration software utilities and dynamic I/O reconfiguration capabilities into its CompactRIO and NI Single-Board RIO
framework to save time in setup and reuse for end-application programmers and custom circuitry designers. NI Measurement &
Automation Explorer (MAX) configuration software automatically detects your custom and National Instruments I/O circuitry
installed in the system. Integrated diagnostic tests of I/O peripherals also ensure that I/O devices function properly.
Planning for dynamic configuration helps hardware reuse and speeds design while providing the ability to begin high-level
application coding without new I/O circuitry. It can be problematic if driver software and the associated APIs do not execute
properly or return device-specific errors without the I/O circuitry installed. To get around this, software developers often create
simulation subroutines that temporarily replace the I/O circuit code within the application. This method makes it difficult to get a
start on the application development and makes it virtually impossible to debug the code. The NI middleware driver architecture
includes functionality to integrate simulation code directly into the functional driver, thus simplifying code reuse and debugging.
5. Step 5: Make tough decisions and understand the financial costs of embedded design.

If the return on investment of the engineering cost incurred in product development is justified by eventual profits, then you have
made a good decision. This is never as simple as it seems; if you just add the cost of the board components plus the hardware
and software development time, you could be grossly underestimating the total investment. You must consider other hidden
costs before you accurately assess the true cost of the job.
For example, manufacturing and inventory costs typically account for an additional 20 to 30 percent of the systems COGS. In
addition, on average, more than 30 percent of total software development time and 75 percent of software debugging time is spent
on operating system, driver, and middleware development though by choosing a packaged platform with integrated middleware
software, you can eliminate the need for this board bring-up. You also need to account for other hidden costs including
environmental regulations, validation, unexpected end-of-life components, and last-minute specification changes, which force
design alterations and complete redesigns. Finally, the least tangible but potentially most impactful cost is the opportunity cost of
spending engineering time on designing this aspect of the system rather than the key differentiation components of your product
that defines its unique value proposition.
Once you assess the engineering investment, you can calculate a simple break-even financial point. Imagine you assign
engineers to spend nine months developing a custom board from specs to shipping for an investment of approximately $300,000
USD. Next, you spend $25,000 USD each on pre-equipment, prototyping, prerelease units, tooling, and other nonrecurring
engineering expenses, raising the total investment to $400,000 USD. After you complete this effort, the custom design cost of
goods is $400 USD less than an off-the-shelf platform. Using Equation 1, you see that the investment breaks even at unit 1,000
and is not profitable until you ship unit 1,001. Again, this does not account for the many other costs discussed in this article.
However, if you choose a validated and proven embedded reference design platform as a starting point, you can shorten time to
market, and the early profits pay for cost optimization and feature improvements. In this way, you amortize your investment over
the life of the product rather than investing all of the money in up-front development.

Equation 1. You can use a simple equation to calculate the break-even point of any custom design.
6. Do More with Fewer Resources

When thinking about what hardware and software tools to use for your next embedded control project, be sure to remember these
five steps before starting the project. All design teams wish to do more with fewer resources and investments. Selecting high-level
software tools and off-the-shelf hardware gives you the ability to save on development time and costs in the long run.
- Greg Crouch
Greg Crouch is the embedded systems business manager for the industrial and embedded product lines at National Instruments.
Greg graduated cum laude with a bachelor of science in electrical engineering from Texas A&M University and has been a part of
the National Instruments family for more than twenty years. Greg has served roles in R&D and sales and marketing, and is active
4/5

www.ni.com

the National Instruments family for more than twenty years. Greg has served roles in R&D and sales and marketing, and is active
in local STEM program initiatives within the city of Austin.

5/5

www.ni.com