The Cloud Lives!

18 Nov 2011: Ralph Grabowski proposed his opinion that the cloud is dead. He couldn’t be more wrong. Consider users at the Siemens NX CAE Symposium that ended last week. Virtually all of the eight users at a panel noted that cloud computing would definitely be part of their plans. Assuming that some minor issues such as security, cost, and application software licensing could be solved, all seem to have or want it in their future plans.

Several customers represented companies that already have with HPC clusters. While this ideal “local cloud” met their expectations, the cost of such a cluster is very high and not a solution for smaller companies.

I agree that the use of cloud computing for interactive applications is a bad idea. However, the vast computing power, parallel processing, and expected low costs make it a very appealing idea for tasks that require modest bandwidth and have high computational needs. Autodesk’s CEO, Carl Bass, clearly has the right idea. Autodesk, over the past two years has introduced several applications that span the range of interactive hardware and relying on the cloud to ramp up compute speeds. At AU last year I had the chance to listen to Bass and speak with him about his ideas for best utilizing the cloud. As I wrote in that article, Autodesk’s concept is to “Don’t replicate desktop solutions on the cloud. Instead make maximum use of desktop and mobile systems, utilizing the cloud where it makes sense.” Still makes sense today. Here is a link to that article http://wp.me/pvn8U-3e.

Oddly enough, with the possible exception of DS, Autodesk’s competitors don’t seem to get the concept. For example, while I interpreted from Siemens customers that they were excited about potential use of the cloud, Siemens PLM Software, except for licensing issues, seems to have no plans to enable them. The same goes for PTC.

Let me know what you think.
—–

How Local Motors won the DARPA contest

A few weeks ago I published an article entitled “DS clarifies DARPA crowdsource win.” A few things, in my mind needed clarification. Dassault Systemes PR rep, Jessica Harrison from fama PR, arranged for me to speak with Alex Fiechter, Local Motors Engineer. I was curious, among other things, about how crowd-sourcing was used for the design and whether it was useful. I also wondered how they handled input from 12,000 community users and what was the process they used. Finally I wanted to find our more about Local Motors.

Here is how the process worked. Local Motors (LM) massaged the DARPA specs for the contest into a “brief,” a mission statement of what they desired, and posted it onto their website, asking their community members if they were interested in responding. Most of the community members are interested in industrial design and some helped LM design their Rally Fighter. Along the way, LM developed their concept for Local Forge, an open source web-based co-creation platform. Apparently, car lovers worldwide love to design shapes for cars of their dreams. Local Forge is a way for them to share their designs via images, with all other community members.

A key aspect of the mission statement was to use the existing Rally Fighter chassis as a base upon which to build the body. With the mission statement , eventually 150 to 180 proposal were submitted, from which the final design was chosen. The proposals could be in any electronic form, such as images or even CAD files. They had to show the 3 required views at a minimum. The community then voted on the submissions. Only the winning submitter gets paid. LM used SolidWorks for the mechanical design and Catia for the body design.

What next? Will it be produced? DARPA owns the design now that the contract is complete. A research arm of the DoD, the DoD may or may not choose to produce the design.

Has Local Motors discovered a new way of doing business that involves minimal plant investment, a way to solicit valuable (and mostly free) input from leading designers, and deliver an exciting new product? You be the judge. Visit some of the links from my previous article quoted above and provide some feedback via comments on this blog.

——

DS clarifies DARPA crowdsource win

A few days ago Dassault Systemes (DS) released a press release announcing that the first online, co-created military vehicle was delivered through the collaboration of Local Motors, DS, and 12,000 community members.

I was really interested in this announcement because of the concept of crowdsourcing, I had never heard of Local Motors, and what in the heck was a co-created military vehicle? After delving into more details about Local Motors, and trying to find out if this military vehicle could withstand IED’s (improvised explosive devices, as often used in Iraq and Afghanistan) I was a bit confused. The DS PR people were kind enough to put me in touch with Al Bunshaft, Managing Director of DS North America.

Al and I spoke recently, and you might be interested in what I found out.

First of all, this is a DARPA initiative (Defense Advanced Research Projects Agency). By the way, DARPA is the agency that provided the early funding for what later became the Internet. So, when I hear that DARPA is involved my ears always perk up. This project appears to be one of a series of projects DARPA is initiating to see if there are better ways to provide defense sourcing differently than in the past; namely, cheaper, more rapid development, faster deliveries, and the delivery of specialized vehicles without a massive dollar commitment.

Here is what DARPA had to say about the requirements for this vehicle. “It is important to note that even though this is a militarily relevant vehicle, this is not an offensive fighting vehicle. The goal of this vehicle will be to transport items and/or people around quickly and efficiently in a potentially hostile but mobile environment.” I found it interesting that the design requires no body armor to protect against IED’s. Apparently the military feels that a fast off-road vehicle for emergency transportation can be effective, especially if it can avoid heavily traveled roads. This winning design appears to do just that.

DS was heavily involved with Local Motors, supplying much of the core CAD, CAE, and PLM technology, namely Catia, Simulia, Enovia, and visualization tools. The winning design was based on Local Motors’ Rally Fighter chassis, a street legal rally vehicle. Contributors were invited to submit their design concepts using any design tool, even paper based drawings and ideas. Both Local Motors and DS personnel were heavily involved in converting and assembling the submitted designs into a workable CAD model. To vote on the final designs a panel of military and commercial experts was assembled.

