Employee Webmail


Products for Measurement and Automation

Zero Programming
Zero Schedule
Zero Risk









Home » Company » News » American Controls Conference


Cyth Systems Presents at American Controls Conference 2006


2006-06-13 Minneapolis, MN


Abstract— In today’s product development world teams need to be able to prototype, test, and deploy control systems in with ever-shrinking resources of time and cost.  One factor that wastes both is risk: the possibility that something will happen to take up more time and more cost.  Eliminating risk items is the most effective strategy to save time and cost, and eliminating custom hardware and software are the focus of the improvement.    


  I.      Introduction

Revolutions in computer and microprocessor technologies have brought many new options in control system development platforms like Linux, FPGA’s and even PocketPC’s.   With internet search engines helping expose us to the world’s products, development teams may have more options than they are capable of selecting from.


Once a development platform is chosen, the next largest obstacle is the algorithms and behaviors that the system needs to be programmed to do.  The most demanding and risky part of the effort is often the software programming.  It is nearly a rule that software projects are overbudget, overschedule, and will have bugs in development.


In an experimental or cutting-edge environment the needs of the system may be the subject of trial-and-error, or iterations and experiments.  In such a case creating software is not quite the trouble but changes and rewrites.  Any complications in software design can be multiplied to some degree every time the code is iterated.


The risk of custom programming includes many factors.  Each programming language has pros and cons.  One language might have less training required, while another is more stable.  Although those factors may be hard to define, they plague the process, and like a contaminant in a fluid, more liquid brings more contaminant as well.  Therefore it’s best to keep custom software to a minimum. 


Custom hardware, though easier to measure and test, can also be prone to mistakes.  So as not to overburden software as a culprit in design effort, one can conclude that custom work should be minimized as a whole. 


Cyth Systems has developed a tool to eliminate risk, time, and cost when creating control systems. 



II.      Anatomy of Risk-Free control system

a.       Platform

The first task of developing a risk-free system is to choose a platform which eliminates some of the risks identified.  Hardware and software are sometimes interlinked with some options or variations available; the hardware usually implies the software to be used.   We most valued the following characteristics:


·         little or no custom wiring or circuitry

·         reconfigurable or expandable for changing needs

·         Easy to program with minimal training

·         Easy to modify and rework

·         Debug or troubleshooting available


The choice which most satisfied these needs was the Compact-RIO (cRIO) from National Instruments.  As an FPGA based system it can make a very fast and reliable controller.  Most FPGA systems have a few shortcomings including having only discrete logic, no ability to handle floating point math, a requirement for custom circuitry, and VHDL text based code programming.   The cRIO handles these with an elegant design and countless man hours of effort.  




Figure 1: A typical controls development platform showing an FPGA on a breadboard for custom prototypes.  This option requires too much custom programming and custom wiring.


Figure 2: The cRIO FPGA chassis with 4 module slots on the right and the Real-Time computer on the left.


The cRIO chassis routes the FPGA circuitry along a backplane making it available to multiple slots and a Real-Time operating system (RTOS).  Together they provide the following benefits

·         cRIO Modules condition the signals as needed to create analog I/O, condition and read strain gauges or thermocouples, communication buses, and signal manipulation

·         RTOS can do floating point math and communications like TCP/IP and RS232.


The most powerful benefit of the cRIO implementation of FPGA is the use of LabVIEW to eliminate programming in text-based VHDL.  With the modules for cRIO come well structured and defined electronic capabilities, and software which matches. 


Figure 3: Sample cRIO code demonstrates how to make a thermostat control system



Figure 4: Shows a function to read the values of three named analog inputs


Combining the capabilities of an FPGA with the cRIO implementation gives us a large boost forward in creating our risk-free system and meets all our primary goals for the platform.




b.       Eliminating Custom Software

Even with the custom hardware and software burden reduced, kept away from low-level text-based programming, for the sake of time and risk we prefer to further minimize custom programming.


Even with the use of software modules such as the one shown in Figure 4, reading inputs needs to be combined with logic to give each module the personality you require.  For example, a 24V digital output module is available to be configured as a PWM output if desired.  Therefore, calculations based on a known clock or cycle time are programmed to control the state of the 24V digital output.  Figure 5 shows a PWM setup done in FPGA hardware using LabVIEW software for cRIO.  Although the code is exceedingly simple, Figure 6 shows how it can be packaged and reused in future applications without the need for programming or validation.



Figure 5: Beginnings of code implementing a PWM signal




Figure 6:PWM Code turned into a subroutine for easy reuse



c.        Software Modules Simplified Further

Imagine as demonstrated in Figures 5 and 6, a collection of the most common control tasks reduced to a library of easy-to-use, pre-tested tools.  With those installed on a cRIO, the design of your control system would be to execute one or more commands based on the value of variables or inputs. 


We developed a sequencing application for use on a cRIO system which is designed to interact with the library of software tools described above.  That sequencer has the ability to check the state of logic based on factors chosen which comprises the unique and meaningful part of the application. 


