I have been living in the US now for 13 years and occasionally I get a little nostalgic for the TV shows I grew up with in the UK. I found a DVD catalogue which included what in the US we call Cop Shows. The English vernacular I remember is Police Dramas. I ordered some old favourites such as “The Sweeney”, “The Professionals” and even an extraordinarily dated “Dixon of Dock Green”.
As I sat through a few it struck me that there was often a common stage in the plot line. If a bank had been robbed, security van hijacked or similar knavery, the first thing our heroes did was to arrest the ‘usual suspects’. The thinking is pretty logical; if somebody’s going to rob a bank they have probably done it before. Police dramas are somewhat telescoped in time. We need a solution within an hour - or if it’s a special show at most 90 minutes.
I’m sure real policemen cringe at some of the procedures but there is probably merit in the ‘usual suspects’ theory. In FE Analysis we don’t have many crimes but sometimes things do go dramatically wrong. The solution fails to run or we get dubious answers.
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.
Commercial marketplace for CAE software is undoubtedly similar to any other marketplace where competitors vie for increased market share. Add to this landscape, organizations and individuals who believe in open source environments and the landscape becomes even more competitive for CAE software companies. This paradigm certainly holds true for CFD software as evident by “significant” number of available software and frequent new releases and upgrades. Discussing this landscape with a friend, he made an insightful comment that today’s CFD software (commercial or open source) seems to be about 10 to 15 years behind the currently available FEA tools in terms of maturity. Now, I don’t know enough about FEA software to gauge the accuracy of this comment. However, with some certainty, I can declare that the present CFD tools cannot be considered “mature” at this time.
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.
Earlier this year I travelled from London to Glasgow for a meeting. That gave me the opportunity to ride on a railway train for the first time in Britain since the era of British Rail. My memories are of a system that was starved for funds with much neglect and decay. Returning by rail to my hometown on one trip was a shock. The elegant Victorian station had been savagely removed, and a corrugated iron shed had been put in its place, losing a few hundred yards of track.
However the journey to Glasgow drove away all those memories – it was a brilliant ride! The journey only took four hours and it was comfortable, quiet and very relaxing. It was tempting to sit back and thoroughly enjoy the experience, instead of working as planned.
One of the main improvements was the ride smoothness at around 125 mph. I had to do some ‘engineering’ experiments to detect the vibration (I will leave you to guess what those were and perhaps get some feedback on ideas, in the spirit of exploding dough and carrots). I walked along the carriages without the violent swaying and rocking that I remember well. I have since read an article explaining that it is a combination of track straightening and banking, together with carriages that can tilt into the curves. The combined bank angle was impressive; with the surrounding countryside rolling about the carriage axis quite happily.
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.
Saving the Engineering Budget
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.