Aras Innovator: PLM on a Shoestring, 2 in a Series

By Brent Evers

This is the second in a series of three articles on Phoenix International’s internal implementation of Aras Innovator. This segment discusses the realities of that process—where the effort was in understanding the system and the moves Phoenix made in making the product more useful to our engineering group and business. Read part 1 here.

The evaluation and selection process that led Phoenix to choose Aras Innovator was somewhat challenging, but we found that its implementation was where the real work was.

Phoenix’s Aras Innovator ECAD integration provides a tight coupling of Innovator parametric part data, OrCAD Capture, Orcad Component Information System, and PAD’s PCB Layout.

While working with the test installation, we were learning but weren’t making any progress on actually putting the system to use. It took a few dedicated engineers (with a little more time on their hands than we would have liked) to get the ball rolling. At the end of 2008, we finished a few projects and elected to put some of those engineers onto the development of our Aras implementation. Fortunately, each of them was sufficiently frustrated with our existing (lack of) systems so they had a vested interest in making Innovator sing.

  The ability of Innovator to work seamlessly with our existing CAD platforms was a primary requirement. We knew that success in implementation would only come if our engineers had buy-in, which meant their workflow couldn’t be impeded with a burdensome process. Innovator had to add value for the people it would most affect day to day, and it had to be easy to use. Significant manual manipulation of files to move data was unacceptable.

  Integrating OrCAD and PADs
Our first serious thrust was in integrating our OrCAD/PADs toolchain with Aras Innovator. Phoenix had recently completed generating an electrical parts database that assembled all of the parts used in our existing designs in one place. We extended the depth and breadth of that database by adding a rich set of parametric data—more than 40 fields of characteristics—that improved each engineer’s toolset in selecting the correct part for an application from the pool. Symbol and footprint libraries were standardized and centralized, eliminating the need to manage multiple libraries. This ensured that each of our electrical engineers designed using one correlated set of data from the initial schematic to the board layout and from the fabrication package to documentation.

  Our company’s ‘homebrew’ OrCAD integration is tightly coupled to Aras Innovator. Parts are uploaded directly to Innovator and appear near instantaneously in OrCAD Capture Component Information System (CIS). Each electronic part’s characteristic is entered by the user via a drop-down menu of predefined variables, precluding variation and ensuring that parts are entered accurately. Part descriptions are generated from characteristics, ensuring consistency and avoiding duplication. OrCAD CIS pulls the parametric data directly out of Innovator and drops it in the schematic, matching it with the correct schematic symbol and the PCB footprint information embedded for PADs. Phoenix chose to do a complete Innovator-OrCAD integration ourselves since we had the skills; others might opt to review the available third-party Innovator-OrCAD integrations.

Solidworks: Off the Shelf Solutions
Buoyed by the success of having all of our electronic part data in Aras Innovator, we continued with mechanical part data and our own drawings and assemblies. Several third-party providers have developed CAD connectors for Solidworks, and along with the possibility of brewing our own solution, we wanted to review all our options. Once we determined the capabilities we wanted, we evaluated a number of packages.

Phoenix developed parametric part data for each part type, providing a rich, searchable database and a single source of all engineering data.

The Solidworks/Innovator connector from xPLM of Dresden, Germany, showed us that for about the cost of two seats of a popular integration solution we could have a solution with all the functionality we required tailored to the Innovator framework, for 15 Solidworks seats. Phoenix intends to implement this MCAD connector in the near future.

Database Development to Add Value
While Innovator can be implemented right out of the box, we found that customizing our installation with a rich database of consistent, parametric part data added significant value. Part of our implementation process included reviewing and cleaning up almost all of our part and document data. Without having solid business processes in place from the beginning, each engineer had developed his or her own way of naming parts, saving part data, etc. We had cleaned up a lot of that data and wanted to ensure that Innovator provided the structure to help engineers enter data in the future and prevent a return to our previous way of doing things.

  The formalization of those processes is executed in the way we developed our Aras Innovator database. Through the use of forms for data entry, Innovator users are guided through the entry of a document, part, assembly, BOM, etc. so that the data gets entered the same way each time. Sure, we have some legacy parts that don’t conform and aren’t worth changing, but by and large, going forward we will generate clean,  consistent parametric data for every item entered in Innovator. This greatly aids in the future selection of parts, as a user will be more or less guided to use the same parts we have been using, precluding the constant divergence of material and part sources.

Digging through the Basement
In the past, we at Phoenix have committed some serious PLM sins, like issuing blocks of part numbers to a project but not closing the loop on the unused numbers status. We’ve stored most of our project data through a series of folders on a network drive that are essentially managed by the project manager, and each has done so in a different way. The depth of documentation and documentation control applied to a project has varied according to the whims of the project manager,  the needs of the customer, and whether it was correctly budgeted for (more often not). The previous systems were put in place to be cost effective and allow each project some flexibility, but we often ended up paying multiple times to stand up multiple systems. We’ve made stabs at engineering change processes, but have never been successful at getting it right and making it stick.

  No software application can correct all this, but having the tools in place and a proven framework to follow sure helps. Aras Innovator has provided that framework and we are much further down the path to a defined and accountable development and documentation process than previously.

  The process of evaluating our data and our processes in preparation for upload to Aras Innovator and the need to understand its processes and how they meet or don’t meet our needs has been a challenge. It’s taken some time, but it’s helped us learn what we need and what we needed to change in Innovator. At this time we’ve nearly completed that process.

  In the final installment, I’ll discuss some of the ramifications of going live, lessons learned, and where we’d like to see Aras Innovator’s development go in the future.

More Info:
Aras Corporation

Phoenix International Holdings

xPLM Solution GmbH

Read part 1 of this article here.

Brent Evers is the engineering manager at Phoenix International Holdings, Inc. Send comments about this article to [email protected].