In this post, I’ll provide a little background on this product, the capability it provides as well as my own commentary and analysis.

Background

In 2000, Michael Topolovac and Eric Larkin founded the company bom.com to continue the development of the Arena BOMControl PLM system that they started back in 1994 at Light & Motion Industries. In February, Arena Solution launched two new products, PartsList and PDXViewer (press release), to work alongside BOMControl.

Capabilities Provided

Today, we’ll be focusing on the two new products offered by Arena Solutions: ParsList and PDXViewer. Let’s take a look at the capabilities that each provides.

First, let’s start with PartsList.

• Users can create BOMs by adding new components or import spreadsheets in the form of CSV files.
• When importing CSV files, you can map your spreadsheet columns to the fields in PartsList.
• By default, a PartsList BOM includes the following fields: Item Number, Manufacturer Number, Manufacturer, Description, Distributor, Distributor Number, Quantity, Reference Designator, Cost, File, Part Notes, URL and Buy.
• The fields for PartsList can be customized by the user. The size of the columns that show these fields can be resized and reordered.
• Through its integration with Octopart (corporate website), which provides component information about electronic parts, PartsList automatically fills out all of the BOM fields such as costs, descriptions and even data sheets.
• The URL field takes the user to the supplier’s web page about that part.
• The Buy field lets you add the component to your shopping cart so you can purchase it.
• The BOM can be exported in the CSV format or the Product Data eXchange (PDX) format, a standard organized by the Interational Electronics Manufacturing Initiative (iNEMI, corporate website).
• The PDX format acts like a package of structured information and files that includes BOM, prints, drawings, specifications, images, messages and other files. All of this is captured in a single file. This single file can also be imported or exported by several PLM systems.
• PartsList works inside of web browsers, so there is no installation of a software application.

Second, let’s look at PDXViewer.

• PDXViewer lets users view PDX files, which includes BOMs, part information, Approved Vendor Lists (AVL), Approved Manufacturer Lists (AML) and other files.
• PDXViewer allows users to filter these files based on their attributes or by selection. A user could select a subset of parts and only send that information to another person.
• PDXViewer also works inside of web browsers, so there is no installation of a software application.

Commentary and Analysis

OK. We now know a little bit more about what capabilities these products provide. Now lets talk about what it means for engineers.

Concept BOMs for the Engineer

As I mentioned before, there aren’t many tools for engineers to mockup conceptual BOMs. Most just use spreadsheets for that purpose today. So is there any advantage of using PartsList over a spreadsheet?

If your products include a lot of electronics components, then the answer is a resounding yes.  The advantage isn’t in creating the list of parts. It’s in getting all that other information you need to be populated for each component. You need to know the cost. You need to know the suppler. The capability of automatically populating those fields from Octopart is huge. Not only because of the automation, but also because of the accuracy. Human error can take the form of incorrect information.

There are many PLM systems that trending towards supporting mechatronics products. However, there are very few that support conceptual BOMs like this.

Sourcing for Contract Manufacturing

An important characteristic of the PDXViewer product is in filtering and exporting. I know. It doesn’t sound like the each-shattering functionality. But here is why it is important.

Some subsets of even just individual components from a mechtronic product might be sourced to a specific supplier. If you are only sourcing a subset of the components, then you certainly don’t want to provide more information about the product than necessary. Yet, you do want to share as much information such as data sheets and the like. The fact that PDXViewer lets you filter down to what you want to source to one supplier and export only that information lets the engineer or purchasing agent accomplish both goals: share information but do it in a IP secure fashion.

Summary and Questions

OK. Let’s hit the recap.

• Arena Solutions, which was founded in 2000, launched two new products called PartsList and PDXViewer in February of this year.
• PartsList lets engineers create conceptual BOMs and use an integration with Octopart to automatically fill out lots of information about those parts. These BOMSs can then be exported in CSV or PDX formats.
• PDXViewer lets engineers open, filter and export PDX files. These files can be used to interact with suppliers in an IP friendly fashion.
• If your products include a number of electronic components, then these two products can offer a significant advantage in developing, managing and sourcing BOMs.

Those are my thoughts, now it’s time for you to sound off. What do you think about tools that let you develop BOMs outside of a PLM system? Are any of you using PDX to exchange information with your suppliers?

Take care. Talk soon. And thanks for reading.

Related posts:

1. Point Solutions, Integrated Solutions and the Granularity Value Proposition
2. Mechatronics Management (Part 1): Mechanical Aspects

The Chain of Progressive Models for Simulation

When you start to prepare for a simulation, it’s not as simple as pulling up a model and starting to work. There’s actually a progressive sequence of activities that leads to a chain of distinct different artifacts. Let’s walk through them.

• Fully Detailed CAD Model: It often all starts out with the CAD model that is used to generate manufacturing drawings. But to various degrees, that includes every single detail of the design which often is not needed for the simulation. This first artifact is taken and then changed into the…
• Simplified / Abstracted CAD Model: In this model, the user makes several abstractions or simplifications. They might remove geometry or replace it with different alternative representations. Ultimately, this lets the simulation be functionally equivalent to the original but solve faster. This model is then used to create the…
• Simulation Model: Once the simplified / abstracted CAD model is complete, it is then used to generate simulation artifacts such as the mesh, loads, boundary conditions and the like. Once this is ready, the simulation can then be solved.

Where Is the CAD Model Managed?

Seems like an obvious question, but actually this is where things can get a little confusing.

There’s little question that CAD models have been managed by workgroup level CAD PDM systems for years. There are a wide variety of tools out there that can offer this capability.

However, the bigger issue seems to be not he SLM side of things. Part of the reason you want a SLM system is to gain traceability across that chain of progressive models for each simulation that is run. You want to know which iteration of the CAD model spawned which iteration of the simplified / abstracted model and in turn, which simplified / abstracted model spawned which simulation model. If you don’t know that, you don’t have a chance at understanding which original design the simulation results represent.

That can be problematic if you are trying to make a simulation driven design initiative work. As a refresher, a simulation driven design initiative is supposed to provide insight into design performance in the design cycle, when the designs are changing rapidly. Without traceability, you could quickly loose track of which applies to which.

Approaches to Solving the Problem

So how do you work around this problem? Well, it seems like there are a few different strategies or approaches that are available.

First, you could go with a combined CAD and CAE data management solution. These offerings are few. However, if you house both in the same system, you eliminate the issue altogether. The issue with this approach is putting every CAD and CAE model into once system. Is it reasonable to use a single system in today’s day and age? I think that’s debatable. But its a debate for another post.

Second, many SLM systems offer integrations with CAD PDM systems. The issue to address in this scenario is to make sure that the SLM system points to the right iteration of the CAD models in the CAD PDM system. It’s a capability to deeply investigate if you are looking at this kind of setup.

Third, you could try to go with some Master Data Management (MDM) approach? For those of you not aware of it, MDM offers the ability to create a ‘golden record’ of everything that exists in various different systems. Once you have a centralized record like that, you can control information from there and push it out to all of the various different systems, SLM or CAD PDM or otherwise. This lets you drive it from a single place. The appeal of such an approach is to address the duplication of files and information, which seems like a root issue in this scenario.

Summary and Questions

Alright. Let’s recap.

• Simulations are built up through a progressive sequence of models. It starts with the original CAD model. That spawns the simplified / abstracted CAD model. That in turn spawns the simulation model.
• It’s important to know which iteration of a model was used to generate which iteration of the next model. If not, you don’t understand which simulation results relate back to which CAD model. That can undermine any Simulation Driven Design initiative.
• This trail of progressive models needs to be created. However, CAD models are managed by CAD data management tools today. Simulation models are managed by SLM systems today. The fact that these two related models are managed in separate systems can break that trail of traceability.
• There are a few different ways to address this shortcoming. You could use a combined CAD and CAE data management system. Another approach is to use integrations between CAD PDM and SLM. Lastly, a MDM approach might work.

Alright folks. This are my thoughts. Now, I’d like to hear yours. How do you document and keep up with traceability between these models today? Has anyone tried to use the MDM approach? What other issues are there with respect to traceability between these models?

Take care. Talk soon. And thanks for reading.

Related posts:

1. The Pitfalls of Multi-Disciplinary Simulations: Divergent Model Abstractions
2. The Misnomer of Simulation Lifecycle Management
3. Is Teamwork the Key to Simulation Driven Design?

