Serious mature businesswoman using computer at desk. Female professional is sitting in office. She is wearing smart casuals.
Chad Jackson

Chad Jackson

The Vision Behind Aras’ Acquisition of Comet Solutions

Click here
A little while ago, Aras acquired Comet Solutions. At ACE, Aras' user conference, we got a little more insight into the vision behind that acquisition. Here's my review of that presentation.

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 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.

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.

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.

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.

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.

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.

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.

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.

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.

Share this post

Share on facebook
Share on google
Share on twitter
Share on linkedin
Share on pinterest
Share on print
Share on email