Then Local Motors sourced the components and assembled it at their micro factory in Arizona. Here is what it look like.

XC2V winning entry

—–

Click here for the DS press release.

Related websites for more information:

About the DARPA design challenge:

http://www.darpa.mil/NewsEvents/News/DARPA_issues_Experimental_Crowd-derived_Combat-support_Vehicle_(XC2V)_Design_Challenge.aspx

About Local Motors and their participation:

http://www.local-motors.com/XC2V Click on the description for an excellent description of the vehicle mission.

Check out the video on this page of the XC2V being assembled:

http://www.darpa.mil/NewsEvents/Releases/2011/2011/06/24_DARPA%E2%80%99s_Defense_Manufacturing_Efforts_Support_White_House_Vision.aspx

Dassault Systemes discusses their Intercim acquisition

Recently I had a chance to speak with both Dassault Systemes (DS) and Intercim about the acquisition of Intercim by DS. On the call were Patrick Michel, Vice President, Solutions and Marketing, DELMIA and Romain LaVault, Vice President Strategic Development, Intercim.

About Intercim

Intercim provides software to help customers in advanced and highly regulated industries with real-time Manufacturing Operations Management (MOM) and Predictive Analytics for Discovery, Design, Manufacturing, and Operations. Intercim enables the supply network to better define manufacturing processes, execute shop orders, manage non-conformance and ensure quality. One of the benefits is that real-time control and intelligence on Manufacturing Operations helps Intercim customers achieve their Lean Manufacturing goals quicker and accelerate time-to-market.

Their software, the Pertinence Suite, provides manufacturing execution modules, manufacturing intelligence modules, and is already well integrated with CATIA and Delmia.

Background

In 2007, Intercim acquired Pertinence, a French company with technology for using real time production data to analyze potential quality issues. In 2009, Dassault Systèmes announced a minority position in Intercim LLC and in 2010 announced a global reseller agreement. The idea was to use the DELMIA – ENOVIA Manufacturing Hub or the DS V6 environment to deliver manufacturing process plans and work instructions to the shop floor via the Intercim Pertinence MES system.

Intercim is a US based company in Egan, MI, with French connections; revenue in the last fiscal year I estimate at between $7 – $10 million; DS is purchasing the company for 36.5 million USD. The company employs 70 people worldwide. Its customers include Boeing, BMW, Airbus, Ball Aerospace and Honeywell.

Details on the acquisition

Q. Why is DS making this acquisition?

A. To show our serious commitment in the Manufacturing Execution Systems (MES) space. DS expects to integrate Intercim into the Delmia framework, possible for the creation of a Delmia Shop Floor module.

Q. What is the value in “closing the loop” between manufacturing planning and execution?

A: Faster turn around time in case of a problem and it improves the ability to work on and deliver engineering or manufacturing initiated changes.

Q: Give me some idea of the size of Intercim.

A: We have outstanding about 100,000 software licenses focused on the integration of PLM and Manufacturing Execution Systems (MES). We are widely used in the US, particularly within the aerospace industry. Only 10% of our target market are equipped with an MES system from any vendor, thus offering a huge market potential.

Q. How is the software used for regulatory compliance?

A. I can give you several examples. We are used for NASA’s space shuttle for the cargo tracking and have replaced mountains of paperwork. Obviously, for aerospace, individual part serial number control is required; Intercim software accomplished that. In the pharmaceutical industry, the process is important. Such items as temperature, time stamps for dating, operator and machine usage are important and can be captured and fed back to the engineering department as well. In the case of creating flu vaccines data can be read real time to enhance rapid build up of the vaccine. Many data points can be read with no need to wait for later batch analysis results.

Q. What about any potential existing OEM contracts?

A. Our only OEM arrangement is with DS.

Q Tell me about the analytics aspect of Intercim.

A. Analytics allows access to as built data for the PLM system. Decisions can be made as to whether the as-built is the same as the as-designed. Further, we can analyze the reasons for generating scrap and even to understand the commonality of scrap.

Q. Does DS envision major changes in the Intercim management?

A. No, the people in Intercim are very important to our plans and we hope for a high retention rate.

My take

This appears to be a natural extension of DS plans to extend Delmia throughout the enterprise. The two companies were already very close for the last several years and this fills a gap in shop floor control, as well as data analysis to predict potential quality problems. On the shop floor side, it brings DS closer to Siemens Tecnomatix offering, their archrival in aerospace and automotive companies. In shop floor analytics DS now has the edge.

I admit that I have been wrestling with the idea that shop floor control (SFC) is driven by a manufacturing production release system, namely material requirements planning (MRP) and ERP systems, which generate the manufacturing plans that SFC tracks. DS never likes not being in the driver’s seat. Could there be some exciting possibilities for this in the future? Hmmm. I doubt it, but one can never tell.

www.3ds.com

www.intercim.com

TechniCom test-Part 8 shows how Inventor and SolidWorks compare for Mechatronics

Mechatronics

