The engineering software space is crowded, particularly when it comes to design and documentation tools.
This is because the needs and preferences of engineers are highly variable. Even within one company, it’s common to have engineers working with different design tools at each step of the process. The situation becomes even more complex when you have engineers in different countries, working in different languages and in different engineering cultures.
The goal of this article is to help engineering managers navigate the maze. First, we take a high-level view of the main types of software engineers use to design products, plants, and processes. Then, we use the most common questions we hear from engineers to identify key functionalities. Finally, we propose a single software solution that supports engineers at all phases of the design process.
Types of engineering design and documentation software
Computer-aided design (CAD)
In many organizations, CAD is what gets the ball rolling. Engineers use CAD programs to create 2D and 3D drawings and diagrams, integrate different elements (e.g., mechanical and electrical) into a single design, collaborate with other teams, and more.
Your team probably uses some type of CAD software on a daily basis to create and optimize designs and to develop digital prototypes of projects.
Computer-aided engineering (CAE)
Since CAD and CAE software are often used in tandem, they are also often conflated.
But there’s a big difference in the purpose and the capabilities of the programs. CAE isn’t a design or documentation program — it’s a computational program. CAD designs your model. CAE tests your model. For example, CAE can run simulations on models created in CAD to test factors like fluid dynamics and interactions among components.
Traditionally, using CAD and CAE together requires exporting data out of the CAD software and then importing it into the CAE software. But, as we’ll see below, there’s another option that streamlines the process by doing away with imports/exports altogether.
Engineering document management (EDM)
CAD drawings, CAE analyses, images, spreadsheets, PDFs — an engineering project produces many types of documents. EDM software offers a way to organize and manage all of these documents in a centralized repository.
EDM systems help engineers solve common problems related to version control, collaboration, and more, while also making sure a paper trail is handy when audit time comes.
Product data management (PDM)
PDM software is a tool for managing multiple CAD models. It is a central hub that integrates information and provides a hierarchical structure across CAD documents. PDM is similar to EDM, but specific for CAD data.
Product lifecycle management (PLM)
PLM software is an information management system that consolidates data and documents across CAD, EDM, PDM, and more. It’s less engineering-centric, and instead provides knowledge that for stakeholders across an organization. For example, managers and executives can use the data in PLM software to gain insights that help them make data-driven decisions about product roadmaps.
In short, PLM creates an umbrella that covers everything else on this list as well as a host of other business functions.
A note about engineering software
The taxonomy above is one perspective on the relationship among different types of engineering design, documentation, and data management applications. There are as many different tools — and ways to use them — as there are engineering projects. For example, in addition to the general categories outlined above, many teams develop local tools to fit their specific needs.
The engineering software field is currently evolving, and what we’re seeing is tools that are much more powerful, much more flexible, and much more complex.
What to look for in engineering design and documentation management software
We talk with engineering managers and the engineers they work with every day. Though they ask different questions, the issues they’re dealing with are, at their core, the same.
Based on those conversations and the deep expertise of our in-house engineers, we’ve identified 10 primary concerns. Here’s an overview of the issues and a look at how the Engineering Base platform solves the problems your organization faces every day.
A data-first orientation
Often when we meet with prospects, the first question we hear is: “What type of documents can your software generate?”
This is no doubt an important question. Documents like P&IDs and electrical diagrams make up your main project deliverables. The software you work with needs to be able to produce all of the documents and reports you need to send to your clients.
But it’s also the wrong question.
In the past, engineering drawings and documents were the data — they needed to stand on their own. Today, those same drawings and documents are just representations of the data. Once you have the data, a robust software can generate any type of document you need, from diagrams to reports.
So, rather than asking what type of documents a software can produce, instead inquire about the database that sits behind those documents. How is data stored? How can it be used? These questions will get you much closer to the answers you’re looking for.
Facebook: A model of modern engineering software?
For many engineers and engineering organizations, the idea of a data-oriented approach is pretty novel. It represents a shift away from a system in which drawings and documents are the primary sources of data to a system where the data is the central asset.
As an example of what a database orientation looks like, we can look to the world’s most popular social network.
Just like engineers used to do their work on paper, we also used to take Polaroid pictures, write letters on stationery, and send party invitations in the mail. Today, we have Facebook.
Facebook currently has 1.23 billion users. But when we as individuals log into Facebook, we don’t see pictures and updates from 1.23 billion people. We see a view that is 100% customized to us. It features content from people and organizations that we like. It has timelines of our lives and relationships and picture montages of our friends. Even the ads we see are customized to our individual interests and behaviors.
And no two people’s experiences with Facebook are the same. While there is likely some overlap, what you see when you log in isn’t exactly what your friends and family see when they log in.
This is possible because Facebook is all about data.
Facebook is essentially a huge data repository (300 petabytes and counting). An object stored in the Facebook database is just an object. As such, it can be presented in many different ways depending on who’s looking.
This is essentially how data-oriented engineering software works. An object stored in an Engineering Base data repository is also just an object. It can be presented in any type of drawing, report, or document, to meet the needs of any engineer, manager, or executive. In this way, Engineering Base isn’t so much a documentation software as a data repository from which the documentation follows automatically.
Designing projects from scratch is a thing of the past. Today, most engineering projects follow typical-driven workflows, using predefined modules and templates.
The software you choose doesn’t need to have thousands of typicals. What it does need is a solid collection of basic typicals, as well as options and variance for each. With a well-stocked template library, you can design and complete a plant or process without having to reinvent any wheels.
Multi-user environment management
It’s common for many engineers to work in parallel. These engineers may be on different teams working on different aspects of a project. They may be in different timezones or different countries. They may even be working in different languages.
How can one piece of software handle all of the data and manage the workflows in this highly collaborative environment?
Currently, many engineering workflows require exporting data out of one tool so you can import it into another. For example, if you use traditional CAD and CAE software and want to test your models, you first need to export your data out of CAD and import it into CAE. You can run into problems — especially if your software doesn’t have robust version control — if someone else makes changes to the CAD model while you’re working in the CAE.
Another option is to have everyone working in the same database. This is how data-oriented tools like Engineering Base work. In these applications, the key to multi-user environments is how the data is handled via user permissions.
Engineering Base has a flexible multi-tier architecture that’s customizable depending on individual users’ needs. For example, the hierarchy of a three-tier architecture may look like this:
- Tier 1: The database. This is the centralized data repository where all project data is stored.
- Tier 2: The application level. This tier manages data traffic between the database and numerous end user applications.
- Tier 3: The user interface. This is where the design magic happens.
In this multi-tier architecture, clients don’t connect to the database directly, but rather via the application level. This architecture is infinitely flexible — you can modify it depending on your specific situation and give engineers access to different levels according to their needs.
With everyone working on the same database, conflicts can sometimes occur. For example, “What happens if an engineer in India adds a motor, and then another engineer in the United States deletes it?”
The real question here is how the system tracks changes. For the answer, let’s go back to Facebook.
In Facebook, you can adjust your account settings so that you see updates from some people and not others. You can even control how much content you see from each person, or block someone completely if you want to.
With a database program like Engineering Base, you can do pretty much the same thing. Each user can create their own view of the database so they can track just the changes they’re interested in. For example, an engineer could create a view to track the history of a collection of motors. By doing this, that engineer in India would know immediately that the engineer in the United States had deleted the motor.
Workflow management is another huge challenge for engineering organizations. This is similar to multi-user environment management.
With only 10 people on a project, workflows are not a problem. But what if you have 1000 people spread around the world? The engineers in the United States are going to sleep while those in Europe are just waking up. It’s may be a different day for one team than for another.
Today, it’s common to have engineers working 24/7 somewhere across the globe. You need tools that will help you define and optimize your workflows so you can execute on the project as quickly as possible. Again, a tool that doesn’t require imports and exports streamlines workflow management in a way that simply isn’t possible when you work with multiple systems.
A plant project can generate thousands of pages of PDFs. And, let’s face it, revisions are inevitable. What happens when the customer requests a change?
Change management is one of the most complex areas of engineering design. For example, in a 2012 study of the automotive industry by the Aberdeen Group, the top product development challenge was frequent engineering changes (ECOs and ECNs), cited by 40% of companies.
Even with thousands of pages of PDFs, engineers need to be able to jump directly to the change that’s relevant for them and see the before state, the now state, and any consequences of the change. This is only possible with a data-oriented tool — as soon as you make the change to the database, that change is immediately reflected in all documents and drawings down the line.
An engineering firm’s work doesn’t end when a plant is completed. In reality, the ribbon-cutting ceremony just signals a shift from the design phase to the maintenance phase (assuming construction happens in between).
Imagine that after a few years of plant operation, you want to change a motor. Now you face the same problem as before with all of those PDF documents, with the added complication of needing to retain the integrity of the as-built documentation.
Like with change management, a data repository makes quick work of the maintenance management process. It takes only a few seconds to change the attributes of an object (like a motor), and then all of the related documentation will update with the new information.
By adopting a data orientation, you can also move from taking a traditional approach to maintenance — which is both time-consuming and costly — to a predictive one.
For example, suppose you have a chemical plant equipped with sensors that stream data online in real time. If the reading on the vibration sensor starts to go up, the sensor sends you an alert. On examining the data, you decide that the motor will require maintenance in 6 or 12 months. You can start preparing to make the necessary repairs right now. This could head off a potentially critical situation. It can also save a lot of time and money on repair costs.
The previous items on this list focused on functions of the design and documentation software. The last four explore how engineers interact with the tool.
Ease of use
Like any tool, engineering software is only useful to the extent that it’s actually used. The best software is based on programs already familiar to engineers, such as Visio and Microsoft SQL.
Everything in Engineering Base, for example, is based on the look and feel of Microsoft. This makes the transition seamless as almost every engineer already knows how to work with Windows Explorer tree views and SQL. Engineering Base is essentially a combination of these tools with a database behind them. As such, the learning curve is practically nonexistent.
We’ve talked about engineers working on different teams, in different phases of a project, and even in different languages. What it all comes down to is that engineers — and engineering organizations — all have unique needs.
Customization for engineering software falls into two main categories:
- The user interface. User interface customization includes things like shapes, standards, and attribute names. For example, the following table shows some examples of items that need to be customized based on whether the engineers are in the United States or Europe.
|Standards||International Society for Automation (ISA)||European Committee for Standardization (CEN)|
|Temperature nomenclature||Temperature||Design temperature|
|Loops||Designed horizontally||Designed vertically|
- Functionalities. Depending on their knowledge and preferences, engineers require different functionalities. For example, how do you assign two wires to one motor — alphanumerically or on a drawing?
No two lists of engineering requirements are exactly the same. Make sure your software is fully customizable so that it can adapt to your preferences and processes.
Imports and exports
Not only do engineers work with different styles and different requirements, they also work with many different types of files. Your engineers may be dealing with files created internally or received from a client in formats including DWG/DXF, XLS, XML, and PDF.
Engineering Base supports you with the ability to import and export data into any of these formats. This provides your engineering team with the support they need, regardless of what format their data comes in.
Finally, as we mentioned above, engineering software doesn’t exist in a vacuum — it’s often used in conjunction with many other tools, both commercial and in-house.
Here are a few examples that require integration:
- One team uses Engineering Base while another uses AutoCAD.
- The organization wants to integrate the engineering software with a materials requirements planning (MRP) tool like SAP.
- A client requires deliverables in one specific format.
You can solve these integration challenges by selecting software programs that have an open API.
For example, Engineering Base features an open API, which allows you to integrate it with both upstream and downstream tools (e.g., PLM or ERP system), as long as they have an open API as well. That means that whether you use five pieces of software or 50, and whether they’re commercial packages, local applications, or legacy tools, all of your systems are on speaking terms.
The problems that engineers spend their day solving are complex. They require very high levels of communication and collaboration among people, teams, and departments. The tools you use need to support these communication and collaboration needs as well as help you increase efficiency by streamlining processes.