"Global Trends and Best Practices in Mechatronics Product Lifecycle Management," ME Online Web Exclusive, Oct. 6, 2005

for 10/06/05

To read
our previous
ME Online Exclusives,
click here.

Global Trends and Best Practices in Mechatronics Product Lifecycle Management

by Don Vossler and Vikram Dutt
UGS Corp.

Abstract

The design and manufacture of modern electromechanical products engages a wide range of disciplines as products mature from concept to delivery and support. The development of electromechanical products in the past has been done in separate silos of electrical, mechanical, and software domain experts. However, market drivers, technological advances, and globalization are leading to increased interaction between the domains. We call this convergence of mechanical, electrical/electronics and embedded software mechatronics. This paper describes industry trends and best practices in the full product lifecycle of mechatronics systems.

Introduction

Creating content-rich and price-competitive products in increasingly reduced product lifecycles is a challenge faced by all manufacturers of electromechanical products. In this paper, we highlight the key challenges and trends faced in the development of mechatronics systems and provide a best practice description and vision for mechatronics. Our findings are based on comprehensive interviews conducted during the last two years involving over 20 companies and covering a wide array of electromechanical products. Our vision revolves around three key elements-integrated applications across multiple domains, common product data management architecture, and a system design and simulation environment. We consider management of the complete product lifecycle, including conceptual design, engineering design, analysis, testing, manufacturing, delivery, support, and disposal/recycling.

Scope of Mechatronics

We define a mechatronic system as the synergistic integration of mechanical, electrical, electronics, and embedded firmware (software) technologies into electromechanical products. Mechatronic systems and subsystems appear across all industries, including automotive, aerospace, consumer electronics, machinery, equipment, and others. Mechatronic systems are excellent candidates for design process optimization due to the high complexity of mechatronic designs, the high degree of integration of electrical, mechanical and information-processing components, the overlapping design disciplines and system behaviors, and the critical nature of opti-mizing of the overall system.

We use the following product categorizations to distill common characteristics of various mechatronics products. This categorization allows us to identify common practices and require-ments between various industries, and also to distill important differences.

Electronics and Consumer Durables

• Electronics: examples include cameras and audio equipment;

• Consumer Durables (white goods): examples include washing ma-chines, refrigerators, dishwashers, and dryers;

• Consist of printed circuit boards (PCBs) in a mechanical package; can be freestanding, handheld, or mounted in racks or vehicles;

• Issues relating to aesthetics, form factor, and heat dissipation are critical; software component is large. Consumer durables, in addition, usually have significant mechanical mechanisms.

Vehicle Systems (harnessing and wiring)

• Examples include automobiles, small aircraft, trucks, small watercraft, and personal transportation;

• Primarily provides electrical and control functions, electronic control units (ECU), wire harness, sensors, human interface; provides connectivity and control for mechanical (engine, brakes) and electronic systems;

• Issues relating to aesthetics, form factor, and heat dissipation are critical; software component is large.

Communication Systems

• Examples include radio base stations, telephone switches, satellites, and radar equipment;

• Consist of intricate electronics and control units to serve as communi-cation infrastructure; devices are usually freestanding or mounted on rooftops or towers;

• Managing software revisions and third-party suppliers is critical; issues relating to scalability and reliability are also very important.

On-board Control Systems

• Examples include automotive, aerospace, marine, weapons, and space systems;

• A combination of electrical and electronics components that provide a control mechanism in vehicles;

• Usually a black box, issues relating to inputs as they relate to other components, size, and heat are important.

Biomedical Instrumentation

• Examples include MRI, CT scan, dialysis units, and airport security systems;

• Diagnostic and investigative equipment used in medicine; expensive and not mass produced;

• High precision and reliability required; there are significant mecha-nism and electronic PCB components.

Office Equipment

• Examples include copiers, fax machines, printers, computers;

• Both mechanical and electronic in function although some, like copiers, have a significant mechanical mechanism component;

• Software is key control method; run on 110V or 220V (as opposed to electronics) so issues relating to EMI are important.

Industrial Machinery and Equipment

• Examples include large industrial equipment, silicon fabrication machines, printing presses, gas turbines, weapon systems; simulators;

• Mixture of electrical and mechanical components; comprised of large-scale machinery with intricate control requirements; products in this category are primarily freestanding;

• Very large mechanisms, produced in low volume; custom electrical and electronic controllers as opposed to software control; typical requirements to handle high voltage and 3-phase.

Large Scale Transportation and Equipment

• Examples include large aircraft, locomotives, shipbuilding, and mass transit systems; construction equipment (cranes, bulldozers, trucks);