This blog series and the tests reported herein is designed to show some of the key differences between Autodesk Inventor Professional 2011 and SolidWorks Premium 2011 for digital prototyping workflows. This final part of our 8 part blog series examines Mechatronics – the ability to perform cable and harness design in an existing design from an imported electrical wiring diagram.

We test the ability of the mechanical CAD system (MCAD) to leverage data from an electrical CAD system (ECAD). The ECAD system specifies the appropriate connectors, wires, and their connection points while the MCAD system specifies the physical location of those wires and connectors within a product.

Electrical schematic to be imported into mechanical assembly on the right

Autodesk supplied an Inventor video of their solution, a net list in Excel format, a STEP file of the enclosure assembly, and a schematic drawing (.dwg) of the connections.

What’s Important in Mechatronics Design

  • Leverage the data stored in schematic drawing files to design wire harnesses in the mechanical system. Such data can be stored exported from an electrical design file using various techniques. At its most basic, the electrical design software sends a net list to the mechanical package containing connector information for each wire, wire types, and a list of pin-to-pin connections.
  • Generate correct wire lengths
  • Generate output to enable manufacturing of the wire harness
  • Not tested were two-way associativity between the electrical and mechanical software, nor were any tests designed to simulate electromechanical interconnections such as activating switches or sensors based on mechanical actions.

Autodesk supplied us with an Inventor video of their solution, a net list in Excel format, a STEP file of the enclosure assembly, and a schematic drawing (.dwg) of the connections.

What we found out

The two software packages (Inventor and SolidWorks) are comparable. Inventor has a tight connection to AutoCAD Electrical with the xml file transfer. SolidWorks has similar tight coupling with some third party software such as Zuken’s E3. Both systems use added cost electrical software to generate the net-list. SolidWorks was not able to read the AutoCAD Electrical generated xml list, and instead used an Excel file with similar data that needed manual cleanup in Excel.

It appears that there are a few more interactions with SolidWorks, but this may be due to the operator-preferred method. Both systems effectively produced the required output. There appears to be no real operational advantage to either package when used with tightly integrated electrical schematics software. Since AutoCAD Electrical is one of the most widely used electrical schematic packages, the advantage goes to Inventor.

Observations

For this test, on the AutoCAD side, AutoCAD Electrical exports an XML file to Inventor. Inventor reads this file and generates the 3D wiring and, under user control, assigns wires to cables. It can then generates wire lengths, a flat wire harness diagram and a pin board for manufacturing.

Inventor opens the 3D model and then the xml file of the net-list from AutoCAD Electrical. This designates the pin-to-pin connections where the wires are to be placed. Different than SolidWorks, the Inventor user placed the harnesses in anticipation of the wiring to be imported. The wire import could also have been done first, as seen in the SolidWorks video. The names of the connectors and the number of pins on each connector are stored in coordinated libraries in both the electrical and mechanical systems.

Importing the wires in Inventor

Importing the wires in SolidWorks

After the import, the imported wires appear as direct point-to-point connections between the pins without using any harnesses. 19 wires were imported and identified as un-routed. Then Inventor asks for an auto-route of all un-routed wires. It then places all 19 wires into the predesigned harness, we guess by using closest entry and exit points. Then Inventor builds (and reports) a pin board payout of the harness showing the 3D derived wire lengths. The video below shows an Inventor user performing the test. 

SolidWorks takes a slightly different, albeit very similar approach. After importing the net-list, the operator builds a 3D representation of the harness and then places the wires into the harness, with the software computing the wire lengths. This took more manual interaction than the Inventor solution, but yielded the same end result. The video below shows a SolidWorks user performing the test. 

This is the final blog in this series. Users can review a summary of these tests, published as Part 1 of this series by clicking here. We have also published a pdf file of the complete report here. The pdf file does not contain any videos. To see them you have to revisit this blog series at raykurland.com.

About the author

Raymond Kurland is president of TechniCom Group LLC and its principal consultant and editor. His firm, founded in 1989, specializes in analyzing MCAD and PLM systems and has been involved in reviewing and comparing such software since 1987. Ray frequently consults with both vendors and users. Ray has degrees in Engineering from Rutgers University and from NYU. His career included stints with Bell Telephone Laboratories, IBM, and Dassault Systemes. Ray can be reached at rayk@technicom.com.

For more information about TechniCom Group and other software reviews please visit http://www.cad‑portal.com and Ray’s blog at www.raykurland.com. You can also follow Ray on twitter using the id technicom.

——

TechniCom tests Part 7 reveal key differences between Inventor and SolidWorks Design Automation Solutions

Design Automation

Continuing on with part 7 of our 8 part blog series dedicated to showing the differences between Autodesk Inventor Professional 2011 and SolidWorks Premium 2011 for digital prototyping workflows, we examine the ability to automate the design process by automating the creation of drawings for part families, creation of parts from parameters, and creating copies of an assembly constrained along a variable path.

This test looks at simplified automation examples, yet it provides a glimpse of this capability in both products.

  • Create a simple piece of stock lumber (2×4 board) and examine how a user can make that same part file represent several variations of lumber that could be used in a project.
  • Automate the variation of individual drawing views, scales, and annotations.
  • Automate assembly variations that vary by size and position.

Autodesk provided us with three movies showing Inventor completing the tasks. They also provided three STEP files of the frame, the assembly, and the curves to follow for the frame assembly resizing.