That’s the question we took at a recent roundtable discussion at this year’s COFES. You see, in the past year, there have been a number of PLM-ish products that have been launched that don’t have PDM capabilities included. You have Autodesk’s PLM360 which can optionally be integrated with their Vault product (here’s my review). You also have Kenesto, an ad-hoc process routing system that let’s you attach files, but doesn’t do day-to-day PDM (here’s my take on their product as well). Then you have Nuage, which is far more focused on the social technology side of PLM than PDM (and here’s my review of this one too). And of course, you have Arena Solutions and Aras that have 3rd party offerings for PDM.

So what’s the argument for and against integrated PDM and PLM offerings? Let’s take a look.

The Arguments Back Then

Back in December of 2010, I published a post titled PDM-less PLM: Pragmatic or Problematic? In it, I laid out some early arguments on both sides. I went back, took a look at them and had to admit that not a whole lot had changed. To start, here’s the arguments against the separation of PDM and PLM.

Traditional thinking is that PLM and PDM should be integrated. Why? The idea is that while executing a process with a PLM system, stakeholders will need to reference and review product data which resides in the PDM system. An integration between these two systems enables the PLM system to always point at the right version of the product data. As a result, decisions in the process are always made against the correct product data. If done manually, decisions may be made against the incorrect version of product data, leading to erroneous decisions. This same core concept extends to reporting and analytics that may be based on product data. It also extends to generating an traceable audit trail for liability or legal reasons.

And here are the arguments for the separation of PDM and PLM.

The fly in the ointment with the above argument is how PLM systems are deployed today. Very few companies go with a big bang deployment of PLM. It’s just too expensive and too long before an return-on-investment is achieved. Instead, many manufacturers use a phased approach composed of intermittent projects that on show a ROI on an individual basis. Where’s the problem? The deployment of PDM across multiple sites, multiple continents or an extensive supply chain requires a significant investment in terms of time and money. As a PDM deployment must often be completed prior to the start of the PLM deployment, it can be years before the PLM system addresses process issues.

If you’re not familiar with this concept of granularity in the IT ecosystem for product development, you can catch up on it in my post titled Point Solutions, Integrated Solutions and the Granularity Value Proposition.

The Arguments Now

Fast forward a year and half, and there have been some progress or maturation of the arguments on both sides.

During the COFES discussion, one executive from a software provider took an interesting position. They said that if you should really look at PDM system simply as an extension of the CAD application. Whichever CAD application you choose, you should also use that same PDM system to manage its CAD data. They further went on to say that if you have multiple CAD applications, then you should have multiple PDM systems, one for each CAD application. The implication, as a result, is that you will need something separate to manage all of those processes anyway. So why not separate it.

Another related concept was related to how you integrate an IT ecosystem that is fragmented due to a granular approach. Most everyone in that session agreed that a ‘light’ integration made sense. But we never did dive down to really come to a consensus around what that ‘light’ integration would look like. However, I would suggest that it needs to be integrated enough to point people to the right data that is spread across the fragmented IT ecosystem. Interestingly enough, solutions like Inforbix (my review is here) and alcove9 could provide such capabilities. But to be honest, they would really need to be integrated into something like PLM360, Kenesto or Nuage.

What are the other arguments against take such a granular PDM separated from PLM approach? We had some representatives from software providers that offers such PDM-PLM integrated solutions. But they weren’t vocal. I don’t think that the ‘you need to access the right data during the process’ argument has faded in terms of strength. All one needs to do is point to the harm that an decision made off the wrong data can do to a product development schedule. I’m not sure, however, that is has matured beyond that.

Summary and Questions

Here’s the recap.

• A number of PLM-ish systems that do not offer PDM capabilities have emerged in the market, including Autodesk’s PLM360, Kenesto and Nuage.
• The argument against the separation of PDM from PLM is that decisions in a process might be based on the wrong data, which leads to downstream errors.
• The argument for the separation of PDM from PLM is that a more granular approach needs to be taken to the IT ecosystem supporting product development in general. All encompassing solutions take too long to deploy and are too costly.
• Folks at COFES agreed that in a granular IT ecosystem, there needs to be a ‘light’ integration between systems. Although it wasn’t clear what form that should take. In my opinion, the key is getting people to the right data.

Like I said before, it’s been a year and a half since the last discussion. What’s your position on this topic? Is it dangerous, too dangerous, for manufacturers to take seriously? Is it a long overdue concept? What do you think some critical aspects of a ‘light’ integration are? Sound off. Let us know what you think.

Take care. Talk soon. And thanks or reading.

Related posts:

1. PDM-less PLM: Is It Pragmatic or Just Problematic?
2. Mechatronics Management (Part 1): Mechanical Aspects
3. What Wasn’t Said at SolidWorks World 2012

I thought that looked pretty interesting. I hadn’t heard from the Oracle folks in a while. So I then headed over to look at their blog post. I started reading and, apparently, they’ve been talking about this ‘Product Value Chain’ concept, which linked from that post off to Oracle’s corporate site. From there, I got a little better idea of exactly what they were talking about. Here’s a brief excerpt.

To manage growing product complexity and innovation challenges, product-focused applications such as Product Lifecycle Management (PLM) and Product Information Management (PIM) solutions are becoming staple IT investments. But as product information continues to span more and more functions inside the company and out, these implementations are not only expanding enterprise-wide; they are adding integrations, functionalities, and touch-points to serve new needs in a fully connected world. We call this progress the Product Value Chain, an integrated business model powered by Oracle that offers rich new strategies for executives to collectively leverage enterprise Agile PLM, Product Data Hub, Enterprise Data Quality for Products, and other industry leading Oracle applications to achieve further incremental value.

Below this excerpt, they included a little chart showing that Product Value Chain Management is an evolution beyond Product Lifecycle Management. I thought to myself, “wow, they must have something truly revolutionary here.” So I started digging, investigating and looking into what this next step in the evolution of our industry is all about. That’s what this post is all about.

Here, you’ll find a little bit of background on their vision and the Oracle product behind it, the capabilities of those products as well as my own commentary and analysis.

Background

It seems as if Oracle’s vision about Product Value Chain Management is relatively new, although they may have been talking about the concept for some time. Per their site on the topic, here’s an excerpt that describes how they define that vision.

Managing the entire Product Value Chain with Oracle empowers business leaders with accurate information instantly to make the best decisions at any point, from any perspective, of a product’s life cycle. Companies can evolve fragmented engineering and design processes into information-driven product value chains with best-in-class development processes and capabilities, global 360-degree visibility, and real-time collaboration. By integrating the solutions that manage the inherently connected product, demand and supply chains, companies can transform their engineering and R&D operations from siloed necessities to world-class, information and value-driven competitive advantages delivering on both innovation and operational excellence.

This vision is powered mainly by three products: Agile PLM and Product Data Hub and Enterprise Data Quality components of their Master Data Management solution.

Agile PLM was originally developed by Agile Software Corporate, which was acquired by Oracle in 2007 (wikipedia entry on Agile Software Corporation). Oracle’s Master Data Management solution has evolved over time both organically through Oracle’s software development organizations as well as through acquisitions.

Capabilities Provided

OK. Let’s get a little deeper into how Oracle’s product support their proposed ‘revolutionary’ vision of Product Value Chain Management.

Agile PLM

If you’re familiar with the common definition of a PLM system, then you’d probably be familiar with many of the capabilities provided by Agile PLM. However, there are a few additional capabilities that might surprise you.

• Product Data Management: Agile PLM provides most of the capabilities needed to manage mechanical CAD data, documents and the like. However, they don’t go as deep as some other PLM systems go in terms of managing the entire mechatronics product record.
• Workflow: As you would imagine, you can build and execute workflow processes. The workflows interact with various ‘things’ like change orders, quality inspection sheets and the like.
• Scheduling and Resourcing: Agile PLM has its own scheduling and resourcing capabilities (think project management). However, back in 2008, Oracle acquired Primavera, a Product Portfolio Management (PPM) software provider. If desired, you can use Primavera’s more comprehensive PPM capabilities instead.
• Customer Needs Management: This set of capabilities enable an organization to traditional requirements management definition and flowdown you commonly see within product management organizations. However, there are additional social capabilities where there are tag clouds, discussion threads and voting that let the product management organization collaborate on those requirements.

