Profile

I am originally from Tipperary in Ireland, but have lived in the UK since I graduated over 10 years ago. I studied Physics and Instrumentation at University, that’s where I was introduced to control systems.

My favourite place to go hiking is Scotland, especially along the coast. My most impressive hikes were in Tanzania (reaching the summit of Mt. Kilimanjaro) and Japan (Mt. Fuji, a loop hike rather than a summit one).

I also enjoy photography (especially birds, I am a member of the RSPB) and crafts such as cross-stitch, knitting and I am currently trying to learn crochet.

I develop software for industrial control systems; this is where an industrial computer (known as a PLC or Programmable Logic Controller) monitors and controls machinery located around a site (This can be within a building or spread across multiple buildings or even sites) via a control room operated by the people who run the site.

My work centres around projects; each project is usually one control system and I have described an example of one below.

When a site has a new process they will send the details to a company like mine, who then respond with how long and how much it will take to complete the project. This is their bid (I am sometimes involved in this stage to check that what they are asking is physically possible).

If we win the bid, I am given the full design details with a list of hardware and have to decide how to make it all work in the best way possible. Where I have said, I, it is usually a team of people all working together. I also work closely with the customer, to ensure the design meets their safety requirements.

Documents will be developed which will detail what will be included and how I am going to do the control system, as well as raising any issues I have found e.g. they want an alarm for a water tank if  the water reaches a high level but haven’t included anything to measure it with. These documents are sent to the customer so they can read through them and make comments which are incorporated into the design. These changes are checked again before the customer gives us the go ahead to make the control system.

The control system itself will usually be made up of the following items; an industrial computer (PLC), a SCADA system (Supervisory Control and Data Acquisition system – this is the computer program that will be displayed to the operators in the control room, showing all the details), control stations (anything that can display the SCADA program e.g. computers, laptops or touchscreens), servers (which holds the SCADA system and all the information for the control stations) and some electrical cabinets. These are all interconnected using Ethernet or Fibre cables.

I am involved with programming the PLCs and SCADA systems, while one of my co-workers will handle setting up the servers and control stations.

To programme the PLCs and SCADA systems, I will follow the documents that were accepted by the customer. If I spot any issues during the development, I will raise it with the customer and make any approved changes as required.

The PLC will be used to talk with the machines and devices on site; receiving information and sending commands. Commands will be sent either automatically through the PLC program or if a command is received from the control stations via the SCADA system.

The SCADA system is used by the operators to monitor and control the machines and devices. It will also display the status of the control system; diagnostics to show if any hardware or device is not healthy, alarms and warning messages.

Once I am happy (I do have a timetable to work to but it can be flexible) that the PLCs and SCADA systems have been programmed fully, I will put the systems into test. To test the system, I use virtual versions of the machines and devices and a test specification.

I usually develop the virtual system (sometimes called a simulation) alongside the PLC code, this will mimic how the devices and machines respond to inputs and generate outputs.

A test specification is a big document which details how the system should behave.

The system will be tested atleast three times in my office; a shakedown test (making sure everything works overall), internal test (we will run through the test specification to ensure everything works as it should) and then an external test (where the customer runs through the test specification to ensure it works the way they want it). If there are any issues, these are documented and any changes approved. Once the system is updated, we test it again; first internally then with the customer.

Once the customer is happy, the system is deemed to be accepted and we can bring it to site. Where once it’s installed, it is tested again, this is called commissioning. First, inactive testing (where we use water instead of chemicals, or metal waste instead of radioactive waste) and then active testing (where the system is run using the chemicals and radioactive waste).

Once commissioning is finished, all the documentation is updated to match the final system.

Sometimes, for big projects the end customer can hire a separate company that manages the construction, build of hardware and software. They report back any issues to the end customer.

I am required to work 40 hours a week, which is 8 hours a day however we do have flexi-time. Which means I get to start and finish when I want, all I have to do is be around for the core hours 10am-3pm. I usually start earlier when I am in the office to avoid traffic and so I can have an early finish on Friday.

I start my day with an e-mail and meetings check. Not everyone works the same hours or even the same timezone so I usually have one or two waiting for me in the morning. If I have meetings, I will make sure I have everything ready for them rather then searching round five minutes before they start.

I usually work on two projects at a time, so I will have some form of software or documents to work on. I also check documents for other projects so if what I am working on is getting boring I can stop for a bit and do something different.

I prefer to work on documents in the morning, up until midday. Then I stop for my lunch, go for a walk to get away from my computer. Then in the afternoon, I will work on some software. I find the software a lot more interesting and can avoid that mid-afternoon slump.

My day will also be broken up with project meetings (usually one a day) and tea breaks where I can chat with my co-workers away from my desk.

I finish around 5pm depending on the amount of work that needs to be done for that day or week. If a deadline for issuing a document or software is coming, I will work later to get it done.