Hi all, I'm a CS student researching how engineers handle specs and drawings during the design phase of a project. I did an internship at a ship design firm and noticed a lot of manual fetching of data from the relevant documents. Another EE friend of mine mentioned the same thing when creating SLDs.

So, I'm trying to understand how common that is. Is this manual cross-referencing between specs, datasheets, and drawings more of a daily occurrence? Does it get annoying, and do you have any tools or scripts that help with this searching (apart from Ctrl+F and BlueBeam)?

I'm genuinely just trying to understand the real workflow pain here. I don't have anything to sell, so I'd appreciate any insights!

 

AI has entered the picture now.

 

AI has entered the picture now.

I mean, with Autodesk (which holds about 40% of the market) exploring how to integrate AI into its workflow, why don't we, as independent creators, focus on grabbing our own piece of the pie right now and try to break the monopoly?

 

good luck... there is a reason some products or companies dominate market.

 

good luck... there is a reason some products or companies dominate market.

I believe one of the main reasons for their dominance is that those companies were early adopters in a new field, pushing through the initial reluctance from the market.

I love your signature btw.

 

Is this manual cross-referencing between specs, datasheets, and drawings more of a daily occurrence?

Depends on what you mean by that.

Say I am working on a new circuit using a couple of new parts, which are not in the library for my EE CAD software. I will have to create the symbols and footprints for these parts. That will require going back and forth between the data sheet and the CAD program. Is that what you mean by cross referencing?

Of course this is not necessary for common parts. I would attack a schematic with passive parts, opamps, transistors, diodes etc, without ever looking at a datasheet.

So, no, It would not be close to a daily activity, even if my only task was drawing schematics and designing boards.

Hope that helps.

 

So, I'm trying to understand how common that is. Is this manual cross-referencing between specs, datasheets, and drawings more of a daily occurrence? Does it get annoying, and do you have any tools or scripts that help with this searching (apart from Ctrl+F and BlueBeam)?

It depends heavily on the specific project. Complex projects that have a lot of interacting elements will tend to require more of this than simple, standalone projects.

 

Depends on what you mean by that.

Say I am working on a new circuit using a couple of new parts, which are not in the library for my EE CAD software. I will have to create the symbols and footprints for these parts. That will require going back and forth between the data sheet and the CAD program. Is that what you mean by cross referencing?

Of course this is not necessary for common parts. I would attack a schematic with passive parts, opamps, transistors, diodes etc, without ever looking at a datasheet.

So, no, It would not be close to a daily activity, even if my only task was drawing schematics and designing boards.

Hope that helps.

That's really helpful, thanks!

Yeah, I was referring to the back and forth between data sheets and CAD or other documentation. Seems like for you, it's only when adding new parts, not during regular board design, right?

 

It depends heavily on the specific project. Complex projects that have a lot of interacting elements will tend to require more of this than simple, standalone projects.

So when you're doing this cross-referencing for complex projects, what usually takes the most time, tracking changes, verifying values, or something else? And is it usually the Design Engineer or Checker who spends the most time doing this?

 

So when you're doing this cross-referencing for complex projects, what usually takes the most time, tracking changes, verifying values, or something else? And is it usually the Design Engineer or Checker who spends the most time doing this?

Again, it's going to really depend on the project. When I was designing full-custom mixed-signal ASICs, on some projects I kept a printout of the specs next to my keyboard because it seemed like everything I did to address one design goal impacted performance against other requirements significantly. At the other extreme were projects that were so loosely defined (usually because they were an initial proof-of-concept design for some lunatic fringe system) that the design was guided by what we were coming up with on the fly and not the specs documents. But, on most projects, after the initial review of the specs I was able to look at them mostly when I shifted focus from one performance goal to the next because I was able to chart an initial path that made it unlikely that later work would upset prior work. Of course, I had to verify that this was actually the case as I progressed, and again, how frequently I did that depended on the specifics of that project. On some, I checked it each time I moved from one aspect to the next, since there was both a greater likelihood of unexpected interaction and also because it would be increasingly more difficult to backtrack and address any issues that came up. On others, the likelihood was sufficiently low and my confidence in being able to handle any issues sufficiently strong that I only did the verifications leading up to the major design reviews.

It also depended on what phase of the design we were working on. When doing the initial design and simulations, we referenced the customer's specifications but seldom looked at the documents for the process. But, for some designs, a lot of time was spent looking at the process documents in detail because the performance of the chip was going to be very sensitive to some aspects, particularly matching parameters. But when we got to the layout portion of the design, we almost never looked at the customers specs but frequently referred to the process design rule docs. On some, it was sufficient to just have a little summary, sometimes hand-written, of the key rules. On others, the design rules were always open and probably referred to several times an hour.

At the end of the day, you've got to do what you've got to do to get the job done.

 