Agile PLM comes in a number of different industry specific flavors including ones for process and pharmaceutical. These industry specific solutions provide capabilities suited specifically for those industries like recipe management or FDA regulatory compliance. But in this post, we’re focusing on the fit for discrete manufacturers.

Product Data Hub

This Oracle software product provides Master Data Management capabilities. For a little context, you can find lost of information about Master Data Management solutions on its entry in wikipedia. In short, however, a MDM solution defines and manages a single source of truth for information. In this context, that would be the ‘golden’ product record. It can then drive that single definition into other enterprise systems. This is especially valuable if you have multiple enterprise systems with duplicate information, which opens up the possibility of information that is not in agreement, meaning that one set of information is incorrect. This becomes particularly dangerous when product development decisions are made off that information.

Oracle’s Product Data Hub provides a comprehensive set of capabilities in terms of MDMD. Specifically, it includes:

• The ability to import information, clean it and compile a ‘golden’ product record. Basically, you can bring in information from all sorts of different sources to create a definition for your products.
• The ability to manage and change to the ‘golden’ product record. Essentially, you need to define when, why and how it can be changed. Product Data Hub also provides a workflow system to enable a process to drive those changes.
• The ability to share the ‘golden’ product record to other enterprise systems via service oriented architectures (SOA) and XML templates formats.

So essentially, the idea here is to compose a single source of truth for the product by importing information from various other enterprise systems. Once composed, you can clean it up and define how and why it can be changed. Then you can push that definition out to all of your other enterprise systems.

Supporting the Vision

OK. Now that we have an idea of the capabilities that Oracle’s products provide, how exactly does it support their vision? Before we dive into that, let’s make sure we understand their vision.

To start, let’s understand how they look at product development. They say that product development is a cross-organizational process. All sorts of enterprise views on the product must be taken into account during the development process. You need to not only see the engineering view with respect to form, fit and function. You also need the impact of development decisions on procurement, service, manufacturing, operations and many other organizations. Because this is true, you need to make product information that exists in each of those different organizations accessible to every other organization. So procurement needs to see and understand the relevant information from engineering, manufacturing and other organizations so they have complete context. As a result, decisions are made in full context. If you don’t have that, then you are making decisions without understanding how it could negatively impact the rest of the development process.

But furthermore, those cross-organizational processes need to be executed in an automated fashion across multiple enterprise systems. Oracle has built out integrations between their different enterprise ‘applications’ that includes ERP, PLM, CRM and much more. Also, they have built out integrations with other enterprise systems to work in a similar fashion. For example, they’ve done this in a way such that when a problem gets reported as part of a quality management system, it initiates a change process in PLM. And when the change is approved and ready to be implemented, the PLM change process send inventory dispositions to the ERP system.

Commentary and Analysis

OK. Now we understand what Oracle’s products can do. We also understand how it supports their vision.

Engineer’s Need for Enterprise Information

First off, let me say that the folks at Oracle are dead-on right in one regard. Design as well as broader product development is an enterprise game today. Decisions in development must take enterprise considerations into account. A little while ago, I wrote a post titled What’s the Killer App for the Modern Engineer? that talked about this in the context of the engineer. Here’s the most relevant excerpt.

Another extremely challenging aspect of an engineer’s job is dealing with all of the enterprise systems across a product’s lifecycle. Most likely, design artifacts are managed within PDM or PLM. Released product records exist in Enterprise Resource and Planning (ERP) systems. Individual supplier and supply chain network information is captured in Supplier Relationship Management (SRM) and Supply Chain Management (SCM) systems. Customer data resides in a Customer Relationship Management (CRM) system. The list could go on and on. The important point though is that the engineer needs to access information in any and all of these systems to lead the day-to-day company wide effort to resolve product issues. The frequent means to doing that is to go find someone with access or have the engineer maintain 10 different login identities, which is unreasonable.

And this isn’t only true for engineers, it’s true for just about anyone involved in product development including manufacturing engineers, procurement agents, service planners and the list goes on and on. In my eyes, the problem that Oracle is trying to fix here is imminently valid.

Is the Problem Access or Duplication?

While I agree that getting information to various roles in the development process is critical, I’m not sure the folks at Oracle and I are on the same page in terms of the underlying problem.

On one hand, you could argue that the underlying issue is access. Product information might exist in various enterprise systems, applications, files and share drives all over the place. Getting that information to everyone can be extremely challenging. In many cases, those roles probably have no idea where the information exists, much less have an explicit problem getting to it. If that’s the big issue, then MDM might seem like an overdone solution. There are some lightweight alternatives like Inforbix, which I reviewed last week in a post titled Inforbix: Access to Enterprise Information for the Engineer? as well as the emerging alcove9 (corporate site) that can crawl and index information in enterprise systems and drives to expose information to anyone that has access rights. Furthermore, something like Actify’s Centro can create a 3D mashup, which I also reviewed in a post titled Actify’s Centro and Microsoft’s Sharepoint: The 3D Mashup that can expose enterprise information to more stakeholders in a different way.

Now, if duplication of product information is the problem, well then, tools like Inforbix, alcove9 or Centro won’t solve the problem. And that certainly can be a legitimate concern. With all the mergers and acquisitions going on in the manufacturing space, there are often duplications of enterprise systems that somehow must be integrated in some fashion. Master Data Management (MDM) solutions like Product Data Hub can help solve that problem.

How Important is Integrated Data and Processes?

Two weeks ago, while at COFES out in Phoenix, I led an analyst discussion on exactly this topic: Decoupling PDM from Process.

You see, since the time PLM solutions were first launched, many have been preaching the virtues of integrated product data and development processes. And the advantages in doing so were mostly self-evident. If you’re executing a process and need to reference some product information to make a decision or complete a task, you needed access to product information that is accurate. If not, you risk making decisions off inaccurate product information. And that’s a practice that can result in downstream errors. The implied solution is that you must have a single solution to manage your product information and development processes.

But a funny thing happened along the way. Many organizations spent inordinate amounts of time and money trying to deploy PLM systems to manage product information and development processes in a single solution. Very recently, a rash of solutions have emerged that don’t require product information and development processes to be managed in a single location. Autodesk released PLM360, which I reviewed in a post titled The Devil Must Be Cold: Autodesk Launches PLM Product Nexus. Kenesto announced plans to launch their product, which I reviewed in a post titled Kenesto: A New Take on PLM. Nuage is in the midst of launching their product as well, which I reviewed in a post titled Nuage: The First Social PLM System? The key difference in each of these cases is to loosely link or couple product information and development processes. Make it possible for the stakeholder to find the information instead of requiring the information to be managed in the same system as the development process.

Does consolidating and compiling a single source of truth of the product record sound like a good idea? Yes. But I think the traction of recent PLM solutions that are decoupled from product data shows that there is a little bit of blowback in the market against solutions that require you to ‘put it all in one place.’

Enabling Cross Organizational Proceses

One point that I do favor is their concept of cross organizational processes. I think their PVCM vision acknowledges a reality of organizations today. Even though it might not be automated, I think today’s processes already cross multiple enterprise systems. They’re just done so in a manual fashion. For smaller enterprises, this may not be that big of a deal. When you have fewer people, it’s easier to communicate what needs to get done. But in larger companies, especially ones that have gone through multiple mergers and acquisitions, you probably can’t just walk down the hall and remind that guy in procurement to update the approved vendor list or one of a million other cross-organizational process examples you can think about.

While I like this idea in concept for larger companies, I can’t help but think about flexibility. When I talked with the folks at Oracle, these cross organizational process that span multiple enterprise systems were enabled by integrations. Obviously its good to have such integrations across Oracle enterprise applications. However, the permutations represented by all the potential combinations of different enterprise systems that are out there is monstrous. From an Oracle development perspective, that is a lot to keep up with, even though it mainly uses SOA approaches. Furthermore, these processes can morph and change. How flexible are these integrations? If you start to look at this PVCM vision for your company in a serious way, you’ll need to have some very frank discussions along these lines.

Big Box Enterprise Systems vs. Granularity

Another point to touch on here is the recent trend towards granularity. I wrote on this topic not long ago in a post titled Point Solutions, Integrated Solutions and the Granularity Value Proposition. What’s the idea behind granularity? Here’s the excerpt for that.