• Primarily mechanical in function; all of the ducts, wires, conduits, controllers, and mechanical components required to manufacture a large transportation vehicle;

• Wiring and plumbing are important; customization level is high; software version management is critical; complete environment is composed of other electromechanical products.

Trends and Challenges

Market drivers in product design with increased usage of software and electronics as a distinguishing feature in electromechanical products, coupled with changes in manufacturing such as globalization, increased competition, higher safety needs and faster serviceability have led to challenging new requirements for stylish, content-rich and price-competitive products. In the electromechanical domain, the latest product designs incorporate new intelligent mechatronics features with increasing complexity and the use of electronics and software as differentiators in the marketplace. These features require added electronics, increased embedded software, and smart manufacturing processes to drive the next level of operational efficiency and performance. The development of these complex interlaced systems over the entire product lifecycle represents an increasing challenge for all manufacturers and their suppliers.

The following are some product lifecycle management (PLM) challenges faced by manufacturers in the general electromechanical domain:

• Mechanical, electrical, and software product development have traditionally grown up as separate silos of expertise and technology that need to be brought together earlier in the development lifecycle.

• There is no single product data management (PDM) system for capturing design data. Mechanical, electrical, and software data are often handled in sepa-rate PDMs with no automated sharing of data between the systems or links between data.

• There is no commercial system design environment currently available. Some manufacturers are patching together homegrown systems that are expensive to develop and maintain.

• Due to the growing number of product variants and increasingly short lifecycles, costs for developing physical prototypes have become increasingly prohibitive.

• Many different ECAD and MCAD tools are currently used at OEMs and their supply chains. Keeping different versions of software in synch and main-taining interfaces is costly.

• Software is an increasingly significant component of products because of the decrease in cost of reprogrammable memory and increase in number of ECUs (electronic control units) due to complexity of product control systems.

• Companies are realizing embedded software is an area of competitive differentiation and are investigating how to improve and streamline their software processes. There are no commercially available systems for keeping the software version synchronized with the mechanical and electrical product data.

• Interfacing with an incumbent PDM system requires more flexible application interfaces and data standards. An intermediary PDM system for work-in-process (WIP) data is sometimes required in some engineering disciplines.

• Large-scale machinery in the past 20 years has increased electronic content. The challenge today is tie together mechanical design and system simulation.

• Due to the increased electronic content, traditionally mechanical companies are outsourcing the development of PCBs. Managing the supply chain and tying to as-shipped product structure is a growing challenge.

• Intellectual property rights are increasingly moving to suppliers, rather than OEMs, as the product behavior is moving to software.

We envision a best practice in product lifecycle management (PLM) for mechatronics that will address these challenges. Our vision encompasses three cornerstones: best-in-class applications, data integration, and system design environment.

PLM Applications for Mechatronics

Our applications vision integrates a comprehensive set of domain-specific software applications for every phase of a mechatronic system's product lifecycle. Competitive enterprises require electromechanical applications suited to a diverse range of components and systems:

• Mechanical Components

• Electrical/Electronic Components

• Wiring Harnesses

• Printed Circuit Boards (PCBs)

• Embedded Software/Firmware

These applications will be provided by best in class independent software vendors (ISVs), and need to operate within a common product lifecycle environment.

Mechanical and Electrical Component Design

There are well-established vendors supplying application software for mechanical and electrical design. Competitive and best-in-class manufacturing companies use these MCAD and ECAD applications extensively in the product lifecycle.

Downstream activities involving analysis, manufacturing, and testing take advantage of the data produced by MCAD and ECAD tools for increasing productivity, quality, and efficiency. Major challenges involve tying these systems to enterprise product data management and sharing data with other applications.

Harness Design and Routing

Leading MCAD applications provide capabilities to design and route wire harnesses. These applications provide the crossover between MCAD and ECAD systems, and effective applications must provide for coordination and collaboration between the MCAD and ECAD domains.

In a typical engineering environment, electrical data is exchanged between MCAD and ECAD using data files having no structural relationships (flat files of textual data). The sharing mechanism involves two files: a harness file describing the connections (from and to information) and a component file describing the components present in a harness. These flat files are typically exchanged between the MCAD and ECAD designers by manually sending files. Engineering Change Orders (ECOs) from either the MCAD or ECAD domain require that these files be exported and reconciled, a process that is often tedious and error prone. For example, a part substitution in one application requires the appropriate part substitution in all other domains.

