Blog post about software for hardware engineering and how it needs to be more interoperable

Disclaimer. This is a shameless plug for a blog post I wrote

Hi all,

I know this community spends a lot of time talking about interoperability. And also all of the problems that come from everyone being locked into different CAD platforms that don’t work well together. An how that affects collaboration and our dreams of an internet of production.

Anneal is a new company setting up offering tools for hardware collaboration. Their still in startup phase so their product isn’t ready. But having chatted to the founders, they really seem like they are trying to build something great.

I have guest written a blog post for Anneal describing what I see as one of the biggest problems with engineering software. I tried for this post to separate out problems with the software landscape for hardware development in general, from my own opinions on Open Source.

Anyway, I hope it is interesting to some of you:

3 Likes

Great blog post. I thoroughly enjoyed reading it and have experienced the same frustration with the vertical integration of CAD software that prevents the ability of hardware developers easily using their own revision control and other features you have highlighted.

This stranglehold you describe has real consequences beyond messy file naming — often, a partial CAD description in one software must be re-implemented in another CAD software (i.e. Rhino → Solidworks) in order to make use of certain features that are discovered to be important to the project partway through. This can be laborious and time-consuming.

One opportunity I see is for an exchange format that encodes not the geometry, but the constructive sequence of operations that produced the geometry. Effectively the “history” or “timeline” of Solidworks or Fusion360… This is in effect isomorphic to Rhino-Grasshopper’s parametric visual networks, and Blender’s new(ish) Geometry Nodes.
One challenge / opportunity is that many CAD softwares use similar commands and specifications, which could be mapped to one another and thus rebuild the geometric specification across CAD vendors. A challenge is that different softwares often use different and incompatible mathematical descriptions (etc Boundary Representation, Mesh, NURBS, Sub-D, Solid Volumes, Signed Distance Functions…). These differing underlying descriptions may make it impossible to port geometric and to different “IDEs” so as to run different analyses (FEA, FEM, CFD) and further operations (CAM, Animations, Rendering)…

Do you have any ideas for a first foree into CAD interoperability that could be used? How could interchange formats like STEP be extended to be more useful to users while not moverpromising functionality that proprietary programs may or may not choose to support?

I see interoperability not starting at the CAD level. No player really has an incentive in the current market to add this. I do see external tools adding value. Tools for collaboration, versioning, testing etc. Tools where the prices scale organically rather than starting at $10k per head. If these tools succeed and support projects using multiple CAD packages then that might start to increase the incentives of the CAD packages to collaborate.

The worry, as always in the tech world, is that any new player that gets a big enough market share will just be bought up by one of the big corporations. Hopefully the winds are starting to change here as the power of big tech giants is becoming all too clear.