So what’s the concept here? Actually, I originally heard about this concept from Oleg. And he’s written about it time and again at his blog beyondplm.com, but the fundamental idea is that you layer on different solutions that each do something very specific and well. Basically it is the point solution approach but from an ecosystem perspective. It would include something like leaving your workgroup PDM software in place. Layer on top of that a workflow. Then add some social computing solution for collaboration. Then you can add in a project management solution. You get the idea. Leave what you have in place. Add in other point solutions where needed. And integrate them as lightly as you can.

Why is granularity emerging?

So why take an ecosystem approach with point solutions? Well, I think the answer to that question is a whole lot more about someone’s history with PLM than anything else. You see, there’s a host of people out there that have championed a PLM solution. They introduced the concept to the company. They got it purchased by an executive. They were most likely the lead in getting it deployed. And it some of those cases, it failed. Not all. But not all PLM deployments are not successful. And that’s a detriment not only to the organization but to that champion’s career.

That has led some champions as well as some executives pledge a vow to never again pursue a large long scale deployment of PLM. They’re scared of it. And in some cases rightfully so. But they’re not willing to give up on technology as an enabler of better product development. They often still believe in that. So the most palatable means forward is a granular approach. Not because it offers better capabilities or will enable the organization to necessarily do more. But because it is far less risky, both for the organization and their careers. But ultimately, this is all about backlash against the big box approach to PLM.

When you think about big box integrated systems, Oracle and SAP are typically the first two that come to mind. But the vision behind Oracle’s Product Value Chain Management feels like something a little different. The whole concept of Master Data Management is to leave enterprise systems where they are and simply control the data in those systems from a separate centralized source of truth. But still, standing up a separate enterprise system in addition to all of the other ones that already exist within some companies can be a little too much.

Is this the 4th Evolution of PLM?

In their blog post, Oracle claims they have pioneered the 4th evolution of PLM. Is that the case?

On this blog, we’ve had a lot of discussions about PLM. There was the most recent discussion trying to define PLM. I also wrote about what PLM isn’t. But in this post, I guess the question should look more like this: is the next generation of PLM all about exposing information from various enterprise systems to any stakeholder in the development process?

The concept of sharing this sort of product information, regardless of which enterprise system it lives in, is not a new concept. Various software providers have been working on this sort of problem for some time. Now, Oracle may have a unique perspective on this issue because, unlike many others in this industry, they provide PLM alongside ERP, CRM, procurement and many other systems. But that unique perspective doesn’t make this stance revolutionary or even evolutionary.

The concept of cross organizational processes that span multiple enterprise systems is new in application, even if the concept has been discussed before. Personally, I have not seen other software providers try to turn this into reality as of yet. So I applaud Oracle’s gumption for taking the vision on. Of course, with Oracle having many enterprise applications like ERP, PLM, CRM and others as part of the same suite, it seems like a natural progression and plays to their differentiation. But that doesn’t mean they shouldn’t get credit for a big vision.

All in all, I don’t think this is the 4th evolution of PLM. I don’t think what the propose changes the debates going on the industry around defining PLM. But actually, I think it is something a little bit bigger. Oracle’s PVCM vision is about an evolution of the ecosystem of enterprise systems beyond PLM. And even though it doesn’t material change the evolution of PLM, it brings another aspect to the enterprise ecosystem that must be taken into account for PLM.

Summary and Questions

Yes, I know. This was a long post. But there was a lot to discuss. Here’s the recap

• Oracle claims they are leading the industry into the fourth evolution of PLM, which they are calling Product Value Chain Management.
• Oracle’s Agile PLM system offers many traditional as well as non-traditional capabilities for in PLM systems.
• Oracle’s Product Data Hub is a Master Data Management system that lets organizations compose a ‘golden’ product record that can then be managed and driven into many other enterprise systems.
• Oracle’s vision behind Product Value Chain Management is to enable the access of product information, regardless of where it may exist, to various stakeholders in the development process so they can make development decisions in a fully informed manner. I agree that this is a valid and critical need in product development.
• If access to product information is the most critical issue, there are numerous other solutions that solve that problem in a more granular fashion. If duplication of product information is the most critical issue, a system like Oracle’s Product Data Hub is a good fit.
• Part of the Product Value Chain Management vision relies on the longstanding value proposition that product information and development processes must be integrated. Some recently released PLM systems such as Autodesk’s PLM360, Kenesto and Nuage explicitly offer decoupled PDM and processes capabilities. This has gained some traction due to the granularity that it offers.
• Oracle’s PVCM vision around enabling cross organizational processes that span multiple enterprise systems reflects the reality of many large organizations today. Even though this can be seen as simply playing to their strength of making their own suite of enterprise applications work together, they deserve some credit: this is no simple problem to tackle.
• Does Oracle’s Product Value Chain Management vision represent the 4th evolution of PLM? In my perspective, no. The concept of making product information accessible to more stakeholders is not new nor is their approach revolutionary. Enabling cross organizational processes, however, represents a large change. It doesn’t redefine PLM. But it does affect it.

There are my thoughts. Ready to weigh in? Leave any of your comments below, but here are some starter questions. Does this vision represent the 4th evolution in PLM? Do you think Oracle’s MDM part of their PLM story is a nod to granularity? How important is integrated product data and development processes today? Sound off. I’m interested in hearing your perspective.

Take care. Talk soon. And thanks for reading.

Related posts:

1. PDM-less PLM: Is It Pragmatic or Just Problematic?
2. Mechatronics Management (Part 1): Mechanical Aspects
3. What is the Killer App for the Modern Engineer?

At one time, PDM was the bleeding edge of the software industry for product development. After trying to manually manage the complex interrelationships between CAD files and documents, people were ecstatic to have a system that would just do it. Initially, it was seen as a miraculous boon. But over time, however, the attention in the industry turned to other things. Slowly but surely, PDM was buried under wave after wave of new PLM technologies. At this point, PDM is relegated to a quiet little corner of the industry.

For me, though, it all strikes me as a little interesting. If you look out at the broader scope of technology, there are other things that look, feel and act a lot like PDM. And in some instances, those other things not only undergoing some dramatic changes but offering some really cool and impactful capabilities. So with that in mind, this post is dedicated to what PDM could be. But in addition to that, let’s also talk about the potential for change and who could take advantage of it.

The Reality of PDM

Before we jump into the tech, let’s level set. How many organizations do you think are completely done with the PDM deployment?

Well, I had an interesting discussion with an executive who had recently left a PLM software provider. I asked them why they left. After a moment of silence, they said “we always talk about the new capabilities of these PLM systems, but you go out and talk to customers, you know, actually see what they are doing, and you know what they are deploying? Global PDM.”

That, in a nutshell, summarizes a good bit of my experience as well. And let’s be honest. Global PDM is a terribly complex deployment to complete. On this blog, we’ve talked about managing the artifacts related to mechanical, electrical, software and system aspects of the product. On top of that, there’s many different layers of PDM that need to be deployed as well. It may not be the most exciting thing, but that doesn’t make it easy.

Four Areas for Potential Improvements

Now this is where the discussion gets interesting. What could be done to improve PDM and make it more effective? If we look at some other technologies, I think there are some hints worth considering.

1. Hands-Free PDM: Have you used modern backup software? Take a look at Mozy or Carbonite? Have you ever looked at Apple’s Time Machine? For all intents and purposes, it’s practically an invisible application. You define some settings up front and almost forget about it. The initial backup is lengthy, perhaps even in numbers of days. But once the baseline is set, then it only grabs incremental changes. Whenever a software provider talks about embedding PDM within CAD, they always talk about a minimalist UI. Well, maybe it’s time to take it to a no-UI state?
2. Visual PDM: Have you seen how new apps work on OS X Lion? Well, when I went to go perform a ‘save as’, I was a little shocked. Why? Because it wasn’t there. It’s replaced by ‘save a version’. Basically, instead of saving a separate file, you save a version inside the same file. Once you do that, you can revert back to a prior version. You can select one of these versions by visually browsing the different versions so you have an idea of which is which. So alongside so ever-running background backup PDM, you could browse through visual versions of your CAD model.
3. Streaming Changes: In a number of different applications, you’ll find this concept. We’ve talked about this in the industry before. When a number of users are working on different parts of the same assembly, those changes could be pushed back out. What you would get is a real time morphing and updating assembly. Match that up with social technologies like chatting or webcams for discussions, and you have a powerful collaboration tool.
4. Self Organizing Data: PDM could learn a lot from Business Intelligence. Analytics? What? I know. I know. At first glance, this doesn’t seem applicable in any way, shape or form. But the enabling capability of this type of software that is intriguing is the ability to extract structure out of data when there is no explicit data structure. Essentially, the data that needs to be managed by PDM needs to be associated with the ‘right stuff.’ All that is done manually today. But with a little smarter software, there might be no need for the user to do that explicitly at all.

