Why the move from MDB to PI AF

PI Server 2010 (PI Data Archive 3.4.385) introduced Module Database to AF synchronization. The Module Database (PI MDB), a tool to create asset models, has been superseded by PI AF which provides much wider functionality and overcomes PI MDB limitations in scalability and accessibility. This section explains a few of the key reasons for the move from PI MDB to PI AF.

PI AF is far more scalable than PI MDB. Each Data Archive server includes its own separate database that cannot be accessed from other Data Archive servers. This results in a set of disconnected databases. If you add a new Data Archive server to your site, you need to create a new PI MDB for that server.

PI MDB cannot be shared between different servers

PI AF provides a single database to which any number of Data Archive servers can connect. The PI AF database can include PI data, as well as other data. With this model, your asset database can grow and expand as you add new servers.

PI AF can be shared between different Data Archive servers

In addition to the scalability inherent in the fundamental PI AF architecture, PI AF provides a range of powerful features:

• You can manage your metadata in a simple and scalable way. PI AF provides a sophisticated template feature that allows you to manage your metadata globally. When you make a change to a template, the changes are automatically applied to all the objects that use that template.

• Enables you to access non time-series data. PI AF allows you to access data from systems other than the AVEVA™ PI System™.

• You can integrate notifications and asset analytics.

• With asset analytics, you can configure notification alerts on event frames and set up trigger conditions to have notifications sent to email addresses. You can also configure notifications to escalate if recipients do not respond in a specified period of time.

See Getting started with PI AF for more about PI AF.