Death by TLA’s (Three Letter Acronyms)



Some BMA’s are being installed at one of factories, all part of the BIP. They’re being integrated via PLC to the DCS because the DCS can only support TCP. You not following? Think of TCP as the bridge between the I/O and the NIM. Unless you’re using FF then you’d use a FIM. Then your FIM is connected to your firewall, unless all your ports have been taken up by WDM’s or PCDI’s. Just think of the whole thing as a PCN, unless you’re on the old version then it’s called an OPC. Don’t worry if this looks complicated; the APM is a simple piece of software to take care of it all. Now, when you’re on the APM, make sure you specify you pick DACA from that drop-down menu when you configure the DD.Think yourself lucky: changing from TDC to PKS has really simplifed things.


Here, I have fitted in about half of the TLA’s (Three Letter Acronyms) and a few cheeky TLA’s (Two Letter Acronyms) mentioned in Wednesday’s meeting into a single paragraph. The beauty of acronyms is that a single one can have several different meanings.

For example: P  I  D

PID: Proportional, Integral, Derivative [control law]

P&ID: Piping and Instrumentation Diagrams

PID: Passenger Information Display

And these are just the PID’s that I have personally come across so far. I could go on to name the top results of my Google search such as Pelvic Inflammatory Disease but you get the point.


What I’m really trying to get at here is how difficult it is to follow conversations and learn when dozens of different acronyms are being thrown around. A handful will be commonly used in the control world: PLC (Programmable Logic Controller) and DCS (Distributed Control System) are two of the most common. The majority, however, will be specific to different products, companies, or industries. And with Engineering being a small fish in Google’s pond, it’s pot luck to whether a search will give you a meaning in the correct context.




So what needs to be done?

 We need to be aware how acronyms can form communication barriers. Many meetings will be attended by non-specialists whether that is an intern like myself; a different type of engineer used to a different working set of acronyms, or a representative from a different department such as Procurement or Sales.

Conversations can be difficult for non-specialists to follow at the best of times. Using a full name over an acronym can make the difference between knowing and not knowing what you don’t understand.

And if you don’t know what you don’t understand, without asking for the definition (which unfortunately doesn’t always happen for various reasons), the conversation might as well not have happened.


Engineering Tip #2 Challenge yourself, challenge your colleagues


Yesterday, I received the best piece of criticism someone has ever given me:

“I don’t think you are getting as much out of this project as you could be.”

Let’s add some context:

I started working on the project about two months ago, before that my whole 7 months of engineering experience was in an office based role. For the first month on the project, I was at site 1-2 days a week familiarising with the challenges and issues the project engineers were facing and the engineering process itself. There was a lot of information to take in.

It felt as if I were back doing work experience. Like a true intern, I started making tea and coffee for the rest of the team, not because I was asked, but because I knew it was the most useful thing I would contribute that day.

Gradually, I built the familiarity in order to take responsibility for some small but important tasks, but the learning process is ongoing and still a lot slower than I would like it to be.

And that is why the criticism is valuable for me.

The person who gave it is the project mechanical engineer. I can’t recite the exact words that followed word-for-word but here’s the gist:

1. If someone is explaining something and you don’t understand, don’t assume you’re the only person in the room who’s not following. Ask them to explain it again.

2. Don’t be afraid to ask for help. The worst that can happen is that they’re not in a position to help you right away, but they will find the time.

3. Don’t be afraid to challenge the way things are done, doing so won’t offend anyone

4. Challenge yourself to engage more with your colleagues

There is a fear that I have, that at this stage of the project I will ask a basic question and they may think/say ‘Shouldn’t she have understood this weeks ago?’ and think me incompetent.

But pretending you know something by not asking is even more dangerous.

The longer something is left not understood, the more embarrassing it is to ask someone later on down the line. One of the biggest frustrations I have at work is how difficult it is to find out something by searching the internet or the company intranet and drives. Often, asking someone is the only way.

So to all those starting out in the workplace, put yourself out there. Particularly if you’re introverted like me, going to someone and asking them to explain something or talk a bit about what they’re working on is a good way to break the ice and form a good working relationship.

Engineers are engineers because they like a challenge. Challenge yourself to harness the expertise of those around you to learn something quicker, and challenge your colleagues as well.

When you are new and inexperienced, it is easy to sit on the edge, but as my colleague rightfully says, you wouldn’t be getting as much out of it as you could be.

Project Engineering – it’s a love-hate relationship



About an hour ago (my clock reads 19:18), I got back from work. I’m too tired for my usual post-work gym session and grateful for the leftover casserole in the fridge that only needs 5 minutes in the microwave.

I am living the life of a project engineer. Despite the fact the novelty of travelling for my job has well and truly worn off, I rather like it.

Perception isn’t everything but it’s one department where most project engineers can’t complain. When people ask you what you do, the name of the large-scale, high-profile project just rolls off the tongue while trying not to look too smug. Explaining my asset management projects usually takes at least a couple of sentences. By the end, most people regret asking.

Two days a week, I put on my hardhat and make the one hour and twenty minute drive on single carriageways to our site which produces biofuel- I’m working on a project to expand that part of the factory.

As it is an expansion project, we can replicate designs of existing parts of the site, making the design process relatively straightforward. I am currently putting together specifications for the instruments (sensors, valves and actuators) so we can start the tender process (inviting companies to provide us with quotes- if more than one company can do that, then the company with the lowest price wins the contract). There are other engineers looking at how the pipes will connect to the existing process; determining locations of tanks, pipes and motors, and putting together technical drawings. The list of tasks goes on.

Project engineering suits generalists. Although the majority will have an area of expertise (mine is control & instrumentation), there is a greater necessity for engineers of different disciplines to work together at every stage. One of the biggest challenges engineers face is designing systems that are user-friendly and that takes collaboration. One example of bad communication between the civil and the instrumentation engineers is when you’ve got instruments connected to a vessel and the structure designed to give engineers access to the devices doesn’t allow access. Instead, when the sensor’s annual calibration is due, the maintenance team needs to spend time and money erecting scaffolding for a small routine task.

All in all, there are no shortage of headaches for the project engineers, and certainly no shortage of migraines for the project managers. There are several issues we face on a daily basis ranging from trying to keep up with what the rest of the team are doing, to discovering the drawings which form basis of your design are out of date. On top of that, most engineers and contractors are working on multiple projects in different areas of the country, meaning long commutes or hotel stays (another novelty which wears of quickly) are inevitable.

Yet everyone I meet on the projects, including myself, enjoys their job. I think it’s the sense of purpose combined with the satisfaction when every last obstacle has been overcome and the project has been completed. Construction won’t start for another six months at least, by which time I will be back at university. The sense of purpose is enough for me though.