Category

PLM

Is Your PLM System Running Out of Steam?

By Internet of Things (IoT), PLM No Comments

The manufacturing world continues to change at an accelerated speed. New complexities driven by embedded software and cyber-physical system interactions introduce new design and testing challenges. Fierce competition and demanding customers force product companies to incorporate new business models and rethink everything, from product architecture to supply chains.

Can your PLM system handle these pressures?

With roots in a CAD-centric world that revolved around bill of materials data management and simple workflow, traditional PLM software tools are already highly taxed.  They support different design disciplines in parallel: mechanical and electrical design, hardware and software, and manage multiple rapidly reiterating development cycles. And top these off, the number of product configurations and variants is exploding.

PLM systems are running out of steam!

Manufacturing organizations are changing their business thinking and design philosophy to harvest the value promised by the Internet of Things (IoT) and Industry 4.0, in which software control systems embedded in smart devices and connected machines form a network of sensors and actuators that are continually monitored and controlled online.

The potential impact of the Industrial Internet of Things (IIoT) and Industry 4.0 are undisputed. But are engineering and design tools—PLM software in particular—equipped to handle the complexities of designing IoT-enabled devices?

The simple answer is no.

Not unless product companies take the time and effort to rethink their product lifecycle management strategies. Manufacturers need to reevaluate how ready their product development and methodologies are to tackle the impending hurdles posed by product complexity. They need to determine their organizational maturity to incorporate new business models. And they must develop new approaches to position PLM as the underpinning for restructuring the product organization and harvest the value in the Internet of Things.

If you’d like to hear more, join industry experts in the Product Innovation Conference Boston on November 17th and 18th. I will discuss key product lifecycle IoT design elements:

  • Design for IoT
  • Design for the Business of IoT
  • Design for IoT or Design by IoT?

See you there.

Unlocking the Value in PLM-ERP Integration

By IT Strategy, PLM No Comments

PLM-ERP Alignment is Critical

In the seemingly endless conversation about product development software, there are those that argue that PLM and ERP serve different roles in product development and product lifecycle management. Those on that side of the fence use arguments such as “PLM helps drive product innovation, ERP helps execute the business of manufacturing”, and prop their arguments by making debatable observations such as that ERP is a static system of record and PLM manages product changes; that product data structures in ERP are rigid whereas PLM’s are flexible; or that ERP can only handle hierarchical data relationships as opposed to the dynamic many-to-many relations data model of PLM. Some years ago there was even an attempt to restore the lackluster image of ERP by coining a new term:  “Operational ERP.” Read More

To Reuse or Not To Reuse Parts, That is the Question

By Automotive, Design Reuse, Manufacturing, PLM One Comment

Design Reuse

For years I have been critical of the automotive industry and its overzealous and careless tendency to design new parts instead of reusing existing designs, inventory parts and suppliers.  The Rationale to resist the temptation to innovate and reuse tried and proven parts is broad and multifaceted. Among the chief arguments:

  • Accelerate time to market and reduce the number and severity of ECOs
  • Reuse tooling and manufacturing processes
  • Improve quality and have better estimation of volume manufacturing ramp up, service load and warranty costs
  • Reduce the need to recreate work instructions, remove and replace procedures and related documentation
  • Lower manufacturing and final product cost
  • Reduce inventory and related costs

A useful way to look at this is that in addition to the benefits of reusing a physical commodity, design reuse promotes knowledge reuse, which has broader and longer lasting benefits.

The argument for design and part reuse gets a bit more involved when we look beyond small parts and subassemblies, which the average consumer doesn’t care about. What about systems that represent the brand identity, such as the engine or transmission? Do consumers know and care whether an engine is exclusive to the brand? How does this knowledge influence buying decisions?

A recent study by Automotive News of auto dealers offers an interesting perspective on the topic. The study indicates that consumers are split almost evenly about how they feel about the brand exclusivity of the engine in the car they’re shopping for and how this knowledge influences their busying decision.

Interestingly, according to the study, consumers care much more about the brand exclusivity of the transmission: more than 50% of consumers now and care whether the car’s transmission is exclusive to that brand.

An even more surprising finding, which, quite frankly, make me somewhat leery about the reliability of this very small (n= 169) study, is that 71% of consumers know and care whether the axles are exclusive to that brand. Or, at least, this is what auto dealers believe.

For some reason, the study did not ask about common car chassis that might have a stronger impact on consumer decisions, because it makes it easier to pitch one brand against the other. A good example is Volkswagen’s A4 platform that is used in a range of vehicles from the luxury sporty Audi TT to the lower end SEAT and Skoda. While most consumers are not aware of the pervasive use common platforms, will they change their mind if they did?

The fidelity of the study’s findings aside, it’s clear that line executives and designers face a dilemma: how far can they reuse parts and systems before they start diluting the brand identity. But finding the right mix of model-exclusive and common design, especially lower level assemblies and parts, is an important step in improving operations while maintain brand’s identity and integrity.

Number 48 (Jackson Pollock, 1949)

The Fallacy Behind Counting Lines of Code

By Automotive, Aviation and Aerospace, PLM 4 Comments

Mercedes-Benz vs. F-35