For a simple example, to create an elaborate thermostat, one would monitor the state of a thermocouple input using a simple “analog read” tool.  The value read would be compared to a user-input in degrees, and if the temperature was out of the chosen range, perhaps a PWM would drive a heater or air-cooler.  If the temperature is far from the target, the PWM might go to 100% to drive the temperature more rapidly, and use a PID to vary the PWM to approach the temperature target without overshooting.


In this case, no programming is required, only sequencing, calculation, and decision making tools using the sequencer.  The user input can be provided using a physical signal like a knob, or over TCP/IP with the help of the Real-Time OS coupled to the FPGA.


d.       Zero-Risk Control System Development


Now that the platform affords reduced custom hardware and software, the development team will be working for some period of time developing algorithms.  This implies changes and repeat testing of the algorithms.


Using the cRIO system as a test and development platform does have two small barriers.  The first is converting LabVIEW code to VHDL.  It can be very time consuming, taking 1-8 hours to compile larger applications.  Secondly, the FPGA does not have direct user interface controls such as video output or keyboard and mouse input. 


It would be nice, then, to generate and test as much of the control system as possible without compiling and test the system with the most user friendly environment possible. 


To meet this need, Cyth reproduced the entire library of software modules for use within LabVIEW for Windows, in which PCI or PXI devices emulate the cRIO modules and Windows emulates the FPGA and RTOS.  Now, using a very intuitive interface, we can create prototypes which do not need to be compiled to run, and which can display data to the PC monitor or save results to the PC hard-disk.


But at some point using Windows in a control environment is not appropriate, and real-time determinism is required.  Once the systems have been tested and approved on Windows, even if they’re not complete, the development team can transition to cRIO at any time, or even work on both in parallel.


On the cRIO platform, even more steps have been taken to eliminate programming.  The modules and the sequencer are designed to be programmed and need few changes once they basically function.  Compiling such a sequence with the associated modules might be done once, while any control variables are left as a text file or other lookup table, eliminating the need to recompile for the sake of smaller changes, like delay times, duty cycle settings, or even the order of execution of steps. 





e.        Reviewing the Platform


As set forth in the introduction, we have described a system with significant benefits in terms of risk and schedule.


The cRIO platform, combined with Cyth Systems’ no-programming toolsets, is now a product available for future projects which allows


·         little or no custom wiring or circuitry

·         reconfigurable or expandable for changing needs

·         Easy to program with minimal training

·         Easy to modify and rework

·         Debug or troubleshooting available


These goals are accomplished in the following ways by the combination of cRIO and Cyth Systems’ zero-programming libraries:


·         cRIO modules arguably reduce custom wiring by 95%

·         Chassis allows adding or rearranging up to 8 modules

·         Programmed using LabVIEW with lots of built-in examples and help

·         Toolsets of most major control and I/O needs are provided from Cyth Systems

·         Prototypes and Engineering units can be developed and tested in Windows or cRIO interchangeably

·         Custom software is reduced to arranging code modules and compiling only a few times, while behavior is contained in a configuration file

·         Changes to execution or settings can be done outside code in just minutes without recompiling



II.                  Implementation in Hybrid Vehicle Development


The L3 Engima Hybrid Electric Vehicle boasts 260 horsepower and estimated 80 mpg

a.       Zero-Risk Control System Development


Development of the Hybrid Vehicle control system was an iterative process involving dozens of students, lots of mistakes and experiments, and product donations and hardware which trickled into the laboratory as it became available.  Needless to say, such an environment mimicked commercial competitive development pressures and demands.


To start, control signals needed to be understood and routed from the components of the HEV back to the main control computer.  Some example tasks were reading the throttle petal and controlling both motor and engine to desired speeds.  To ease in this development, LabVIEW for Windows XP was used to create simple drivers and test or prove signals.  The design and improvement cycle on these tasks were very rapid, slowed only by availability of hardware and documentation.   A driver for the throttle pedal, for example, was implemented and proven in about 15 minutes.


Once those signals were understood, algorithms to control them were built and tested, expanded and improved.  The first and most critical was the control loop for basic driving, which included reading the pedal and selecting and calculating an output for the motor and engine.  This was a simple task which became more complicated as more demands were placed on it.  Our needs included preventing spinning too fast (12000 rpm) when on blocks without resistance, and establishing a regenerative braking region of the pedal movement while allowing the car to brake smoothly.  Other more complicated algorithms came into play, such as starting the engine using the motor, switching gears smoothly, and shifting the motor and gears into reverse.  Each required specific timing and interrupting the normal control loops for special tasks.  Implementing these in LabVIEW for Windows with ergonomics and debugging tools made this process much easier to accomplish.


b.       Validation test for control system


Since the control system can be developed in Windows or cRIO, it would be nice to have the same flexibility for simulation and testing.  In the previous example, it is actually quite dangerous to directly apply control signals to a motor or engine when any mistakes could potentially damage hardware or injure personnel.  A comparable system could, in this case, provide pedal signals and verify the resulting motor and engine control signals.  In fact, unlike a human foot on the actual pedal, the test platform can automatically cycle incrementally through many pedal voltages, and perhaps measure hysteresis during signal changes.


