G2

Verified User in Automotive

Enterprise (> 1000 emp.)

7/10/2018

"Global Enterprise PDM Lite"

4/5

What do you like best about Centro?

Best thing about Centro is it's ability to create browser-based CAD assemblies that can be viewed in a browser using SpinfireWeb. These CAD assemblies are now accessible to all of our engineering and manufacturing centers across the globe.

Centro is also wonderful at 3D shape-searching where it can find duplicate and similar parts with just a few clicks. There is tremendous amount of cost-savings potential with this feature.

Once you are trained in creating pipelines using the "Quick publisher", creating Catalog Part assemblies is a breeze. It is IT-heavy in global enterprise installations, so training will get a little thick. Overall, once you master pipelining, you'll want to import all of your data. Review collected by and hosted on G2.com.

What do you dislike about Centro?

Unfortunately, latency/lag is horrendous on cross-continental distributed architecture installations. Add the overhead of crossing the Atlantic, PLUS any WAN overhead you may encounter, and the product is virtually unusable. We are considering breaking up the Arango database into two separate installations (one in North America and one in Germany) to help us with latency. Until that happens, only our North American users are using Centro.

Also, there is very little fault-tolerance with pipelines. If you are pipelining an assembly, there is no way to know if there are any inconsistencies with the assembly (broken links, assembly trying to access components stored on a directory inaccessible to Centro service account, etc.) until after the pipeline errors out. Then you are left with a Project with dozens of decoupled components and a broken top level assembly. Furthermore, pipeline error handling is basically useless to even the highest level administrators since the error codes and error messages are very cryptic. It is almost impossible to troubleshoot an error without pulling in Actify developers to help us trouble shoot the issue. Error messages need to be simplified so that we (the customers) can self-help our issues. Right now that's impossible.

Document management isn't a built-in feature in Centro. As a matter-of-fact, Centro is a CAD solution and not really made for structured document management. All of our engineering documents are currently organized in a Windows folder-based structure. Centro does not offer folder-based organization for document management. You have to upload documents into a Catalog Part (that was originally developed to store CAD assemblies and components) and organize them by Tags or Categories one-by-one. This is extremely time-consuming if you just uploaded 100 engineering documents and now you have to throw Tags on each document or individually categorize them. Our work-around was to create a fake/empty CAD assembly that mimics our folder structure and pipeline that assembly without uploading native CAD. This gives us collapsible "folder-like" Catalog Parts where users can upload their engineering documents. It's not perfect by any means, but it's something that is familiar (folders and sub-folders) to end users. Centro really needs a better way at handling engineering documents.

System pipeline needs some customization. Right now it is hard-coded to run only one concurrent job. It needs prioritization and the ability to tweak timeout settings, and how many concurrent jobs it can run. We have that ability on all our other pipelines. Why don't we have same options in System pipeline? A usage case for this is if a user decides that they need to create a STEP conversion from the drop down menu. That conversion won't start until all other System pipeline jobs are completed.

Some other minor dislikes: 1) CAD attributes (metadata) being stripped during a simple check-out/check-in, 2) No way to use assembly resource manager to add/remove components of an assembly (the only way to do this is force a pipeline update from watch directory), 3) CAD-to-CAD converters not working properly in previous releases, and 4) Unsatisfactory quality-assurance testing with Centro revisions (in a production environment we were down for a few days until fixes were implemented) Review collected by and hosted on G2.com.

Recommendations to others considering Centro:

Be aware of cascading updates on very large assemblies with multiple sub-assemblies. If designers are using check-out/check-in functionality and checking-in multiple bottom layer components, every sub-assembly up the tree will initiate a cascading update for thumbnails, SpinfireWeb and Spinfire Ultimate files. Depending on complexity of assembly, the Spinfire Ultimate files can become very large the higher up the navigation tree you go. You can consume a large amount of disk space without even knowing it. Furthermore, cascading updates utilize the System Pipeline which is currently hard-coded to only run one concurrent job at a time. Large assemblies can bog down System Pipelines. We decided to turn off all Spinfire Ultimate (ACT3D) conversions and only create thumbnails and Spinfire Web conversions.

Also note: the "Generate..." option in the resource menu will automatically set the conversions to cascade whenever there is a change. For instance, if you want to create a STEP conversion, you need to select "Generate..." and select the STEP conversion box. From that point forward, that conversion will always be updated with a new version any time the native file changes. These versions can add up and consume disk space. If creating a one-time STEP conversion and don't need that STEP conversion to update every single time there is a change to the assembly, make sure to go back into the "Generate..." menu, and uncheck the STEP conversion.

Also make sure that any assemblies you decide to pipeline are linked 100% to the top level assembly. There are many ways to do this. In Catia you can put everything in design mode and use save management to link all the components properly. You also have the option to use the "Send to..." command that will save the top level product and components to a different directory such as a Centro Watch Directory. In NX, you can use the clone tool to do the same thing. If you have components saved on different directories that Centro cannot access, you may end up with a top level assembly with broken links to its components.

Biggest thing we learned: sharing components with the exact same name between two different OEMs can be disastrous. For instance, JLR and Ford often use the same Teamcenter part names since JLR was once owned by Ford. The original beauty of Centro was the ability to use the "where used" function to see all of the assemblies that used a specific component. This is perfect for VA/VE, cost reduction opportunities and many other benefits. The underlying problem with this is the idiosyncrasies with native CAD software and versions that OEMs use. If two different OEMs use the same part but different versions of CAD, there is a chance that a designer using a higher level of native CAD will overwrite the lower level of CAD. The other OEM designer will not be able to open that file to make any changes to it. We had to solve this issue by adding OEM-specific prefixes in our pipelines. We lose "where used" functionality but we keep our native CAD consistent with the OEM native CAD software version. Some functionality is there for us though: the Duplicates tab. This then will show us duplicate parts and the CatalogID prefix shows us the OEM.

Lastly, beware global implementations that use the distributed architecture model where there is one Arango database linked to multiple Pipeline Host/Pipeline Managers. There is a show-stopping latency issue when logging into a European Pipeline Host that access a North American Arango database. This setup is unbearable to use in Europe to the point that end users will not use it due to the lag. We are considering splitting up our Arango databases so there is one for all of Europe installations and one for North American installations. This option breaks up any aspect of global searching and sharing between continents, but it will improve user adoption.

Additional note update: System RAM seems to be the largest bottleneck and most critical aspect of the Pipeline Host server. There is a balancing act between the amount of cores and available RAM. We ran some tests that saturated the CPU cores by running multiple pipelines with six concurrent jobs per pipeline. What we found is that once available RAM is saturated, the system will start writing data to swapfile. Once this happens, when Pipeline Host is accessing very large assemblies in order to process SpinfireWeb, ACT3D and thumbnail conversions, they will probably timeout. Due to the volume of pipelines that we have always running, we are considering standalone server with 500GB of RAM and 32 cores. Our workaround now is to limit the concurrent jobs per pipeline to three, as well as limit how many pipelines we run. We continue to monitor system resources and make sure that our RAM usage never exceeds 75% utilization. Lessons learned: avoid oversaturating system RAM to the point where Pipeline Host is moving enormous amounts of data to swapfile. Review collected by and hosted on G2.com.

What problems is Centro solving and how is that benefiting you?

Global CAD sharing, feature model template library, fastener library, design work flow Review collected by and hosted on G2.com.