Key differences you will see in this test

SolidWorks has some of the same capabilities built into the core modeling system and by using DriveWorks Xpress, a 3rd party add-in delivered with SolidWorks. It can handle configuring a part when placed into an assembly, but updating it in the part model on the fly is not possible. It was able to create the multiple configurations of an assembly – although it required more steps than Inventor to achieve the same solution. SolidWorks Premium was unable to automate the creation of drawings for part families, which requires users to go through the manual process of creating a drawing for each instance of the family. SolidWorks’ third party partner, DriveWorks, offers software that can perform this process, although at additional cost. The no-charge version was not able to control the final drawings, as desired. We did not evaluate DriveWorks, although the extra cost versions of DriveWorks Solo and DriveWorks Pro appear able to perform this task, again, at added cost.

Autodesk Inventor includes iLogic and iCopy technologies that use rules to control the parameters of the part, assembly, or drawing and these capabilities were used to complete this test. Inventor created the lumber workflow, the frame resizing and the drawing scaling without flaws.

What’s Important for Design Automation

  • Engineers can capture design intelligence by using rules to embed design intelligence into parts, assemblies, and even drawings
  • Such design intelligence, in the case where repetitive designs or portions of repetitive designs are used, can radically reduce design time and produce more repeatable results.
  • What techniques are used to build the design intelligence (often programmatic)
  • How easy is it used to create new designs once the rules have been built
  • How such design intelligence is accessible and how it can be maintained in the future

Observations

Autodesk Inventor includes iLogic and iCopy technologies that use rules to control the parameters of the part, assembly, or drawing. Inventor controls the parameters of a part through a single dialog box that updates the model on the fly. It is also able to automate the process of creating unique assembly configurations by modifying the parts and sub-assemblies automatically for the user. iLogic also can use rules to drive drawings – from view placement to scales and annotations – for a family of parts or assemblies, which can save significant amounts of time in large scale projects.

SolidWorks has some of the same capabilities built into the modeler. It can handle configuring a part when placed into an assembly, but updating it in the part model on the fly is not possible. It was also able to create the multiple configurations of an assembly – although it required more steps. Without using extra cost third party software, SolidWorks is unable to automate the creation of drawings for part families, which requires users to create a drawing for each instance of the family.

For the stock lumber workflow, both Inventor and SolidWorks were able to capture all the variations within a single part file.

A family of parts or assemblies also requires a family of drawings to document their design intent. Recreating essentially the same drawing, which only varies by a few critical dimensions wastes time and effort. Inventor allows the user to easily automate drawings using iLogic functionality. Inventor drawings can be set up to automatically vary view placement, scale, and annotations for a family of parts or assemblies. SolidWorks, without extra cost third party software, is unable to automate the creation of drawings for part families.

Creating copies of a frame along a path using Inventor

Creating copies of a frame along a path using SolidWorks

For the frame variation example, Inventor allows the user to automate complete assemblies that vary along specified paths. SolidWorks was able to manually model the frames along a path, but took substantially longer.

See how an Inventor user solved the problems in this 3 part video series:

  

See how a SolidWorks user solved the problems in this 2 part video series – automating the drawing was unable to be done without additional cost software:

 

—-

The next, and final, blog in this series will examine Mechatronics – the ability to perform cable and harness design from an imported electrical wiring diagram. Stay tuned or sign up to be notified of my blog updates.

—-

TechniCom tests Part 6 show why Inventor’s digital prototyping outshines SolidWorks in Interoperability

Interoperability and Direct Modeling

Continuing on with part 6 of our 8 part blog series dedicated to showing the differences between Autodesk Inventor Professional 2011 and SolidWorks Premium 2011 for digital prototyping workflows, we examine the ability to import MCAD models from CATIA and to perform direct edits on the imported geometry. Finally we take a drawing off the final model.

As in the other blogs in this series, this blog includes videos of both systems being used to perform the test.

To examine interoperability, we tested the capabilities of the software by importing a CATIA part, modifying the imported part, and creating and validating the accuracy of a DWG drawing of the part for communication with vendors.

View of the bell housing used in this exercise

Autodesk provided a video of Inventor accomplishing this test, a DWG drawing of the bell housing, the bell housing in CATIA format and the bell housing in IGES format.

Key differences you will see in this test

Autodesk Inventor is able to import and export most common CAD formats as well as neutral formats. Working with imported data uses the direct modeling tools found in Inventor Fusion Technology Preview to make changes. Creating a fully associative drawing in DWG format requires no additional effort since Inventor uses native DWG as the file type for drawings created from the 3D model.

SolidWorks can also import and export from a variety of CAD formats but has no support for CATIA files, which must be translated into a neutral file format introducing opportunity for errors. It also has tools for modifying geometry with several functions like feature recognition and move face. Lastly, DWG drawings are not associative to the 3D model and may require a significant amount of time and effort to clean up translation errors prior to sending them to customers and vendors. In this test, the SolidWorks DWG associativity did not work, however, SolidWorks supported this capability in past releases. It did not work on TechniCom’s version of SW2011; it may work in other installations.

