We read the application before we quote the migration. Six sections, shown on one worked example.
The example that runs through this article is a process-plant application with 7,553 tags, 126 operator windows, 143 scripts and 1,103 navigation statements. It is a de-identified record drawn from delivered process-plant projects, with every name, identifier and figure changed and the proportions kept. Each section below shows the source-side count that record started from. The report you get for your own application covers the same six subjects.
You send us a read-only copy of the application folder as it was delivered to you: the tag database export, the window files, the script store, the alarm configuration, the logging configuration and the I/O server configuration. We install nothing on your system and we touch nothing that is running. Within two to five working days you get a written report in six sections, and with it a fixed price for the migration, calculated from the report’s own counts. Assessments are scheduled in the order they are requested, the ones requested at the webinar included.
1. The application file inventory
Every file in the folder is listed, with its class and its hash, and the report says which files were read, which were excluded, and why. In the example, decoding the source enumerated the 7,553 tags, 126 windows, 143 scripts and 1,103 navigation statements before anyone interpreted anything. Every later count in the report reconciles to that census, which is the reason it comes first.
2. The tag model
The tag dictionary read back as a structure: how many tags, of which classes, and where the same equipment repeats. In a flat dictionary the same instrument on two process trains shows up as two unrelated names, and the only thing holding them together is a suffix. The report finds those families. They are what the rebuild turns into typed templates, so you do not carry thousands of individual names across. In the example, the area identity lived in the tag-name suffixes _T1, _T2 and _PW.
3. The PLC addressing scheme
The I/O server configuration, the controller access names and the address grammar behind the points, written so an engineer can check it against the panel. In the example all 6,863 I/O points sit on three access names over one controller family, and every controller tag name matches the source item character for character, so the two point lists can be compared directly. The census also found that the 6,863 points read 6,840 distinct addresses. 23 addresses are read twice, once as a direct tag and once as an inverted one. If the scheme is regular, the report says so, and that part of the migration is data work. If it is not, the report says where it breaks.
4. The alarm census
How the alarms are organized, by group and by condition, and which equipment produces them. The example carries 614 armed alarm slots in three groups. 572 are discrete status bits whose limits live in the controller, and 42 are numeric limits on analyzer inputs. The report says what each group holds and which equipment fires it. That matters when the rebuild needs a severity structure, because you decide it once, with the facts in front of you, and you do not come back to the question 614 times.
5. The historian census
Which points are logged and trended, at what deadband, and how the history is grouped. The example logs 556 points and carries 47 trend objects. The 76 logging deadbands the source set are each exactly 0.60 percent of that tag’s span. A rule like that is worth finding, because it is what lets you check the rebuilt trends against the old ones, tag for tag.
6. The application navigation map
One page that draws the whole click grammar of the application, every screen and every wired action, and how deep the application actually goes. In the example the map starts from 1,103 show and hide statements across 64 windows and 103 screen-select buttons, and groups them by the pattern they repeat. This is the section the scoping conversation is really about. How many screens there are, and how alike they are, is the size of the display rebuild, and this page puts it on the table before anyone commits to anything.
What the delivered record adds
The assessment tells you what is there. When a migration is delivered, the record that comes with it answers a second question: what happened to every one of those things. In the example, all 8,940 source constructs are listed in two columns. 8,282 were translated onto a delivered mechanism, and 658 were logged with a named reason, a retired tag for instance, or a duplicate navigation statement, or a script whose behavior is now configuration. The two columns add up to the source count on every row, so nothing can disappear between them. The 1,103 navigation statements came out as 754 wired actions under 12 rules, and each of the 349 that did not carry is logged with why. That study is scoped and quoted separately. It needs the delivered solution to exist, so it cannot be done from the source alone.
Who reads it
Tatsoft engineers, against a method that has been run on delivered projects. In 1997 our team designed InduSoft (now AVEVA Edge), and FrameworX from 2009, so the people reading your application have built this kind of software for three decades. The report is yours whatever you decide next. It describes your application and says nothing about our product, and it is useful whoever ends up doing the work.
Bring yours on 15 October
On 15 October we read a legacy application back and rebuild it live on FrameworX in one hour, then walk through what the platform gives you once you are on it. The offer is the same for every reader, attendee or not: a free assessment, a fixed price, and you pay only if you accept the result.
Register: https://tatsoft.com/webinar-scada-hmi-migration/
FrameworX is free to download and develop with: https://tatsoft.com/fx-101/#download
Aim High. Start Simple. Scale Without Limits.