When designing industrial control systems quite a few of the products used in a project are the same. So one knows the capabilities of components.
In addition, quite a few companies have lists of components that they want to be utilized. so that reduces the searching a whole lot. Likewise for switches and buttons and indicators. And a lot of other pieces.
One important difference is that with industrial systems the primary target is maximum uptime, rather than minimum cost. So while cost is minimized, it is never the main parameter. The product needs to run perfectly until it becomes obsolete. OR the requirements change. That is vastly different from designing consumer products.

 

It depends on what you mean by cross referencing.

If a component is already in a database, one has to put some trust in the accuracy of the database. It could happen that the mechanical data is incorrect or a wrong variant was selected.

MCU and software development is a different fish. It is not unusual to have to read datasheets multiple times in order to get a full understanding on how to use a device correctly.

 

Again, it's going to really depend on the project. When I was designing full-custom mixed-signal ASICs, on some projects I kept a printout of the specs next to my keyboard because it seemed like everything I did to address one design goal impacted performance against other requirements significantly. At the other extreme were projects that were so loosely defined (usually because they were an initial proof-of-concept design for some lunatic fringe system) that the design was guided by what we were coming up with on the fly and not the specs documents. But, on most projects, after the initial review of the specs I was able to look at them mostly when I shifted focus from one performance goal to the next because I was able to chart an initial path that made it unlikely that later work would upset prior work. Of course, I had to verify that this was actually the case as I progressed, and again, how frequently I did that depended on the specifics of that project. On some, I checked it each time I moved from one aspect to the next, since there was both a greater likelihood of unexpected interaction and also because it would be increasingly more difficult to backtrack and address any issues that came up. On others, the likelihood was sufficiently low and my confidence in being able to handle any issues sufficiently strong that I only did the verifications leading up to the major design reviews.

It also depended on what phase of the design we were working on. When doing the initial design and simulations, we referenced the customer's specifications but seldom looked at the documents for the process. But, for some designs, a lot of time was spent looking at the process documents in detail because the performance of the chip was going to be very sensitive to some aspects, particularly matching parameters. But when we got to the layout portion of the design, we almost never looked at the customers specs but frequently referred to the process design rule docs. On some, it was sufficient to just have a little summary, sometimes hand-written, of the key rules. On others, the design rules were always open and probably referred to several times an hour.

At the end of the day, you've got to do what you've got to do to get the job done.

Thanks a lot for the detailed breakdown. I appreciate it a lot!

When designing industrial control systems quite a few of the products used in a project are the same. So one knows the capabilities of components.
In addition, quite a few companies have lists of components that they want to be utilized. so that reduces the searching a whole lot. Likewise for switches and buttons and indicators. And a lot of other pieces.
One important difference is that with industrial systems the primary target is maximum uptime, rather than minimum cost. So while cost is minimized, it is never the main parameter. The product needs to run perfectly until it becomes obsolete. OR the requirements change. That is vastly different from designing consumer products.

Yeah, I see how standard parts would save a lot of time and headache.

It depends on what you mean by cross referencing.

If a component is already in a database, one has to put some trust in the accuracy of the database. It could happen that the mechanical data is incorrect or a wrong variant was selected.

MCU and software development is a different fish. It is not unusual to have to read datasheets multiple times in order to get a full understanding on how to use a device correctly.

My terminology might be a bit confusing here. I’ve seen this more on the ship design and electrical substation side. For those kinds of projects, especially upgrade or retrofit ones, it can take days just to figure out what’s affected and what needs to be updated, based on the requirements/specifications from the client. There are tons of different documents to cross-check to make sure everything still meets the specs and compliance requirements. I guess the requirements there are a bit more unique than electronics.

--

Thanks for the clarifications everyone. This has been super helpful! It sounds like cross-referencing isn’t as big of an issue in electronics design compared to larger electrical or mechanical projects.

 

Designing a new system is a bit like servicing an older system , in that it is important to understand what the system will be doing. Sometimes others do not really believe that, but it is true. Never assume or guess! Yes, that is a bit off-topic, except that being wrong can lead to a big waste of time.

 

Here is a grandiose generalization:

The hardest part of any project is not the answer, it's the question.

Back in my MIL projects days, it was common for us to work with a customer for weeks (and in one case, months) to get their spec into a good enough shape to quote. In round numbers, every day we took working on the spec saved multiple days or weeks in problems and re-works down the road. I approached a new spec as a negative treasure hunt - somewhere in there, buried in the middle of all of those things that would be easy or hard to do, was one sentence that was going to cost us buckets of money if we missed it. Check, cross-check, repeat.

ak

 

AK is certainly correct, although understating it a bit. Creating the exact description of capabilities of a machine, both included and omitted, without giving away details that help the competition, was always the goal. That lead to a good number of great machines, and happy clients, as well.
THAT portion of design engineering often did take a bit of time. Describing correctly what the process would do, in adequate detail, without telling HOW it would do it, except for how accurately, was the challenge.

 

Here is a grandiose generalization:

The hardest part of any project is not the answer, it's the question.

