·The Sergregation between ALARM and GROUP is important to:-
·To know which is an Alarm and which is a Group from the Alarm Report
·An Incorrect DCS MAP File will cause the Channel Fail to start. It is therefore important to ensure the XML code is correct. E.g:-
·Comments must start with “<!--“ Comments and ends with “-->”
·Valid Values for TYPE
·Valid Values for EngType
·Valid values for Field Type
·Priority Map Node Names Must be
·Discovered on 16/8/2011, not all cases where channel failed to start is due to DCS MAP FILE Failure… sometimes the sync service just becomes out dated. Resaving the settings in the ‘Manage Channels’ page would solve this. Discovered on 12/10/2011, resaving the DCS MAP file solved the problem
·The Name attribute
·Indicates the type of tag
·Must match up with the Rules File (.rbf) TagType in the MOC rules builder
·Will be displayed in the AM MOC Tag type
·The Classification attribute
·Is used for the Alarm Point Type Distribution By Area
·This report answers the question of how many alarms are configured per tag (alarm/tag); which is then segregated by tag type
·The Value would normally be
·The <PARAMETER> child node
·lists down all the parameter to be scynchronized.
·If synchronizing from OPC, the Name attribute it must match the OPC Parameter Name (Such as PV,OP,PVHHLIM and etc) (Not the name in the rules builder). The parameter should be browsable from the Rules Builder
·The FieldType attribute determines the type of parameter. It must be either:-
·No Values (Default)
·Priority ç Alarm Priority, needs to synchronize
·TripPoint ç Alarm Set Point, needs to synchronize
·Unit ç Name of Unit
·Desc ç Appears in the Description Field
·[CHECKED ON 13/10/2011] The ‘DESC’ value is put in to Tell MOC that this is what needs to appear in the Desciption field in the web report. If there are more than 1 field having the ‘DESC’ value, the LAST ‘DESC’ field will be used in the the Description web report
·TagLevelAlarmStatusç Enabled State of Alarms
·E.g. if <Parameter Name=”AlmEnable” FieldType=”TagLevelAlarmStatus” TagLevelAlarmStatus = “1” />, this means that whenever The AlamEnable parameter is read as 1, it means this alarm is enables
·This is important for the disabled alarm report
·Note that this is for the TAG LEVEL. Meaning that if this parameter matches 1, the whole tag is considered inhibited (All Alarms Disabled in the tag). It is not for individual parameters within the tag being disabled
·I did an experiment where I had several parameters with TagLevelAlarmStatus. Only when all of them does not match the TagLevelAlarm Status (i.e. = 0 in this example), will the tag be registered as disabled or inhibited in the report. However, for the Tag to be enabled back (cleared from the disabled report), only > half the number of the alarmtaglevelstatus need to be activated.
·The EngType Field is a parameter setting to be used in the TagBrowser. It also effects the discrepancy report.
·Ignore – This is by Default (if nothing is specified). For this, the parameter is excluded from the discrepancy report
·Value – If this is specified, then the user can enter only a single value (in the Min field). If the value does not equal this value then it is considered a discrepancy
·Range – If this is specified, then the user can enter the Min and Max Eng value, as long as the actual value is between this, it is not considered a discrepancy
·Issus on Disabled Alarm
·Now what if an Alarm is disabled? By right it should not be shown as a discrepance if it is disabled. MOCCA takes this into account.
·By default MOCCA, assumes all alarms that has Severity value not in the priority map as disabled.
·As shown in the sample DCS map above, all alarms will be under an <Alarm> node and this node contains the severity.
·<ALARM Name= “PVHH>
·<ParamRef Parameter=”PVHH_LIM” />
·<ParamRef Parameter=”PVHH_SER” />
·By Default, If the priority value = ‘0’ then the alarm will be disabled.
·Additional disabling can be added by adding configured expressions e.g. Note that PVHHALMEN does not need to be configured in the ParamRef for this to work
·<ParamRef Parameter=”PVHHALMEN” /> ç Can be removed and still work
·In the MOCCA TAG Browser in OI, alarms which are enabled will be bolded
·The <PRIORITY> Child Node
·Is used to determine the Alarm Priorities available in the system.
·MOC has defined by default that alarms should be categorized as
·Hence, the priority map node must only be restricted to these values. A DCS Map file error will occur if the node values are not within these values
·This can be changed by (Have not researched this yet)
·The Value in the DCS map determines which value should map to that priority. This priority mapping value will be applied with parameters with FieldType=Priority
·IF there are more than 1 value which represents a particular priority. The node can be extended as follows:-
·Note that the value cannot be null or it will cause an error
·The priority map having emergency, high, medium, low is only important for the
·Priority Distribution By Alarm Condition Report
·Priority Distribution by Area Report
The VB SynchronizationScript
·After you edit a VB script, one does not need to restart synchronization. Tested on 12/10/2011, even if you edit the script while a MOC browse is occurring, the changes effect immediately
·The sync script must have the ProcessTag() subroutine and this must be executed
·In this script, the object Rawtag is exposed. This tag can be modified as follows
·Rawtag.DCSID – Get
·Rawtag.Name – Get, Set
·Rawtag.Qualifier – Get, Set
·Rawtag.Type – Get, Set
·Rawtag.Network – Get,Set
·Rawtag.Area – Get,Set
·Rawtag.Unit – Get,Set
·Rawtag.Parameters – Get,Set
·Rawtag.Parameters.Item(“PVHH_SER”) – Get, Set ç The ParameterName is called here
·The get items work for items not declared in the DCS Map
·The get item however does not work if the Parameter is not defined in the parameters section of the rules builder
·The rawtag Parameters.Item
·Note that the Sync Script is not persistant. The entire script (Outside and inside the processtag procedure is executed every cycle). Variables are not pass on the next execution. This is unlike AM
The VB MOC Structure Script
·The MOCCA structure script is a VBScript which invokes the procedure ProcessMOCStructure everytime it reaches a branch which satisfies the requirements outlined in both TAGDEFINITION and TAGTYPE (i.e a particular tagtype is identifier). THIS IS IMPORTANT!!!. The MOC Strcuture script is not executed at a branch that does not satisfy a tag definition
·This script is at every branch or movement of the OPC browsing while the Tag Update Synchronization is done.
·In this script, the object MOCStructure is exposed. This object holds
·TagCount ç Number of Tags in the Structure (As long as it fits the tag criteria defined in the Rules RBF file)
·ParameterCount çNumber of Parameters in the Tag
·TagType ç The type of tag as defined by the Rules (RBF)
·Name ç This is the Name of the Parameter, as it appears during MOC Browsing using MOC Rules Builder. In the Example Below the Item(x).Name (or Parameter Name) is “ALARM”. This NOTE : This Parameter Name is used in the Parameters Identification in the MOC rules builder
·ItemName ç This is the full OPC Item Path. It is the same path which is declared in the ODH Source Name Column. It can be used in VB scripts to make the OPC Call [TESTED ON 30/8/2011]. This is it’s true location
HarmonyNavigation/RootUnit/U-Batch and Chem Prep Harmony/U-Batch Mill Harmony/U31-Digesters/ILBP2:TYPE
(In this case the Parameter Name is TYPE. The “:” becomes a separater between Path and Item)
(In this case the Parameter Name is PV)
·Synchronize ç Set ad “true/false”. If false, item is not synchronized
For this reason, one can use a BLANK DCS MAP FILEand A BLANK MOC SYNCRONIZATION SCRIPT [TESTED ON 30/8/2011]
Blank DCS Map File:-
Blank Sync Script:-
Private Sub ProcessTag()
·NOTE, THIS WAS TESTED on 15/8/2011
·The ProcessMOCStructure script AND ALSO THE ProcessTag (Synchronization Script) execution is not persistent. If you declare a global variable (i.e. Dim X) outside the procedure, use it in the ProcessMOCStructure subroutine, it will not maintain the last value of X on the next execution.
·TESTED ON 12/10/2011 on the MOC Synchronization script: The code executes everything outside the procedure vs before going into the procedure. Therefore the object created need to be destroyed in the Process Tag Function (Set FSO=Nothing).
·The entire script is executed, on every MOC branch step. The top part, and also the script inside the ProcessMOCStructure. This is unlike AM where only the ProcessMessage() is executed for every step and the TOP part (normally used for object declaration) is executed at the start only once
·For A GLOBAL Variable, it needs to be declared outside the ProcessMOCStructure. If it is not declared outside, any assignments done to it inside the ProcessMOCStructure will not be passed to other subroutine..
·Execute periodically. Executes also every time the service is started
·SQL server stores, all OPC item names (or paths). Performs the following query on SQL server, to get the item names
AMTag.Name as TagName,
AMOPCParameter.ItemName AS ItemID,
AMOPCParameter.Name AS ParameterName,
AMTag innerjoin AMOPCParameter on
AMTag.DCSID = 7 AND
and HMTP = 0
·Quickly grabs all OPC values from the results of this query
·Does not browse the OPC tree structure
·(And therefore) Does not invoke MOC Structure Sctipe (ProcessMOCTag)
·Below is how the Synchronization Log File works when regular update is done
·Execute Periodically as well
·Executes also every time the service is started
·Invokes the tag update synchronization script (Process tag), updates everything
·Invokes MOC Structure Sctipt
·Browses the OPC tree structure. This causes it to take longer!
Triggering the Synchronization
·Sometimes when restart service, both tag and regular update is performed if, scheduled start time is less than current time. If this does not work, play around with the manage channels. Change the time start to 1 minute later and save
·You can turn off the regular update and fast update cycle if you are only interested in the tag list update
·Regular Update Started
·Start of Tag list Update
·Tag List Update Completed
·Regular Update uses the data obtained from SQL to perform the update. The processing tag is done immediately (Invoking the Process Tag Script)
·Regular Update Completed
·Reasons Why Browsing Fails
·The start path is configured in rules builder (There is a bug here (26/07/2011).Removing in rules builder may fix it
·The tag definition in OPC item is not configured correctly (TAG DEFINITION IS CASE SENSITIVE!).
·Sometimes the regular update does not browse the tree. To fix, this you can play around with the options in the MOC Rules builder. There are 3 ticks (8 combinations). Changing this will have immediate effect on the program browsing (witnessed on 22072011)
Process Tag Synchronization scripts
·Installed in the process tag
·Tag is deleted using the MOCCA Excel Interface. Once a Tag is deleted, it should immediately dissappear from the plant hierarchy (no need to refresh netobjects or whatever)
·Tag list update will rebuild the tree
·If a tag is already configured and the area need to change, the tag must be deleted first. Tag is deleted using the MOCCA Excel Interface
·Once the tag is deleted, when it is re-imported back, thenew object trees will be rebuilt.
·Note that the Net Object tree does not need to be deleted for this, only the tag
The rules builder is used to build an “rbf” file which contains the rules on what items to take and classify when MOCCA parses through an OPC server
·Note 1 2/2/2011 MOCCA 3.0.4 – The Set Start Path doesn’t’ work don’t bother to use it
·You can prevent the OPC server to go through an entire branch by right clicking => Exclude Branch
·You do not need to restart the synchronization service after the rules file has been changed.
The rules is structured into 3 parts
·In an OPC structure there are many items (e.g. Alarms, Status, Tags, etc). This definition is used to identify which OPC structure is a tag.
·Rules can be built to determine a tag based on
·Important! Take note that the OPC Item is not the parameter name or parameter item name, it is a hierarchy name based on the browse where each branch is separated by a ‘\’ . For this it is imperitave to take note that the Operator equals may not work for OPC item. One should use the endswith term instead.IMPORTANTTIP!!: To get a more precise rule. Use set the OPC Item rules as “Ends With \BAL” (For selecting only BAL parameter)
·The OPC Items need NOT BE DECLARED in the Parameters Tab of the Rules Builder for it to scan an OPC Item [TESTED ON 20/8/2011]
·Each Rule by default is an “AND” Operator. If one opens the RBF File, under <Tag Ident><Criteria> node, there is a possibility to change this from and “AND” to an “OR”. This change unfortunately does not work (as of 27/7/2011)
·The Path to Next…
·Is used to determine where is the tag. Typically it’s “..” means that the tag(name) is a parent to the node
·The Maintain Tag Types Hyperlink
·Tag types must be declared here. There are many tag types such as for a yokogawa system there are PVI, PID, PVO and etc.
·TagType and Parameters Definition
·The tagtype declares a rule of which of the tags belong to the defined tag type.
·The rules has lines, each line is and AND operator. If no rules are configured, here (i.e. no parameter or tag lines), no tags will be detected
·By Default, a tagtype “Default” is already created in a freshly opened rules file. This “Default” tagtype cannot be deleted Using the MOC Rules builder. It can however be deleted by directly deleting the tagtype node in the RBF File.
·NOTE!!! The “Default” Tag type will captue any tag even though nothing is declared in it’s parameter. By right one should not allow default tags to be synchronized
·To declare this part one can declare MOC Node Type by Parameter or By Tag
·By Parameter –
·If one selects this, one needs to define the parameters first on the parameter tab.
·IMPORTANT!! VERIFIED 22072011 The Name is actually the Parameter Name, which does NOT include the path.
·Table above shows the difference between parameter name and parameter item.
·The parameter tab is used to define the rules for which parameter is selected. Since we have selected the tag in tag definition, in the parameter tab, we need to select which parameters we need. An easy way is to take all parameter and define a very generic rule (such as ends with “”), this will results in the system browsing all tags including the tags we don’t want. (This does not effect the tag browser report as the tag browser report is based on what is configured in the DCS Map file). Picture below shoes this. All Parameters are highlighted green indicating all parameters have been selecting with this generic rule
·Each line in the rule is an OR parameter.
·Important! Take note that the OPC Item is not the parameter name or parameter item name, it is a hierarchy name based on the browse where each branch is separated by a ‘\’ . For this it is imperitave to take note that the Operator equals may not work for OPC item. One should use the endswith term instead. In the example above, the BAL parameter OPC Item is = Blablabla\Program\AC38_002\BAL. TIP: To get a more precise rule. Use set the OPC Item rules as “Ends With \BAL” (For selecting on BAL parameter)
·Once the parameter tab is done, the TagType tab is done next ( and yes, we do the second tab first ). Since we have selected the only parameters we want from the parameter tab, we can tell MOC that a certain tagtype must have these parameters. Each line in the parameter rules in an AND operator
·The TagType parameter works line-by-line, it first searches the first tagtype and how it is defined (as explained above, by specifies what parameters it have). If the tag type is taken, it accends down accordingly.
·Example is that a tag type PID, must have parameter P, I, and D. SO we specify “Ends with P”, “ends with I”, and “Ends With D” as tag type rules. If say MOC finds a A tag wouthout any P,I or D, in then checks the next tag types.
·Identification by Tag is basically based on the tag name (have not tried this yet)
Alarm MOC Excel Plugin
·You can install the Excel Plugin by downloading the plugin from OI
Save and check the control drawing
Open-Plant is a revolutionary Industrial IOT Platform software, used to create and deploy Industrial IT apps/solutions. It is an all-encompassing solution offering both back-end and front-end components i.e. the full stack. From our user's experience, creating and deploying Industrial IT apps became 10x faster and 10x less cost. We serve the mining, energy, oil & gas, construction and manufacturing industry.