The goal moving forward is to squeeze as much profit out of the plant floor as possible. To do that, it will mean change and that will necessitate converging plant floor technologies and know how with IT’s expertise.
“A tough environment like this is where leaders separate from the pack,” said Keith Nosbusch, chairman and chief executive of Rockwell Automation, during his keynote address Wednesday at Automation Fair.
Rockwell’s message during this year’s Fair is all about convergence. The company feels if the plant floor and the IT department unite into a team, there will be far greater overall advantages.
“We do have an opportunity during this downside to be leaders of the pack,” said Paul McNab, vice president of enterprise and mid-market solutions marketing at Cisco, during his portion of the keynote. “Information has changed from just data to data, voice and video. This is an opportunity to not only analyze the data, but to put it in context.”
McNab went on to say the PDA, his information vehicle of choice, can do just about anything he needs to get his job done. The technology loaded onto the PDA is able to put everything in context, he said.
That is change that manufacturing can adopt, he added.
“We are going through massive unprecedented change, with regulations, globalization and virtualization. The big issue ends up being what is the threat and what is the opportunity?
He went on to say, the combining of the plant floor and IT is going to happen whether people like it or not, so it might be wise to embrace it.
“It is your choice, you can be the disrupted or the disruptor.”
Archive for January, 2009
Rockwell Automation
Sunday, January 25th, 2009Think ahead: Build a system on security
Sunday, January 25th, 2009Manufacturing is always looking to squeeze as much out of the process as possible. Increased productivity and lower productions costs means a hike in profitability, which is what it is all about.
But if someone can hack into your system, just how much profit do you think you will make? The answer to that question is simple. None. Manufacturers have systems and then they think about adding in some security.
That is where manufacturers have to start thinking a bit differently. The foundation for their systems has to be secure. Security can not be an after thought; in these cyber-focused days, it needs to be the first thing a manufacturer has to think about before putting together their systems.
“It is amazing how fragile we are underneath,” Green Hills Software Director of Networking Solutions Sue Hares said today at the Green Hills Software Technology Summit 2008 in Santa Barbara, Calif. “We have to include security from the ground up. Operating systems are vulnerable and firewalls do not solve the problem. You need to change the paradigm.”
How hostile is the world today? She asked. Over 150 million records were breached over the past three years, she said. “Cyber crime is becoming a for hire business that is as easy as point, click and hack.”
Sometimes to ensure a different outcome true leaders have to look outside their cozy safe comfort zone.
“Change will not come from within the industry,” said Dan Perrier, president of Automated Control systems Inc., a Vancouver, Wash.-based system integrator that focuses on the power industry. “Sometimes we have to model other industries. To force change in your industry, sometimes you have to look outside your industry.”
Rest assured though, change has to occur.
“Everything we have is based on computer systems and basically they are not secure,” said Dan O’Dowd, founder and chief executive at Green Hills Software. “They are in charge of everything in our lives and they are not secure. They are in charge of our money, our privacy, our democracy and our lives.”
Instead of building a system and then checking it for security, they should start with security then build the system, said Jimmy Sorrells, vice president of enterprise products at Integrity Global Security a subsidiary of Green Hills Software. Instead of building a system focused on functionality, performance and then adding in security, Sorrells said security first. A system should start with security then add in functionality and then performance. This way you have a solid base to add a secure future.
“Security is backwards; it is broken,” Sorrells said. “Security is the first thing you should do. You get security by building security.”
While it is easy to feel everyone is out to get you and you should fear everything, but it is not all doom and gloom for O’Dowd. “In 10 years we can have a safe infrastructure that we can bet our lives on everyday.”
Emerson deals for Calif. integrator
Sunday, January 25th, 2009As integration becomes more of a key element throughout the industry, Emerson today acquired Napa, Calif.-based Bay-Tec Engineering.
Bay-Tec Engineering is a process control system engineering and industrial technical services company focused on project management, engineering and design (including cGMP processes), system integration, panel fabrication, installation and commissioning, calibration, and system validation. Terms of the deal were not immediately available.
“The acquisition expands our ability to address industry needs for automation engineering and project management solutions, particularly on the U.S. West Coast,” said Steve Sonnenberg, president, Emerson Process Management.
“Emerson’s global reach and technological leadership will help us to better serve our valued existing clients, as well as new ones,” said John Justus, president of Bay-Tec. “Our organizations are well aligned in terms of our strong focus on meeting client automation needs.”
GETTING INTO PRODUCTION
Friday, January 23rd, 2009This is an excerpt from Henry Ford’s Autobiography called “My Life & Work”. It is very relevant to modern manufacturing methods and automation.
CHAPTER V: GETTING INTO PRODUCTION
A Ford car contains about five thousand parts–that is counting screws, nuts, and all. Some of the parts are fairly bulky and others are almost the size of watch parts. In our first assembling we simply started to put a car together at a spot on the floor and workmen brought to it the parts as they were needed in exactly the same way that one builds a house. When we started to make parts it was natural to create a single department of the factory to make that part, but usually one workman performed all of the operations necessary on a small part. The rapid press of production made it necessary to devise plans of production that would avoid having the workers falling over one another. The undirected worker spends more of his time walking about for materials and tools than he does in working; he gets small pay because pedestrianism is not a highly paid line.
The first step forward in assembly came when we began taking the work to the men instead of the men to the work. We now have two general principles in all operations–that a man shall never have to take more than one step, if possibly it can be avoided, and that no man need ever stoop over.
The principles of assembly are these:
(1) Place the tools and the men in the sequence of the operation so that each component part shall travel the least possible distance while in the process of finishing.
(2) Use work slides or some other form of carrier so that when a workman completes his operation, he drops the part always in the same place–which place must always be the most convenient place to his hand–and if possible have gravity carry the part to the next workman for his operation.
(3) Use sliding assembling lines by which the parts to be assembled are delivered at convenient distances.
The net result of the application of these principles is the reduction of the necessity for thought on the part of the worker and the reduction of his movements to a minimum. He does as nearly as possible only one thing with only one movement. The assembling of the chassis is, from the point of view of the non-mechanical mind, our most interesting and perhaps best known operation, and at one time it was an exceedingly important operation. We now ship out the parts for assembly at the point of distribution.
Along about April 1, 1913, we first tried the experiment of an assembly line. We tried it on assembling the flywheel magneto. We try everything in a little way first–we will rip out anything once we discover a better way, but we have to know absolutely that the new way is going to be better than the old before we do anything drastic.
I believe that this was the first moving line ever installed. The idea came in a general way from the overhead trolley that the Chicago packers use in dressing beef. We had previously assembled the fly-wheel magneto in the usual method. With one workman doing a complete job he could turn out from thirty-five to forty pieces in a nine-hour day, or about twenty minutes to an assembly. What he did alone was then spread into twenty-nine operations; that cut down the assembly time to thirteen minutes, ten seconds. Then we raised the height of the line eight inches–this was in 1914–and cut the time to seven minutes. Further experimenting with the speed that the work should move at cut the time down to five minutes. In short, the result is this: by the aid of scientific study one man is now able to do somewhat more than four did only a comparatively few years ago. That line established the efficiency of the method and we now use it everywhere.
The assembling of the motor, formerly done by one man, is now divided into eighty-four operations–those men do the work that three times their number formerly did. In a short time we tried out the plan on the chassis.
About the best we had done in stationary chassis assembling was an average of twelve hours and twenty-eight minutes per chassis. We tried the experiment of drawing the chassis with a rope and windlass down a line two hundred fifty feet long. Six assemblers traveled with the chassis and picked up the parts from piles placed along the line. This rough experiment reduced the time to five hours fifty minutes per chassis. In the early part of 1914 we elevated the assembly line. We had adopted the policy of “man-high” work; we had one line twenty-six and three quarter inches and another twenty-four and one half inches from the floor–to suit squads of different heights. The waist-high arrangement and a further subdivision of work so that each man had fewer movements cut down the labour time per chassis to one hour thirty-three minutes. Only the chassis was then assembled in the line. The body was placed on in “John R.
Street”–the famous street that runs through our Highland Park factories. Now the line assembles the whole car.
It must not be imagined, however, that all this worked out as quickly as it sounds. The speed of the moving work had to be carefully tried out; in the fly-wheel magneto we first had a speed of sixty inches per minute. That was too fast. Then we tried eighteen inches per minute. That was too slow. Finally we settled on forty-four inches per minute. The idea is that a man must not be hurried in his work–he must have every second necessary but not a single unnecessary second. We have worked out speeds for each assembly, for the success of the chassis assembly caused us gradually to overhaul our entire method of manufacturing and to put all assembling in mechanically driven lines. The chassis assembling line, for instance, goes at a pace of six feet per minute; the front axle assembly line goes at one hundred eighty-nine inches per minute. In the chassis assembling are forty-five separate operations or stations.
The first men fasten four mud-guard brackets to the chassis frame; the motor arrives on the tenth operation and so on in detail. Some men do only one or two small operations, others do more. The man who places a part does not fasten it–the part may not be fully in place until after several operations later. The man who puts in a bolt does not put on the nut; the man who puts on the nut does not tighten it. On operation number thirty-four the budding motor gets its gasoline; it has previously received lubrication; on operation number forty-four the radiator is filled with water, and on operation number forty-five the car drives out onto John R. Street.
PLC Machine Control
Sunday, January 18th, 2009Industrial Training Video – AB PLC Cables – Drivers
Sunday, January 18th, 2009Allen Bradley PLC Video
Friday, January 16th, 2009Automation IT – MES ownership up in air
Thursday, January 15th, 2009IT or engineering? Users need both
FAST FORWARD
|
By Bianca Scholten
MES typically is an IT layer, and it ought to be an IT responsibility,” one user said. Conversely, another said, “Our IT colleagues do not have any process knowledge. It is essential that you understand the processes about which MES reports, well. If not, you are reporting rubbish.”
Everybody agrees, more or less, the manufacturing execution system (MES) is the responsibility of users, mostly production. But where can production go when they want to select and implement a new MES? Where can they go with their questions about changes and maintenance of the system?
A small and informal survey made it clear that not only are there different opinions, but also, in reality, there are different ways in which industrial companies handle these issues. Traditionally, there are two parties that take care of automation: IT and engineering. What can they learn from each other? How can they combine the best of both worlds in order to develop, select, implement, and maintain better MES solutions, and last but not least, to use these solutions?
A production manager said she wanted to purchase an MES solution. She contacted the engineers for help, but they sent her to the IT department. When she went to the IT department, they sent here back to engineering.
IT departments traditionally handle ERP and other systems used in the office. The functionality in these systems, like order processing, administrative material management, and cost accounting, belongs largely to ISA95 level 4. These IT people “speak” Java, .Net, and other programming languages. Engineers are working in a completely different world, namely the world of instrumentation, PLC, SCADA, and DCS with programming languages like ladder diagram, SFC, and function blocks. They are active on ISA95 level 2, 1 and 0.
But who takes care of the automation of activities at ISA95 level 3, often called the MES layer? This is about activities like finite production scheduling, recipe management, data collection, tracking, and tracing. Traditional level 2 process control system vendors have offered more level 3 functionality over time, with historians, standard production reporting, and recipe management. These systems closely integrate with the systems on level 2, so it is essential to have thorough knowledge of the process and its automation. This suggests engineers are the ones to support MES and execute MES projects.
On the other hand, there are reasons to think MES should be supported by IT. MES software vendors have based their historians, reporting functionality and recipe management on the operating systems, programming languages and network protocols characteristic for IT environments. Moreover, the term Manufacturing IT is becoming more predominant today.
Quick snapshot
In an effort to gain more insight into who really owns MES, I decided to conduct an informal, non scientific survey among a series of users to get a snapshot of what they were thinking about the issue.
“It can not be a coincidence that we keep addressing the same subjects,” was the reaction of one MES project leader. “I’ve just become a member of a European working group to investigate this very same subject. It appears that in our plants in Europe, we think differently about it. The purpose of the working group is to develop a recommendation for a boundary between the different disciplines and the related organization. The final goal is to develop a common approach.” Others responded enthusiastically. It appears to be a hot topic that needs clarification.
The survey went out to 18 end users; 15 responded before the deadline. The respondents all work for international companies with headquarters in Europe and in the U.S. Every one of them has a good understanding of the ISA95 standard, so I am relatively sure we all have the same basic idea of what is meant by level 4, 3, 2, 1, 0, and MES.
Most of the respondents work in pharmaceutical and chemical industries, but some work in food, tobacco, energy, and biotechnology. Almost a quarter of them is active within level 4 IT, almost half of the group is active within level 3 IT, almost a quarter is active within engineering, and one works for production.
Except for one, all of these companies have implemented one or more MES systems. The other is using SAP on level 3, for electronic batch records. In 33% of these cases, support of MES projects and maintenance are the responsibility of IT. In 20% of cases, it is the responsibility of engineering, 40% have shared responsibilities, and 7% have not decided.
When asked how closely IT and engineering are working together in their companies, 20% said there is no collaboration at all, 43% said they work together in case of projects, and 23% said they work together closely on a daily basis. The remaining 13% could not give a single answer because there are too many differences between divisions.
“In my opinion, IT and engineering do not collaborate in our company,” an engineer said. “Even worse, they are opposed to one another. Although the technical gap between IT and engineering is getting smaller, the chasm between the departments still is huge. I think this heavily impacts the success of MES implementations.”
One respondent said within MES projects, their IT and engineering departments work together closely, but for the support of MES systems, the collaboration could improve.
In case of daily collaboration, IT and engineering usually report to the same entity. Several respondents said the relationship between IT and engineering strongly improved from the moment they had to work on an integrated architecture. This led to more clarity about roles and responsibilities, and they started to trust each other more. Establishing a level 3 IT department also seems to positively impact collaboration. Nevertheless, people keep competing, and IT people seem to stay convinced the ERP system can do anything.
Some of the survey participants emphasized the level of cooperation between IT and engineering strongly differs per division. “Generally speaking, there is not enough cooperation,” one of them said. “Nevertheless, it is becoming clearer that there is a need for a separate manufacturing IT entity. Neither engineering nor IT can offer enough for effective MES functionality. We need a bridge, and we can build that bridge by establishing a dedicated manufacturing IT group that combines IT skills with automation skills,” she said.
Can’t we get along?
Survey respondents mention strong points and weak points of IT as well as engineering, concerning the question, “Which party would better support MES projects and maintain MES systems?” Not surprisingly, strong points of IT are weak points of engineering, and vice versa.
IT strengths
One of IT’s strong points is its knowledge of information technologies, like Ethernet, the IT infrastructure, networks, protocols, topologies, databases, MES data, data management, security and software development technologies, tools, and methods. “An MES is an application that is oriented toward interfaces and databases. Databases are not part of a technical engineering environment,” one respondent said.
Another respondent said, “Engineering in most companies has been stripped to the bone and fragmented to provide support for manufacturing systems and equipment in diverse sites. This severely limits the talent pool at any single site.”
Several respondents said IT tends to be more professional when it comes to system maintenance. IT is better at systems monitoring, making back ups and developing system documentation. Engineering, on the contrary, does support “on the side.” It is not their core task and they handle it less professionally. Furthermore, IT can work with several disciplines.
Another advantage for the support of MES is its central place within the company. From there, IT has an overview over the complete site, or even over the company. So IT is familiar with the infrastructure MES uses and are already responsible for the desktops MES uses. Furthermore IT knows the other business processes and systems MES has to exchange information with.
From this central position, IT has a better basis for harmonization and standardization and to avoid double functionality. IT would be capable of developing a corporate MES strategy and integrate this with the corporate IT strategy. This would lead to synergy between plants. A company could reuse the implementation knowledge over all plants.
Engineers do not have this overview. Historically, they focus on local projects, with a scope that does not reach beyond a production machine or a production line. One of the respondents said their engineering department had once implemented OEE functionality for a production line that was not interesting from a business perspective at all because it had too much capacity. That could mean unnecessary sub-optimizations could result when investments do not undergo an assessment from a higher level.
It is about savings
IT’s central position can lead to cost efficiency. It can limit implementation and maintenance costs. Moreover, IT has professional negotiation power.
IT has knowledge of level 4 systems and their interfacing possibilities. If a company wants to realize all the possible advantages of the MES system, then it will have to integrate MES and ERP.
In short, the 15 respondents mentioned advantages where IT is responsible for the support of MES projects and the maintenance of MES systems. This suggests IT ought to be responsible. But let’s see if there are any significant advantages if engineering is responsible.
Engineering strengths
Almost every respondent acknowledges production knowledge and affinity are strong characteristics of engineering.
“Even if process automation will be more and more influenced by information technologies, detailed knowledge will always be required about the production process, product specifications, and the limitations of the process and the equipment. I hope that engineering will always be available to deliver this knowledge,” one respondent said.
“When the production process is a mixture of manual steps (supported by MES) and automated steps (supported by the level 2 system), then MES will have to be in close harmony with the level 2 systems, and this is something that engineering can take care of,” another respondent said.
One of the companies deliberately put MES projects and support under the responsibility of engineering. “MES systems contain process information that process people need. Management information is only a summary of this process information. That is why we think it should be supported by engineering.”
IT is not known for its knowledge of the process. They are physically, as well as in their experience, far away from the processes MES deals with. One respondent said, “it is not feasible to train IT-people to be able to deal with this.” Another said, “the biggest challenge for an IT person is to think like a production person. For example: Reliability between the four walls of a production plant is much more important than corporate efficiency, being able to work at a distance. You cannot decide just like that on a Friday night to shut down the system for a few hours of maintenance. The engineers within our company are realizing that much more than the IT people. They are much closer to the reality of the production process.”
Local support works
For production departments, it is better to have one party that can solve their problems and handle their wishes in the field of automation,” said one respondent. “Engineers usually report directly to production departments, and they are part of what companies call ‘production’ or ‘supply chain.’ ”
“Engineering people are familiar with the requirements of production and willing to develop solutions meeting these requirements. Engineering does not start after a functional specification is ready, but helps to get a user requirements specification and develops the functional specification on its own,” said someone who works for an engineering department. Many respondents mention engineering can provide 24/7 support, whereas that is not the way IT tends to work. “IT is not trained to help blue collar personnel and give support for a 24 hours/seven days environment. To shut down an ERP system during a weekend for maintenance is OK for an office but not in production.”
Knowledge is key
Some of the advantages of engineering supporting MES systems and projects relate to their knowledge of production process systems and methods. “MES will have to be integrated with level 2 systems,” one respondent said. “On level 2, there are many systems, all with their own specific technologies, and they can only be maintained by engineering. For integration, you need knowledge of these systems. The IT people are not familiar with the process automation landscape in which systems, platforms, and technologies are used that are sometimes more than 25 years old, but also very new software is used.”
“A large part of the process data that are needed within MES originate from the PLCs, SCADA, and DCS systems,” said another respondent.
MES projects and maintenance of MES systems have points of concern that have resemblances with the methods used by engineers. “Engineering projects have direct impact on production processes. Often these projects can only be realized by production stops. Those stops have to be as short as possible. This is an aspect that IT people are not familiar with,” said one engineer. “IT people are not known for their understanding of real-time production environments and the impact of system errors on production,” a respondent said.
End users’ perspective
In short: Engineering and IT bring in important knowledge and skills for MES projects and support of MES systems. Companies seem to be in a situation where that has grown organically instead of it being the result of a conscious, strategic decision. The ones that did make a conscious decision did not all make the same decision. There still are many diverse options, and nothing points out that one scenario is better than the other. For example, you could make IT responsible and have them communicate with engineering on a project basis. This is also possible the other way around. Another possibility is to establish a dedicated manufacturing IT department. But such a department will have to communicate with IT as well as with engineering. Yet another possibility is to put IT and engineering under the same responsibility, to merge the departments.
It is not yet clear what the advantages and disadvantages of all these scenarios are.
Finding utopia
Picture the ideal situation: There is this industrial company, taking a conscious, strategic decision about making IT and/or engineering responsible for the support of MES projects and the maintenance of MES systems. They purchase an MES from a solution provider that sells mature MES products, with a very high percentage of standard functionality, but also with enough flexibility to adapt it to the specific characteristics of the plant’s production process. And finally the industrial company hires a system integrator specializing in the MES solution of this specific provider, and that has decided to combine the best of both worlds (IT and engineering) in its MES project approach. By the time this becomes true, that guarantees success, right?
Users have relied upon several parties: IT, engineering, the MES software supplier, and the MES system integrator. Nevertheless, there is one important task for them. If you want an MES project to be successful, it is very important the users prepare themselves for using the system. Already at the start of the MES project, they should start writing documentation, develop procedures and train colleagues in adopting these new habits, involve the communication department in order to send newsletters, and write articles on the intranet about the upcoming changes. There are end users not aware of this necessity. This of course has something to do with the lack of clarity about responsibilities in MES projects, but it is also due to the fact that production people and other users of the system just are not specialists in the aspects of automation and IT projects.
In the end, there are quite a few questions, but no real answers. After more research, the issue may clear up, but until then, we can move forward on an individual basis, finding our own way.
ABOUT THE AUTHOR
This story was taken from a paper presented at WBF 2008 in March in King of Prussia, Pa. Bianca Scholten is a fellow at Ordina ISA95 & MES competence centre in the Netherlands. Her e-mail is bianca.scholten@ordina.nl.
Data acquisition drives fiber-optics needs.
Thursday, January 8th, 2009By Jonathan Pollet
Imagine being the vice president of operations for an oil and gas exploration and production company. Having just finished a major acquisition of several oil and gas producing fields, your task is now to determine what assets your company just bought and how to effectively operate these fields, which four separate owners operated before your purchase.
At this point, data is your friend. You need to know how much oil and gas the company is producing from these fields, and you need to know how to allocate oil and gas sales back to each well to make decisions about pulling wells and performing maintenance on your new field assets. With more than 1,000 wells, nearly 50 metering stations, several gas scrubbing stations, and oil and water treating plants, acquiring data from these facilities will not be easy. This task is especially difficult when the facilities have instrumentation and hardware from different manufacturers. Your first instinct is to deploy people on the ground to start gathering data by hand. You quickly realize this manual process with five operators and two office clerks is costing you a lot of money, and you decide there must be a way to collect the data automatically. A Houston-based company faced just this situation, and this is when they called in supervisory control and data acquisition (SCADA) analysts to present a solution to the problem.
The first step in designing a SCADA system is to determine what level of automation the organization has already applied in the fields and what manufacturer’s equipment is controlling the processes. The second step is to find the best communications medium for connecting these intelligent field devices to a centralized SCADA system in the field office.
The company needed to find an appropriate medium to acquire data from multiple types of flowmeters, programmable logic controllers (PLCs), and other intelligent end devices. After considering various spread spectrum radio vendors, cellular digital packet data (CDPD) modems, and other communications options, we decided fiber optics would give us a consistent communications medium and allow for data transfer over long distances without any data interference. We applied different data protocol adapters to the ends of the fiber runs, so specific SCADA drivers could work with the existing hardware already running in the field.
Why fiber?
Although there have been multiple practical applications for fiber optics since the 1960s, optical fiber technology has actually been available since the 1920s.
Some of the first commercial applications for fiber optics were in the medical industry. Because fiber is very flexible, has a small diameter, and can transport light to illuminate various parts of the body, it became a natural choice as a communications medium to bring data and images back to the doctor for analysis. Fiber has also seen use in the medical industry as a transport medium for laser surgery.
Because optical fibers are not sensitive to electromagnetism interference and radio-frequency interference, they are a reliable transportation medium for voice, telecom, and data services. Fiber optics is also highly suitable for military, communications, and industrial control applications where high signal quality, secure data transmission, and survivability are critical.
The list of applications for fiber-optic technology for the industrial controls and commercial industry continues to grow daily. The industry is using fiber optics for level sensing, part inspection, down-hole oil and gas drilling, and process control applications.
We selected fiber optics for this project for several reasons—including fiber’s insensitivity to interference and its ability to transport virtually any type of data protocol over long distances. We also wanted to achieve a high level of data throughput without packet loss. We found fiber-optic technology provides the most consistent and reliable communications medium for SCADA applications.
SCADA and systems integration engineers assume fiber costs are too expensive, and they often turn toward wireless options such as spread spectrum radio, wireless Ethernet, and satellite for providing the communications link to field devices. However, if you look at the total ownership cost of fiber optics versus other communications media over a five-year period, fiber’s ability to deliver consistent data throughput with virtually no packet loss or system downtime makes it an attractive choice. The costs involved with purchasing and installing fiber-optic materials have also reduced significantly over the past five years. Usually, if the remote field devices are less than 10 miles from the SCADA server or if they are aligned in a pattern where one fiber bundle run can pick up multiple facilities, fiber is a good choice.
Relighting existing fiber
Much of the data the company collected by hand resided in remote terminal units (RTUs), PLCs, and electronic metering systems. All field equipment we needed to monitor was already installed. These controllers were all within a 7- to 10-mile area of the local field office. Upon further inspection, we found an old abandoned fiber-optics cable bundle that passed near several of the well testing stations. Technicians verified the integrity of the dark fiber and were able to relight several pairs of fiber to use for data collection. This saved the company money, because we were able to reuse existing fiber installed for phone and data services years ago.
The PLC devices located closest to the main fiber run were Allen-Bradley SLC 505 model types with an Ethernet RJ45 port on the front of the PLC. We used a fiber-to-Ethernet converter from Black Box to establish a 10-megabyte TCP/IP connection from the PLCs back to the control room—where we had installed the central field SCADA server. The team connected additional PLCs by running industrial Ethernet cable from the fiber break-out boxes. Because you can use CAT5 Ethernet cable to connect any IP-based device within 300 feet, we used industrially rated CAT5 Ethernet cable to branch out from the fiber termination points to pick up other devices located close by.
Copper network extension
On another area of the field, we had installed an RS-485 copper network to connect eight Daniels flow computer devices. We then used a Sierra Air Card CDPD modem as the communication link back to the field office.
Near this set of flow computers were additional well testing stations with Allen-Bradley SLC 505 PLCs. A Modicon Quantum PLC with an installed NOE Ethernet communications module controlled a gas scrubber station nearby.
The distance between the flow computers, Allen-Bradley PLCs, the Modicon PLC, and the field office was about 2,500 feet, and because the PLCs had Ethernet TCP/IP communications capability, we wanted to design a communications medium that could send RS-485 serial data as well as Ethernet data. After conducting a feasibility study and walking the area taking photos, the team was able to design a fiber-optics line that we could hang on existing telephone poles. The company ended up using aerial fiber because of the low installation costs. We hung a six-pair fiber cable with thick insulation, and it arrived at the field office on a large wooden spool with the guy wire already attached to the fiber. After installing the aerial cable on the telephone poles, we dropped the fiber into the control room and terminated one end in the control room, and the other end out in the field in an environmentally enclosed panel.
Because there were six pairs of fiber, the company ended up using one pair to transmit the RS-485 signal. We used a fiber-to-RS-485 converter on both ends of the fiber run. We then snapped an RS-485-to-RS-232 converter onto the control room side of the RS-485 network. This way we could connect the RS-485 network to the RS-232 serial COM1 port on the back of the SCADA server.
The company used another fiber pair to transmit and receive Ethernet TCP/IP data for the PLCs. We again used a fiber-to-Ethernet converter on both sides of the fiber run to break out the TCP/IP data onto RJ45 CAT5 copper cables. We used an industrial hub to allow packet switching on the field side of the fiber run, and we ran individual CAT5 copper industrial-grade communications cable to each Ethernet-based PLC device. A Wireless Ethernet radio system picked up additional flowmeters, PLCs, RTUs, and other intelligent end devices that were not physically installed close to the path of the two fiber runs.
Cost effective
By relighting previously installed dark fiber and using aerial fiber in other places to create a long-haul communications channel for RS-485 and Ethernet data, we created an independent oil and gas producer and were able to cost effectively design and deploy a new field operations SCADA system.
One central SCADA system allowed the local operations team to control and monitor all field equipment with one standard interface, and it was transparent to the user whether the end device was a Modicon PLC, Allen-Bradley PLC, Totalflow gas flowmeter, Westing-house PLC, or a Daniels flowmeter.
The project was economically sound because we took advantage of existing communications infrastructure when designing the communication networks. Fiber optics allowed us to send multiple types of protocols and data through the same type of medium, and the SCADA system had the appropriate industrial automation drivers to allow IP-based Ethernet and RS-485 serial communications through fiber networks.
Behind the byline
Jonathan Pollet is chief executive officer at PlantData Technologies in Houston.
Weight controllers
Thursday, January 8th, 2009Only three inches deep, the HI 4050 general-purpose weight controller is now available with Allen-Bradley Remote I/O (RIO) network communications. Allen-Bradley RIO is a high-level network used to communicate with Allen-Bradley (Rockwell) Programmable Logic Controllers. The HI 4050 weight controller includes WAVERSAVER to eliminate the effects of surrounding vibration for fast, stable weight display, C2 electronic calibration without test weights, a Secure Digital based Secure Memory Module card for fast transfer of configuration data, and INTEGRATED TECHNICIAN for system diagnostics and troubleshooting