Fields marked with a * are required

SIGN UP FOR OUR NEWSLETTER

The Misnomer of Simulation Lifecycle Management

References Cited

Mechanical Computer Aided Engineering (MCAE), Product Data Management (PDM)

It doesn’t seem like it was that long ago when we started hearing about Simulation Lifecycle Management (SLM). But blink your eyes and its five years later.

When software providers first started talking about this type of solution, I remember there was quite a bit of confusion. What exactly does it do? Is it like PLM? Fast forward to today and I think there still is a good bit of confusion.

I plan to write a good bit more about simulation here in the coming months, including topics about SLM. So before I add to the confusion, I figured the appropriate place to start is to provide some sort of definition for it. Because, as you may or may not know, there is no definition for it in wikipedia.

Simulation Data Management: The Foundation

If you’re going to talk about Simulation Lifecycle Management, you have to start by talking about Simulation Data Management (SDM). What is it? Essentially, it fulfills a role similar to that of Product Data Management (PDM). More specifically, it is similar in how some PDM workgroup data managers track and control the versions and iterations of MCAD models, drawings and other deliverables. SDM manages and controls the artifacts that are used to execute simulations as well as the results of those simulations. There are terrible complexities that need to be managed there as there are interconnections between simulation artifacts and MCAD design models as I have published in a post titled The Pitfalls of Multi-Disciplinary Simulations: Divergent Model Abstractions. Furthermore, there is also complexity in terms of managing the ‘who does what’ scenarios amongst a team of simulation analysts or engineers and designers executing a simulation driven design initiative per a post I published titled Is Teamwork the Key to Simulation Driven Design? This stuff is no joke. In many ways, managing the simulation model, all of the simulation cases and the results in addition to their connections to abstracted as well as original MCAD models is far more difficult than simply managing MCAD models through their progression towards design release.

So is this a part of SLM? In my eyes, no. I apply the same logic that applies to PLM and PDM, which I see as two separate types of systems per a post I published titled PLM: The Debate over the Troubled TLA. SDM can and does need to stand on its own so it can be assessed for value independently.

Simulation Lifecycle Management: Technology Automation, Not Process Automation

Many people take the position that SLM is a parallel to PLM except applied to simulation. But I fail to agree with that logic. And here’s why.

PLM (whether you define that as process enabling technology or process and data management technology) is mainly used to automate business processes. That includes things like a change management process that could be executed with paper forms, email or a PLM’s workflow engine. That includes things like a portfolio management process, which again, could be executed using a number of technologies. The same is true of requirements collection, breakdown and allocation. The same is true of design release, manufacturing planning, service planning and so on. Each is a business process that needs to occur regardless of what technology (or lack thereof) enables it to be done more quickly or efficiently.

SLM, on the other hand, is mainly used to automate procedural activities for simulation software. There are powerful capabilities to tell new users exactly how to perform a complicated analysis step-by-step on their own. There are great tools to automate mundane and laborious tasks for expert simulation analysts that are required for complicated multi-disciplinary simulations. I believe there is a lot of value to the individual as well as the organization in these tools and capabilities. However, the process-like capabilities focus on how to use the simulation software, not business processes. The analogy, if any truly fits, to the world of CAD would be step-wise guidance on how to put together multi-CAD assemblies  or engineering automation systems that generate complex models based on a few inputs instead of PLM’s automation of a new part introduction process.

A Better Suited Name?

From my perspective, Simulation Lifecycle Management is a poor and misleading description of what the system actually does. I think this may unfortunately have contributed to the lackluster adoption of SLM over the years. Trust me, I strongly believe there is a lot of value in this type of solution above and beyond Simulation Data Management. But if I were to pick a better description of this solution today, it would be something like Simulation Procedural Automation (SPA) or the like. But let’s admit it, that ship has sailed. I think as long as we understand the scope and application of this type of solution, we’ll be fine.

Conclusions and Questions

