Simulation Beyond Volts and Amps (Part 2)

Last week I wrote about  moving beyond electrical modeling to get more information about system behavior. To illustrate some of the basics, we looked at a portion of an incandescent lamp model which showed declarations for some of the lamp’s thermal properties. At the end of the post, I promised to illustrate some of the discussion with an example of an automotive emergency flasher system. Before diving into the example, however, we need to discuss the model for one more system component: a fuse.

Like the incandescent lamp, a fuse has both electrical and thermal properties. And like the lamp, a fuse’s electrical performance determines its thermal performance. The important difference is that when the fuse temperature gets high enough, the fuse melts and shuts down the circuit it protects. For simulation, we can model the fuse in a variety of ways. For our example, we will model the fuse as a resistance which changes state as the current through the fuse crosses a user-defined threshold. If the current is increasing as it crosses the threshold, the resistance changes from a very low to a very high value. If the current is decreasing as it crosses the threshold, the resistance transition is reversed. The modeling mechanism that enables the state change is inspiration for another blog post. The take away, however, is that the VHDL-AMS language enables multiple methods for modeling real world behavior. Similar to the lamp model, along with changing the fuse’s resistance based on its current, we can monitor the temperature of the fuse element using a VHDL-AMS quantity which is simply an analog unknown the simulator solves for.

(1) quantity v_fuse across i_fuse through p1 to p2;

(2) quantity r_fuse : resistance;

(3) quantity temp_element : temperature;

(4) signal r_switch : resistance := 0.0;

Line (1) declares two branch quantities, v_fuse and i_fuse, which are associated with pins p1 and p2 of the model. In this case, v_fuse represents the voltage across, and i_fuse the current through, the fuse’s element. Lines (2) and (3) declare free quantities which the simulator calculates to give additional information about the fuse’s performance. Line (2) declares r_fuse, the fuse’s resistance calculated as the sum of its cold and state-valued resistances. Line (3) declares temp_element, the temperature of the fuse’s element.

Line (4) declares r_switch as a signal, which in this case is a resistance that can change state instantaneously (quantities are analog unknowns which must change values continuously; signals are analog or digital unknowns that change state dis-continuously). The r_switch state-valued resistance is set by the amount of current flowing through the fuse, and is initialized to zero, meaning the fuse element’s normal (non-melted) resistance is simply its cold temperature resistance.

As I described for the lamp model, the terms following the [ : ] in lines (2) through (4) are type declarations which define the units use to plot the simulation results. Quantity r_fuse and signal r_switch are of type resistance and therefore plotted in Ohms; quantity temp_element is of type temperature and is plotted in degrees Celcius. The units for the v_fuse and i_fuse branch quantities are determined by the definitions for pins p1 and p2, which are assigned electrical natures elsewhere in the model.

Now that we’ve discussed the lamp and fuse models, it’s time to talk about the automotive emergency flasher system. I will introduce the circuit in my next post.

Post Author

Posted November 8th, 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

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