What’s Important in Interoperability

  • Directly reading the other systems data directly – in this case CATIA – rather than performing a multi-step and error prone process of intermediate data conversion.
  • Easily share design data with customers, vendors, suppliers, and other departments using different CAD systems.
  • Reading and writing native DWG files for production, and publishing designs in formats that customers can use in their own applications.

Observations

Importing CATIA Part

The desired result of this test was to import a CATIA V5 model into the software.

Autodesk Inventor read the CATIA data directly and was able to open the model with no issue.

SolidWorks was unable to read the model and requires a third party add-on at additional cost to import CATIA V5 models. To perform the later tests, an IGES format file was made available and was imported successfully. This is a major issue for automotive and aerospace suppliers and OEMs since there are many companies involved, many of which require data in native CATIA format! Oddly enough SolidWorks is owned by the same company as CATIA and yet cannot read the data directly.

Modifying Imported Geometry

This test examined the ability of each software system to make small modifications to the “dumb” solid created from the imported file.

Modifying the geometry in Inventor Fusion

Inventor made the necessary modifications using the free Inventor Fusion Technology Preview labs application. The changes were made successfully and then Change Manager was used to update the dumb solid in Inventor.

SolidWorks had no problem with the direct modification of the imported part. Feature recognition capabilities were used to modify the plates and the holes as required.

Modifying the geometry in SolidWorks

In this case it was easier than Inventor, which required back and forth interaction with Inventor Fusion.

Creating DWG Drawing

This test involved creating a drawing in DWG format, opening the DWG in a 2D viewer, and making a change to the 3D model and updating the DWG.

Measuring the resultant DWG created by Inventor

Measuring the resultant DWG created by SolidWorks

Note the incorrectly scaled dimension in the SolidWorks created drawing.

Inventor created the drawing in DWG format so no translation was required. The file was opened in AutoCAD and presented exactly as it was in Inventor. After making the change to the 3D model, the DWG version of the drawing updated automatically.

SolidWorks could create DWG files for export to vendors. It lacked the ability to be fully associative with the SolidWorks 3D model. Adding dimensions or taking measurements in the scaled view in the resulting DWG drawing were not scaled correctly with the view. In this case SolidWorks added a dimension that showed as 64mm instead of the correct 32mm.

See how the Inventor engineer performed the test: 

See how our SolidWorks engineer performed the test: 

—-

The next blog in this series will examine design automation and creating drawings from the resulting design. Stay tuned or sign up to be notified of my blog updates.

—-

TechniCom tests (Part 5) – Inventor’s digital prototyping vs. SolidWorks for Export to BIM

Exporting BIM Ready Models

Continuing on with part 5 of our 8 part blog series dedicated to showing the differences between Autodesk Inventor Professional 2011 and SolidWorks Premium 2011 for digital prototyping workflows, we examine the ability to export MCAD models to BIM. Not just the models, but models that contain smart information needed by BIM systems. Besides the images we have videos below of how our engineers used each system to perform the test objectives.

In this test, we started with a complex assembly that had already been designed in the mechanical system. The goal was to export a simplified version of the assembly for inclusion in Autodesk Revit software (BIM software). The software should allow the user to reduce the level of detail in the exported file to protect proprietary design information, to indicate to the BIM software the category (window, door, HVAC, etc.) of the exported data, to provide types and locations for plumbing and electrical connections, and to be able to control the orientation of the exported part or assembly.

View of the chiller unit used in this test

Autodesk provided a video of the chiller and the workflow performing the desired steps. Also provided was an IGES file of the chiller with all the model details.

The key differences you will see demonstrated below

Autodesk Inventor has a dedicated workflow that communicates a lightweight version of the geometry with critical information like connection points and component types while maintaining all physical and visual aspects of the design in a file format that can be easily handled by the most common BIM applications.

SolidWorks does not have a dedicated workflow. SolidWorks 2011 added the ability to exchange simplified geometry data, but with limited amounts of component information due to the use of a neutral file format. It was not able to provide connection points or carry physical and visual properties over to the BIM system.

What’s Important in exporting BIM Ready Models

  • Provide lightweight BIM-ready models which can be directly incorporated into the building design process
  • Mechanical models should include unique architectural and construction information

Observations

Model Preparation

The first step was to simplify the model by suppressing proprietary and unnecessary parts from the assembly and removing details such as small holes, grilles, etc. This eliminates exposing intellectual property and also reduces the level of detail, avoiding large file sizes.

Inventor was able to suppress all unnecessary components easily. A shrinkwrap feature simplified the assembly with native and non-native data by removing small features and patching small holes, reducing the file size.

SolidWorks was able to suppress unnecessary components without issue. Because this was imported data, SolidWorks was unable to further simplify the designs, although had it been native data it may have been possible. Readers should note that the Inventor data, however, was native and thus a somewhat unfair comparison.

Orientation for Import

The second step was to orient the part properly for use in BIM software. Ensuring that models come in with the correct orientation removes the frustrating process of reorienting every time the product is inserted into a design.

Inventor allows the user to create and assign a custom local coordinate system that can be specified on export thus eliminating this issue.

SolidWorks can create a custom user coordinate system (UCS), but cannot use it when exporting IFC files (a BIM standard file format). A new assembly needs to be created with the product placed in the correct orientation. This workaround requires additional time to create the new assembly and creates additional data to manage.

