Here are some thoughts about this. For the data access layer, you will probably want to use PI SDK if you want to access the MDB although this technology ison the way to deprecation. Also, do take note that interfaces that are not registered by the PI ICU are not stored in the MDB and hence will fall through your detection. Identifying destination tag will be easy since you can do this by the point source. However, identifying the source tag will be tricky since there is nothing in the point attributes that will link the source tag with the PItoPI interface instance. Therefore, you will probably need to have an algorithm that is similar to what the PItoPI interface uses for searching for source tags in the source PI Data Archive. As you know, there are a few ways to link the source tag with the destination tag such as by Tagname, Userint1 etc. Therefore, unless your company has standardized the linking using one method, you will have consider all the ways that they can be linked.
Regarding dependencies between PE Tags, we do have an enhancement request and a workaround proposed. However, it is not programmatic.
My thought would be to parse the PE expression to extract anything between single quotes and then searching for tags using this. (some searches might fail because time is also surrounded by single quotes but you can handle those exceptions)
Eugene, thank you for the input. I was aware of most of those concerns, and there isn't necessarily a standard method, so all options will need to be checked.
I will look at the PE workaround, but was planning to build a parser to extract tags.
I have already seen such an application that was developed by a little team in a big Energy company in France.
Their idea was to create a central database combined with a validation workflow. All changes to the system must be submitted to the central database and the central database provides files to make modifications to all systems.
Let's imagine a process engineer, Joe, that wants to delete few items in his Control System:
- Joe uses the provided spreadsheet ( that is very formal) and fills the items that he wants to create/delete
- Joe then goes on the Web Portal and pushes the spreadsheet
- The engine analyses the "requests" and will report with possible conflicts
- If no conflicts, Joe can then do his modifications by using the file generated by the engine. If there is a conflict, Joe will need to adapt his request accordingly.
- Since the engine is generating all modifications, it contains the current state of all system layers ( control systems, historians, quality control databases, etc... ). The engine tracks reporting and formulas and can report the data flow for every value.
- All systems are modified by the configuration provided by the engine. I.E. the engine would provide the PI Config Scripts to delete/create/modify PI Tags, a script to modify the DCS etc.
I have seen another application in an oil company where people created a search page for performance equations, and once you clicked on it you could see values of all its related tags. And drill down on dependent PE's.
I think that doing the same "on-demand" logic may be possible in your situation.
For the application you suggested I would think that you can omit to get the interface list, because with the points sources should have enough information already (if not this is easy to change).
List<Dictionary<string, PIPointList>> ServersTagList
For each PI system
Get a dictionary<TagName,list<pipoint>> of tags that correspond to all its PIToPI interfaces (to do that you could use the pointsources naming ex: pitopi*). This dictionary is then added to the ServersTagList
//i.e. var serverTags = new Dictionary<string, PIPointList>();
// the PIPointList will contain at this point: 0 - the tag object itself
// in the next steps, will be added other tags as we find them: i.e. 1 the source tag server A, 2 source tag server B, etc...
For each item in ServersTagList
for each tag in dictionary
Check tag type (normally we already have only PItoPI Tags)
Get Source Tag Name from the tag configuration
use the TryGetValue method to get the tag from other dictionaries
if you find the item, add the the Found tag () into the current tag PointList.
How many tags are concerned by this check?
Hope this helps!
In a perfect world, scenario 1 would be ideal, however, since the system spans almost 100 PI servers and a few million tags total, that isn't going to happen.
But, I asked for feedback before more eys can help find solutions.
Whatever is decided, I will advise.
Please be aware that the logic I provided cannot scale to millions of tags, you'll need to split the problem in smaller chunks (you may be already aware of that, if not we can discuss it further).
You can come back here at any time if you have more questions.