Protecting Intellectual Property
Along with all the real estate, steel structures, piping, pumps, and other hardware, a company’s intellectual property (IP) is one of its largest investments. In many respects, IP may be the most valuable since none of the other areas can function without it. Companies need to be aware of the variety of forms it takes, and protect IP at times when it is particularly vulnerable.
A company’s IP begins with the most basic elements of the processes—the dynamics and stoichiometric relationships of the feedstocks and how they react. It carries through the whole system to the very images on operators’ display screens. In many respects, the operators themselves and the knowledge in their heads also qualifies. Given the situation today with changing workforce demographics and the number of control systems reaching end-of-life phases, keeping close tabs on IP issues now may be more important than ever.
“ARC Advisory Group has been touting the figure of $65 billion in installed control systems that have reached the end of their useful life,” says Betty Taylor-McDevitt, director of DCS business for Invensys Operations Management. “Either they are no longer supported, or their users can no longer compete in their marketplace because the system is so old and has fewer capabilities than competitors that are running a newer and more robust system with advanced control capability and other features that allow them to be more productive.”
Ken Keiser, PCS7 marketing manager for Siemens, has seen firsthand the importance customers place on operational information as the collective knowledge of employees dissipates. “That’s where a lot of angst is located with users because they put all this effort into graphics or the configuration of the controller, and they don’t want to lose it,” he says. “Not only that, with turnover, retirements, and other loss of knowledge about the process and about the control system, those that are left may only know about 90% of what’s in there, so they want to preserve it.”
Preserving human IP
Keiser’s comment reflects changing operator demographics. A very common problem currently is loss of experienced operators, either through retirement or cost pressures. Companies are trying to replace the knowledge carried in the head of a former employee after that person is replaced by someone with far less experience and probably less training. The best practices that skilled operators knew after years on the job have to be built into the control system.
“One of the items of IP that a customer has is the knowledge of how the plant can be operated in the most safe, productive, and efficient manner,” says Chris Morse, product manager for Honeywell Process Solutions. “When you start up a new plant, the licensor is there and he documents the best way to run the plant, trains the operators, tunes it up, and then goes home. Another 15 years later, there’s been turnover of operators, probably not much influence of the licensor, and that knowledge can get eroded. There are products that capture the knowledge of the best operators, and automate or partially automate the procedures they use. That captures the IP and builds it into the DCS so that a particular procedure is always carried out in the same way, the way the licensor expected it to be done, and the way the best operator does it. That leads you to a much better position in terms of safety, efficiency, and general operability.”
But is that sort of knowledge capturing going on in real life? John Murray, global business development manager for MOD 300 platforms for ABB doesn’t think it’s happening as much as it should. “Maybe the term is overused, but the ones that are doing it are trying to achieve operational excellence” he says. “If that’s part of their vocabulary, then yes, they are thinking about these things. On the other side of the coin, there are customers out there that aren’t aware of it.”
Preserving machine IP
If extracting information from people isn’t a big enough challenge, understanding what’s going on inside a controller presents its own difficulties. Controller code is what is actually running the plant, so it is always current. However, the understanding that human beings have of what it is doing may not be accurate. This can be the result of poor memories and made worse by documentation that no longer reflects reality. Some companies keep very close tabs on changes to their automation architecture. Others let it get away.
Mark Bitto, global business development manager for ABB’s Harmony/Infi 90 product family says you can tell a great deal about a plant’s strategy by looking at the controller code. He suggests, “If the control system has been installed for 10 or 15 years, those applications have been proven, tweaked, and are running production the way they want them to. It’s in the applications, it’s in the mode of operation, in the graphics, the HMI, alarm strategy, and the way the operator interacts with the system. If you look at the controller level, the best practices are in the documentation of the control logic of the process application. To move that to a new control platform, there is risk if you don’t have a method to port that into a new controller. Without that method, you’re reengineering, redesigning, retesting, verifying, and commissioning. There are costs to that and risks to actual production. You need a method to take what you have and move it to whatever platform you want to move it to.”
The problem is trying to get a handle on what really is running in an old system. That control code probably changed a lot over the last 10 or 15 years, and documentation may not have kept up. That isn’t as big an issue with newer systems, but older technology isn’t as easy to work with. “Some of the legacy systems don’t have the self-documentation features that we’re used to now,” says Marjorie Ochsner, marketing manager for Honeywell Process Solutions. “Installed systems can be 30 and even 40 years old, and when you get to that age, not only are there no self-documentation features, you’ve probably also lost the original designer. It’s hard to know why things were changed from their original form. You might have a good hard copy of what was built, but changes down the line may not have been documented properly.”
Siemens’ Keiser adds, “Somebody who knew how the process works wrote it all down and it got translated into control code. So it is an image of that knowledge, but you shouldn’t rely on the control code for all that knowledge. You should have some way of storing that in procedure books or other kinds of documents. It certainly shouldn’t be in just one person’s head.”
Understanding what is actually running in your system becomes particularly important when planning a migration or system upgrade. As Bitto pointed out, if everything does not move to the new system correctly, there are many elements that have to be redone and this can get very costly. Ochsner says that there is no substitute for doing a thorough front-end engineering design at the outset of a migration project.
Given the value of IP, users often want to create reusable engineering that can be transferred from one system to another. To large companies that have multiple plants doing the same process, consistency from location to location can be very critical. Honeywell’s Morse adds, “Some customers have a standard approach for certain processes. They maintain that standard very rigorously because they see enormous value in the IP and the lifecycle cost savings of keeping something standard. One customer we have replicates their designs for every plant of a particular category and the only thing they will let us change on site is something to do with local electrical codes or local language. They see great economic value in that approach.”
When contemplating a new system, customers need to be clear what they want, but having some flexibility can help in the longer term. “We are seeing more of our customers wanting to create reusable objects,” says Kam Yuen, product manager, GE Process Solution Group. “There are several reasons for doing that, including saving engineering costs, but a big driver is IP protection. Some customers come to us and say, ‘We want to use your tools in a certain way.’ It’s usually because of a specific requirement they want in the product, and they want us to help them. But sometimes the way the customer wants to use the tool can limit its capability.”
ABB’s Murray agrees, but suggests that customers can be convinced: “In many cases we move customers to the new platform as is. Then we begin conversations and discussions about leveraging the system’s capabilities and going into advanced alarming and monitoring. If you do a changeover, there is only so much you can do at any one time. If you try to do too much at once, it’s overwhelming.”
In some cases, customers choose to make changes to correct those seemed-like-a-good-idea-at-the-time selections made in years past. “With the emergence of the Abnormal Situation Management standards, companies are going back to more basic user graphics,” says Invensys’ Taylor-McDevitt. “Screens use more gray, and a lack of color means the situation is normal. They only use color when something wrong is happening, and the displays are not so cluttered. When graphical user interfaces first came out, the tendency was to animate the whole thing and make it look like a Play Station. But they found that was too much data, too much activity, and they’re going back to a simplified user interface.”
Regardless of whether you are planning on making changes to your control systems, or doing all you can just to maintain what you have, keeping a handle on your intellectual property is more important than ever. The variety of forms that IP takes, including operators’ memories, control code, and paper documentation, suggests that a multi-prong strategy is necessary to preserve it all.
|Peter Welander is process industries editor. Reach him at firstname.lastname@example.org.|
Legal protections for IP: What manufacturers need to know
Given the value of intellectual property (IP), there are legal structures built around it to protect owners, just as there are for real estate. Formulas and processes can be patented, but so can control strategies if they bring a new form of innovation. In some cases developments may involve multiple parties which can bring a higher level of complexity.
Darren M. Jiron is a partner with the law firm Finnegan and deals with such issues regularly. He says that when companies work together, they need clear agreements at the outset. For example, if a manufacturer develops a new process to make a given product and asks a control system supplier to design a control strategy, the two companies have to understand which company will own the various parts of the resulting solution. He suggests, “The area of joint usage and joint development can be complicated. When a producer develops a process and determines that it wants to join with another company to implement a control system for that process, the first step is for those companies to determine where that relationship is going and what they want to accomplish.
“Then they draw up an agreement that contemplates all IP related issues to the extent that they’re foreseeable. The nature of the agreement could vary. It could say that the user owns all IP, not just the process, but that it will eventually own everything that the control system supplier develops for the process. Or, it might make a delineation between the process and the control system and keep them separate.
“If the agreement is somewhat vague as to who owns what IP, it could be problematic down the road. The more forethought that goes into the agreement trying to anticipate various issues, the better off the companies will be because there will be fewer questions. If they’ve already contemplated some situation arising, and they have spelled it out well enough so they both know what they can and cannot do, that’s the most important thing in these types of situations.”
Safety system IP
While a process safety system may be separate from the larger control platform, it has its own IP, and it is just as important. In fact, a safety system may have 10 times the amount of documentation as its associated control platform.
Matt Willmott, marketing manager for Honeywell Process Solutions, points out that there are two areas related to safety instrumented systems: “You’ve got the automated safety systems which are typically embedded in the safety controller, and they’re functionally defined through the design process which involves hazardous operation and other analysis techniques that produce safe charts, cause-and-effect diagrams, and a well-defined requirement for safety.
“The other aspect is the layer before that, which is your alarm sub-system. The knowledge of what to do when an alarm comes in is IP, and that needs to be retained, particularly if it is not written down or it’s something operators may only learn over many years of experience. The retention of the knowledge of the safety system should come through good management of engineering documentation. But putting together haz-ops and cause-and-effect charts is not a cheap endeavor. That’s an investment and should be preserved. It may not be proprietary, but it’s still an investment. The preservation of what an operator knows of the actions he needs to take from experience into an alarm system is quite important from a safety aspect.”