WHAT ARE THE TOP 10 ISSUES FOR EMBEDDED CONTROL DESIGN THAT NI IS ADDRESSING WITH THE TOOLCHAIN???

[BMac]

What are the top 10 issues for embedded control design that NI is addressing with the LabVIEW RIO toolchain?

1. Our control applications require a combination of DSP, FPGA and microprocessor functionality.

2. The majority of our development time & cost is spent on low value tasks.

3. The VHDL/Verilog code generated by our modeling tool requires specialized hardware design engineers to implement, and as soon as the generated code is modified, our simulation test results are invalidated.

4. It takes too long to move from a working desktop simulation to deployment on an embedded system.

5. Our modeling tools don't accurately simulate fast transient events like short circuits and faults when co-simulating with our embedded code. But these are the most important cases for testing the embedded code!

6. Our simulation/modeling environment doesn't have the right computation models for embedded systems programming.

7. For our organization, the cost and risk of traditional custom circuit design for embedded control boards has become unsustainable.

8. We make big investments in simulation/modeling to test our embedded control software, but we don't get to reuse our test code on our physical teststands OR for HIL testing.

9. Using in-house board designs, we are struggling to meet the market requirements for self-diagnostics, web based monitoring, fault recording and utility SCADA communication protocol support.

10. Float to fixed-point conversion is expensive, error prone and requires specialized experts. We often run into fixed point math problems in our control algorithms.

