Imagine agreeing to a road trip with a driver who refuses to use directions.
No GPS, no folded-up paper map, and certainly no stops to ask for directions, just an open road stretching out into a giant question mark.
Chances are, you’re not going on this one.
You wouldn’t agree to an aimless road trip, and you wouldn’t trust your surgeon to improvise an operation. You wouldn’t want your operators on the plant floor to just wing it.
So why risk a SCADA upgrade by skipping the system assessment?
SCADA upgrades are nothing new—nearly every company or organization has been through some kind of system upgrade. Whether it’s as simple as updating the operating system on a PC or as involved as a full-fledged SCADA upgrade project, we’ve all experienced it.
Once an organization overcomes the hesitations that typically surround facilitating a SCADA upgrade, it’s time to get down to business.
Let’s think realistically here. Depending on the size and scope of the existing system, an upgrade can be fairly complex. In fact, some can include over 70,000 points and 13 independent legacy nodes, all of which will be combined into one seamless system.
Of course, sometimes the most common challenges surround the systems that don’t seem all that complex—small to medium systems, or situations that have 8,000 points or less.
A project of this scale takes a lot of planning. It takes a game plan, or a road map into your system. The most critical part of preparation comes down to performing a system assessment.
More often than not, organizations will run through an assessment for virtually any sort of process modification. For some reason, when some organizations discuss the assessment as a first step toward a successful upgrade, it’s viewed as an extravagant step.
But most of us would hardly label our GPS navigation for long road trips as extravagant.
It might sound simplistic, but that’s what the system assessment is able to provide– important, thorough insight into the system. It’s worth it in the end to not skip this step.
And the assessment isn’t just a visit. It results in a physical document that outlines the system in detail. The deliverable gives you an accurate, clear picture of the work that will go into actually performing the upgrade. It’s your own, personalized route to completing a successful upgrade.
So what should be documented when going through the system assessment? Here’s what you can expect.
Begin the process by noting the number of SCADA-related computers, servers and clients, computers, computer physical locations, and IP addresses.
It’s important to record the hardware brand and model, the number of devices, locations of devices, and communication media and protocols.
This can be challenging, especially if operators are using older protocols. It’s possible that the companies who provided the protocols are no longer viable options. In this situation, it’s going to be critical to look for new ways to communication with new hardware.
This can quickly turn into a situation where some careful investigation and brainstorming will be needed to overcome the challenge. But that’s why you’re facilitating the system assessment.
Next, be sure to note the type of PC and how much RAM, hard-drive size, or free space is available. You’ll also want to know if the internal cards will work on the new architecture. If not, it might be the time to see what else is available.
Document what supplementary equipment, such as barcode scanners, is included. It’s critical to know what’s in place that the organization frequently relies on.
And don’t forget to note the PC software—the operation system version, the Microsoft Office version, and installed components that work with the operation system.
Of course, it’s important to note the SCADA version, along with any patches or service packs that are currently in place.
After noting the basics about the SCADA, take a deeper look into the tag database, or how many tags are currently in the system. An export of the database is preferred here. It allows you to not only look further into the number of tags, but the types of tags that are being communicated with.
Additionally, document the driver versions and complete an export of those configurations. Depending on the system, those drivers may no longer be viable. Now may be the time to make wholesale changes to the drivers. If so, it’s ultra-important to know the configurations that are going to be replaced and the effect it will have on the tag database.
Once the knowledge surrounding the SCADA system is mapped out, it’s time to outline the details of the stored, historical data that’s being collected.
The organization might start the process by asking: How many points are being collected? Where are they being stored? How much data currently exists?
And does that data need to be migrated to a newer system, or can it be held, maintained and accessed on an as-needed basis? Or maybe it’s important to simply hang onto the data, but not necessarily to have immediate access to run operations.
Pay special attention to reporting. It’s a term that everybody seems to understand, but it’s not always the easiest concept to define. It’s certainly not always black and white.
Reporting can be so intimidating that it’s thought of as a black hole, because there’s just so much to it.
There’s the format of how data is presented, how the data is laid out, the specific time and date of when data was retrieved, and the location where it usually comes from.
Even the most qualified, knowledgeable operators might be unfamiliar with where an actual value is coming from—not just from the SCADA, but from within the PLC.
So while you’re knee-deep in assessment, building your road map, why not spend the time to take a more thorough look into reporting. You might be able to better understand where the data is coming from.
Ready to start your digital industrial transformation? Download the GrayMatter eBook.
Cookie | Duration | Description |
---|---|---|
cookielawinfo-checbox-analytics | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics". |
cookielawinfo-checbox-functional | 11 months | The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional". |
cookielawinfo-checbox-others | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other. |
cookielawinfo-checkbox-necessary | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary". |
cookielawinfo-checkbox-performance | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance". |
viewed_cookie_policy | 11 months | The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data. |