Runtime profiles for modules

Software modules in Niagara 4 are distributed with a “runtime profile” type, designated by a suffix on the module’s JAR file name. In this refactoring of modules, many now often have multiple runtime profiles.

For example, the alarm module is distributed as three separate .jar files: alarm-rt, alarm-se, and alarm-wb. The runtime profile describes the contents of each JAR based on what systems are able to use them, where rt module JARs are a baseline among all Niagara 4 platforms.

In Niagara 4 and later, each .jar file is digitally signed. This security measure ensures that the content cannot be changed at commissioning time.

The following table lists the types of software module runtime profile types in Niagara 4.

Only a very few modules do not have the –rt extension. One of those is baja.jar.

Runtime Profile

Example module name

Minimum 
JRE Version (1) Dependencies

Description

rt

alarm-rt

Java 8 compact3

Module JARs for data modeling and communications. These have core runtime Java classes only, with no user interface. This is the largest runtime profile group.

ux

webchart-ux

Java 8 compact3

Module JARs for BajaUX, any Java classes implementing lightweight HTML5, JavaScript, CSS user interface interaction, also theme modules.

wb

report-wb

Java 8 SE or 
Java 8 compact3

Module JARs with Java classes for Workbench or Web Launcher user interface; views, field editors, widgets, and so on. Includes Hx and HTML5 Hx views.

se

test-se

Java 8 SE

Module JARs with Java classes that use the full Java 8 Standard Edition (SE) platform API. Currently, these can run on Windows-based hosts only.

doc

platformguide-doc

not applicable

Module JARs without Java code (classes), typically for documentation.

(1) JACE controllers use a “Java 8 compact3” compliant VM, whereas Windows-based hosts use the full Java 8 Standard Edition (SE) VM.

 

Currently, the runtime profile type rt is by far the most common of Niagara 4 software JARs. An inventory of module JAR files by type in one Beta build !/modules folder (4.0.11.0) yielded counts of:

  • *-rt: 378
  • *-ux: 17
  • *-wb: 116
  • *-se: 6
  • *-doc: 20

Where the majority of modules with two runtime profiles had both rt and wb, with only a few modules having three runtime profiles, as follows:

  • alarm: rt, wb, se
  • hierarchy: rt, ux, wb
  • history: rt, ux, wb
  • platCrypto: rt, se, wb
  • search: rt, ux, wb
  • seriesTransform: rt, ux, wb

Niagara 4 module refactoring was done for several reasons, notably:

  • Niagara 4 software module files are digitally-signed, to improve security. This does not allow for module files to be installed with removed content during commissioning.
  • To simplify dependencies between different modules.