.png)
Within the overall software for hardware product development ecosystem, CAD software is the belle of the ball. Mechanical and electrical design engineers spend the vast majority of their time in CAD by creating or updating geometries, mates, associations, metadata, etc. However, updated geometries could mean re-running simulations in other FEA software, triggering other redesigns back in CAD. These redesigns ultimately need to be checked-in to PDM systems for broader team visibility. The designs may then go through approval and release processes in PLM systems. BOMs need to be created from any of these systems. The software stack for just the core design aspect of an engineer’s role can encompass a variety of systems, prompting many design engineers to ask for native CAD add-ins from all the other software systems in their stack.
The larger players in the industry like Dassault Systemes, Siemens, PTC, and Autodesk with their broad portfolio of these simulation, PDM, or PLM systems have developed add-ins for their respective CAD products as a medium to perform these downstream workflows. Newer players in the industry who are cloud-native have also developed these add-ins for major CAD products. However, CAD systems were purpose built for CAD and not as a platform, leading engineers to face two common issues: performance and workflows.
The number one frustration of these add-ins within the CAD system is the degraded performance after add-ins are installed and activated. Many users have noted CAD crashes, even for those with engineering grade computers with 30+Gb of RAM. Simply booting up CAD applications can take minutes.
Unsaved work - whether any redesigns, or whatever activity was occurring in the add-in will get lost, sometimes causing engineers to spend hours re-doing prior work. These interruptions to the day-to-day can be tedious, especially if they occur frequently.
As a result, engineers manage their add-ins by activating/deactivating to increase CAD application performance. If add-ins are deactivated to manage performance, workflows/integrations with other systems may halt. In those cases, the updated information from other systems that needs to appear in the add-in will not update till the user reactivates the add-in. This can also be an issue, if that particular add-in is being used for design input.
Stemming from what CAD applications were designed to do vs other systems - most add-ins contain limited functionality in comparison to their respective software products. Developers of these add-ins are constrained by the architecture of CAD applications, meaning engineers still have to navigate to other software products (whether another installed application or to the web) at some point in their workflows. Further, when engineers make updates within those other systems - those same updates are slow to appear in the CAD add-in, leading users to keep using the other system concurrently anyway just to have the latest information.
As CAD is the primary system engineers spend most of their time in, it is a natural ask from engineers to use the core CAD application as the focal point for downstream systems. However, by trying to consolidate overall hardware workflows in systems that are not designed for that - more issues are caused than solved. For many teams, the ROI of some add-ins is not justified due to the limited value the add-ins provide compared to the CAD application performance degradation.
Overall, as the industry matures and more engineering teams adopt cloud-native tools, hardware engineering workflows will be more API and integration driven across a variety of purpose built systems. While most teams will prefer for CAD systems to be locally installed applications vs cloud-native, most other software systems in team’s stack can be cloud-native. In these cases, PDM/PLM systems like Bild that are the sources of truth (and if cloud-native) can serve as air traffic controllers for downstream applications and integrations.