I now have no doubt left in my mind: system simulation is now all the rage.
A few weeks ago, I hopped on the bandwagon to write on the topic. I published a post titled Systems Simulation: Far-off Future or Feasible Now? here at the NAFEMs blog. That post focused on how to build a simulation model that incorporates various digital and physical representations from different engineering disciplines. Its complicated stuff in its own right. In that post, I posed the question of whether we're close to reality or some future vision.
Reality, however, is actually far far more complicated. Some organizations actually don't want to just simulate a system's performance at a single point in time, but want to progressively check behavior and validate requirements continuously during the design cycle. In simulation-speak, that makes it a transient problem. Suddenly a seemingly complex challenge becomes an order of magnitude more complicated.
With this post, I'm starting a three part series that looks at the next level of complexity and ultimately what capabilities are needed by software solutions. Where do we start? It makes sense to kick things off by looking at reality right in the face. Let's examine how design representations progressively change over time by engineering discipline.
OK. So where does it all start for mechanical design? How do engineers represent their design? And how to do they assess performance? From my perspective, the progression of mechanical design looks something like the following.
Now of course, this is still simplified. There are various shades of gray between each of these types of representations and assessments, but it will serve the purpose of this conversation. Now, let's take a look at electrical and electronic design.
Here, the engineers are designing boards as well as processors (ASICs, FPGAs, SoC, etc.) and have similar questions to answer. How are the designs represented? How are they assessed? Here's the progression for electronics.
Again, this is a simplified view of electronics design. However, it is representative of the progression from a very functional representation to the physical item that is prototyped and tested.
With software, there is no physical item to ultimately manufacture. Instead, you flash the software onto controller hardware, where it merges with the design of the electronics. However, the same questions are relevant here. How are the designs progressively represented? How is performance assessed?
It interesting that in the software world, there really aren't separate phases of detailed design and testing. Testing occurs very early on and continues all the way through release of the finished compiled software. In this way, this concept of continuous systems validation is more familiar than it is to mechanical and electrical engineering organizations.
Why is this important?
Well, think about what continuous validation of a system's performance actually means in the context of progressive representations and assessments in each engineering discipline. That brings up all sorts of interesting implications, but we'll get into that detail in the next post.
For now, let's recap.
Every organization is different. How do your designs progress? Any major representations I missed? Sound off and let us know your thoughts.
Take care. Talk soon. And thanks for reading.