A while ago I attended a discussion about vehicle software development and maintenance. The presenters discussed the increased complexity in automotive software, especially in in-vehicle infotainment (IVI) and the advantages of remote over the air firmware update (FOTA).

To demonstrate the magnitude of the problem, one of the speakers used oft-cited statistics contrasting the number of lines of code (LOC) in the software in a modern car and of a military aircraft. The statistics (attributed to IEEE) were:

  • Current generation aircraft        1.7 Million LOCs
  • Next generation aircraft (F-35)   5.7 Million LOCs
  • Modern passenger car                100 Million LOCs

Do these figures mean that the software in a passenger car packs more functionality than an F-35?  As complexity increases exponentially with the number of lines of code, do the numbers indicate some 500-fold increase in the complexity of vehicle software? Read More

BigLever and Aras Deliver Product Line Engineering Integration

By Mergers & Acquisitions, PLM 3 Comments

Product Line Engineering: Rethinking Product Development

BigLever Software, a provider of product line engineering software, announced today that the company has partnered with Aras Corp. to deliver an integration between product line engineering (PLE) and product lifecycle management (PLM) software suites.

The integration enables product designers to define product options and variants in BigLever’s Gears software and communicate them directly to Aras Innovator PLM tool to generate a complete bill of materials for each product variant. This helps configuration engineers handle the increased complexity in product architectures, and, in particular, the proliferation of embedded control software modules.

To understand the significance of this announcement, a brief, somewhat technical, explanation of PLE is necessary.

What is PLE Anyway?

The need for higher density and richer repertoire of product functionality to meet consumer expectations and establish market differentiation continues to burden brand owners. Marketers and designers need to add product features at a high pace, frequently utilizing embedded electronics and control software to add functionality and configure products to specific markers and demographics. The result is often a large and complex set of product configurations and variants that include not only hardware and software components, but also test scripts, manufacturing work instructions, compliance certificates, user documentation, and more.

In a typical product development process, market requirements are decomposed into functions that are mapped onto a hierarchical bill of materials (BOM) structure. Individual BOM items are grouped to form the configurations and option packages that can be manufactured and sold to consumers, such as the option to add power windows and locks to a car, or a higher end PC “bundle” that includes expanded memory capacity and a fast graphic card. Frequently, rules have to be defined for “allowable” configurations to reflect design constraints, product pricing strategy, and other technical and business considerations.

Many engineering organizations find the complexity of culling BOM items (and their associated non-BOM objects) and creating “packages” for design, manufacturing, sales and support extremely difficult to handle. And the fact that many product companies use manual processes supported by an assortment of databases and spreadsheets to manage product configurations doesn’t do much to alleviate the situation.

Inverting the Process

Product line engineering takes a different approach to decomposing requirements into product design variants. Rather than starting the configuration process with an existing BOM, PLE starts with the set of “features” that are put together to form valid functional configurations as defined by the product functional requirements; for instance, a power windows “package.” The important distinction is that features do not have to correspond to physical parts. Rather, they describe functionality units linked directly to functional requirements and managed at a functional level.

In essence, one can see the product description in PLE as a bill of features containing all physical and virtual artifacts such as mechanical, electrical, wiring, software, calibrations, requirements, designs, test cases, documentation, and so forth.

The bill of features isn’t limited to itemizing features that must be engineered and manufactured in the traditional sense.  It can include, for example, the different warranty terms and bundled services for each configuration.

As importantly, features are canonical and not product or design specific, and therefore are easy to understand and manage even before the actual design has started. Feature “dictionaries” can be shared and reused across multiple products in a manner that reduces configuration management complexity and errors.

PLE and PLM

With a direct PLM-PLE integration such as the one demonstrated by Aras and BigLever, configuration engineers do not use external documents to configure a BOM for a specific product and hope that all the needed components (and only these) are included. Instead, an engineer uses Gears, BigLever’s PLE software to select the desired functionality “package.” Gears generates the list of features for each desired configuration and send it directly to Aras Innovator to generate the bill of materials.

Why is this Important?

As discusses earlier, some organizations find that managing complex product configurations and options can be a labor intensive, time consuming and error prone activity.

One outcome of this complexity that is seldom discussed openly is its impact on product testing. Because of the large number of product variants and seemingly endless number of permutations and dependencies between individual parts and subsystems, the generation of relevant and effective test cases is a dauntingly complex and time consuming task that still does not guarantee complete test coverage. Consequently,   products undergo insufficient testing, precious resources go to waste, and project schedule and quality are jeopardized.

With PLE, only the relevant features—and therefore only affected parts and software modules­­—are selected. If test cases for a specific configuration exit, they will be included automatically, or, new ones can be designed and included in the bill of features for future use.

Implications

The integration of between Gears and Aras Innovator can help companies reduce complexity, enhance efficiency, and improve the accuracy and completeness of product configurations.

Aras users that manage variant-rich product portfolios would benefit from the new ability to manage requirements and complex feature set in Gears and keep Aras Innovator BOMs in sync.

Gear’s users, not all of them are also Aras users, should consider implementing a small proof of concept PLE project using Aras Innovator to gauge the benefit of a direct PLE-PLM gateway firsthand and discuss it with their PLM software vendor.