Define Connection Points

The third step was to define connection points to the assembly with sizing and connection attributes. Mechanical, electrical, and plumping (MEP) engineers need to know the location, size, and type of connections required for the product when designing piping or wiring for the building.

MEP connection definition in Inventor

Inventor allows the user to specify the location of connections along with information about pipe size, wiring, connection method, system type (i.e. hot water/cold water/120v/240v/etc.), and flow direction.

SolidWorks is unable to assign connection properties, instead requiring the data to be manually communicated, a minimally acceptable alternative.

Data Export

The final step was to export the assembly to a file format that can be read into BIM software with the necessary attributes assigned. Inventor exports file formats that can be directly read into Revit or AutoCAD and can be included in Building Information Models.

Inventor model of the Chiller as it looks in Revit

Component types assigned in Inventor were carried over so no additional categorization was required. Additional properties are carried over, such as weight, size, and appearance.

SolidWorks exports IFC 2×3 neutral format files that can also be directly read into Revit or AutoCAD. Component type can be assigned on export and are carried over into Revit. BIM designers are required to manually assign additional properties.

SolidWorks model of the Chiller as it looks in Revit

Videos of each system performing the test

Watch the video of Inventor performing this test:

Watch the video of SolidWorks performing this test:

—-

The next blog in this series will examine interoperability and direct modeling of an imported model, focusing on importing a CATIA model, modifying it, and creating drawings. Stay tuned or sign up to be notified of my blog updates.

—-

TechniCom detailed tests (Part 1) show why Inventor’s digital prototyping outshines SolidWorks

Executive Summary (Part 1 of an 8 part series)

Last Summer (August 2010) TechniCom Group published a report comparing Autodesk Inventor and Dassault Systemes SolidWorks using our Delphi Expert Analysis methodology[1]. The results of this report were somewhat controversial; Autodesk Inventor scored better in all fifteen categories than did SolidWorks, including core modeling. The scoring for the Delphi Expert report was the result of a very detailed survey of eight expert users of the two systems, four experts for each system. The experts had comparable familiarity with their systems and comparable backgrounds.

Readers of that report evidenced hunger for more detailed information, one that might be less sensitive to opinions and be more factual. As a result, TechniCom worked with Autodesk to develop a series of tests between the two systems that might expose the differences between the two systems and perhaps highlight advantages Inventor might have as compared to SolidWorks.

We are publishing the results of this series of tests in an eight part blog beginning with this summary of the results. Every two days or so we will add the details of each test, concluding the whole series within the next three to four weeks. Videos and images of both systems performing the tests will be included. At the end of this blog series we will publish a pdf version of the complete report on http://www.cad-portal.com.

A little background up front:

  • Autodesk commissioned (paid for) the tests.
  • Autodesk specified the tests which it challenged TechniCom, using SolidWorks Premium 2011, to match the results.
  • The seven tests are in the seven categories where TechniCom’s Delphi Expert report showed Autodesk Inventor rated the highest.
  • Extra cost third party software was not to be considered. When we were able, we used no-charge third party add-ins for SolidWorks — none were needed for Inventor.

Deciding what to test

First we had to decide what to test and the scope of the testing.

Followers of the mechanical CAD market are no doubt aware of the term Product Lifecycle Management, often designated as PLM. Autodesk’s mechanical philosophy is to eschew developing PLM software in favor of digital prototyping.

The term “Digital Prototyping” has led to some confusion in the industry. One clear definition comes from IDC in a paper entitled “Digital Prototyping: Autodesk Strengthens Competitiveness of Worldwide SMB Manufacturers’, published October 2008. This whitepaper differentiates digital prototyping from PLM by noting that “PLM reaches from a product’s cradle to its grave. On the other hand, digital prototyping stops at the completion of the digital product and its engineering bill of materials . . . The beauty of digital prototyping is that designs can be tested out before they go to manufacturing.”

Thus, Autodesk’s definition of digital prototyping includes the basic functions of PLM — industrial design, design and engineering, data vaulting, and collaboration, without the post-manufacturing baggage.

Autodesk has been carefully steering its Inventor software product development over the past few years to enable workflows that take maximum advantage of seamlessly passing data among its built-in application solutions. Thus, what we see in Inventor today is a careful melding of technologies that Autodesk has acquired or built. Many of these technologies are not available as extra cost add-ons to the base software, but fully included as part of the Inventor software. Some example, of which you will see more later, include mold analysis software, mold base design capabilities, built-in advanced simulation, inherent design automation options, an intelligent part library, built-in engineering calculations, and many others. Not only are these available as an integrated part of Autodesk Inventor, but they are often combined to form workflows that aid in developing the digital engineering models.

Thus, when deciding the scope of what to test, we settled on a series of tests that focus on the areas in our Delphi Expert analysis where Inventor rated the highest. These areas include the following:

  1. Plastic Part Design
  2. Plastic Injection Mold Design
  3. Assembly Design and Analysis
  4. Exporting BIM-ready Models
  5. Interoperability
  6. Design Automation
  7. Mechatronics