The Business of PDM

I don’t think I’ve surprised anyone with the discussion above, either in specific suggestions nor with the concept that PDM could be improved. I’m sure many PLM software providers know a large number of their customers are still working on rolling out global PDM. They employ incredibly creative product managers and developers too, so I’m sure they have better ideas and concepts that the ones I propose above. Actually, most of that is fairly moot. Because here’s the key question: would it pay for the PLM software provider to improve PDM?

You see, most in the industry, including many PLM software providers, consider PDM a commodity set of capabilities. Many of them manage CAD data from multiple applications. They all provide revision control to a minute level of detail. And most importantly, most of their customers already own it. Translated, that means there’s little revenue opportunity to entice them to make dramatic, bold and sweeping moves forward in terms of technical functionality. Let’s be frank: that’s the nature of the software business. What results is a set of capabilities that almost seem to be frozen in time, despite the advances of similar software tools in parallel industries.

So who will drive new innovation in this space? Well, right now, it seems like no one will. However, there are opportunities for new software startups. And there have actually been new entries into the field of PLM fairly recently including Autodesk, Kenesto and Nuage. Ultimately, this point comes fill circle back to the title: is PDM disruption ready?

I believe there is an opportunity to develop and deliver better PDM. I believe the advances in other types of software offer a glimpse of what form a new PDM system might take. I believe the traditional PLM software providers have little financial incentive to invest heavily to revamp their PDM offerings. All of that looks like a ripe opportunity for a software startup to me.

Summary and Questions

Let’s look at the recap.

• Most PLM customers are actually deploying global PDM. Most probably want to be deploying a different aspect of PLM, but as a foundational element, they need to get global PDM going first.
• Advancements in other software applications offer some hints as to where PDM could be improved. This includes hands-free PDM, visual PDM, streaming changes and self organizing data.
• Traditional PLM providers have little financial incentives to dramatically change or improve their PDM offerings as most of their customers already own it.
• This combination of factors makes for an environment ripe for disruption by new software startups.

Alright. Those are my thoughts. What are yours? Have you seen any recent innovations in the PDM space? What other similar technologies do you think represent some other opportunities to improve PDM? Sound off and let us know what you think.

Take care. Talk soon. And thanks for reading.

Related posts:

1. Is CAD Still Disruption Ready?

In the rest of this post, I’ll provide a little background, a factual look at the capabilities the product provides and then round it out with my own commentary and analysis. Stay turned for the questions at the end. I’m interested in your take.

Background

Inforbix was founded in 2010 by Oleg Shilovitsky and Anatoly Savin. Oleg worked the last 11 years working for Smart Solutions, SmarTeam, Enovia, Dassault Systems. Most recently, he was ENOVIA SmarTeam Chief Technology Officer. Inforbix was first launched in November 2011.

Capabilities Provided

Alright. Let’s get down to the nitty-gritty details. What exactly does Inforbix do?

Some Context on IT Ecosystems for Product Development

Before I answer that question, let me set the context. Think about this. In product development, you literally have data and information spread everywhere. Some part characteristics might be in a table on an engineering drawing. Inventories are in ERP. Part effectivities might exist in PLM. Lists of preferred suppliers are in procurement systems. Some bills of materials are sitting in a spreadsheet on share drives. It’s ugly. It’s messy. And in many cases, it’s practically impossible to find what you need. That’s the context in which we can now answer our earlier question: what does Inforbix do?

In short, Inforbix lets any kind of user find and then use data that across that nasty mess of enterprise systems, share drives, complex deliverables and documents. Simple enough at a high level. But the next question is obvious:

How does Inforbix do it?

Well, before we can answer that question, we’ll need just a bit more context.

Some Context on Web Crawlers

Are familiar with how google and other search engines work? They use something called web crawlers. Wikipedia’s entry on web crawlers offers a far better definition than I could write, so here it is.

A Web crawler is a computer program that browses the World Wide Web in a methodical, automated manner or in an orderly fashion.

This process is called Web crawling or spidering. Many sites, in particular search engines, use spidering as a means of providing up-to-date data. Web crawlers are mainly used to create a copy of all the visited pages for later processing by a search engine that will index the downloaded pages to provide fast searches. Crawlers can also be used for automating maintenance tasks on a Web site, such as checking links or validating HTML code. Also, crawlers can be used to gather specific types of information from Web pages, such as harvesting e-mail addresses (usually for sending spam).

So essentially web crawlers are constantly spidering the web, looking for new content to gather information about. They then send that information back to the search engine for which they were built. The search engine then builds out an index of all the content on the web. So when someone searches for something, the search engine just references it’s index, which is really fast performance wise, and provide results.

But actually, there’s a good bit more to it than that. You see, different kinds of web crawlers understand different kinds of information on the web. In fact, as you can see on this Google webmaster help page, Google has numerous types of web crawlers that are attuned to different kinds of media. There’s one for news articles, one for images, one for video and so on. That’s because each web crawler understand different kinds of data on the web.

Crawling Product Development Data

Given all this foreshadowing, I’m sure it’s not too hard to see where I’m going here. Yes. Inforbix uses their own crawlers to spider your product development IT ecosystem. But these aren’t like Google’s web crawlers, which are just traversing the web. Using API toolkits, Inforbix crawlers go into enterprise systems like ERP, PLM, procurement systems and others. It also has crawlers that spider your desktops and share drives. So Inforbix crawlers are unique in that they traverse enterprise systems and drives in your product development IT ecosystem.

However, there’s more complexity to this ecosystem. And Inforbix’s crawlers have to deal with it as well. You see, product development information is terribly complex. As many are probably aware, mechanical CAD models, whether they are parts, assemblies or drawings, have a huge amount of information embedded within them. What’s key is that Inforbix’s crawlers were written to understand that type of data and much more. So another away that they are unique is that they understand the huge variety of product development data.

As a proof point, take a look at Inforbix’s supported data types on their site. You can almost think of each of those as individual web crawlers.

What do the Inforbix crawlers do with this information? They communicate with Inforbix servers, which sit in the cloud, where all of that information is indexed. So the parallel so far is fairly close to how the search engine for Google works. But from there, there’s a slight divergence.

Delivering Product Development Data

Are you familiar with how Google delivers search results? Most everyone can see the textual results of a search. But if you’ve noticed, there’s also a way to look just at images, video, maps, videos, news and more. And as you might expect, the parallel applies as well to product development information. Just a little differently. Specifically, Inforbix provides search results from your product development IT ecosystem through the following lenses.

• Textual Search
• Charts
• Tables

Essentially, different sets of results from your search across your product development IT ecosystem can give you information that would be easily dropped into charts or tables. And Inforbix lets you do that. However, Inforbix calls them apps. But furthermore, you can create a dashboard of different combinations of text, chart or table based search results which you can save to reference again and again.

Making Changes

One last note. As opposed to search results from Google, Inforbix search results let users actually make some changes when they have access rights. So you can not only look up information in a table, but you can actually make modifications as well instead of making you open the deliverable and manually make the change.

Commentary and Analysis

Now we understand what it does. So what? What’s its value? Let’s take a look at that.

Enabling the Engineer

Some time ago, I published a post titled What is the Killer App for the Modern Engineer? In it, I outlined a major challenge I saw in an engineer’s day-to-day job in taking many enterprise considerations into account when making design decisions. Here’s the most relevant excerpt.

Another extremely challenging aspect of an engineer’s job is dealing with all of the enterprise systems across a product’s lifecycle. Most likely, design artifacts are managed within PDM or PLM. Released product records exist in Enterprise Resource and Planning (ERP) systems. Individual supplier and supply chain network information is captured in Supplier Relationship Management (SRM) and Supply Chain Management (SCM) systems. Customer data resides in a Customer Relationship Management (CRM) system. The list could go on and on. The important point though is that the engineer needs to access information in any and all of these systems to lead the day-to-day company wide effort to resolve product issues. The frequent means to doing that is to go find someone with access or have the engineer maintain 10 different login identities, which is unreasonable.

