Platform Services

PlatformServices provide the station’s perspective on its host platform. They act as the station interface to specifics about the host platform (whether a controller or a PC).Unlike the various platform views, a platform connection is not needed to access PlatformServices. Instead, you need only a standard station (Fox) connection.

A station user with admin-level permissions on the Services container (in the component Config space) of a running station also has access to a special subset of platform functions, via Platform Services.

Under Config, Services, every running station has a PlatformServices container, which any station user, with admin-level permissions to this component, can access. PlatformServices are built dynamically at station runtime—you do not see PlatformServices in an offline station.

Figure 1. Example of a station’s PlatformServices


PlatformServices and all child components are unique from all other station components. In a running station they provide two main types of functionality:

  • A subset of the platform views that are available in a platform connection. These services do not provide the full set of functions available in a platform connection. For example, you cannot install or upgrade software, or transfer stations and files. However, a number of platform configuration views are available.

    Apart from configuration usage, some PlatformServices provide status values that you can further incorporate including built-in alarm features. Usage is typical for power monitoring.

  • Certain platform configuration settings are accessible only through PlatformServices and are not available in a client platform connection.

Changes you make to PlatformServices and all child services are not stored in the station database. Instead, changes are stored in other files on the platform, such as its platform.bog file, or within the platform’s operating system. The changes are independent from the running station. Do not attempt to edit the platform.bog directly; always use PlatformServices’ views.

If you install another station, PlatformServices are dynamically recreated again when the new station starts, based upon the last settings.

Some PlatformServices changes may require you to reboot the host to become effective. Examples include: TCP/IP changes and some NTP-related changes in a controller. A Reboot Now? window opens upon saving such a change.

Note: When you design station security, be careful about assigning user permissions to PlatformServices and its child service components. In general, you should regard this portion of the station as most critical, as it allows access to items such as host licenses and TCP/IP settings. Furthermore, right-click actions on the PlatformServices include Restart Station.
Table 1. Platform Services
Service Platform Description
CertManagerService both PC and controller Manages PKI certificate stores and/or allowed host exceptions, used in certificate-based TLS connections between the station/platform and other hosts.
TcpIpPlatformService both PC and controller Provides access to the same configuration using the platform’s TCP/IP Configuration view.
LicensePlatformService both PC and controller Provides access to the same configuration using the platform’s License Manager view.
SerialPortService controller only Allows review of available serial ports on the host platform.
NtpPlatformService controller only Provides the Niagara 4 interface to the NTP (Network Time Protocol) service or daemon of a controller’s OS (QNX), including several configuration properties and a list specifying one or more NTP time servers.
DataRecoveryService controller only Monitors the service that automatically creates and manages static RAM buffers in the controller, allowing battery-less operation (if so configured), or usage of the SRAM along with an installed backup battery (if applicable).
HardwareScanService controller only Provides a graphical diagram of communication ports and other features on the hosting platform, including callouts to a table that explains the location, description (such as COM2), port type, and status/usage of each item. This optional feature requires the installation of the modules platHwScan and a corresponding platHwScan<type> where <type> is a controller model.
SyslogPlatformService both PC and controller Provides a standard protocol for message logging. It allows messages that are generated by Niagara to be stored and analyzed on a remote server.