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.

—-