In the past, I’ve seen mashups as the solution for that problem. But as it turns out, it’s not the only solution to that problem. In fact, this type of search across the product development IT ecosystem is incredibly powerful. In some cases it is more powerful than mashups. Why? Because mashups are frequently focused on looking into enterprise systems. And in my experience, most engineers do most of their work in documents, spreadsheets and presentations. This is a critical aspect that Inforbix has integrated into this support ecosystem.

Supporting the Granularity Approach

Another aspect of Inforbix that is beneficial is its ease to slide into practically any product development IT ecosystem. It can literally plug and play with a wide variety of different enterprise systems because of its long list of crawlers. Why is that a big deal? Because it can be deployed fairly quickly and easily. It can start making an impact for an organization quickly. This stands in contrast to big box PLM systems that take years to go live. All of this points back to the concept of granularity, which I wrote about in a post titled Point Solutions, Integrated Solutions and the Granularity Value Proposition, but has been touched on many times in the industry.

The Positives I see

What’s my bottom line? I have two main thoughts.

Here’s my first thought. As much as I wish it weren’t true, product development is chaotic and messy. You hope most of your stuff gets into an enterprise system during the design phase, but in reality most organizations mandate that all released representations of designs get stuffed somewhere. And all that other work-in-process stuff gets left on desktops and shared drives. Inforbix helps address that reality with an interesting approach: leave it there, we’ll index it and let you find it easily when you need it.

My second thought is about the reality of today’s engineer. They are pulled in so many different directions, rushing from conference room, to shop floor, to prototype shop, to test lab and supplier’s campuses that at the end of the day, they’re just trying to make the right design decision. They have neither the time nor the effort to make sure everything is perfectly organized, whether that be in an enterprise system or their shared drive. Inforbix helps in that regard by organizing it for them in a virtual manner. But probably more importantly, when engineers need to make important decisions, they don’t need to waste time trying to track the information or data down. Let’s be honest. Spending hours searching for information is not how engineers add value. Inforbix helps minimize that wasted time by deliver the right information with minimal effort.

My One Little Nit

How would I make it better?

If you’ve been reading this blog, you’ve probably seen my series on the engineering notebook. My position is that, essentially, the engineering notebook has been left behind my technology. I think something like Inforbix embedded in a virtual notebook alongside notes (like Evernote), sketches (maybe Sketchup) as well as some calculation tools (like MathCAD perhaps) would be incredibly powerful. And Inforbix would allow for a dynamic updateable view info all of the information that is relevant to an engineer.

Conclusions and Questions

It took quite a bit to explain what Inforbix does and how it does it. Let’s recap.

• Product development information and data that you want to find and reuse are spread out across different enterprise systems, desktops and shared drives.
• Google and other search engines use something called web crawlers to traverse and index web content.
• Inforbix has crawlers that understand how to interact with everything in the product development IT ecosystem. They also understand how to mine and index complex product development data.
• Inforbix delivers results through ‘apps’ that drop results into text, chart or table type formats. Different kinds of results can be combined into dashboards which can be saved and reused for later reference.
• I believe Inforbix can aid today’s engineers by letting them find product development data and information quickly and easily without forcing them to organize it with time-consuming manual effort.
• I also believe that Inforbix supports a granular approach to the entire product development IT ecosystem. It can be easily integrated into existing ecosystems.
• My preference would be to see this kind of functionality as part of an engineering notebook alongside note taking, sketching and calculation tools.

So there you have it. Those are my thoughts on Inforbix. Now its time for you to weigh in. How many different enterprise systems do you have in your organization or have you seen in others? Can you tell me about your or other’s experience in trying to find and reuse product data and information that is spread across the ecosystem? Would love to hear your thoughts.

Take care. Talk soon. And thanks for reading.

Related posts:

1. What is the Killer App for the Modern Engineer?

The Engineer’s Need

A major aspect of the design decisions that engineers make is based on driving a product towards a desired function. It could be related to structural characteristics, materials composition, heat management, geometry traits or one of any other myriad of other characteristics. In some cases, some geometric representation of the product is required for the calculations. For example, mechanical engineers often use free body diagrams (FBD) in statics or dynamics calculations.

Why are calculations important to engineering? It’s related to the role they are supposed to fill. One of the core concepts that separates engineers from tinkerers is the ability to predict those traits before a prototype is built and tested. Furthermore, engineers can make adjustments to drive those traits towards the goals for the product. But beyond the responsibilities of engineers, there are impacts for the organization as well. Building and testing prototypes can be costly and time-consuming. Predictive calculations contribute towards the vision of a virtual prototype where you can predict and drive characteristics towards goals in a digital medium as opposed to the physical world.

Relation to the Engineering Notebook

How exactly is all this related to the engineering notebook?

Well, traditionally, all of these calculations and related diagrams were captured in the engineering notebook. And as such, they existed in a centralized location, albeit a physical one that could get lost or destroyed. But the advantage to the engineer was that it existed at their finger tips in the context of all of their other engineering stuff that related to that product. So these calculations sat right next to their notes, their concepts and sketches, their pictures from the prototype shop or test lab. It was all in one place.

Some Modern Alternatives

What modern tools exist to help engineers perform these calculations? There’s actually a number of different types that are relevant to this topic.

To start, there are calculations software applications. These tools let users build equations and plot live results which update as the inputs or equations are modified. On one end of the spectrum, you have PTC’s MathCAD, that allows users to use more of a natural language inputs as opposed to coding the equation with abstract concepts and functions. This works well for engineers as they can afford to become dedicated experts in any one software application. On the other end of the spectrum, you have Wolfram’s Mathematica which offers incredibly deep capability in terms of the functions and integrations with other applications and systems. While such a tool offers quite a lot, it can place a high knowledge and skill overhead on the user in understanding how to use it. There are a number of similar apps available for tablet style tools.

Another kind of software application that’s relevant here is combined calculation and diagramming tools. Specifically, Autodesk’s ForceEffect app for the iPad let’s engineers use sketches, pictures and diagrams as the basis for calculations. In essence, it uses free body diagrams (FBD). While it only covers structural types of problems, it seems very accessible and easy to use.

The Downside

Now, these software applications certainly can be useful and provide value. But I see one negative with all of them: they aren’t related to a notebook type of tool. As a result, these calculations and diagrams don’t exist alongside all of the other pictures, sketches and notes that an engineer should maintain for a product development project. But in all honestly, this comes as no surprise. No existing software application really addresses the need for engineering notebooks today. Evernote may be the closest.

Summary and Questions

Alright, let’s recap.

• Engineers need to perform calculations, sometimes based on diagrams, to predict and then drive design characteristics towards desired goals or objectives.
• These calculations traditionally existed in engineering notebooks alongside sketches, pictures and notes.
• Calculation software applications, such as PTC’s MathCAD and Wolfram’s Mathematica, offer capabilities engineers can use to build calculations. These tools vary in terms of ease of use.
• Autodesk offers a Free Body Diagramming app for the iPad called ForceEffect. It’s capabilities are focused on structural statics and dynamics.
• The downside for each of these modern tools is that they do not link or integrate with anything that could be used as a broader engineer notebook software application. But that isn’t surprising, considering there is no software tool that comes close to offering engineering notebook functionality.

OK. Ready for some questions? What do you use to perform engineering calculations? Do your organization try to manage them in some way or do they rely on personal organizational skills? I’m interested in getting your thoughts.

Take care. Talk soon. And thanks for reading.

Related posts:

1. The Forlorn Engineering Notebook
2. Digital Sketching and the Engineering Notebook
3. Digital Notebooks for Engineering?

Background

On March 21st 2012, Kubotek announced their plans to launch their KeyCreator Analysis product which is based on SEFEA technology (press release). This product should actually be released at some point this spring, most likely May. To date, their offerings have included KeyCreator, a CAD application that primarily utilizes direct modeling techniques, and ECO Manager, which compares changes between different versions of a CAD model or between two CAD models.

Capabilities Provided

So what is KeyCreator Analysis and SEFEA? Let’s look at them one at a time.

