". let us go down and there confuse their language, that they may not understand one another's speech"
about a year ago, i wrote an article for the millennium edition of electronics cooling magazine called "electronics thermal analysis moves into the 21st century". in the article, i wrote:
if i seem to have been concentrating on areas such as integration with other design and analysis tools, it is because i see these as the areas that will change the most over the next five to ten years. today's analysis software tools - whatever their underlying technical basis, gridding system and turbulence model - are all more than capable of calculating flow and temperature fields with a degree of accuracy that is more than acceptable for design purposes. after all, what value is there is a calculation accurate to 0.1°c when the input power levels are 100% out!
the real advances that the next decade will bring are in areas which tangibly and significantly enhance the productivity of thermal designers by making it easier and quicker to assimilate and simplify the varied data sources contributing to the analysis, and to manage and digest the resulting volumes of data.
the main difference will be seen in the increasing number of data sources that the analyst will be able to draw on, including importing geometrical and board layout files, web-based tools for specialized applications and more accurate component thermal models in public and corporate libraries. the end result - models that today take one or two hours to create will take minutes in future.
|
a year later, i believe that conclusion to be just as true as the day i wrote it. so what progress has been made over the last 12 months? sadly, not very much!
another tower of babel?
in genesis chapter 11, the bible tells how the construction of the tower of babel was halted simply by causing the builders to talk different languages so they couldn't understand each other. electronics thermal analysis didn't need any intervention from above! as things stand today, a file from icepak won't transfer to flotherm, a flow network model from macroflow can't share data with coolit, and there's certainly no common standard for describing a component tbm (thermal behavior model) - despite well over a decade of research into the subject!
this confusion isn't helping design engineers, or the industry as a whole. the productivity impact on design engineers is obvious, but it also affects others. for instance, if i were a fan manufacturer wishing to distribute data for use in software analysis packages, i would have to distribute different models for each software package. why couldn't i just post a single model which could be used by cfd tools, flow network models . ?
previous attempts at setting standards have either been focussed on a single area of the problem (e.g. iges, dxf and sat files for geometry, idf and gerber files for pcb layout etc.) or have become extremely complicated (e.g. step/express). as a result, software vendors have continued to develop proprietary file formats with little if any ability to move data from application to application. but the emergence of xml could change all this.
what is xml?
xml has developed from sgml - a tag language used mainly for aerospace documentation systems. sgml also spawned html so what i'm about to discuss may look familiar to some of you. the major difference is that, where html describes the appearance of a piece of text, xml tells you what it means and allows the software that is reading the file to figure out how to display it or interpret it. for instance, the following html gives you bold text:
<b> an html example </b>
the following xml would tell an appropriately configured system about an rjb value:
2.5
and this data could (for example) be:
- displayed in a browser as a static web page;
- used to create an entry in a pdm database; or
- processed to develop a mathematical model within an analysis package
over the last year or so, xml has become an accepted standard for exchanging data across the internet and between applications, and it is already being widely adopted as a b2b standard in a number of industries - including electronics. but to see what it might do for electronics thermal analysis, let's look at a simple example.
an example . an axial fan
let's build an xml file for (say) an axial fan. we start with the header that says that the file is xml. this has to appear at the top of the file:
]>
the next thing to do is to add beginning and end tags. these are important because they tell the parser that it's about to read a fan. so now our file looks like this:
]>
. the xml data goes here .
it's time to start adding content. let's define the geometry parametrically like this:
1.0 60 40 clockwise
but we may also want to associate a cad file from (say) pro/e or sdrc or . so we use what's called an inline tag like this:
note that the cad data doesn't actually need to be included in the xml file - the tag simply references an external file - either on a local disk or, using a url, somewhere else on the internet. now let's define a fan curve:
sealevel 12 60 0 0,85 0.01,40 0.04,25 1.0,0
and put those into the file along with acoustic data, emi data, applications notes. this is what we get:
]>
1.0 60 40 clockwise
sealevel 12 60 0 0,85 0.01,40 0.04,25 1.0,0 sealevel adjusted for object proximity 12 60 0 0,65 0.01,30 0.04,15 1.0,0
this fan should only be used in non-hazardous environments. it has very poor emi characteristics but is very cheap! also, this fan is likely to become obsolete pretty soon.
and now we have a complete xml file describing an axial fan. this file could easily be processed to be displayed as an html datasheet or read into a cfd package or stored in a pdm database or .
but who defined the tags?
i did. the cool thing about xml is that anyone can define a set of tags. but the power of xml emerges when a group of people get together and agree on a common set of tags. you can see the power of this in some of the formats being defined at www.xml.org.
the crunch . and a plea for action
so who is going to define this standard? i hope you are . design engineers, manufacturers of electronics thermal components, software vendors . no one single group will be capable of doing this.
about steve addison
from his early days as a project manager at british aerospace working on guided missile systems through phd studies in gas turbine engineering, post-doctoral work on aeroelasticity and vibration, consultancy in fields as diverse as the design of fans for vacuum cleaners, the development of diesel emissions sensors, analysis of power station heat exchanger performance.steve has worked across quite a spectrum of engineering disciplines.
from 1993 to 1999, steve worked for flomerics in the uk, california and massachusetts. amongst other things, he ran the san jose office, edited the user newsletter and developed web-based applications such as flopack and, more recently, flo/eda. he was also involved in the jedec jc15 committee on thermal standardization. in 2000, he worked for a time as the vp services for an e-learning consultancy headquartered in boston.
he is now living and working in seattle as an associate professor and program director for the oregon institute of technology and consultant for addison robson llc.
copyright © 2001 design-center.net inc. – all rights reserved.
|