In Part 1 of Maximizing the Value of the Specification Process, we began discussions on how the specification documentation process can bring value to planning a migration project. In Part 2, we continue to highlight the potential value that collaborative planning brings to the specification process, and also provide some insight to evaluating key decisions during the planning phase. Both goals move the Project-Management Team, the Corporate-Management Team, and the Trusted Partner closer to a win-win-win scenario of a quality outcome that is on time and on budget.
What’s Your Role in the Project?
- Are you involved with engineering, production, or maintenance?
- Do you set the budget, scope, and timeline for projects?
- Do you approve the capital for the projects and when the money will be available?
- Do you award the bids?
Each of these personnel roles needs to be aware of the factors identified in this blog to reduce the number of surprises and disagreements throughout the project.
What’s Your Project Scope?
- Does your process have stand-alone Programmable Logic Controllers (PLCs) that need to be replaced, because spares are difficult to acquire or because you have unexpected shutdowns?
- Do you have a network of PLCs or a larger Distributed Control System (DCS) that needs to be upgraded to a new version or platform to meet higher production needs?
- Do you have a mix of stand-alone and distributed control systems that need to be condensed into one system?
The suggestions in this blog for developing collaboration and specifications should create discussions across personnel roles that could improve planning for a future project’s outcome.
For clarification, specification documents can be used on migrating systems, upgrading systems, or creating new systems. As we focus on reducing the risk of obsolete control systems through the specification process, we will refer to two possible paths – migrating to a different control system or performing a version upgrade within the same platform. Since that strategic choice needs to be thoroughly evaluated during the specification stage, both terms are used as examples in this blog. For example:
- Version upgrades usually occur when staying with the same platform. Updating hardware and programs within an Allen Bradley ControlLogix system or a Siemens PCS7 system would be a version upgrade.
- Migrations occur when changing from Vendor A’s system to a Vendor B’s system. An alternative scenario sometimes happens when a vendor no longer supports a platform and a full migration is required, even if staying with the same vendor.
The Value of a Trusted Integrator Partnership
Creating a trusted partnership means that all the plant’s stakeholders and the trusted industry partner (consultant) develop a mutual understanding of goals and perceive similar values. The suggestions to foster this trusted environment derive from the evaluation of many completed projects and asking the question, “What characteristics and trends were present in the successful projects that may have been missing in the troubled projects?”
By asking that question, one answer became clear. Clearly defining what each internal department and the external consultant values can dramatically reduce the level (and type) of trouble that a project experiences. Several questions need to be addressed by the plant’s decision makers before the plant and consultant can start discussions on the project’s key values.
- Do we have the manpower to do this project ourselves in the timeframe that we need?
- Are we comfortable with the unknowns in undertaking this project alone?
- Should we work with a consultant?
- What could they do that we cannot do alone?
- What should we look for in a consulting firm?
If the value that the consultant brings to the project is not clear to all internal decision makers, then a trusted partnership will most likely not develop and could have major repercussions as the project progresses. Hopefully, some added-value characteristics for the chosen integrator will be seen as we continue exploring what a trusted partnership looks like in the specification process.
Since system obsolescence is a fact of life in process control environments, planning for the eventual migration with a trusted industry partner can mitigate unnecessary costs and reduce operational risk by painting a fuller picture of what is needed for a successful outcome. The plant personnel brings first-hand knowledge of the plant’s specific processes and requirements to the table, and the integrator supplies expertise in designing and implementing system migrations. While the plant may have very capable engineers and resources that have maintained the existing system for years, the personnel typically lack bandwidth of time or familiarity with system conversions to accomplish the project in the required timeframe.
Using an integrator that is familiar with a variety of major control system platforms can help in evaluating whether a version upgrade in the same platform or a complete platform change may be the best option for the future. The platform evaluation utilizes pros and cons that the integrator has seen from handling many similar projects. By incorporating these different perspectives in planning, a more realistic picture for the project specifications, costs, and timeline can be created.
Avoid Logic-Induced Headaches
As a primary example of value differentiation, this blog will explore the frequently-contested value of whether or not the existing program’s logic (or code) can be reused in the new system. If the perceived value of the existing logic varies between the plant and consultant, then the project has a higher risk of failing to meet the timeline, budget, and quality expectations. However, by working together to determine the value or risk of the existing logic, then the corporate-plant-consultant relationship has both a stronger foundation and less risk of deteriorating as the specifications are developed.
Logic quality can determine a control system’s ability to convert an obsolete program to a new version or platform. The conversion process, if possible, can reduce time and cost by not having to completely rewrite all the logic or code. However, if the logic contains complexities such as scripting, had many different parties managing it, uses a proprietary format, or has no existing conversion path, it may not be able to be reused. If it is technically reusable, the complexity of the logic may take significant time to review, troubleshoot, and then incorporate in the new PLC or DCS system. In either case, it may be better to start from scratch and apply the updated industry standards to improve the overall quality. To make this determination, the project team and trusted partner should evaluate 8 factors before deciding on the best approach. These may not all be present, but they give a starting point for evaluation.
The Unique Evolution of Your Control Logic
- The risk of converting complex logic could create performance issues later in development or allow any chronic problems to remain in the control system. To allow the plant personnel a more objective stance, it is important to note that the quality of the logic is not necessarily a direct reflection of the people maintaining the system now. Whether plant personnel or a consultant manages the existing code, the current strategy to maintain the system may be the best approach available based on the developmental history of the program. However, by collaboratively evaluating the code for these complexities during the specification process, mutually-agreed-upon requirements can be emphasized in the documentation to protect the new system from harboring these unfavorable characteristics. When the plant personnel and integrators can openly discuss areas for improvement in the logic, then the successful outcome will be realized more often.
- Perhaps, the current controls engineer or incumbent integrator programmed the existing system. Since one party was solely responsible, it may be in a format that only the original programming-party understands. For one reason or another, it may not have been programmed with alternate support in mind.
- In another case, it may have started out as a small control system and morphed into a sprawling system over time. Due to possible time constraints in development or an urgent pace for programming changes, the existing code could have a lot of unnecessary processes, which makes troubleshooting or further modifications more difficult. Whatever the case may be, the present is always a good time to assess the true quality of the system’s programming. Then it can be determined whether new program logic using improved standard features could simplify maintenance, allow access for more avenues of support, and create other process-related efficiencies. If an emergency happened or if the primary programming resource is unavailable, it could provide peace of mind to know that additional programmers can access and understand the system’s programs.
Simplify, Simplify, Simplify
- Changes in plant management may have introduced a myriad of disparate platforms causing a complex network for logic and communications between various control systems. Not only is this a nightmare for troubleshooting, but updated technology could help reduce the number of systems for those smaller systems. By requiring the reduction of platforms where it makes strategic sense, the plant can experience efficiencies in programming resources by working on fewer systems and thereby simplifying the troubleshooting labyrinth. Licensing, training time, and other cost-saving factors may be simplified as well.
- As standards and technology improve, the possible programming strategy in process-control applications changes as well. Prior strategies for logic may have been affected by accepted practices, hardware or software limitations, budget, or development timeline constraints. Lower-cost control systems usually require more engineering time to patchwork the various software, programs, and components, which can open the door to complexity.
- Another factor is how the logic requirements were determined. Were a majority of the requirements known prior to programming or were they identified and added once process began? If requirements are known up front, then the project team can plan a more simplified architecture and program. If functions are added later in the project, it may require rework or cause unexpected errors and delays.
- Similar to construction, programming a PLC or DCS can be more expensive and complex during a remodel than the initial building process. Moving a support wall because the room needs to be larger is much easier to do on the blueprint than when the wall in place. Likewise, functional and detail specification processes can help reduce the risks and costs associated with reworking the code mid-project by incorporating feedback from all personnel familiar with the process. While there still may be changes in the future, those possible changes can be identified in the discovery process so that the code’s foundation can be properly equipped for the adjustment later. This also helps phase in desired capabilities to defer programming and development costs over a longer period of time. By identifying aspects to the code that are less of a priority, provisions can be made for them at some point down the road.
Require Access to Programs
- To be fair, there are cases where the programmer has not developed the logic the way the plant wants, locks out sections of the code, leaves out comments, or maintains possession of the program for troubleshooting the system. Despite those facts, the program may still allow proper control of the ingredients, levels, flows, and instrumentation in an updated system. However, if that system remains tied to one person due to proprietary software or complicated logic, then unnecessary headaches could have been avoided by requiring fully-accessible engineering programs in the new project. Moving to a new platform or a version upgrade may be a good opportunity for another chapter in managing the plant’s process control systems. In this industry, system support should be based on a trusted partnership rather than being held captive by a complex or proprietary programming method. Establishing new programming standards that closely collaborates with the engineering team will ensure that the final product will allow the plant personnel full access to manage the system according to their specifications.
Maximize the Value of Specification Documents
Maximizing the value of specification documents begins with valuing collaboration and key decisions. Here’s how to optimize value from the specification process that we identified so far:
- Establishing common values for the project between corporate, project, and consultant teams ensure a greater degree of overall success.
- Utilizing the expertise from the plant personnel and system integrators can present a realistic picture of the project requirements, cost, and timeline.
- Evaluating the existing code during the specification process can determine if the code can be reused or should be reused. Complexity, accessibility, convertibility and other factors will need to be analyzed to weigh the cost versus benefits of reusing code.
- Determining code quality is not intended to assign blame, but rather to understand the history of the plant’s systems and the decisions that led to its current state.
- New standards and technologies can simplify programming methods that were previously used.
- Determining requirements prior to programming can prevent rework and improve code quality.
- Standardizing code functions can make programming enhancements and maintenance more accessible for the plant’s programming resources. Moving away from a single programming contact reduces the risk of losing that person and their knowledge of the system.
- Requiring internal and external programmers to provide full access and configuration software to the critical programs will allow recovery efforts to be handled more quickly. Anyone with that access will need to be trained on the software and follow the approved coding methods.
- Specifications can reduce or eliminate the number of proprietary and inaccessible programs in your overall process control network by requiring access to the systems.
- Requiring the reduction of disparate control platforms could simplify the process management and troubleshooting for the plant personnel.
- Specifications can be used to plan future programming needs, reduce possible rework, and spread the cost of development over phases for budgetary purposes.
- Investing in specifications and new programming may reduce future engineering time required for maintenance or downtime related to failures.
Collaborative Planning Leads to Project Accuracy
While this list is far from exhaustive, it shows the impact that internal and external collaboration along with mutually accepted values can have on a migration project. Key decisions, like whether or not to reuse logic, should be based on a collaborative analysis to identify the short-term and long-term impact on engineering, maintenance, production, and corporate objectives. By determining these requirements ahead of time, a more realistic budget and timeframe, as well as higher quality systems, can be expected for the overall project. Stricter programming requirements or a rewrite may cost more initially in engineering time, but it could prevent a lot of financial and engineering headaches in the future that far outweigh the investment. Engineering projects can be a messy process, but by taking additional precautions, the Project-Management Team, the Corporate-Management Team, and the Trusted Partner can more often than not experience the win-win-win scenario.
