Autonomous Site Operation

Large scale installations of system:inmation can face challenges when relying on a single Core component to direct all the data flow for a global network of sites. Continuous connection between all global sites is not always guaranteed and if there is an outage or break in communication between a single central Core and for example, a remote Connector, the site could feasibly be offline for an extended period of time. This would mean on-site history queries would be unavailable, data archiving would cease and system updates would be unavailable. By creating local Core components for global sites that sit beneath an overall Master Core component, the site can operate with autonomy, whilst continuing to maintain the benefits of a centralized system.

The installation of Local Core components, enables separate sites to operate autonomously during disconnection from the central Master Core installation at headquarters. Local Cores operate with their own MongoDB Data Stores that are accessible site-wide, during offline events. The gathered data is kept in the Store and Forward buffers of the Local Core and Connectors until the targeted System and Local Data Stores have archived the data.

Autonomous Site Operation - Local Cores
Figure 1. Autonomous Site Operation - Local Cores

The Local Core components can be accessed as separate entities using DataStudio and the Web API. This allows for on-site access to the Core and locally stored historical data, even during global outages. The Local Cores make use of the Custom Time Series Data Store feature to archive data locally as well as in the central System Data Stores. This enables data to be persisted locally and avoids potential data loss if the System Data Store is offline for long time periods.

Local Cores services can be installed using the Window Installer or from the command prompt.

Hierarchy between Master Core and Local Core

Local Cores running below a Master Core are the children of the Master Core object in the hierarchy. A user connected to the Master Core can create/update/delete objects beneath the Local Core. However, in the opposite scenario (user connected to a Local Core), the user would not be able to perform the same actions below the Master Core object.

If connected to a Local Core (for example with a client application like DataStudio), the user is able to view the Master Core and System objects in the I/O Model but cannot view any other children below the Master Core unless they connect directly to the Master Core.

Another limitation is that operations such as deleting objects, can only be done on a Master Core level when connected to the Master Core with the necessary credentials.

When connected to a Local Core using the system owner profile, the user is able to configure properties on the Master Core and System objects. To add restrictions for Local Core users, profiles with specific object level security limitations can be created in the Access Model.

Local Core’s share Model Panels with the Master Core. Servers can be configured to connect directly to the Local Core and will be visible in the same Server Model as the Master Core.

In the ISA-95 Equipment Model, Site and Area objects can be linked to Local Core objects through the Code Execution property.

Local Data Store archiving

Data producing items beneath Local Cores will automatically archive data in the System Data Stores of the Master Core, by turning on the Raw History archiving option option.

To configure Local Cores to archive data both locally and in the System Data Stores, the user can create and configure Custom Data Stores objects below the Local Core object. The Data Store Sets property on the Master Core is used to configure the combinations of Data Store archiving required.

With this configuration, the Local Core can autonomously exist without a Master Core connection and still be able to archive and retrieve historical data. Also clients connected to the Master-Core will be able to retrieve data created in the Local Core.

Local Cores can also query data from any data store connected to the system including the System Data Stores and Custom Data Stores on any other Local Core.

Local Cores under Relays

Local Cores can be created below Relay objects in the system, where the Relay is below a Master Core object. This enables the system to be set up in such a way where data can be forwarded from a Local Core running in the Manufacturing layer for example, through another transition layer where a Relay service is running, then onto the Master Core running in the Enterprise layer.

Autonomous Site Operation - Local Cores under Relay objects
Figure 2. Autonomous Site Operation - Local Cores under Relay objects

For more information on how to install and configure Local Cores under Relays please read the How-to instructions in the DataStudio documentation.

Local Core Logging and Log Storage

Local Cores can store and retrieve logs generated by itself and child components. The Local Log Store settings can be configured to use MongoDB or SQLite for local storage (choosing "MongoDB" means that a MongoDB instance should also be configured). The default for new Local Core installations is "SQLite".

The Log Mode property on the Local Core is used to configure whether the log messages will be stored locally (STORE), forwarded to the parent component (FORWARD) or both (STOREANDFORWARD). Please read about configuring the System Logging Data Store to understand how the logs are stored if forwarded to the parent component.

Any issues with MongoDB connectivity (even in FORWARD mode involving) will be indicated on the Local Core Component by a Warning and accompanying log message.
Log Store Configurations for Local and Secondary Cores
Figure 3. Log Store Configurations for Local and Secondary Cores
MongoDB and SQLite for Logging

It is important to note that using SQLite for the Logging Data Store may require more disk space than using MongoDB. In addition, if the Logging Data Store is configured to use SQLite, when a large number of log records (~250000) are stored in the Logging Data Store, the disk usage for SQLite will start to exceed the disk usage of MongoDB for the same amount of records. Using the General Log Retention property, the frequency in which logs are purged from the Logging Data Store can be configured.

Variations in query time are dependent on the configuration and hardware of the System and therefore, the overall performance of the query time for the Logging Data Store should not be largely affected by using either MongoDB or SQLite for the Log Store Backend.