Back in my MIL projects days, it was common for us to work with a customer for weeks (and in one case, months) to get their spec into a good enough shape to quote. In round numbers, every day we took working on the spec saved multiple days or weeks in problems and re-works down the road. I approached a new spec as a negative treasure hunt - somewhere in there, buried in the middle of all of those things that would be easy or hard to do, was one sentence that was going to cost us buckets of money if we missed it. Check, cross-check, repeat.

ak

That's exactly what my EE friend implied. Honestly, the initial planning part applies to my field too; however, I work directly with customers too, and my usual projects aren't that huge, so I don't have to go back and forth a lot except for the initial planning phase. However, the designers in my company did that; they would spend 15+ minutes looking for a single part number in a 300+ page legacy PDF until I automated it for them.

Let me put it this way. Say you're working on one of your regular projects, do you think you'll save any time from a document management system that lets you search for information across all of your documents for a project, regardless of whether the information is in a Table, PDF, image, etc? And I'm not talking about the feasibility of it yet.

 

Does it get annoying, and do you have any tools or scripts that help with this searching (apart from Ctrl+F and BlueBeam)?

not annoying... of course i have things that help me. without them my productivity would suffer and i would not have time to relax.

However, the designers in my company did that; they would spend 15+ minutes looking for a single part number in a 300+ page legacy PDF until I automated it for them.

Let me put it this way. Say you're working on one of your regular projects, do you think you'll save any time from a document management system that lets you search for information across all of your documents for a project, regardless of whether the information is in a Table, PDF, image, etc?

that is what i do right now (and did for long time).

300+ pages PDF file must be a joke. depending on what i am working on, my simple everyday single search goes across many such files, on occasion tens of thousands of such files.

any computer literate person will be aware of basic tools like
Everything - for finding files by (partial) name
Agent Ransack - for searching inside group of files or folders (grep for windows)
etc.

to stay ahead i also have tools and resources that go beyond that and - not just search...
finding things quickly is important, but let's face it, finding info is only a part of a job.

 

Let me put it this way. Say you're working on one of your regular projects, do you think you'll save any time from a document management system that lets you search for information across all of your documents for a project, regardless of whether the information is in a Table, PDF, image, etc? And I'm not talking about the feasibility of it yet.

I agree with most of my colleagues here, in that most of us already have some form of such a facility already; it would be impossible to function efficiently otherwise. Previously, working as a design authority in a major systems integrator, I've been in a situation where the end client subcontracted different parts of the system, down to PCB level, to different suppliers, allegedly so that no one supplier had visibility of the whole (other than yours truly!) but I had the problem of dealing with massive disparities between different suppliers take on document management and level of detail in their deliverables.

Now, working as an independent advising a few aspiring start-ups on their product design and documentation processes, as well as doing some of the design work, the basis of the documentation system is a GIT repo containing versioned copies of everything, even down to the datasheet for the lowliest resistor, as well as OCR'd text from images, often translated from Chinese/Japanese, recorded Teams meetings and transcribed audio so thoughts and decisions are captured and documented. And everything can be readily searched with common tools. What I want to try, when time permits (which maybe never at the moment!), is to use AI to trawl this repo to see if we can link, e.g. a high-level design decision with its consequences, e.g. specific choice of a component or a topology.

 

I agree with most of my colleagues here, in that most of us already have some form of such a facility already; it would be impossible to function efficiently otherwise. Previously, working as a design authority in a major systems integrator, I've been in a situation where the end client subcontracted different parts of the system, down to PCB level, to different suppliers, allegedly so that no one supplier had visibility of the whole (other than yours truly!) but I had the problem of dealing with massive disparities between different suppliers take on document management and level of detail in their deliverables.

Now, working as an independent advising a few aspiring start-ups on their product design and documentation processes, as well as doing some of the design work, the basis of the documentation system is a GIT repo containing versioned copies of everything, even down to the datasheet for the lowliest resistor, as well as OCR'd text from images, often translated from Chinese/Japanese, recorded Teams meetings and transcribed audio so thoughts and decisions are captured and documented. And everything can be readily searched with common tools. What I want to try, when time permits (which maybe never at the moment!), is to use AI to trawl this repo to see if we can link, e.g. a high-level design decision with its consequences, e.g. specific choice of a component or a topology.

That's a nice setup. The AI idea that you mentioned is somewhat similar to what I had in mind, although more generalized (and confused) because again I'm not an engineer and my experience is mostly limited to mid-sized mechanical design firms. My idea was to create a dynamic link between specific clauses or requirements in specifications to the related content across datasheets, drawings, etc. It's definitely a huge project, but worth looking into if there's a need, which is what I'm trying to figure out.

300+ pages PDF file must be a joke.

That's just the floor for one of the many PDFs. However, even a single 300-page PDF was no joke in our case, since off-the-shelf OCRs did not work due to handwritten tag numbers and tables. Basically had to fine-tune a handwritten DL OCR model to get something usable.