KeyCreator Analysis

In short, KeyCreator Analysis is a standalone software application that lets you perform simulation analysis. It leverages KeyCreator’s direct modeling capabilities to allow for implication and abstractions of simulation models. From an analysis perspective, it includes multi-physics simulations including structures, thermal and electro-magnetics phenomena. Sounds pretty vanilla, right? Well, it gets far more interesting when you start looking at the technology used to perform the simulation.

SEFEA Technology

Before we proceed, what’s up with the name? It’s an analogy standing for Strain Enriched Finite Element Analysis. It basically refers to a the type of algorithm used to solve a simulation. It’s the method that the folks at AMPS Technologies, who partnered with  Kubotek to develop KeyCreator Analysis, use in their simulation software. So it’s in KeyCreator Analysis. Now why is that important?

Well, it all comes down to how FEA equations are solved and what types of elements are used. Traditionally, FEA using tetrahedral elements with only four nodes (think of a triangle pyramid with points at each sharp edge) were too stiff, and in turn they didn’t match up well to real world results. Folks instead used tetrahedrals with additional nodes halfway along each edge to give them ten. That approach gave far more accurate results, however the additional nodes (10 instead of 4) lead to a dramatic increase in time to solve the equations.

Interestingly, some of the other branches of FEA theory such as the Boundary Element Method (BEM) and the Element Free Gallerkin Method (EFGM) used supplemental comparisons of the volume before and after its deformed state to make some adjustments. The folks at AMPs technologies applied this sort of approach to traditional 4 node tetrahedrals. What happened? The results became far more accurate. The good news is that solving a model using 4 node elements was far faster than solving 10 node elements because there less equations to solve.

But there was another interesting side effect. Apparently, the application of this algorithm also made the results far less dependent on the quality of the mesh as well.

Integration with KeyCreator

Another thing to take into account is the integration between these simulation capabilities and the direct modeling functionality of KeyCreator. Direct modeling capabilities make it far easier to prepare models for simulation, that’s true. And from a conceptual design perspective, direct modeling approaches offer a shortcut to representative geometry. So this could enable designers and engineers to generate ideas and prep them for simulations more quickly. That combined with more ‘foolproof’ simulation capabilities is promising.

The Advantages and Fit

To make a long story short, the SEFEA technology solves analyses quickly and produces results that aren’t terribly sensitive to the quality of the finite element mesh.

The folks at Kubotek see this analysis tool as a breakthrough for common engineers that need to perform simulations. They also think it’s a no brainer tool for expert simulation analysts.

Commentary and Analysis

Alright. We know that this SEFEA technology sounds different. We know that it sounds applicable for casual users like engineers and designers as well as more expert users like specialized simulation analyst. But does any of this sound familiar? A brand new simulation technology that can be used for simulation driven design by common users. You don’t need to have much of any simulation expertise. You don’t have to worry about the quality of the mesh. Any of that ringing a bell?

If you rewind 15 years, it sounds a lot like the old Mechanica product that PTC acquired back in 1995. Back then, the breakthrough technology was polynomial elements (p-elements). The concept was to increase the polynomial order of the element edges until the simulation results converged to an answer. Seemed like great technology and it is certainly in use today. However, it never became widely proliferated. And I don’t think anyone would argue that it revolutionized the ability for casual users to perform simulation driven design.

So how is KeyCreator Analysis and SEFEA different? I, for one, see a few differences.

• KeyCreator Analysis and SEFEA should theoretically see an advantage with speed. When only solving tet-4 elements, the results should come far more quickly than a converged p-element solve or a tet-10 solve.
• KeyCreator Analysis offers multi-disciplinary analyses including structures, thermal and electro-magnetics with fluid dynamics to come at a future date. In comparison, many of the simulation tools aimed at simulation driven design focused only on structures.

So, can speed, resilience against mesh quality and multi-physics address where other simulation driven design tools have fallen short? I think this tool exhibits the capabilities that can make a difference. But the outstanding question in my mind is will it make a difference? Simulation driven design is an initiative that many engineering executives got behind and then saw fail to take root. Would they be willing to give it another go? I think expert analysts will have to put the technology through the ringer for accuracy’s sake first and then once customer start pronouncing success from the rooftops, then more engineering organizations will pay attention and start to make changes.

Don’t get me wrong. I believe this software’s capabilities are impressive. I just think engineering executives will have to be duly convinced that it can make an impact before they’ll want to ride that simulation driven design horse again.

Conclusions and Questions

OK. Let’s recap.

• Kubotek released a new product called KeyCreator Analysis on March 21st 2012.
• Kubteok partnered with AMPS Technologies to use SEFEA technology in KeyCreator Analysis.
• SEFEA technology is an advanced multi-physics simulation technology that combines multiple FE theories to solve simulations more quickly and with less sensitivity to mesh quality.
• At face value I believe this technology could be used successfully in simulations driven design efforts by causal users such as engineers and designers.
• I do think objections existing engineering executives minds, especially those that have backed simulation driven design initiatives in the past to only see them fail, that will have to be overcome.

Alright, time for you to weigh in. Do you think the biggest hurdles to simulation driven design are technological or cultural? What objections have you encountered with your engineering executives? Sound off. I’m interested in your perspective.

Take care. Talk soon. And thanks for reading.

Related posts:

1. Is Teamwork the Key to Simulation Driven Design?
2. Siemens PLM and Synchronous Technology in Solid Edge
3. Design Engineer Aaron Solet on Transitioning to Synchronous Technology in Solid Edge

Inside Engineering

Let’s start within engineering. Specifically, let’s look at how PDM manages artifacts that represent a product’s form and fit.

Managing Design Representations

A few months ago, I wrote a series of blog posts on how different aspects of mechatronic products are managed. Won’t reinvent the wheel, but I’ll pick out the most relevant stuff here.

• Managing Mechanical Designs (Mechatronics Management (Part 1): Managing Mechanical Aspects): This type of system manages all the different types of deliverables that Mechanical CAD produces such as 3D models, drawings, assemblies and the like. These systems also extract detailed information from these deliverables for enterprise access as well as manage the interrelationships between the deliverables, of which there are many.
• Managing Electrical Designs (Mechatronics Management (Part 2): Managing Electrical Aspects): This type of system parallels the capabilities provided by MCAD oriented PDM systems in that they manage the diagrams, schematics and drawings associated with PCBs as well as the electronic parts libraries that are used to assemble the boards.
• Managing Software Artifacts (Mechatronics Management (Part 3): Managing Software Aspects): The similarities in the prior two systems continue in this type of system, often called Software Configuration Management (SCM) in that the various code snippets that make up embedded software are configuration managed and tracked.

When I run into someone and start talking about PDM, it’s often the very first one we hit on here: PDM for Mechanical CAD. It was one of the earliest types of systems to become widely used in engineering. But as you can see from the other types of systems that are available, there’s a lot more to PDM than just managing Mechanical CAD. But so far, we’ve just talked about managing design representations. Let’s continue.

Managing Simulations

Another aspect that engineering organizations are starting to centrally manage are simulation artifacts. Just last month, I published a post titled THe Misnomer of Simulation Lifecycle Management, Here’s the most relevant excerpt.

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.

Most of the types of simulations that are managed so far are very oriented towards mechanical engineering. And there are certainly many simulations relevant to electrical engineering that don’t seem to be supported today.

Furthermore, anyone that develops embedded code often test the codes for ‘bugs’ against a battery of simulated tests to track quality. There is a strong need to capture as well as track which software configurations performed well and poorly in that context. Furthermore, each test can progress and mature over time, which of course needs to be tracked and managed as well. Some SCM systems provide this capability.

Managing Engineering Documents

Despite the overwhelming buzz in the industry about CAD and Simulation, engineering organizations need to track and manage a huge amount of documents, spreadsheets and presentations. They might be engineering specifications. They might be Failure Modes and Effects Analysis (FMEA) documents. They could be forms that are used in processes.

Some call this document management as opposed to data management, however, these are often not standalone documents. In many cases, these documents need to refer to information that is extracted or comes from different design representations such as a Mechanical CAD model or an Electrical PCB schematic or even a Multi-Physics Simulation. But that information shouldn’t be static, it needs to dynamically change as the information in those artifacts change. Some systems provide some ‘dynamic linking’ such as this, but not many.