Let me go back and quickly summarize my points here.

  • Simulation Data Management (SDM) is a system separate from SLM that controls and manages simulation artifacts. It’s parallel in the MCAD world is CAD PDM. However, managing simulation artifacts is an order of magnitude more complex than managing CAD models and deliverables.
  • Simulation Lifecycle Management (SLM) is a system that assists in the procedural of simulation software, whether that is in the form of guidance or automation. It’s equivalent is not PLM, which automates business processes, but more like engineering automation solutions that generate complex CAD models with a few inputs.

Well, I’ve shared my thoughts. What are yours? Did I miss any major categories of capabilities for SLM? Do you feel that SLM truly is equivalent to PLM? I have no issue with professional disagreements. In fact, I like those types of conversations because it only lends clarity to complicated topics like this one. So please, don’t hesitate to let me know you don’t agree. I look forward to the conversation.

Take care. Talk soon. And thanks for reading.

Chad Jackson is an Industry Analyst at Lifecycle Insights and publisher of the engineering-matters blog. With more than 15 years of industry experience, Chad covers career, managerial and technology topics in engineering. For more details, visit his profile.

Like this post?

Sign up now to get more like it

Fields marked with a * are required

SIGN UP FOR OUR NEWSLETTER

  • Stan Przybylinski

    Hi Chad,

    Once again you are getting in the middle of the vendor-induced nomenclature wars (see “what is PLM”). We should be spending our time talking about what use cases need to be supported, and then let the vendors battle it out to define the terminology. And, once again, we are talking about some level of data and process management. But what is the right data, at the right level of abstraction?

    Managing data is important, but it is not enough. Process enablement is important but it is not enough. I saw an interesting demo from Tecplot recently for their Chorus offering and their notion of “simulation analytics” and their support for advanced visualization to support higher level decisionmaking. These type of use cases will support collaboration across broader sets of stakeholders and can help make simulation and analysis (S&A) a part of the strategic conversation, not as just another set of tools.

    • Stan, in this case, I respectfully disagree.

      There are many out there that have legitimate questions about these types of technologies. What is it? What the value to me? What concerns are there about it? This and earlier posts aim to answer those questions or at least serve as some type of reference for others to come to their own conclusions.

      For me, I try to understand what the capabilities are and then understand the implications are for the organization. I don’t feel a compelling need to make a tool or technology be any more useful or strategic than it already is. I think it’s fairly clear what engineering organizations are trying to do. If a technology is earth-shattering in that regard, so be it. But if it falls short, then so be it as well.

      If you don’t think this type of conversation is worthy of your time, I understand. No one is forcing you to participate. However, I do think it is worthy of my time, so plan to continue conversations like this around SLM/SDM/SPDM and many other technology areas relevant to engineering.

      And by the way, I’d be happy to help with the other type of conversation you are suggesting as well.

      Take care. Talk soon.

  • Dennis Nagy

    Hi Chad,

    There is also (perhaps a little newer fashionable term) Simulation Process Management (SPM) which IMHO is closer to what you described as the activities mis-labeled as SLM. PLM exists because products (P) have lifecycles (L) (from initial ideas through design, manufacture, deployment, maintenance, and finally retirement) which are somehow managed (M).

     I think the activities of SDM, SPM, V&V, KBE, and a few other simulation-related activities could all now fall under the emerging term of “Simulation Governance” (SimGov).  Whereas products are what companies produce (hence PLM), simulation is one of the (increasingly more strategic and important) resources used by companies in the process of PLM. As simulation becomes more recognized as a corporate strategic resource, it needs to be correspondingly governed (software verification/validation, user certification, data management, best-practices management, etc.).

    An aside to Stan: CIMdata is using the acronym S&A (Simulation and Analysis) so it would be helpful if you could explain the difference between the two terms “simulation” and “analysis” (i.e., you are using two words to describe what I believe most people consider to be one thing, but called “simulation” by some and “analysis” (as in FEA) by others).