Evolution of electrical data exchange is occurring throughout the industry. The STEP AP212 standard enables electro-technical exchange and is a robust exchange format. German automotive companies have effectively embraced AP212 with an implementation called KBL, allowing a robust exchange between multiple data providers. These implementations, however, are still relatively young and continue to evolve.

Providing a product data management system that supports STEP AP 212 and KBL will create an environment where electromechanical data can be created or modified in different applications with confidence that the data changes will propagate to other applications.

Additionally, the integration of the AP212 data into XML schemas will further allow for a seamless integration with PDM systems. Using XML, an MCAD application will edit electromechanical data and react to changes made outside of its application context. The reverse will hold true for an ECAD application. Given the complexity of mechatronics data, coordinating these efforts across multiple application domains remains a challenge, but is beginning to be addressed by leading software vendors.

PCB Design and EDA

The increasing component density of today's printed circuit boards (PCBs) requires a much tighter integration between PCB design and mechanical engineering. Every PCB contains mechanical constraints primarily due to product packaging requirements that constrain the shape, size and position of PCBs. Based on these packaging constraints, the mechanical designer determines the board outline and the size and locations of mounting holes for the board. The mechanical designer also knows where to place certain critical components, such as connectors, displays, and switches, because these locations are determined by the product packaging itself. Often, the mechanical designer indicates areas on the board where components cannot be placed, or where placement is limited by other obstructions in the overall assembly.

On the other hand, the PCB layout designer uses initial information from MCAD as the basis for creating the board layout in ECAD. Often the layout designer adds additional placement and routing restriction areas, tooling holes, pads, and solder masks. With the pre-placed components as a start, the layout designer places additional components. The locations of the pre-placed components may need to be modified to accommodate board routing considerations. Typically, several revisions between MCAD and ECAD are required to stabilize the design, or to accommodate product packaging or functional changes.

Today the Intermediate Data Format (IDF) standard is typically used to communicate data between MCAD and ECAD. The IDF exchange process is well defined and the content has evolved over time, although some PCB ECAD vendors have not implemented the newest version IDF 4.0 (available since 1998). This limits the depth of information that can be exchanged in ECAD/MCAD co-development process. Currently, most MCAD application vendors do not support the IDF file format directly, but rely on third-party companies.

Many of these issues will be solved by using the emerging STEP standards to achieve the same co-development goals. STEP AP210 is the standard for ECAD/MCAD data exchange. By implementing the STEP data model with a PDM system using XML schemas, the integration between ECAD and MCAD applications will be simplified. Similar to the harness applications case, an MCAD and ECAD authoring tool will place design elements into the data model, and this information would be used by both the originating authoring tool for data management, and also other authoring tools for design validation and collaboration. Thus, association at a data model will change management propagation across domains.

However, historically, ECAD applications have not embraced standards so convincing them to support the STEP standard is a challenge.

Embedded Software

Embedded software processes for manufacturing companies are evolving at a rapid pace, as software content is increasing due to the complexity of product control systems. Legal regulations for software release, testing, and traceability are increasing, and improvements in diagnostics equipment are enabling real-time service of the product in the field. There is a growing need to conduct more frequent software updates (reprogram or "flash" the software on an ECU after product is sold) to address quality issues or provide improved capabilities. The critical path in the new product introduction process now often involves software development activities.

Manufacturers are facing issues of creating correct software builds synchronized with product development milestones due to a lack of formal change management and release mechanisms. This results in excessive iterations of software content, managing redundant information, and poor traceability for legal compliance. The need to service the product in the field promptly, coupled with the high cost of equipment downtime, requires that correct software files appropriate to the equipment's configuration (accurate service packs) be delivered reliably. Product designers need to understand what software should be embedded, its communication network with devices and sensors, and the dependency of multiples ECUs in the system.

Using enterprise PLM tools, manufacturers can manage the complexity inherent in this domain. The initial prototype to launch phase is of key importance where the engineering group provides the design (along with software) to the manufacturing group. In the absence of a structured approach to data management, many issues surface that prevent the distribution of correct software files. Furthermore, managing data during upstream phases is heavily dependent on the integration of PLM backbones with specific in-house tools for simulation, analysis, and code generation. We have identified two distinct applications-embedded software processes: software release management (SRM) and source code configuration management (SCCM).

Enterprise PLM is the obvious platform for manufacturers to adopt for SRM, as software and hardware are combined when product is built and the hardware release management is typically already stored in the enterprise PLM system currently. Change management for software and hardware is mutually dependent and having both types of data in a single product data management (PDM) system enables proper synchronization. Augmenting SRM within enterprise PLM leverages existing tools and processes. PDM provides rich capabilities for configuration management, security, scalability, supplier integration, and collaboration.