Even deciding on these seven areas leaves a great many options to be tested. Autodesk decided on the detailed functions to be tested; Autodesk specified the seven tests in detail. They are aimed at comparing the two systems ability to perform common, real-world engineering workflows. These tests are not designed to be impartial; they are taken from standard demos used by Autodesk that were designed to represent a series of engineering workflows highlighting Inventor’s digital prototyping capabilities. Most of them, as the users will see from the blogs that follow in the next few days, are aimed at performing a complete design sequence. The complete eight blogs, including this summary, will cover the seven workflow tests we performed. We will include the details of what we tested, images and videos of the results, what we observed comparing the two systems, and our summary of how well each system was able to perform the desired workflow.

Tests specified by Autodesk

Autodesk provided TechniCom with the test definitions including videos of Inventor performing the desired task, starter geometry, related dimensions, and other relevant data, all described below within each test section. TechniCom’s task was to perform the same tests using SolidWorks Premium 2011. Because Autodesk provided much of the model data we were able to focus on the desired workflow details of each test rather than building geometry.

Autodesk commissioned TechniCom to perform these tests and to document the results.

Our approach

TechniCom, in collaboration with a Certified SolidWorks Professional (CSWP) performed and analyzed these tests during November and December 2010 using Inventor Professional 2011 and SolidWorks Premium 2011. To make the scope reasonable, we limited each vendor’s software strictly to what was included with the package or third party add-ins that we were able to find and download free of charge.

For the test definitions, we used the Inventor videos illustrating the work to be performed. We attempted to deliver the same results, as did Inventor, using SolidWorks Premium 2011.

As we publish the results of the seven tests, we will make available annotated videos of both Inventor and SolidWorks performing the tests on TechniCom’s blog at http://www.raykurland.com. Readers wanting to understand how the two products compared have the unique ability to review these videos along with reading our test summaries in this report.

We remind the reader that we compared Inventor Professional 2011 versus SolidWorks Premium 2011 with the restriction that extra cost third party software was not to be considered. When we were able, we used no-charge third party add-ins for SolidWorks — none were needed for Inventor.

Summary of the test results

We plan to provide more detail, including videos of both systems performing the tests, in a series of blogs beginning in the next two days.

Plastic part to be designed

In the first two tests, plastic part design and injection mold design, Inventor clearly outclasses SolidWorks. Whereas Inventor completed all aspects of the test, SolidWorks was unable to complete major portions of the analysis of the part and the mold.

Mold design used

Inventor was also able to design the mold significantly faster than SolidWorks due to the inclusion of automated tools for designing the various subsystems of the mold.

For the assembly design and analysis test, both systems were able to model the addition of a clevis pin. However, Inventor excelled in its ability to design the correct pin by coupling its engineering calculation library to the potential design. In other words, Inventor helped select the correct pin size because it was able to use its calculations concerning the required stress that the pin would need to perform correctly. This is subtly different than SolidWorks, which used its library to size the pin, but without taking into account its stress requirements.

Final assembly showing clevis pin

The SolidWorks approach was to design the pin and then analyze it in an iterative fashion using its built-in FEA solution until the specifications were met. In this case SolidWorks was unable to verify that its built-in FEA solution was correct. A more advanced version of the FEA solver would have been required; concomitant with more advanced engineering skills.

Chiller exported to Autodesk Revit

The latest release of SolidWorks added some BIM exchange capabilities, but Inventor’s BIM data transfer capabilities exceeded SolidWorks in key areas important to building designers. These included specifying connection points and component types that are carried over to the BIM-designer’s software. In addition, the mechanical designer using SolidWorks had a more difficult time orientating the model and simplifying a non-native model for export.

Bell housing

Our test of CATIA interoperability and direct modeling on imported models reiterated the widely known issue that SolidWorks does not directly import a native CATIA V5 file, even though both products are part of the same company. Direct modeling was comparable for both Inventor and SolidWorks, with SolidWorks being a little easier to use for the simple direct model changes we made. The SolidWorks drawing output in DWG format produced an incorrect dimension in a scaled view.

Copies of frame along a path

For design automation, our tests revealed two weaknesses of SolidWorks. SolidWorks with DriveWorks Xpress was not able to automatically scale drawing views to fit a part within the confines of a drawing after the size of the part was changed. Manual intervention was necessary. A second weakness was shown when scaling a copied assembly using 3D curves to define key points as the assembly was copied and scaled to other planes. Inventor was easily able to scale a copied assembly using drive curves; SolidWorks could, but required significant manual effort.

Electrical schematic and assembly

Both systems proved to be comparable in mechatronics where we tested the ability to build wire harnesses using schematic input from electrical software packages, albeit Inventor was able to do so with many fewer interactions.

Conclusions

Ray Kurland, President of TechniCom, knew that the tests were meant to highlight Inventor strengths, but was surprised that SolidWorks Premium 2011 was, in many tests, not able to do the work without adding pricey third party software. Duplicating Inventor’s capability on these tests with third party products will also make SolidWorks substantially more expensive than Inventor.

These seven tests underscore our contention from our previous Delphi Expert Analysis, that Inventor is a mature system that can more than effectively compete with SolidWorks and should definitely be considered for even the most complex situations.

The Inventor workflows illustrated in this series of tests are integrated and highly logical, enabling users to accomplish their design goals with minimal effort. Beyond that, we hope to have shown the value of Autodesk’s digital prototyping emphasis, which we expect will continue to evolve even further.

