Simulation Beyond Volts and Amps (Part 1)

Using simulation, engineers can analyze a system’s performance prior to building and testing a hardware prototype. Doing more simulation at the front end of the design process reduces prototype and test costs at the back end. Simulating an electrical design, for example, means tracking voltages across, and currents through, system components – just like testing a hardware prototype. But improving system performance and reliability often requires understanding more than the voltage and current profiles tell us. Getting at these additional details, however, can be a challenge – unless you are using a modeling language that allows you to move beyond volts and amps to investigate the finer details of your design.

I have posted a few commentaries on VHDL-AMS, the IEEE standard language for modeling analog and mixed-signal system behavior. VHDL-AMS gives engineers increased flexibility in what they can model, and therefore analyze, about their systems. As a simple example, let’s take a quick look at a basic incandescent lamp model.

A basic incandescent lamp consists of a sealed glass bulb containing a filament suspended between two electrodes. The glass bulb is typically evacuated, or contains an inert gas, to prevent filament oxidization. When current passes through the filament, it heats up and glows, giving off both light and heat. As it turns out, the majority of energy consumed by an incandescent lamp is emitted as heat, while very little is turned into visible light. Since most of the energy is lost as heat, it is useful to understand the lamp’s thermal profile.  VHDL-AMS is well suited for this task.

Electrically, the lamp filament behaves like a temperature dependent resistance. Thermally, current flows through the filament and power is dissipated as a combination of thermal conductance, thermal capacitance, and radiation. The following portion of a VHDL-AMS based lamp model declares important lamp quantities, or analog unknowns, for which the simulator finds a solution. Note that I’ve added the line numbers for ease of reference.

(1) quantity v_lamp across i_lamp through p1 to p2;

(2) quantity r_temp : resistance;

(3) quantity temp_fil : temperature;

(4) quantity hflow : heat_flow;

Line (1) declares two branch quantities, v_lamp and i_lamp, which are associated with pins p1 and p2 of the model. In this case, v_lamp represents the voltage across, and i_lamp the current through, the lamp’s filament. Lines (2) through (4) declare free quantities which the simulator calculates to give additional information about the lamp’s operation. Line (2) declares r_temp, the temperature dependent resistance of the filament. Line (3) declares temp_fil, the temperature of the filament. And finally, line (4) declares hflow, the heat flow from the filament. Note the terms following the [ : ] in lines (2) through (4). These are type declarations which define the units used to plot the simulation results for each of the free quantities (r_temp is of type resistance and is plotted in Ohms; temp_fil is of type temperature and is plotted in degrees Celsius, and hflow is of type heat_flow and is plotted in Watts). The units for the v_lamp and i_lamp branch quantities are determined by the definitions for pins p1 and p2, which are assigned electrical natures elsewhere in the model.

In addition to the typical voltage and current relationships for the lamp, the simulator uses these free quantities to calculate the lamp’s thermal performance.  In my next few posts I will use this lamp model in a simple automotive emergency flasher system to analyze the circuit’s thermal behavior.

Post Author

Posted November 3rd, 2010, by

Post Tags

, , , ,

Post Comments

No Comments

About Mike Jensen's Blog

Views, insights, and commentary on mechatronic system design and analysis. Mike Jensen's Blog

Comments

Add Your Comment

Archives

October 2014
  • Reliability vs Robustness
  • June 2014
  • Wow Factor
  • May 2014
  • SystemVision 5.10.3
  • March 2014
  • IESF 2014: Military & Aerospace
  • Engineering Oops!
  • Big Engineering
  • January 2014
  • SystemVision Model Wizard
  • December 2013
  • SystemVision 5.10.2
  • Modeling: An Engineer’s Dilemma
  • October 2013
  • What is Your Legacy?
  • September 2013
  • Automotive IESF 2013
  • July 2013
  • Simple Design Solutions
  • June 2013
  • SystemVision 5.10
  • May 2013
  • Engineering Muscle Memory
  • EDA vs. Windows 8
  • March 2013
  • VHDL-AMS Stress Modeling – Part 3
  • January 2013
  • VHDL-AMS Stress Modeling – Part 2
  • VHDL-AMS Stress Modeling – Part 1
  • December 2012
  • Practice! Practice!
  • November 2012
  • Sharing Tool Expertise
  • October 2012
  • Preserving Expertise
  • Virtual Prototyping — Really?
  • Innovations in Motion Control Design
  • September 2012
  • Game Changers
  • Do We Overdesign?
  • August 2012
  • Tsunami Remnants
  • July 2012
  • A New Look at Device Modeling
  • SystemVision 5.9
  • June 2012
  • Veyron Physics
  • May 2012
  • Rooster Tail Engineering
  • April 2012
  • Automotive IESF 2012
  • Teaching and Learning CAN Bus
  • March 2012
  • Analog Modeling – Part 6
  • Analog Modeling – Part 5
  • Analog Modeling – Part 4
  • February 2012
  • Analog Modeling – Part 3
  • Analog Modeling – Part 2
  • January 2012
  • Analog Modeling – Part 1
  • Connecting Tools and Processes
  • December 2011
  • Turning-Off and Tuning-In
  • Use vs. Experience
  • Analyzing the Big Picture
  • November 2011
  • Simulating for Reliability
  • October 2011
  • SystemVision 5.8
  • VHDL-AMS Model Portability — Fact or Fiction?
  • September 2011
  • IESF 2011 Moves to Frankfurt
  • Simulation Troubleshooting
  • August 2011
  • Qualities of VHDL-AMS Quantities
  • Military & Aerospace IESF 2011
  • Touring Johnson Space Center
  • July 2011
  • Engineering versus Science
  • June 2011
  • System Reengineering
  • May 2011
  • Integrating Hardware and Software Design
  • Engine Remote Start
  • Integrated System Design
  • Simulation Experiments (Part 3)
  • April 2011
  • Automotive IESF 2011
  • Pushbutton Cars
  • System Simulation with FEA-Base Motor Models
  • March 2011
  • Simulation Experiments (Part 2)
  • Simulation Experiments (Part 1)
  • Japan: Patience and Grace Amid Disaster
  • Top Gear = Driving Fun
  • February 2011
  • Buoyancy
  • Ideas in Motion
  • January 2011
  • The Mechanical Half of Mechatronics
  • Detroit Auto Show
  • Signal-flow vs Conserved System Modeling
  • SystemVision 5.7…Ready, Set, Go!
  • December 2010
  • SystemVision and Windows 7
  • Friction Vacation
  • Simulation Beyond Volts and Amps (Part 4)
  • November 2010
  • Simulation Beyond Volts and Amps (Part 3)
  • Simulation Beyond Volts and Amps (Part 2)
  • Simulation Beyond Volts and Amps (Part 1)
  • October 2010
  • SAE Convergence Recap (and an Unexpected Surprise)
  • VHDL-AMS Black Belt
  • Converging on SAE Convergence
  • System Design vs System Repair
  • September 2010
  • What’s the “AMS” in VHDL-AMS?
  • How Sensitive is Your System?
  • Do You Trust Your Simulator?
  • August 2010
  • What’s in a SPICE Model?
  • Cycling + Gravity = Pain
  • NI Week: Fun for Engineers
  • June 2010
  • Are You a Flexible Thinker?
  • VHDL-AMS and Switch Hysteresis
  • May 2010
  • VHDL-AMS Revisited
  • Segway to U3-X
  • Atomic Glue
  • March 2010
  • IESF Recap
  • February 2010
  • IESF is Coming…
  • System Level HDL-topia
  • January 2010
  • Mastering Design Abstraction
  • The Joy of Disassembly