[Guest Blogger] 40 Years in the Field (Part 6)
Graham Jones (Surrey, British Columbia, IT Pro) |
Part 6 sees me in an entirely new job in a new location; in many ways in a whole new “world”. I am now living in “bonny” Scotland having never been there before and experiencing what it is like to be a “Sassenach”. As one of my new neighbours said to me one day, “ you know, we really don’t like the English”. To which I said, “but I’m English!”. He then said, “oh, that’s right but you’re OK”. Mind you he got his licks in by playing his bagpipes in his back garden on occasion. Kicking the cat would have been more melodious!
As much as I had thoroughly enjoyed my time working in a research environment writing software and had learned a lot, my engineering instincts told me that I couldn’t really call myself an “engineer” without spending some time “at the sharp end of the business” where I could hone my “practical” skills, ie in the chemical production environment, in this case a Nylon Salt complex. Nylon Salt is used to produce Nylon 66. My first assignment was to work in process improvement, which basically means that you have to look for ways to improve production output and operating efficiency, ie. put more money on the bottom line. I didn’t start out thinking that computers would play a significant part in that but pretty soon I found them again :). My predecessors had used a common experimental approach, ie. change some operating parameter, measure what happens over a period of time and do some “significance” stats on the results (Design of Experiments). It had taken them several years to discover that a multi-million dollar chemical plant can generate “random” numbers quite well if it is poorly operated!
“There had to be a better way!”. My mathematical modeling skills from the past came in quite handy. However, that wasn’t going to bear fruit unless the plant was more stable in its operation. Most processes are unstable without the use of “control systems”. The most important “control system” is the process operator. So we are back to people again. The first challenge was to gain the confidence of the process operators and persuade them to operate the plant in a certain way. So where does the “mathematical modeling” come in? This permits you to experiment on a computer to try and determine strategies for getting to optimal efficiency rather than experiment on the plant itself.
In the time since I left my previous job things had moved along in the company’s computing infrastructure. Technical computing was now readily accepted and the company had the 16 bit DEC PDP 11’s for this purpose (eventually moving to DEC VAX 11/780’s [Virtual Address eXtension] by the early 80’s – wow, 32 bit addressing). They had also centralized most of the computing facilities in “huge” computing centres accessed using teletypes over phone lines, ie. effectively internal computer bureau’s. I set about writing a mathematical model of the reaction section of the plant (ie. where the product was made – for the chemically minded the reaction was the air oxidation of cyclohexane to form a mixture of cyclohexanone and cyclohexanol [colloquially called KA]) using good old BASIC (Beginners All Purpose Symbolic Instruction Code). BASIC was suitable for remote computing since it was an interpreted language and therefore could be interactive. Who could have guessed that BASIC would still be around today but is far from “basic” anymore.
As an aside, one day the whole computer system was down. Seemingly “someone” (probably a disgruntled ex-employee) had planted a time triggered “bomb” which wiped all of the mounted discs clean at a major computer centre and popped up the message, “take that!” on an operator console. Malicious individuals are not new and to this day people are still the biggest problem!
We also made some “stuff” that we didn’t want through over-oxidation (ie. loss of yield and therefore profit). So the objective was to minimize the bad “stuff” (my organic chemistry teacher from University would turn in his grave – teaching chemical engineers chemistry sadly tends to produce an early demise!) and maximize the good “stuff”. As luck would have it around the time that I arrived so did a Chemist who was to become my “partner in crime”. He developed some new ideas about the chemistry involved which I incorporated into the model. After some “calibration” the model reflected the current operation of the plant closely enough to be used for predictive purposes. It was soon clear that some fairly expensive physical modifications were needed to the plant to move towards optimization. The mods were eventually made and we waited with baited breath to see if my partner and I would be the “heroes” or the “villains”.
Thankfully, the “champagne corks” were popping. Overall it had been a 2 year project. The next thing I knew I was asked to take over the management of the plant and to continue the “fine tuning” of its operation. This was my first management experience but definitely not to be my last. The overall project, where the mathematical model had played a pivotal role, saved the company approx. $15 million dollars per year in today’s money. Shortly after I moved to the plant itself a government “edict” came down that a complete safety audit was to be performed. The principal motivator for this was the “Flixborough Disaster” where a similar plant had exploded and killed 28 people some years previously. This took me into the “world” of Reliability Engineering, which includes Fault Tree Analysis (FTA) and the probabilities of failure of equipment and people. A major chemical plant is very complex and is made up of thousands of items (eg. process equipment, measurement instruments, control devices, emergency shutdown systems, computer software [very common today], people [mustn’t forget the people!], etc.), each of which can fail in a number of different ways. FTA is all about describing the logic of how an assumed event (an explosion for example) might occur and calculating the probability of that event occurring. A very simple example might be “car fails to start”. This might be the result of a “dead” battery but there may be a number of different reasons why it fails to supply power when required (eg. age, lights left on, car alternator fault, etc.).
Having completed the “fault tree” analysis, which took approx. 12 months, it was necessary to perform a large number of calculations many times for different assumed probabilities. Computers are good at doing calculations quickly and repetitively. So a program to permit us to do the calcs was a logical choice. Today there are many sophisticated commercial packages with graphical interfaces and databases of published failure data, and covering a wide range of techniques, FTA being only one. The real point is that varying certain probablities may have no significant effect on the final answer whereas some will. The “problem” items need to be identified for further investigation and perhaps corrective action. Despite some public “opinion” process plants are designed to very rigorous standards and are extremely safe, safer than crossing a busy street believe it or not. The problem is that they are a little like plane crashes – when things go seriously wrong it can happen in a very big way and garner a lot of attention!
In part 7 I move to another plant and get to try my “modeling” skills again but in a new to me and very different way. I also have one of those rare “eureka” experiences.
Cheers
Graham J.