Chad Jackson is the President and Principal Analyst of Lifecycle Insights, a research and advisory firm that assesses the business impact of software applications and systems on engineering organizations. Chad has more than 15 years of experience with CAD, CAE, PDM, PLM and related technologies as part of the analyst community and software industry. Due to his industry knowledge and thought leadership, Chad is a sought-after expert, author and speaker that has advised, published and presented dozens of times domestically and internationally.
Continuous systems validation brings a whole new level of complication to simulation. In my first post in this series, we looked at how designs progress in various engineering disciplines. In the second one, we looked at how cross-disciplinary simulations are actually assembled out of these different designs. But furthermore, as the design progresses at the system level, that configuration will change. Today, in this post, we'll look at some of the most critical capabilities that a software solution needs to address this reality. Let's dive in.
An obvious first step is being able to run these simulations. Obvious, right? But this capability isn't as widely available as you might think. A lot of progress has been made insofar as Hardware in the Loop (HIL) for controllers. Today, with some simulation solutions, you can plug physical mechanical hardware and physical boards and processors into controller software running on a desktop (as opposed to controller hardware). You can test out the configuration before you ever receive your controller hardware.
But the opposite isn't quite as available. The idea of connecting a mechanical simulation to a board simulation and a physical controller isn't very accessible. Every possible permutation of digital concept, detailed design and physical item for each engineering discipline needs to be covered. This is mainly due to the frequent reuse of items in the design cycle. Complete system clean sheet design is rare.
This marks the first area that needs improvement.
Ready for more system simulation?
Well, strap in. This is where things get complicated.
In the last post, we dove into the progressive means of representing and assessing designs in mechanical, electrical and software domains. We found that in each discipline, the representations changed. We also found that the means by which each design representation is assessed progressed as well.
Now why is that important?
When it comes to simulating systems, you can always create a system model that is representative. You can use that model to simulation a system's performance. However, and here's the catch, the holistic system model will always lack the fidelity of discipline specific representations and assessments. Essentially, I'm saying that the system model will never predict the behavior of the mechanical design more accurately than the mechanical model.
Instead, what some organizations are trying to accomplish it assemble system models form the disparate discipline specific models. But there are two challenges that await such organizations.
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.Continue Reading ->
Is the cloud that big a deal for simulation anymore? I mean, we basically know what it means. Run simulation sin the cloud. Leverage all that compute horsepower up there. Get lots of results way faster. Rinse. Wash. Repeat. Right?
Well, that's where I disagree. Bigger changes for simulation in the cloud are hidden just below the horizon.
All that compute power is enticing, right? It's a great story. But there's just one big problem: getting your simulation model into the cloud. And that wouldn't be a problem if these simulation models weren't quite so humongous. I mean, you wouldn't need all that compute power if these simulations were easy to solve, right?
For me, this along with concerns about intellectual property have been the factors limiting the success behind the vision of performing simulations in the cloud. But interestingly enough, this will soon be changing.Continue Reading ->
Move over multi-physics. There's now a different field that qualifies as the bleeding edge of technology in simulation: system simulation. Many organizations are just starting to broach this field in an effort to better understand how systems perform holistically.
But what is it? Is it really feasible for practical use today? Let's dive in and discuss.
Terminology can be such a challenge. So before we go barreling off to talk about the questions above, let's set some baselines. To start, if you're unfamiliar with systems engineering, go check out its entry in wikipedia. It does a fairly good job explaining the key points.
Furthermore, if you want even more information on systems engineering, you'll want to head over to the site of the International Council on Systems Engineering, or INCOSE for short. They have developed a system engineering standard, both in terms of processes and definitions, that are fairly mature.
Between those two, you should get a good idea of what system engineering is all about.
This last week, I attended the Council on the Future of Engineering Software (COFES)in Phoenix AZ. It's a great event that brings together many of the leaders of the industry from the ranks of software providers, journalists, industry analysts and manufacturers. We get together a debate a lot of edge topics relevant to the technology that engineers use to design and develop products. And this year was no different.
Like every year, there are some topics that are edgier than others. And I came across one in particular in three separate conversations and briefings over the course of the event. All of it was essentially based on this premise.
By the time someone starts using CAD, all the major design decisions have been made.
Now, if you've followed my posts in the past, you already know that I subscribe to this concept wholeheartedly. That is, at least in part, why I advocate that 2D still has a legitimate use in design for engineers (see past posts including Every Engineer's Dirty Little Secret? The Stigma of 2D). But I think there are some other serious implications, especially for simulation.
A couple weeks ago, I wrote a post titled The Key to Championing Simulation here on the NAFEMS blog that looked at the best way to move the simulation capabilities of an organization forward. The key, I said, was to befriend the bean counter. The idea is to get their help building out an ROI case that is credible and specific to your company and, as a result,make a more convincing case to executive leadership.
While I've said that you should work with the finance folks to build out that justification organically, tailoring it to the specific financial challenges of your organization, that doesn't mean you can't walk into a discussion with the finance folks without some ideas. In this post, you'll find some starters along those lines. Let's take a look.
Engineering, like any other functional department in a manufacturer, carries a budget. Now,of course, most of engineering's budget is tied up in human capital expense(paying people). But individual development project budgets carry money to design and engineer new products, systems, assemblies and parts. That budget is often spent towards the back-end of the design phase in the form of building physical prototypes and testing, as this has to occur prior to design release.
Simulation can play a significant role in this context. One of the primary advantages it provides is the verification and validation of a item's performance before any prototype is built and tested. If you can avoid building multiple prototypes and avoid multiple rounds of testing, then those are hard dollars the engineering organization would have spent that they now don't.
Everyone likes a good debate, right?
Well, as a co-host for the web show Tech4PD, I have to admit that I am a little biased. The idea behind the web show is that Jim Brown, another Industry Analyst, and I debate various topics about technology that enables product development. Viewer's votes determine who wins. The loser has to fulfil a consequence. Last month, Jim did a 35 degree polar bear swim. Earlier, I had to shave my head. In the second episode, Jim had to brush his teeth with wasabi.
Regardless,he and I have debated integrated suites versus granular solutions time and again on the show. And I was thinking, the topic strongly applies to simulation. Perhaps more so than any other area.
Given that, I wanted to get your feedback. Should simulation analysts mainly use integrated suites or granular solutions to setup, run and review their simulations? Before we jump into that debate, however, let's look at some of the past episodes for precedence.