For a complete development and test platform for control systems, Cyth Systems provides a package comprised of multiple cRIO chassis, multiple Windows systems, and a complete set of software and licenses for all systems. 


To get the best performance and reliability from Windows platforms, Cyth chooses the PXI computing platform from National Instruments along with many PXI modules which provide the I/O similar to cRIO modules.  The PXI (PCI eXtensions for Instrumentation) platform provides a common computing experience with an enhanced and expanded PCI backplane with timing and synchronization for up to 18 modules.  Therefore the PXI systems are more than adequate for parallel development of the control system, but also make a powerful platform for Hardware-In-The-Loop (HIL) testing, or for simulation to do control system testing.



Figure 7: An 8-slot PXI chassis used in the HEV Vehicle


For the HEV development project, we developed many of the drivers and algorithms on Commercial Off The Shelf (COTS) laptops and desktop computers.  These were easily transitioned to the Windows-based  PXI system for compact and reliable use while driving and in a small space with imperfect ventilation. 


One additional benefit of the Windows-based PXI platform is the replacement of the Windows embedded computer with and available Real-Time OS computer.  The Real-Time controller uses nearly all the same computing components and runs a Pharlap operating system reduced to loading and executing control code exactly the same as running in Windows, and supports TCP/IP communication to a host computer or laptop.  This was an excellent way to develop code on Windows but quickly eliminate the overhead and potential un-reliability of Windows without much change.


During the development stages of the control system, it would not make sense to test the controller on the actual 200-hp electric motor, or to put the safety of a driver at risk if there were any mistakes in the code.  Therefore it was desired to simulate the engine, motor, and pedal (at a minimum) to test the driveability of the car.  With this software running on PXI Windows, connected to our control system running on PXI Real-Time, the user can simulate a pedal position and see the reaction of the control system. 


During one of the early tests, a miscalculation meant to apply 40% of the available power (Power = Pmax x 0.4) actually applied Pmax x 40 (forgetting to divide by 100).  Naturally the motor virtually ramped to 12000 rpm (trying to achieve 48000).  The problem was quickly fixed and re-tested, and safely validated after having a laugh about such a simple mistake.  Had this test been done on the real motor, it would have either damaged the motor (if it had been on blocks without resistance) or it would have launched the car rapidly out of control and surely injured someone.  As a result, we also applied a maximum acceleration function and tested to prove that even standing on the pedal would not produce dangerous or damaging increases in velocity.


Once the control algorithms had been developed to a basic level of capability, with confidence there were no mistakes, we deployed the code to a real-time PXI system with no changes required, and began driving straightaway.  The system worked as designed, but we quickly realized we wanted more feedback.  Therefore we carried a laptop to view the state of the algorithms and I/O signals.  During later testing, when we could not achieve much acceleration, we were able to read that battery pack voltage was well below the nominal 380V, and presumed the battery voltage was acceptable.  However, during a normal acceleration to only about 35 mph, we saw the pack voltage sag to about 320V which indicated too much resistance or impedance somewhere in the electrical system.  The readings were saved to a file on the laptop and presented on a graph to explain the problem.  Later, the battery pack was found to have a single damaged battery cell, and it was replaced.  Without a Real-Time system with plenty of user-friendliness, it might have been much more difficult to discover the problem.


Finally, the system was modified with the FPGA specific code and migrated to cRIO.  Since we were absolutely confident that the algorithms were technically correct, and included discoveries and lessons learned, we were quite confident we would not need to recompile and revise often.  In any case we did, it was preferable to migrate back to PXI (either Windows or RT), and spend a few hours making changes before going back to FPGA.


c.        Data Storage and Analysis

In nearly any control system or product development effort, data coming from the system can be plentiful with such a level of automation.  Previous generations of FPGA or microprocessors tools had limited (if any) recording capability due to the lack of operating system or hardware for storage.  But with the interfaces described such as the cRIO’s Real-Time component, and the Windows-based PXI platform, nearly all of the measurements and results can be stored.


With such volumes of data, however, comes the overwhelming task of storing and retrieving the data in meaningful ways. 


For storage, the technique is usually files or databases, all of which require something to be designed and administered.  Ideally, you would prefer to have the storage method pre-defined, and the


At Cyth Systems, our philosophy is to provide zero-programming and zero-risk solutions which enable quick delivery.  For control system development, we have chosen or created products to eliminate as much custom work as possible.  As demonstrated above the results are many improvements as measured by risk, time, and cost. 


For more information about any of the products or services listed in this document, please contact NI, Cyth Systems, or contact the author directly using the links below. 



Thanks to Jim Burns for our partnership and for supporting the original presentation of this topic at NIWeek2005.








NI Product photos courtesy and copyright of ni.com

L3 Enigma photos courtesy and copyright of L3 Research

Joe Spinozzi is Director of Operations of Cyth Systems, LLC (USA).   Cyth has offices in San Diego, CA and in the UK and Australia (www.cythsystems.com)

Jim Burns is professor of Mechanical Engineering at San Diego State University.  The project conception, design, and student work are all under his supervision.  (http://www.engineering.sdsu.edu/~hev/)





(c) 2006 Cyth Systems USA, LLC