TrendMiner user management overview
One of the mandatory steps during the TrendMiner implementation is the proper definition of data and user management rules. This support article is covering the basic scenarios of the access rights options.
User management
There are 3 options for TrendMiner User Management. Please refer to the dedicated support pages for more information on how to set up these options.
Creation of the local users allows to start using TrendMiner very fast, ideal for a pilot project. Implementation of LDAP/SAML allows to align TrendMiner security with the corporate standards and procedures.
Access management in TrendMiner is configured through the Access Management page in ConfigHub. It is used to map one or more users to specific data sources. Multiple users can be added to specific data sources at once by their membership in a Group. Groups can be created locally in TrendMiner or synchronized from the external Identity Providers (LDAP or SAML).
Typical use case for Group Access Management:
Automatically provide process engineers or production engineers TrendMiner access, including access to their data (and only their data). This could mean one specific historian server, or even more granular, a subset of tags within one historian (especially relevant for large, centralized historian servers)
Some super-users or central engineers are granted access to all data
Active Directory Group Configuration examples can be found in this article.
This combination allows for very dynamic and powerful access management. In the enterprise scenario, it means users can automatically be granted access through the normal identity management process. For example, when a new engineer starts at a plant, through membership of a SAML group, he will be able to log in to TrendMiner and automatically have access to the tags of his plant, without ever needing to create an IT ticket or requesting access to his manager. TrendMiner recommends the platform admin to discuss with the internal IT team to align on the best configuration design.
Unique tag name concept
TrendMiner does not currently support duplicate tag names. When 2 or more tags with exactly the same name are synced to TrendMiner, analytics, calculations and indexing on/for these tags might fail. Unique data source prefixes can be used to prefix all the tag names such that duplicate tags cannot occur between different data sources.
A prefix can be set up during the historian connection configuration. When you want to add more than one historian to TrendMiner, we strongly advise the use of a Prefix name. Note that the prefix will be visible to end users. For example: if the Prefix name is PI then all the tags will appear as [PI]tagname. Try to create an indicate name but keep them as short as possible for readability. For example, if a plant has a unique code like ANT or CHI, those could be a good choice.
For the scenario below there is a matching list of tags for Pump #3 on 2 historians: A and B. A prefix should be implemented on the TrendMiner side to prevent the conflict. Prefix A added to the 1st data source (Historian A) and prefix B added to the 2nd one (Historian B).
 |
Data management scenarios
3 typical scenarios are covered in this article:
Basic architecture with single data source for 1 plant.
Expanded architecture with 1 central site and 1 remote site.
Advanced architecture with shared data sources for 2 sites.
These scenarios are illustrative of the typical situations that range from a single local installation to enterprise setups with data sources spread across the globe.