“I didn’t know that Inventor had this much functionality,” said TechniCom Group’s associate performing the tests, a CSWP. “I know that they acquired a lot of technology over the past few years, but I am surprised to see it all integrated so well into Inventor.”

Overall, TechniCom is most impressed with Inventor and the direction Autodesk is taking for the future. To keep abreast with our continued tracking of the industry and our reactions to Autodesk’s direction we advise readers to follow our blog and twitter feeds.


[1] “Comparing the Capabilities of Autodesk Inventor Professional 2011 and SolidWorks Premium 2010 Using TechniCom’s Delphi Expert Technique”, 9 August 2010, a paper by TechniCom Group, available at http://www.cad–portal.com.

Aaron Kelly explains the business model for DraftSight

What a shocker! The premier 3D MCAD software organization, Dassault Systemes, announced a pure 2D drafting product with the business side based on an open source software model that provides free software. To find out more about the why’s and wherefore’s, Ray contacted Aaron Kelly, the head of this new business unit. My explanatory comments are within the brackets [] .

Aaron Kelly

What is your new position?

My new position is to lead the DraftSight business unit. I report into the DS SolidWorks Brand and am the General manager for this business unit. [Aaron was in SolidWorks product management for many years and has been with SolidWorks virtually since its inception – 15 years. He is a well respected SW executive.]

Where does the DraftSight organization fit within the DS and SW company structure? Is DraftSight a stand-alone company? How big is it? How is it organized?

The DraftSight organization has its own P&L and is made up of DS employees around the world. The team is made up of about 24 people in training, customer support, technical support, development, QA, marketing, product marketing, and sales.

What is the sales model, considering that the product is free?

The sales model involves selling value added services and/or products that are compelling for DraftSight users. DraftSight is free, but we are offering a service called DraftSight Premium Service. The DraftSight Premium Service includes a concurrent network license, access to the API extension (and updates) and Technical Support directly from DraftSight. This service is offered through all the Dassault Systemes direct and indirect channels. [It costs $250 per user per year]

Who are the target customers?

The primary target customers are existing DS customers who have a need to work with 2D and DWG files. This is a need, up until now, we have not had a solution for.

What is the cost/benefit to proposed customers?

We are trying to make is easier for our customers to invest in 3D and related technologies. By offering a low to no cost 2D offering, our customers can invest money allocated for 2D and use it to invest in 3D. The important thing we are trying to achieve is a superior user experience. It starts with an easy to download, free to activate product, shaped by a free, vibrant community, and is rounded out by professional technical support options.

Is the DraftSight product meant to completely replace 2D software from other competitors?

No, not really. Many of our customers today use DS products and our competitor’s [2D] products side by side. We are happy we are solving our customer’s needs where we can. We want the opportunity to either offer new 2D to 3D users who need it, expand the usage of 2D to those users who need it, but maybe cannot afford it, or replace competitor’s 2D software wherever a customer sees value.

How does DraftSight interface with other DS products? With non-DS products?

Many products from 3D CAD (SolidWorks and CATIA) to PLM products from DS read DWG files that DraftSight uses.

A focus on 2D is new for DS. Why now and what’s to come?

We are trying to solve customer problems. Customers certainly need to 2D functionality and DWG file capabilities. We are trying to help our customers. I think you are going to see many improvements in terms of social innovation tools – we are going to listen to our users with better community tools, we are going to build DraftSight based on user feedback. [Aaron went on to discuss that he plans to use crowd-sourcing from customers to vote on and thus select enhancements that they want.]

Where does the underlying technology come from? Is it Graebert? What is the impact of the Ares announcement on DraftSight?

We have a partnership with Graebert to use the ARES platform with DraftSight. We are in a very close partnership with Graebert and endorse their products for sale that have a different value proposition from DraftSight. For example, ARES Commander has a richer API and 3D as well as other features that DraftSight does not include.

What is the product future of DraftSight?

DraftSight is in Public Beta today. We will be shipping a released product in the coming months as well as a Beta version of a MAC release and a Linux release. Each DraftSight version was written specifically for the platform intended – either Windows, Mac or Linux.

If it’s free, how do you make money?

We make money by enabling our customers to invest in 3D as well as offering services around the free DraftSight product (DraftSight Premium Services). [The product, released on 22 June, about two months ago, has already had in excess of 40,000 downloads. Many fewer have signed service agreements.]

Why is this different than other free CAD products that have failed to be successful?

Customers are looking for more than free software. They want a real product with a future from a solid company, along with a long-term commitment, performance, multi-language offerings, and global support. We are offering this.

Is it open source? How do third party developers work with it?

Open source is not what our customers want. We do not offer an open source version at this time. [Rather, customers under the subscription plan have access to the API’s for adding software. In my opinion, this will slow down the development since all new code has to be done by DraftSight’s limited development team. On the other hand, this allows complete control over the software for quality and makes for a simpler development process for DraftSight.]

What are the support plans?

We have free community support for all users. Users have the ability to post questions to the entire community for feedback. We also have a support offering today that will enable a user to call, e-mail or even request remote access when applicable to help them out.

For more information about DraftSight go to www.draftsight.com .