Engineers responsible for programming embedded software are normally distinct from those responsible for release coordination of ECU software. SCCM is typically used for initial coding, unit testing, and component verification based on customer requirements driven from an enterprise PLM system. A tight linkage between SRM and SCCM is desirable for traceability and visibility on the software development lifecycle.

PLM Data Integration for Mechatronics

Our second best practice cornerstone is PLM Data Integration, which provides a product data management architecture enabling applications to share data for collaboration in the lifecycle of mechatronics systems. A collaborative data environment enables manufacturers to use a diverse set of applications throughout the product lifecycle. To improve new product introduction through integration of mechanical, electrical, and software domains, the product data management (PDM) data model needs to support STEP standards for electrical and mechanical data, and an XML-based standard for robust interchange of data between applications.

Historically, the evolution of the PDM systems followed the path from vaulting and managing bulk data files to fine grain data representation of the data stored inside these files. Up until recently, a core mainstay business of companies offering PDMs has been MCAD authoring tools. Thus, it's not surprising that the strongest functionality of the PDM offering has been a management of physical/mechanical fine grain representation of the product. Future PDM systems for mechatronics will extend the core data model to enable storing, managing, and configuring mechanical aspects of the product, including electrical, electronics, and software representation of the various product categories described earlier.

The core PDM mechatronics requirement is to provide a data model rich and functional enough to represent a fine grain level of details of requirements, functional, and physical aspects of the electromechanical products and relationships between these representations. This includes the electrical and software domains in addition to the mechanical.

These fine grain characteristics imply that the component level of details and bill-of-material (BOM) structures of requirements, functional, and physical components exist in a PDM mechatronics data model. Functional characteristics of the definition imply that while extending existing PDM functionality to electrical/electronics data entities (configuration, structure and occurrence management, embedded visualization, and integration to the authoring systems), mechatronics solutions will also add value by managing and controlling relationships between various product representations, thus providing a single, consistent PLM environment for the design, analysis, support, and maintenance of electromechanical systems and products.

Open Tools and Standards

Mechatronics brings together a wide range of disciplines. In this respect it is, by necessity, collaborative in nature. It is in supporting this collaboration that openness becomes essential. By building upon a common tool set and data architecture, applications from multiple domains can integrate to an enterprise PLM system.

A key strategy for achieving openness is leveraging the STEP (Standard for the Exchange of Product Model Data) standard, a comprehensive ISO specification (ISO 10303) that describes how to represent and exchange digital product information. STEP provides a framework for building the ECAD/MCAD co-development environment. ISO 10303 allows for the following:

• Data sharing between applications (single copy of application data)

• Data exchange using a standards-based format

• Long-term data archival using a standards-based format

• A high-level API that simplifies the complexity and use of the multitude of data structures provided by STEP
Extended Markup Language (XML), a specification for transmitting validated Web documents, and interpreting data between applications and organizations, can be used to provide schemas for mechatronics data models. It is a way is to provide a consistent representation of all the mechatronics data that is shared on the PDM system regardless of its source. This means that the mechatronics data available on an enterprise PLM system will be usable by other XML enabled applications with a minimum of rework. This allows multiple vendors to populate the mechatronics core model, using such XML schemas without expensive code changes in their applications.

PLM System Design Environment for Mechatronics

Our third mechatronics best-practice cornerstone is a System Design Environment providing an environment enabling digital simulation and analysis of electromechanical products. This environment provides an integrated approach to multidisciplinary design, simulation, and analysis coordinating mechanical, electrical/electronics, and embedded software disciplines. It enables digital verification of complete designs, reducing reliance on costly and time-consuming physical prototypes. The system design environment allows validation of electromechanical systems earlier in the product lifecycle, before major lifecycle costs are committed.

In designing electromechanical products, manufacturers adopt a system decomposition approach to define the product. Top-level product systems are divided into subsystems that are further divided into components. The physical aspects related to electrical design are determined as part of component design, function, and placement. The typical mechatronics development process starts with customer requirements for a mechatronics subsystem that eventually flow down into a detailed set of constraining parameters to be met. In the process of flowing down the requirements, users will allocate requirements to functions to be performed by the system, which in turn are partitioned and allocated to physical elements (mechanical, electrical, and software components) that perform the functions. The result is a set of requirements that flow down to each element that perform the task and act as input specifications for each component. Today, this process is typically performed by a number of disconnected tools, including:

• Requirements management (usually in the form of a database or spreadsheet)

