OSIsoft Message Format (OMF)
Welcome to the OSIsoft Message Format feature suggestion box. We created this forum to hear your ideas, suggestions and feedback. For more information on OMF, please refer to: https://omf-docs.osisoft.com
Please suggest your most important features and design change ideas on this site! Also vote for your favorite features now! We welcome your feedback.
Please note that your ideas and comments posted here are visible to all other users.
- For bugs, please open a case with OSIsoft Tech Support through myOSIsoft Customer Portal (https://my.osisoft.com) instead of sharing them on this site.
- For documentation feedback and bugs, please report to documentation@osisoft.com instead of sharing them on this site.
-
Allow Definition of Point Attributes via OMF to PI Web API
When creating containers via OMF the PI Points are created with default Point Attributes - if these need to be changed it is a manual process to subsequently change the attributes appropriately. As OMF solutions can be easily deployed it would be useful to be able to define in the OMF type what the attribute values should be.
Attributes of key interest are:
Zero and Span
Exception and Compression
DisplayDigits
StepThis would allow of the data to be collected in the most efficient way without manual intervention.
17 votes -
OMF: Time Range / Events / Spans Support
Support the concept of time ranges / events EFs / spans as a pre-defined type in the OSIsoft Message Format (OMF) spec.
15 votesFor the spans implementation, let’s consider implications on PI, OCS and EDS. E.g. how does the data source represent spans and/or how does the OMF application recognize these spans? Who / what uses the span data? How does the thing using the span data represent a span and associated data? Do we have scenarios with non-time based spans for OCS and EDS?
-
OMF: Data Quality Support
Add a data quality keyword to the OSIsoft Message Format (OMF) spec and allow specification of a data quality format.
15 votesPlanned for OMF 1.2
-
OMF: Unit of Measure (UOM) Support
Support units of measure for types and streams in the OSIsoft Message Format (OMF) spec.
14 votesCompleted in OMF 1.1 for Types. Planned for OMF 1.2 for Containers.
-
Support an analogue to the "step" PI Point attribute when creating PI Points
Even though it will indeed be useful to be able to specify whether data should be retrieved in a step-wise fashion, for new PI Points (assuming you're writing data to a PI Connector), it's important to be able to specify that those tags should have the step attribute set to true, so that the step option is set at the central, database level where it can apply to all users who query that PI Point.
9 votes -
OMF: Digital State Tags
Would it be possible to adapt the PI WebAPI and OMF to accept digital state tags? For example, 0,1,2,3,4 which can be mapped to named values “open”, “closed”, “half”, “fault”, etc?
7 votesThis feature is planned for OMF v1.2. See “enum” Types
-
OMF: Ability to patch data messages
Add the ability to provide partial information for an existing data point. This is meant as a partial update which replaces values for some properties of a type without affecting others.
6 votesPlanned for OMF 1.2
-
OMF should accept the use of special characters like / : @ ! + % < > ( ) when writing to PI WebAPI OMF endpoint
The OMF 1.1 spec does not allow certain special characters that are indeed accepted in the PI Core system like these here: / : @ ! + % < > ( )
When OMF is used to write to PI Core via the PI WebAPI OMF endpoint, this hinders the migration path of older PI Interfaces toward PI Adapters or EDS since in this use case we would want to continue writing to existing PI tags that could bear in the name (aka StreamId) these special characters.
5 votes -
OMF: Property Bags
Allow reuse of a set of properties for multiple type definitions in the OSIsoft Message Format (OMF) spec.
5 votes -
Clearly state that a Data message cannot include both a container ID and a type ID
Right now, the documentation:
https://omf-docs.readthedocs.io/en/v1.0/Data_Messages.html
Mentions that "For each object, either typeid or containerid must be specified". However, it does not clearly state that you CANNOT include both in a data message, even if either the typeid or containerid is null (and the other is non-null). It's a minor distinction, but it helps prevent folks from trying to create a base class for a data message that includes both a typeid and containerid.
4 votes -
OMF: Container-level overrides
Ability to override Type-level property keywords on a Container level.
2 votesPlanned for OMF 1.2
-
Support TLS 1.3 and enable HSTS on omf-docs.osisoft.com
These changes will make the website faster and more secure.
See the link below for more details:
https://www.ssllabs.com/ssltest/analyze.html?d=omf-docs.osisoft.com1 vote
- Don't see your idea?