Outside Engineering, In the Enterprise

Now of course, Product Data Management (PDM) isn’t just about managing stuff within the engineering organization It’s about the enterprise too. However, there are two progressive ways in which it can be used.

The first is all about access. A prevailing concept is that many other stakeholders in the enterprise would greatly benefit by having access to the information generated within engineering. If they could, they would make better decisions in their domains. Procurement agents could source functionally equivalent but cheaper parts. Service planners could start designing their procedures earlier. Marketing managers could start generating their collateral far earlier as well.

But that’s not the whole story. There is also the concept of Enterprise PDM. The basic idea here is that every organization in the company uses the same PDM system to manage all of their artifacts and deliverables, creating some type of interdependency or linkage between related documents. When one changes, the owner of dependent documents get a notification to update it. Of course, that leads to a discussion about how feasible Enterprise PDM truly is, but that’s a topic for another post.

Summary and Questions

Let’s recap.

• The term Product Data Management (PDM) can have a variety of different definitions.
• One aspect of PDM is the management of design models and deliverables that are discipline specific. These different aspects can be called PDM for Mechanical CAD, PDM for Electrical CAD and Software Configuration Management (SCM).
• Another aspect of PDM is the management of simulation artifacts and deliverables. This is often called Simulation Data Management (SDM).
• Not to be forgotten, engineering organizations author a wide variety of documents, spreadsheets and presentations that should also be centrally managed. This is sometimes referred to as Engineering Document Management.
• While there is value to enabling other enterprise stakeholders to access engineering information, there is also value in managing all deliverables across the enterprise in a centralized system as well. Such a concept is often coined as Enterprise PDM.

That covers the range of PDM definitions that I can recount. Where there any other aspects that were missed? But additionally, where do you see most PDM implementations occurring today? WIthin engineering and only for Mechanical CAD? How many have seen an Enterprise PDM deployment? I’m curious to get your perspective. So weigh in!

Take care. Talk soon. And thanks for reading.

Related posts:

1. Mechatronics Management (Part 1): Mechanical Aspects
2. The Misnomer of Simulation Lifecycle Management
3. The New Management Forum at the CIC Conference

Fast forward a good number of years and I sat down to get an update from the folks at Altair Engineering on their products. Going in, I certainly didn’t think the one thing that struck me as most compelling would be optimization. But it was. What follows is a little background on their optimization technology, what capability it provides as well as my own commentary and analysis.

Background

In the early 1990′s, Altair Engineering exploring university research on topology optimization. After several years of writing commercial code, this effort culminated in the release of their OptiStruct software in 1994. Initially, OptiStruct allowed for stiffness maximization with volume and model constraints. Over time, a variety of types of analyses as well as analysis responses were were added as part of the optimization process as objectives or constraints. Today, OptiStruct is part of Altair Engineering’s Hyperworks suite as well as solidThinking Inspire, a conceptual design tool.

Capabilities Provided

Optimization is all about varying parametric dimensions of a feature-based CAD model to get different iterations on geometry, right? Well, when it comes to Altair’s OptiStruct, there’s a little more to it than that.

Optimization for Concept Design

So what exact does Altair’s OptiStruct do differently? Well, it actually suggests potential shapes for your design. Let me explain.

Let’s say you are designing a part to carry a structural load. With OptiStruct, you essentially model the outer boundary that this part could occupy. From there, you add in your normal constraints and loads. After that, you define your objective and design constraints. From there, OptiStruct essentially iterates on removing material in various locations to meet the objective and stay within your design constraints. Essentially, by performing a structural simulation on the block, OptiStruct understands which material within the block is and is not carrying the load. From there, it’s not to hard to see how OptiStruct could remove the material that isn’t carrying the load and remove it.

At first glance, it may sound fairly unimpressive, but what is key is in defining the outer boundaries that the part could occupy. That starting shape could be as simple as a block or cylinder. But realistically, it could be far more complex. Perhaps you need a part to fit within a number of other assemblies. You could potentially use a CAD model to extract the unfilled volume that the part should occupy along with its attachment points. That becomes the starting point for which OptiStruct could start removing material and tell you what the conceptual shape for the part should be.

Optimization for Detailed Design

Now the example above is interesting but it is also very simplistic. Now, expand it to take into account natural frequencies and temperature variations and it gets far more impressive. The good news is that OptiStruct can go beyond structural analysis with its optimization capabilities. It covers a wide range of physics including:

• Structures
• Modal Dynamics
• Kinematics and Dynamics
• Thermodynamics

All of these types of characteristics can be taken into account when executing this kind of optimization.

Commentary and Analysis

OK. So it’s interesting technology. What’s it mean?

Functionally Driven Concept Design

Have you been tracking the new buzz about concept design in the industry? It’s actually quite compelling. Some say, me included, that CAD tools are very frequently used to document the product after most design decisions have been made. Why? Because CAD is often very difficult for engineers to use, especially when they are running from their desk, to the shop floor, to the prototype shop and the test lab. There’s little time for them to specialize in complex software like CAD. However, the emergence and acceptance of direct modeling has changed that story. Direct modeling lets engineers just grab and drag geometry without having to fiddle with parametrics or features, which can often times need to be handled with care. In addition to that a number of CAD software providers have started offering new tools purpose built to address the design of concept design. With a combination of 2D sketching and direct modeling, it is far easier to capture ideas and concepts in digital models than ever before. But in the midst of all that, there’s one caveat to the whole thing.

A good number of parts are almost purely functionally driven.

Now, don’t get me wrong. Some parts need to be aesthetically pleasing. Some parts are simple and straightforward. However, have you ever looked at the assembly of a car door? What about the inside of an airplane’s wing? Every nook, cranny, divot, rib and whatnot serves an engineering purpose. Practically no one cares what it looks like. It just needs to serve its function. And ultimately, that’s why I find a tool like OptiStruct terribly compelling. You can set it up and let it go. Ultimately, you can get to a better design.

But there’s another really interesting reason to consider this kind of technology. What value do engineers add? If a technology like this can let an engineering flip it on, walk away and work on another design, it is making them more productive. Obviously, they need to validate the results and the design. But I think there is a hidden productivity advantage hidden here as well.

The Caveats

So, it’s all roses? Not quite. While considering this technology, I had to ask myself: how frequently do you use this technology? Would it be every part?

I think it is fairly obvious the frank answer is no. Although there would be some advantage, I think you start approaching the point of diminishing return. You might have an optimized product but you may not stay on schedule. This stuff can take some time. But can you strategically use it for the parts that have a bigger impact on the cost, manufacturability and performance of the product? Absolutely. And I think that is where it would shine. Use it to do the grunt work on big complex parts that impact the design while engineers use some of these newer purpose built CAD tools to buzz through the concept design of parts that simply need to get done. That feels like the right combination of technologies to me.

One other point that needs to be taken into account is the importance of getting to an optimized design as opposed to a feasible design. So many engineers are rushed with their workload that, even if they wanted to, they may not be able to spare the time to take this approach with the impactful parts. I think if this technology is adopted, and the advantages and benefits warrant it, that engineering organizations should triage parts early on into different design processes. The parts that heavily impact product traits should use something like OptiStruct. All others take a abbreviated route.

Conclusions and Questions

Well, this is a new type of technology we haven’t looked at before. Let’s recap.

• historical summary of the product
• OptiStruct lets users model the space that a part could potentially fill, the starting volume, and then figures out which materials affects design objectives and constraints. It removes material that doesn’t make a different, leaving the shape representing the concept design.
• The shape of the starting volume can be very complex, potentially being created from an empty air extracted volume within a CAD assembly model.
• This technology represents a significant value add for parts that are functionally driven and are impactful on the product’s key characteristics.
• Adoption of this technology should come with some procedure to triage parts into a process where concept optimization is used or not.

Alright. Those are my thoughts. Here’s my questions for you. Do you think optimization has gotten a bad rap in the past? Have you had to overcome objections to its use in your organizations? If you use optimization, how do you determine which designs get optimizations and which do not? I’m curious to get your perspective.

Take care. Talk soon. And thanks for reading.

Related posts:

1. The Very Real Skillset Challenges to Simulation Driven Design
2. Is Teamwork the Key to Simulation Driven Design?
3. Design Engineer Aaron Solet on Transitioning to Synchronous Technology in Solid Edge