At Aras’ user conference ACE, I sat in on a session where Malcolm Panthanki laid out the company’s vision for simulation support. Here are the tweets. I’ll add more commentary here and there.
I'm very interested to see what SPDM looks like inside of a #PLM solution. Take it to the #cloud and there are some interesting implications. #ACEcon19
— Chad Jackson (@ChadKJackson) April 16, 2019
I found Malcolm’s vision here interesting and I’m not sure it came through on twitter. When Aras acquires a company, they break that company’s solution down into web services. Those web services are then integrated into the Innovator platform. This is interesting because most PLM providers, in recent years, have acquired companies and kept their solutions separate. Most try to build a bridge between solutions and call that integrated. Don’t get me wrong; there’s some value in getting many solutions in the product development IT ecosystem under one provider’s roof. However, deeper integration allows processes to become more automated. Manufacturers avoid the big headaches associated with trying to get data from that solution to work with data from this other solution. I’m glad to see Aras taking this approach.
"#Systems definitions are the 'connective tissue' between mechanical, electrical, and software in the development process. This also make sense in the context of #simulation" Malcolm Pathanki, @aras_plm
— Chad Jackson (@ChadKJackson) April 16, 2019
I’m exceedingly excited to see Malcolm talking about systems in this way. Too many times, systems engineers develop an MBSE model at the beginning of development. Once detailed design starts, the physical architectures from the MBSE model are thrown over the wall. The rest is often forgotten. The engineering organization is then scared to death of making higher-level changes because it is very difficult to understand all the implications. The MBSE model is a great artifact to perform those kinds of trade studies, but systems engineers are told to focus on the front end. They have no time for it. They aren’t assigned that responsibility. I agree with Malcolm that these systems definitions are the right context for change, simulation, and much more.
"Simulation at the right level and as the right mix of high fidelity and low fidelity should be available at any phase of the development cycle." Malcolm Pathanki, @aras_plm
— Chad Jackson (@ChadKJackson) April 16, 2019
This matches an old concept from the aerospace and defense industry named ‘spiral development.’ You start out with low fidelity simulations to get insight early. Then, as development progresses and you get higher fidelity definitions and simulations, you use those and integrate them together. Glad to see this coming together.
Another piece that is missed is connecting the disparate #simulations produced in development together in a process. That then needs to be connected to systems and requirements for context. Everything needs to be configuration managed. – Malcolm Pathanki, @aras_plm
— Chad Jackson (@ChadKJackson) April 16, 2019
Files are quickly becoming a bad word in the development world. And for good reason. They can be lost. Stakeholders can be working against different versions of them. They can cause havoc. And they are the most widely used basis of development today. There’s strong potential to migrate away from files and reap many benefits.
The second concept here actually relates to the digital thread. Over time in development, you have an increasing number of definitions that grow over time. Furthermore, each of those definitions mature and get more detailed. A further complication is that different versions of different artifacts are interconnected. Configuration management of these digital artifacts are sorely needed to manage what version of what artifact relates to what version of other artifacts.
On top of this sits simulation templates that can be automated for design variants by many different roles in the development process. – Malcolm Pathanki, @aras_plm #ACEcon19
— Chad Jackson (@ChadKJackson) April 16, 2019
This is where simulation automation comes into play. The idea here is to point the simulation template at the right inputs, these various configuration managed artifacts in the Digital Thread, and run them. This is a big vision. And it can deliver a lot of value.
There's any doubt about it: @aras_plm's vision for #simulation is expansive with the addition of @COMETSolutions from an automation and democratization perspective. Slide images are from Malcolm Panthanki's presentation. #ACEcon19 pic.twitter.com/NdFoWR22jX
— Chad Jackson (@ChadKJackson) April 16, 2019
I agree that the systems that can manage simulations artifacts AND offer requirements management, system architecture definitions, configuration management are VERY few. However, these are the early days. Need many more case studies and pioneers to light the way. #ACEcon19
— Chad Jackson (@ChadKJackson) April 16, 2019
And here’s one takeaway: if your company is a pioneering one, then you should seriously look at this solution. It is early. Comet is not tightly integrated into Innovator, yet. But relatively few companies are going to be pursuing this effort. There is an opportunity for differentiation in product development. If your company is good with adopting almost-ready technologies, then you might want to jump on this early.
I know Malcolm's ending argument is to automate these simulations. However, I'd argue that there's a good amount of value in mashing up simulation management, requirements management, and configuration management. That may be the value-added intermediate step. #ACEcon19
— Chad Jackson (@ChadKJackson) April 16, 2019
Malcolm’s automation vision is expansive. I like it. It has tons of potential. But I do think there is an intermediate step: managing simulation artifacts in a PLM solution alongside requirements management with configuration management. There’s strong value there even without automation. Consider that as a step before simulation automation.
Case studies like this give a lot of confidence that there are opportunities to accelerate simulation. The question is what happens when you achieve that? Assess more options? Make the right decision faster? Avoid a prototype failure? I wonder what American Axle did. #ACEcon19
— Chad Jackson (@ChadKJackson) April 16, 2019
Lastly, here is one of those pioneering companies: American Axle. They leveraged Comet Solutions, without Aras Innovator, to automate their simulation process. There are a few metrics in here. I’m curious, as I mentioned in my tweet, about what they did with those time savings.
"Ford's experts spend 60% to 70% of their time making sure they have the right inputs for #simulation. They spend a day running the simulation. They then spend another day generating reports. That's too long" Malcolm Pathanki, @aras_plm citing a conversation with Ford #ACEcon19
— Chad Jackson (@ChadKJackson) April 16, 2019
Here is another case study, this one from Ford. Again, there are time savings here. But what did Ford do with that extra time? That gets to the heart of ROI.