Common Conventions: Difference between revisions

From OPC Labs Knowledge Base
No edit summary
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
[[Category:QuickOPC]]
[[Category:QuickOPC]]
With the help of various conventions, we try to make it easier to find and discover the information needed, and understand the components’ internal consistency.
With the help of various conventions, we try to make it easier to find and discover the information needed, and understand the products’ internal consistency.


== Date and Time Conventions ==
There are also more specific conventions, used where appropriate:
* All OPC-related properties that are of {{Style=Identifier|DateTime}} type (and are consistently in UTC) have corresponding properties with a “{{Style=Identifier|Local}}” postfix, which contain the same value but expressed in local time. For example, {{Style=Identifier|DAVtq}}.{{Style=Identifier|Timestamp}} contains a timestamp in UTC, whereas its {{Style=Identifier|DAVtq}}.{{Style=Identifier|TimestampLocal}} contains the same in local time.
* [[Development Conventions]]
 
== Naming Conventions ==
 
=== Common Naming Conventions ===
* In OPC-UA, the name part “{{Style=Identifier|MonitoredItem}}” is used wherever the type or member applies to both Data Access and Alarms and Conditions, whereas the names that use the term “{{Style=Identifier|DataChange}}” apply to Data Access only.
 
=== Type Names ===
In addition to being compliant with common Microsoft recommendations for names, and in the .NET part with Microsoft .NET Framework guidelines for names, we follow certain additional naming conventions:
* Types which are specific to very simplified (“easy”) model for working with OPC start with the prefix {{Style=Identifier|Easy}}.
* Types which are specific to OPC Data Access start with {{Style=Identifier|DA}} (or {{Style=Identifier|EasyDA}}) prefix, types which are specific to OPC Alarms and Events start with {{Style=Identifier|AE}} (or {{Style=Identifier|EasyAE}}) prefix. Types that are shared among multiple OPC specifications do not have these prefixes.
* Types which are specific to OPC Unified Architecture start with {{Style=Identifier|UA}} (or {{Style=Identifier|EasyUA}}) prefix. Types that are shared among multiple OPC specifications do not have these prefixes.
 
Note that the second and third conventions work in addition and together with the fact that there are separate {{Style=Identifier|DataAccess}}, {{Style=Identifier|AlarmsAndEvents}}, and {{Style=Identifier|UA}} namespaces for this purpose too.
 
The above described conventions also give you a bit of hint where to look for a specific type, if you know its name. For example, if the name starts with DA or EasyDA, the type is most likely in the {{Style=Identifier|OpcLabs}}.{{Style=Identifier|EasyOpc}}.{{Style=Identifier|DataAccess}} namespace. Without any special prefix, the type is likely to be in the {{Style=Identifier|OpcLabs}}.{{Style=Identifier|EasyOpc}} or {{Style=Identifier|OpcLabs}}.{{Style=Identifier|BaseLib}} namespace.
 
=== Interface Names in COM ===
As opposed to .NET, every object access in COM is solely made over its interfaces. In COM, after the object is instantiated, you never “see” the object as such – only the interfaces it has. Therefore, at least one additional interface (besides the COM-defined IUnknown and IDispatch) is needed on each .NET exposed to COM.
 
We consistently use following conventions in COM:
* Incoming interfaces have a form of {{Style=Identifier|_''XXXX''}}, where ''XXXX'' is the distinguishing part, e.g. {{Style=Identifier|_EasyUAClient}}, for the {{Style=Identifier|EasyUAClient}} object.
* Outgoing interface (for events) have a form of {{Style=Identifier|D''XXXX''Events}}, where ''XXXX'' is the distinguishing part, e.g. {{Style=Identifier|DEasyUAClientEvents}}, for the {{Style=Identifier|EasyUAClient}} object.
 
The incoming interface are dual interfaces. The outgoing interfaces are dispatch-only interfaces, hence the use of ‘{{Style=Identifier|D}}’ as a prefix.
 
=== ProgIDs (COM) ===
In COM, all our objects have ProgIDs that are identical to their qualified type names in .NET. For example, the main {{Style=Identifier|EasyUAClient}} component resides in the {{Style=Identifier|OpcLabs}}.{{Style=Identifier|EasyOpc}}.{{Style=Identifier|UA}} namespace, and its fully qualified name and therefore also its ProgID is “OpcLabs.EasyOpc.UA.EasyOpcUA”. The main {{Style=Identifier|EasyDAClient}} component resides in the {{Style=Identifier|OpcLabs}}.{{Style=Identifier|EasyOpc}}.{{Style=Identifier|DataAccess}} namespace, and its fully qualified name and therefore also its ProgID is “OpcLabs.EasyOpc.DataAccess.EasyOpcDA”. This convention makes it easy to instantiate COM objects, based on the namespace-qualified names of their .NET counterparts.


== Coloring Conventions ==
== Coloring Conventions ==

Latest revision as of 09:09, 12 January 2024

With the help of various conventions, we try to make it easier to find and discover the information needed, and understand the products’ internal consistency.

There are also more specific conventions, used where appropriate:

Coloring Conventions

We maintain visual consistency in the product by using specific colors for certain functionality areas. This is typically seen in various icons, images and bitmaps.

Green color is used for OPC Data Access.

For example: Image024.png Image025.png Image026.png Image027.png Image028.png

Orange color is used for OPC Alarms&Events.

For example: Image029.png Image030.png Image031.png Image032.png Image033.png

Turquoise color is used for OPC Unified Architecture. Because OPC-UA supports multiple functionalities, the turquoise color is sometimes used in combination with other colors, such as green for Data, or orange for Events.

For example: Image034.png Image035.png Image036.png Image037.png