Issue/Challenge/Dilemma	How NI Toolchain Addressed the Problem
1. Our control applications require a combination of DSP, FPGA and microprocessor functionality. DSPs have ASIC subsystems for pulse width modulation that do not provide the flexibility we need, so we are forced to augment the DSP with an FPGA for my custom PWM and protection logic. Also, we use microprocessors for supervisory control, data logging and networking.	New heterogeneous-system-on-a-chip (HSOC) devices contain a mix of DSP cores and programmable logic in a single chipset. Both the DSPs and FPGA fabric are programmed graphically with no knowledge of VHDL/Verilog. The FPGA fabric provides nanosecond timing and synchronization of any custom PWM, ADC sampling and control algorithm imaginable. In effect, you are designing your own custom ASIC chip. NI LabVIEW FPGA technology has been in development for over 15 years and is very mature. Typically, the entire control system is implemented in the HSOC device.
2. The majority of our development time & cost is spent on low value tasks. Over 70 percent of our development person-hours and cost is for developing I/O interfaces. This work is tedious, error prone and doesn't differentiate me from other design teams. Signal integrity problems are common. Errors and undocumented bugs on vendor provided I/O chipsets and  documentation often cause delays. Our team would rather spend 70 percent of our development cost on developing proprietary, patentable control and monitoring algorithms that distinguish our organization from the competition.	There is a better way to design these complex systems that enables you to focus more of your development time on high value tasks. NI provides fully validated, deployment ready embedded systems with analog and digital I/O that has built-in signal conditioning for industrial applications. All of the I/O chips interface directly to the HSOC device with no intermediate bus, so the signals are available for control and signal processing algorithms on the following 25 nanosecond clock tick. Fully integrated FPGA fabric interfaces for the I/O devices replace hundreds of pages of hand written VHDL code.
3. The VHDL/Verilog code generated by our modeling tool requires specialized hardware design engineers to implement, and as soon as the generated code is modified, our simulation test results are invalidated. Model based design tools are helpful, but they generate generic code for generic DSP and FPGA devices. In practice, we have to manually edit the generated code for the particular hardware. For example, the DSP48 cores on Spartan-6 devices are different then the DSP cores on Artix-7 FPGAs. So we are forced to modify the generated code. However, as soon as we modify it, all the testing we did in the model-based simulation environment is invalidated.	NI's business model for embedded systems design is the following: NI provides completely integrated embedded systems design software (based on the LabVIEW graphical programming language) and deployment-ready embedded hardware with a fully optimized synthesis and compilation toolchain. NI also provides the programming language itself, which enables us to optimize it for the unique needs of FPGA devices, DSP cores, and real-time operating systems and to synthesize code that's highly optimized for a particular hardware target resources. As a provider of model based embedded system design tools for cyber-physical systems, we are able to integrate simulation and modeling capabilities into the embedded software development toolchain. Our job as a toolchain provider is to ensure that the embedded code has the same behavior and timing when co-simulated with a plant model as it does when I deployed to the actual HSOC hardware. Generally speaking, NI is agnostic about simulation and modeling environments and seeks to be compatible with any simulation tool that a majority of our users want us to support. However, it is less expensive for us to innovate with our own integrated modeling and simulation tools such as Mathscript RT, Control Design & Simulation, and Multisim.
4. It takes too long to move from a working desktop simulation to deployment on an embedded system. It can take days, weeks, months or even a year to move from a desktop simulation of a control system to deployment on a working embedded system.	The NI graphical embedded system design toolchain with integrated modeling and simulation tools enable you to move back and forth between the simulation context and deployment context many times in a day (ECCE conference paper). When you are ready to synthesize and deploy your HSOC code, right-click on the FPGA target and switch it from co-simulation to deployment mode.
5. Our modeling tools don't accurately simulate fast transient events like short circuits and faults when co-simulating with our embedded code. But these are the most important cases for testing our embedded code! When simulating my embedded code with a power electronics model, I have to use a fixed timestep solver. Either I pick a tiny timestep that gives me valid results during transient events, or I pick a large timestep that simulates quickly but only gives me accurate results when the system is running steady state. Steady state simulations are fine for undergraduate courses, but my job is to simulate all the worst case things that can happen and design a control system that responds appropriately. So... the most important things for me to simulate accurately are short circuits, in-rush events, faults and other fast transients.	To accurately simulate both fast transient events and steady-state behavior with accuracy and performance, NI has developed a patented co-variable timestep between the NI LabVIEW Control Design & Simulation loop and the NI Multisim power electronics circuit simulation environment. This means the simulation, including the embedded software, automatically speeds up and slows down to satisfy your accuracy constraints depending on what is happening in the circuit. This enables you to accurately model the fast, closed loop dynamic interaction between the embedded HSOC software (cyber world) and the power electronics circuit (physical world). LabVIEW and Multisim automatically negotiate the variable timestep. (Incidentally, this also enables you to put coupled differential equations on either side-- for example, the mechanical equations for a motor on the LabVIEW side and the electrical equations on the Multisim side.)
6. Our simulation/modeling environment doesn't have the right computation models for embedded systems programming. Modeling environments are great for simulating physical systems and developing algorithms, but trying to write my actual embedded system software in a modeling environment can be problematic. We have to jump through hoops just to implement a while loop or event driven response.	An ODE modeling paradigm is great for simulating physical systems, but it is not always intuitive as a way to program embedded chipsets. The LabVIEW Real-Time and LabVIEW FPGA embedded programming environments have been carefully designed using the latest computer science regarding the best models of computation for embedded signal processing and control. Over the past 30 year, the synchronous data flow programming paradigm has proven to be the most natural and popular way to intuitively describe DSP and control applications for parallel and multirate execution. However, LabVIEW integrates and supports a mix of programming paradigms, including C, VHDL/Verilog, textual math, statecharts, ODE modeling, etc.
7. For our organization, the cost and risk of traditional custom circuit design for embedded control boards has become unsustainable. The cost, risk and complexity of embedded processor/FPGA/DSP board design seems to be increasingly exponentially with Moore's Law. To produce a design with innovative features and competitive performance for its price, our development costs are increasing. Modern devices have hundreds of pins, each pin is surrounded by 8 adjacent pins, and the voltage levels keep dropping closer and closer to the noise floor. Design flaws are revealed too late in the development process and are expensive to fix. We must frequently redesign due to end-of-life parts. Our core area of expertise and differentiators are power conversion equipment design, advanced algorithms, system integration and manufacturing. It's becoming clear that control and I/O board design is outside of our core, yet it is consuming more and more of our development resources.	An open, software designed hardware (SDH) platform can enable your team to balance the flexibility of custom circuit design with the reduced development cost, risk and improved lifetime support of off-the-shelf hardware. Key elements of this approach include: An open graphical system design platform enables embedded engineers and domain experts to collaborate using a mix of text-based and graphical programming. Software designed hardware circuitry combines the low level customization of custom circuit design with the reliability and lifetime support assurance of off-the-shelf hardware. A skilled worldwide network of system integration partners provide startup assistance, training, support and custom embedded design services. Pre-validated, modular hardware with the latest embedded technologies from Xilinx, Intel, and Arm enable innovations that separate you from your competition.
8. We make big investments in simulation/modeling to test our embedded control software, but we don't get to reuse our test code on our physical teststands OR for HIL testing. A big benefit of a model based approach is that we can start testing, validating and iterating on day one. However, in the past we have had little or no reuse of our desktop simulation test code to validate our actual embedded system. Another problem is that it's been difficult or prohibitively expensive to re-use the simulation models we developed for desktop testing into something that runs fast enough to serve as a real-time HIL test system so we can test the control boards/chassis with the embedded code running full speed.	National Instruments has created an design V toolchain for embedded control systems in which the embedded code for the FPGA, the power electronics simulation models, and the software testbench applications are all fully integrated into the development project. This means you can create multiple testbenches for your embedded code that validate each of your design requirements, and fully automate the test sequencing to re-validate all of the embedded software whenever updates/changes are made. All of the simulation testbench results are saved in an industry standard TDMS file format-- the same file format used to acquire data when the embedded control system is running on a physical test stand. Finally, National Instruments R&D teams have been working for many years to develop a methodology to automatically convert desktop simulation models (which execute slower than real-time on a PC) to real-time and faster-than-real-time implementations that execute on an FPGA-based HIL simulator at the required MHz speeds necessary for switched mode power electronics. Successful prototypes of automatic Multisim Desktop to Multisim FPGA HIL simulation were demonstrated in 2014, and later this year we plan to announce collaborations with other industry leaders that will enable models from other simulation environments to be converted to ultra-high speed FPGA solvers executing on NI RIO hardware.
9. Using in-house board designs, we are struggling to meet the market requirements for self-diagnostics, web based monitoring, fault recording and utility SCADA communication protocol ­support. Traditional control-oriented DSP chips can run our custom power electronics control algorithms. However, to create a competitive product, we must include a lot of features that can't be implemented on a DSP or even FPGA device alone. Our customer now expect us to provide self diagnostics, remote or cloud based monitoring, automatic fault event recording, data logging, power quality analysis and even Ethernet communication over complex utility SCADA protocols like IEC-61850 and DNP3.	Most power conversion equipment today requires DSPs for algorithmic control and signal processing, FPGA fabric for custom PWM and fast protection/fault handling logic, and a microprocessor for network communication and datalogging. The good news is that the combined functionality of a DSP, FPGA, microprocessor and industrial I/O have been fully integrated together and can be programmed using a single high level graphical programming environment. This is the NI LabVIEW RIO architecture. A range of performance/price and mechanical form factors are available based on this same architecture. An extremely helpful trend for power electronics designs is the integration of multiple types of computing elements into a single integrated chipset, resulting in significant cost savings compared to using separate chips. For example, a Spartan-6 LX45 device (used in the sbRIO GPIC) contains 58 DSP cores that are distributed throughout a network of programmable logic fabric-- resulting in a 40X improvement in performance per dollar compared to a traditional C6000 class dual core DSP chip. Performance per dollar is measured as the number of multiply-accumulate-operations-per-second (MACS) per dollar using Digikey pricing. Newer chipsets from Xilinx such as the Zynq-7020 device used on the cRIO-9068 chassis increase the number of DSP cores to 220 and add two ARM microprocessors. This yields a 74X improvement per dollar compared to a traditional C6000 DSP chipset, not to mention a 40X improvement in performance per watt. Due to their massive parallelism, these heterogeneous system on a chip (HSOC) devices are on the very forefront of Moore's law. The NI RIO LabVIEW architecture also typically enables many custom peripheral circuit boards to be eliminated, since their functionality can often be accomplished digitally in the FPGA fabric. The end result is that for many of our high volume OEM customers, an off-the-shelf system NI RIO embedded system slightly reduces the total bill of materials (BOM) cost while dramatically reducing development, testing/validation, field service and lifetime support/maintenance/redesign costs.
10. Float to fixed-point conversion is expensive, error prone and requires specialized experts. We often run into fixed point math problems in our control algorithms. When converting our control algorithms from floating point to fixed point math, the conversion process requires a tremendous amount of manual labor by highly specialized experts. Fixed point control algorithm design breaks our normal practice of developing and testing each algorithm as a unit and then putting all the individually tested units together to create the control system. If poles overlap when the control algorithms are connected, we have numerical stability problems. Also, even an individual transfer function algorithm can go unstable when if the timestep is small and it's a higher order control compensator. (Numerical instability happens if the poles overlap in fixed point or reach the boundary of the real-imaginary unit circle.) Finally, numerical overflow should be treated as a warning or fault condition, but adding all of the logic to our control algorithms to check for overflow adds complexity and makes them messy. In theory, we could design our algorithms such that problematic overflows never occur and eliminate the overflow handling logic. However, that requires us to create test vectors ahead of time that represent all the conditions the algorithm will experience in the field.	Up to now, many companies have tried to create tools that fully automate the conversion of floating point algorithms to fixed point implementations suitable for low cost embedded devices. To our knowledge, no company has been able to fully automate the process in a way that eliminates the need for the embedded developer to have a detailed knowledge of float-to-fixed-point conversion. Furthermore, the unique characteristics of control algorithms (such as higher order transfer functions) creates some particularly vexing numerical stability problems that do not typically rear their ugly head in other areas of signal processing such as digital filter design and software defined radio. For example-- the issue of poles overlapping due to series/parallel connections of fixed point control compensators that are individually stable but become (numerically) unstable when interconnected.   While fixed-point math will never go away completely, the good news is that the hard core DSP slices embedded in modern FPGAs are becoming more and more optimized to support floating point math. This has been a major request by National Instruments to our FPGA supplier, Xilinx, over the years. Modern devices like the Spartan-6 LX45 can execute most IEEE single-precision floating point operations (such as multiply) in a single 25 nanosecond (40 MHz) clock tick and using only a single DSP core with companion fabric usage. Since the math operations are >> faster than typical control loops, the trick is to execute the floating point math faster than needed and reuse it for multiple algorithms. (This technique is known as overclocking.) This enables very large control applications to be executed completely in floating point on relatively modest/cost effective targets such as the LX45 FPGA on the NI sbRIO GPIC. See for example, the sensorless magnetic levitation control system example described in the floating point toolkit whitepaper, which executes at 124 kHz and consumes only 64 percent of an LX45 device. Only a single floating point operation of each type (add, subtract, multiply, divide, exponential, etc.) is used for the entire control system. The floating point toolkit we published recently is designed to facilitate this type of reuse, but also includes IP cores suitable for the highest performance, as needed for applications such as power electronics HIL simulation.

Are your top embedded system control design issues listed above? If not, reply to this thread and let us know your struggles. Even better if you have ideas for how NI could help address the issue. We are committed to continually improving the embedded system design toolchain to meet the needs of our customers.