• Diagramming tools (simple drawing tools, or elaborate simulation environments)

• Software development tools (simple code editors/compilers, up through targeted development/debug environments, to high-end software modeling environments)

• Electrical design environments (including schematic capture up through PCB layout systems)

• Simulation environments that analyze different aspects of the mechatronic system (performance, timing, control) and other systems, such as test vector generators/coverage tools, EMI/EMC analysis, harness outputs, and fault tree generators.

The natural place to bring all of these islands together is the enterprise PLM that maintains not only product BOMs, but also the relationships among the components that make up the mechatronics subsystems. In addition, an enterprise PLM already deals with the sophisticated concepts of effectivity, versioning, and configuration that are not completely dealt with by the isolated systems in an integrated way.

A state-of-the-art solution connects these environments through the standard BOM with its interrelationships, while providing an integrated top-down, systems-level development/design environment. The systems design environment includes standard diagramming tools (to capture the wide variety of diagrams needed for mechatronics systems-logic, states, functions) and system simulation framework for integrating the variety of simulation models needed for successful mechatronics product development, integration, and test.

The result is an enterprise-aware, computer-aided mechatronics development environment that is integrated with the standard product data management system bridging the variety of tools needed for mechatronics systems design and providing a single source of product data for mechatronics systems.

Conclusions

We have presented an overview of global trends and best practices for product lifecycle of mechatronics systems. Our PLM vision is centered on identifying best-in-class applications, using a product data management system as the backbone, and providing a systems engineering environment to allow an integrated suite of applications to work well across the electrical, mechanical, and software domains throughout the entire product lifecycle. The increased complexity of electromechanical products coupled with the exponential increase in electronics and software content is creating unique challenges and opportunities. Manufacturers that use enterprise PLM to integrate the mechatronics domains for collaborative design and leverage common data through the product lifecycle will emerge as leaders in product capability, quality, and efficiency.

Glossary

• API: Application programming interface, a formal definition of functions that programmers can use to access the capabilities of a software library.

• ASCII: American Standard Code for Information Interchange, a numerical coding system used to represent text characters in computers.

• BOM: Bill of Material, a hierarchical list of the items comprising the structure of a product.

• CAE: Computer Aided Engineering, the use of computers to analyze and simulate models of physical devices.

• ECAD: Electrical Computer Aided Design, the use of computers to design and engineer electrical and electronic products.

• ECU: Electronic Control Unit, an electronic device typically embedded in an electromechanical product to perform calculations.

• EDA: Electronics Design Automation, the use of software applications to automate the process of electrical or electronic design.

• EMI/EMC: Electromagnetic interference/compatibility, electromagnetic waves caused by electricity flowing through systems that can cause interference or compatibility problems with other components in the system.

• IDF: Intermediate Data Format, a textual file format used to interchange electrical connectivity and component data between software applications.

• ISV: Independent Software Vendor, a company that produces commercial software intended for a wide market, but independent of a particular hardware platform (multiplatform).

• KBL: Kabelbaumliste (in German), meaning harness description list, an extension to the STEP standard for design electrical cables in the automotive industry.

• MCAD: Mechanical Computer Aided Design, the use of computers to design and engineer mechanical products.

• OEM: Original Equipment Manufacturer, a company that manufac-tures a given product, unlike a value-added reseller, which changes and repackages the product.

• PCB: Printed Circuit Board, a rigid, non-conducting board with etched metal providing interconnect and mounting for electrical components.

• PDM: Product Data Management, a software application that stores, organizes, manages, and secures data describing a company's products.

• PLM: Product Lifecycle Management, the management and use of data throughout the entire lifecycle of a product.

• SCCM: Source Code Configuration Management, a software application that stores, organizes, manages, and secures the computer programs for embedded software systems.

• STEP: Standard for the Exchange of Product Model Data, ISO standard (ISO 10303), an international standard specifying a variety of formats for data exchange.

• XML: Extended Markup Language, a specification for transmitting validated Web documents and interpreting data between applications and organizations.

About the Authors

Don Vossler and Vikram Dutt work for UGS, a leading provider of product lifecycle management (PLM) software and services. Don is UGS Fellow and vice president and has more than 25 years of industry experience, specializing in software product development, product management, business development, and strategic marketing. Vikram is manager of strategic initiatives and has more than 10 years of industry experience, specializing in software product development, product management, and business planning and analysis.

The authors are responsible for a key UGS growth initiative in mechatronics. Over the past two years, they have visited and worked with key manufacturers around the world and developed relationships with key partners to develop UGS's strategic vision for mechatronics.