Electrical Fuse Model for LTSpice

Many years ago I developed a very detailed fuse model for the Ansys Simplorer tool. Later I adapted it for use in the Synopsys Saber tool. The concept is generic and easily transportable to conserved simulation tools that are SPICE knock-offs such as PSpice and LTSpice. The model has been successfully used in very large whole systems simulations with terrific success. The concept is valid for SPICE knock-offs. It is just tricky to implement.

I have written a paper intended for publication for either the IEEE, SAE, or the ARRL QEX journal. It’s peer review has been completed to my satisfaction. The only thing holding me back is a sample LTSpice implementation. I am an expert with the Ansys Simplorer and Synopsys Saber tools but know little of the LTSpice GUI. I can talk in detail about what is under the hood with LTSpice but the GUI is still in a learning phase for me.

My model duplicates the fuse functionality for its self-heating effect with very great accuracy. It is also thermally based so that there is no digital timing involved whatsoever. This makes it ideal for periodic stimuli applications.

Here is a brief list of what my model addresses that serves well in whole power distribution analyses.

  • The model is table based. The user assembles in tabular form the time to blow as a function of blow currents from the published curves. A programmed Excel worksheet converts this to energy as a function of current. It is this static table that characterizes the subject fuse.
  • While the user supplied data is i2t, the model (via the Excel conversion) sees the equivalent of j2t or Joules to time. This is significant because the model will therefore respond properly to periodic or random stimuli.
  • Because the characterization is table based, irregular i2t profiles are accommodated with precision.
  • The entire characterization process is highly algorithmic. This means that for the very most part, there is very little engineering judgment required. Plug in the variables into Excel, and it produces the arguments for the model.
  • The accuracy of the characterization depends on the density of the original table supplied by the user to the Excel worksheet. However, the model correctly responds in the direction of the error to solutions taken between table data pairs. That is, the error that results from a distance between data pairs goes in the correct direction except for irregular profiles. If there is too much spacing between data-pairs, then the results will dip too low. But what is too low? Because the model “errs” in the correct direction, it takes a lot of space between data-pairs to err greater than 12%. For irregular profiles, the user must increase the density between data pairs for that particular region or accept the minor error that results.
  • Success of the model depends on how effective the model is at its commutation of current. This is the downfall of all SPICE and analog simulation tools. They cannot process a discontinuity. But in real life, we all know that there is no discontinuity. There will always be a rise and fall time. It may just be too small for us to notice it. Therefore, the model must be robust in this regard which is no small trick.
  • There is a rare case for a thermally bi-modal fuse. When a pulse is applied to a fuse it spends the energy generating heat. At the conclusion of that pulse, the fuse element temperature begins to decay. For most fuses (including those with irregular i2t profiles), the same thermal network that oversaw the temperature increase will properly see its decrease. However, some OCPDs have a bi-modal thermal aspect to them. An example of this is the Master Service Disconnect (MSD) fuse for electric vehicles. The location of these for all electric vehicles is published by the federal government for al electric vehicles and distributed to all fire departments. These fuses cost about $80 each and have a tiny, tiny piece of nearly pure silver serving as the fusing element. But it is buried in a cake of sand that is about the size of your fist. With that topology known, the reader can easily see that it would take “no time at all” for the fusing element to heat but much longer for it to send its thermal energy into the ambient. If the fuse is to accurately accommodate periodic and/or random stimuli, bi-modal modeling is required for these devices.
  • Forbidden Zone operation
    • All fuses have a forbidden zone of operation.
    • Forbidden zone entry happens when sufficient energy arrives to change the fusing element composition but not enough for fusing.
    • Forbidden zone entry compromises the fuse making it likely it will experience a nuisance blow in its future.
    • Forbidden zone entry may be identified as that fusing element transient temperature which equals its temperature given its rated current. An example follows.
      • A fuse is rated for 20 Amperes.
      • Its blow current will therefore typically be 27 A.
      • Two temperatures may then be identified. The fusing element will heat to
        • BenchmarkoC given 20 A
        • 400oC at 27 A which initiates a fusing state. Note that although copper and silver both melt at about 1,000oC, the actual temperature of fusing is much less for alloyed and mounting reasons.
      • When a simulation indicates a fusing element temperature of BenchmarkoC, forbidden entry is assumed and the fuse is considered compromised.
  • Because the model is intended for use in whole systems simulations where the fuse is merely one very, very small part of an entire automotive electro-mechanical braking system for example, the model must be numerically low-demanding. It must be simple so as to not bog down the whole simulation.
  • I’ll add more items to the list as I think of them.

I am comming up to speed sufficiently with the LTSpice GUI. At the time (May of 2023) of this writing, I believe I have a functioning LTSpice model representing the model described in the paper. But here’s the problem: While implementations of the model theory in both Simplorer and Saber have proven extremely robust, I need to battle test my LTSpice implementation. I am going to need a volunteer or two for battle testing before releasing the draft for publication. Until then I am accepting volunteers to help. But in order for me to accept your help, you must first convince me that you have a deep knowledge of the LTSpice GUI and its macro-modeling techniques. This thinking pushes LTSpice to its limits so I can only accept expert help.

Write to: N8QM@arrl.net

Page 1 of the rough draft may be found here.

I have written a paper on SPICE diode characterization which was published in the May 2023 issue of the ARRL QEX journal.