SCADA Final Aggregator

SCADA Final Aggregator (SFA) is a subsystem usually installed directly in the
host wherein the user interface or third-party applications are installed.

It aggregates all the control and monitoring items, logic
macros and decision rules from all
connected UC and LM PLC controllers into one
place. As a result, the final interface or application doesn’t need to know
on which controller the item is present, it does all the
function calls directly to SFA. Ids of the items should be always specified in
oid form (type:group/id) and be unique in the whole installation.

Example of the controller aggregation with the use of two SFA servers

SFA is set up and controlled with eva sfaconsole application
and SFA API. The API doesn’t have a user interface by default, it’s
developed specifically for certain installation certain installation using
SFA Templates (server-side part) and SFA Framework (client-side
part).

All changes of item status, actions, and logs are sent to the
notification system. In addition, SFA can function as the
notification aggregator e. g. by transferring MQTT messages to
other application via HTTP or redirecting them to other MQTT servers. SFA
usually has several or all available controllers connected. At least one MQTT
server should be installed in the setup to let it work in real time.

Since SFA is a part of EVA platform, its operating principles, settings, and
configuration files generally match the other components.

runtime/sfa_cvars.json variables file

sfa_cvars.json - file containing user variables. All SFA user variables are
directly available in SFA Templates and SFA Framework after login
with any valid user or API key.

The file contains a JSON dict:

{"VAR1":"value1","VAR2":"value2"}

Variables can be changed while the server is running via SYS API as
well as eva sfacvar get and cvar set commands.

etc/sfa_apikeys.ini API keys file

API access keys are stored into etc/sfa_apikeys.ini file. At least one full
access key named masterkey should be present for proper functioning.
Important: with master key and API anyone can receive the full access to the
system similar to root user (or the user SFA is run under), that is why it is
recommended to use this key only in supervisory networks or even restrict its
use to local host only.

Connecting UC and LM PLC controllers

SFA works only with the items known to the controller. Prior to
connecting UC and LM PLC remote controllers, it
is necessary to connect SFA to MQTT server (via its notification
system), to which other controllers will send the events. SFA reads the list of
items, macros,
rules and the initial item status from the
connected controllers; further status updates are performed via MQTT.

For timers to be displayed correctly in the user interface, it is important to
maximally synchronize the system time between LM PLC and SFA, if LM PLC
controllers are set up on the remote servers.

When connecting, it is necessary to indicate minimum URI of the connected
controller and API KEY functioning either as a master key or the key with
access to certain items. If Logic Manager and UC keys are the same, the key can
be set as $key (\$key in the command line). In this case, LM will use the
local key of its own configuration.

Items from remote controllers are loaded at the SFA start and then refreshed
with reload_interval frequency set individually for each connected
controller. If SFA fails to get the item list during loading, it will use the
existing one.

To control the list of the received items you can use eva sfa or
SFA API function list_remote:

When managing the connected controllers, ID should be always provided in the
full format: controller_type/ID (i.e. uc/controller1).

Interface

SFA interface is always specifically designed for a certain installation using
SFA Templates, SFA Framework and SFA PVT. Interface files
are stored in ui folder, interface is available at
http(s)://<IP_address_SFA:Port>/ (redirects to /ui/) or
http(s)://<IP_address_SFA:Port>/ui/.

Startup and shutdown

To manage SFA controller server, use:

eva sfa server start start SFA server

eva sfa server stop stop SFA server

eva sfa server restart restart SFA server

eva sfa server reload restart controller only (without watchdogs)

The controller startup/shutdown is also performed by ./sbin/eva-control
which is configured during the system setup.