The TSENTRY Screen Explorer, or Texplore, is the application used to display HMI screens to a user.  Texplore is simply an application for browsing the TSENTRY HMI subsystem, much like Internet Explorer is an application for browsing the Internet.  Texplore provides much of the common framework for an HMI such as connecting to a TSENTRY host, reading the HMI configuration file, providing a login screen, and managing the navigation between screens within the HMI application, but by itself does not define any specific HMI screens.

Texplore relies on several processes running on the TSENTRY controller to provide it with information as it operates as the HMI client browser.  These are:

• The NtRtInfo service, which exposes static information from the TSENTRY controller to client objects in a request/reply architecture.

• The Tsecurity service, which provides authentication and authorization services to client objects.

• The GsmOpcSvr process, which exposes the values of individual variables in global memory on the TSENTRY controller.

• The TrendSrv process, which exposes sampled or trended values of variables in global memory on the TSENTRY controller.

The instructions for installing Texplore on a client workstation are laid out in the Workstation Configuration section.

The following chart illustrates the sequence of events when Texplore is started and loads an HMI application:

An HMI application is configured via a single XML application configuration file.  This file is stored on the TSENTRY host and is retrieved through the NtRtInfo service.  The actual folder on the TSENTRY host in which HMI Configuration files are stored is specified in the configuration file for the NtRtInfo service on the host.

Within this file there must be an <AppConfig> node that specifies the desired configuration for the HMI application

This application configuration file must contain an <AppConfig> node that specifies each of the following basic parameters for configuring the application:

In addition to the above key/value parameters, the <AppConfig> section can also contain several subsections:

• If the EnableSecurity parameter above is set to True, then upon starting the HMI application the user will always be automatically directed to the Login screen.  Consequently, the <AppConfig> section above must also contain a <LoginConfig> subsection to configure how the Login screen is to function.

• If the application is to support multiple languages, the <AppConfig> section can also contain an optional <Languages> subsection to specify various phrases used within the application.

• If custom variables are defined for a given HMI application, the <AppConfig> section must also contain and <AppVariables> subsection to list these variables and define their initial values.

The <ScreenConfig> subsection within the <AppConfig> main section is required to specify any ‘root’ menu screens within the application.  For more information about how Texplore navigates from screen to screen see Browsing from Screen to Screen.

Subnodes in the <ScreenConfig> subsection must conform to the following format:

<Screen ScreenID="MainMenu"
            ClassName="MyNamespace1.MainMenu,MyAssembly1"
            Default="True" />

<Screen> subnodes have the following attributes:

The <LoginConfig> subsection within the <AppConfig> main section is required if security is enabled and the Login screen is to be displayed to the user.  This section specifies the following parameters:

In addition to the above parameters, the <LoginConfig> node should also contain a <Languages> subnode for specifying custom strings (such as the Login screen title) based on currently selected language.  Indeed, it is this subnode that specifies the list of languages presented to the user if the DisplayLanguages parameter above is set to True.

Each of the child nodes listed in the <Languages> subnode corresponds to a separate language available to the HMI system. 

Each language in this table is keyed according to the culture with which the language is specified; consequently, the table key 

The <Languages> subsection within the <AppConfig> main section is used to define language-specific phrases used by the HMI application.  The <Languages> section should contain a subnode for each available language specified in the following format:

<add Language="en">

</add>

The value of the Language attribute must follow the RFC 1766 standard in the format "<languagecode2>-<country/regioncode2>", where <languagecode2> is a lowercase two-letter code derived from ISO 639-1 and <country/regioncode2> is an uppercase two-letter code derived from ISO 3166.

Each of the language nodes should contain a list of key/value pairs where the key is the phrase ID and the value is the phrase given in the current language.  The following phrase IDs are defined by basic Tsecurity HMI functionality:

The <AppVariables> subsection within the <AppConfig> main section is used to define application-specific variables used by the HMI application.  Each of the subnodes in this section should specify the key name of the variable and its initial value.  This variables are all stored as strings within the HMI application.

Example Configuration Section

Following is an example <AppConfig> section for a given HMI application.

<AppConfig>
  <!-- Application settings -->
  <add key="EnableTsecurity" value="True" />
  <add key="DefaultPrivileges" value="Priv1;Priv2" />
  <add key="DefaultCulture" value="en" />

  <!-- Tsecurity settings -->
  <!-- Commenting out the following three entries selects the -->
  <!-- default settings, which is appropriate for most systems -->
  <!--add key="TsecurityHost" value="127.0.0.1" /-->
  <!--add key="TsecurityPort" value="8080" /-->
  <!--add key="TsecurityApp" value="BCS" /-->

  <!-- Screen Configuration -->
  <ScreenConfig>
    <Screen ScreenID="MainMenu"
            ClassName="MyNamespace1.MainMenu,MyAssembly1"
            Default="True" />
    <Screen ScreenID="SubMenu"
            ClassName="MyNamespace2.SubMenu,MyAssembly2" />
  </ScreenConfig>

  <!-- Login Configuration -->
  <LoginConfig>

    <!-- Login functionality settings -->
    <add key="AllowGuest" value="True" />
    <add key="RequireUserIDForGuest" value="True" />
    <add key="PreloadUserID" value="True" />
    <add key="AllowAssumedAuthenticated" value="True" />
    <add key="SessionTimeout" value="2" />
    <add key="PasswordExpirationNotice" value="14" />

    <!-- Login display settings -->
    <add key="BackColor" value="Navy" />
    <add key="TitleColor" value="Yellow" />
    <add key="ForeColor" value="White" />
    <add key="ErrorColor" value="Red" />
    <add key="DisplayLanguages" value="True" />
  </LoginConfig>

  <Languages>
    <add Language="en">
      <add key="LanguageName" value="English" />
      <add key="Tag" value="_en" />
      <add key="Title"
       value="Tsentry Real-Time Process Control System" />
      <add key="UserName" value="User Name" />
      <add key="Password" value="Password" />
      <add key="Domain" value="Domain" />
      <add key="Language" value="Language" />
      <add key="Login" value="Login" />
      <add key="LoginAsGuest" value="Login as Guest" />
      <add key="ChangePassword" value="Change Password" />
    </add>
    <add Language="es">
      <add key="LanguageName" value="Español" />
      <add key="Tag" value="_sp" />
      <add key="Title" value="Tsentry Sistema Control Proceso" />
      <add key="UserName" value="Usuario" />
      <add key="Password" value="Contraseña" />
      <add key="Domain" value="Domain" />
      <add key="Language" value="Idioma" />
      <add key="Login" value="Entrada" />
      <add key="LoginAsGuest" value="Entrada como huésped" />
      <add key="ChangePassword" value="Cambio contraseña" />
    </add>
    <add Language="it">
      <add key="LanguageName" value="Italiano" />
      <add key="Tag" value="_it" />
      <add key="Title" 
       value="Tsentry Real-Time Process Control System (Italian)" />
      <add key="UserName" value="Utente" />
      <add key="Password" value="Parola d'accesso" />
      <add key="Domain" value="Dominio" />
      <add key="Language" value="Lingua" />
      <add key="Login" value="Entri" />
      <add key="LoginAsGuest" value="Entri come ospite" />
      <add key="ChangePassword" value="Cambi la parola d'accesso" />
    </add>
  </Languages>

  <AppVariables>
    <!-- Application variables and default values -->
    <add key="variable1" value="1" />
    <add key="variable2" value="2" />
    <add key="variable3" value="Test Variable 3" />
  </AppVariables>
</AppConfig>

Texplore stores some data in its own configuration file for use the next time the application is started.  The application configuration file is located in the same folder as the Texplore executable file and is named Texplore.exe.config.

Currently, the only persistent information stored in the configuration file is the history of HMI applications to which the TSE program has connected.

Following is a sample configuration file:

<?xml version="1.0" encoding="utf-8"?>

<!-- Configuration file for the Tsentry Screen Explorer -->
<configuration>
  <configSections>
    <!-- Do not edit this section -->
     <section name="TexploreSettings"
      type="TPRI.HMI.Application.Explorer.TexploreSettingsSectionHandler,Texplore" />
  </configSections>

  <appSettings>
  </appSettings>

  <TexploreSettings>
    <AppHistory Host="127.0.0.1" App="TsentryHMI" />
  </TexploreSettings>

</configuration>

The following command line parameters are supported by Texplore:

• /C Host/AppName       
  Automatically connect to the specified TSENTRY host and start the named HMI application.

• /L   
  Run the application using only the locally installed files and assemblies (do not automatically download updated files from the host computer).

• /K   
  Run Texplore in kiosk mode (full-screen without title bar).

• /T path  
  Exit application when user disconnects from host and automatically restart the version of Texplore.exe specified by path.  This parameter should only be used internally by Texplore.

All screens to be displayed in the Texplore environment must conform to the following:

• Each screen must inherit, either directly or indirectly, from the .NET Framework class System.Windows.Forms.Form.

• Each screen must implement the TPRI.Tscreen.ITscreen class interface.

This is required so that the Texplore container can properly interact with and display all custom application screens.

One screen can link to another in a variety of different methods:

• A screen can have a TPRI.HMI.Controls.CmdButton or TPRI.HMI.Controls.LinkLabel object on its display that specifies the ScreenID of the new screen in its LinkedScreen property.

• A screen can raise the ITscreen.ActivateScreen(..) event, which is passed a TPRI.Tscreen.ActivateScreenEventArgs object that specifies the ScreenID of the new screen.

The Texplore application internally has a TPRI.Tscreen.TscreenMgr object that manages navigation between screens.  In either of the cases above, this TscreenMgr object will use the ScreenID name to find the appropriate new screen as follows:

1. If a screen with this ScreenID is already registered in the HMI application configuration file in the AppConfig/ScreenConfig section of the application configuration file.

2. If there is no screen currently registered with the specified ScreenID, the TscreenMgr will check the assembly of the original screen to see if there is a class whose name matches the ScreenID in the same namespace as the original screen.

For instance, suppose the application configuration file has the following <ScreenConfig> section:

<ScreenConfig>
  <Screen ScreenID="MainMenu"
          ClassName="MyNamespace1.MainMenu,MyAssembly1"
          Default="True" />
  <Screen ScreenID="SubMenu"
          ClassName="MyNamespace2.SubMenu,MyAssembly2" />
</ScreenConfig>

When the application is started, a MyNamespace1.MainMenu object will be loaded from the MyAssembly1.dll assembly, assigned a ScreenID of “MainMenu”, and initially presented to the user.  This occurs because this screen is marked with the Default="True" attribute in the HMI configuration file.  At the same time, a MyNamespace2.SubMenu object from the MyAssembly2.dll assembly will be registered with Texplore and its TscreenMgr using the ScreenID of "SubMenu".

If the NtRtMenu screen has a CmdButton on it whose LinkedScreen property is set to “SubMenu”, the TscreenMgr will immediately find the SubMenu screen in its list of registered screens and activate it.

However, if the CmdButton on the MainMenu screen instead specifies “OtherScreen” in its LinkedScreen property, the TscreenMgr will find that there is no screen currently registered with that ScreenID.  Therefore it will check if the MyAssembly1.dll assembly contains a class by the name MyNamespace1.OtherScreen; if it finds one then that screen will be immediately registered, created and activated.  If this class does not exist then the navigation will be canceled.

Consequently, only top-level menus must be specified in the ScreenConfig section of the application configuration file as long as all classes corresponding to screens linked from those menus are located in the same namespace as the top-level menu.

The Texplore application internally has a TPRI.Tsecurity.TsecurityMgr object that manages security for the HMI application.  It is responsible for notifying each screen that is loaded of the currently logged in user and his security access key.  However, it is up to each screen (and each object loaded by each screen) to enable or disable its own components as appropriate based on this security access key.

In addition, the TsecurityMgr object watches the HMI display for inactivity.  If no user interacts with the HMI display for the number of minutes specified by the SessionTimeout key in the AppConfig/LoginConfig section of the HMI application configuration file, the TsecurityMgr will automatically timeout the current login session.  When this happens the Login screen is immediately redisplayed for this user.  At this point if the user reauthenticates again as the original user, he can return to the same point in the HMI application.  If he reauthenticates as a new user then the previous HMI application session will be reset and the user will be log in as if he had not been logged in before.

The NtRtMenu screen is the main menu provided with the TSENTRY system.  The links in the top section provide access to each of the standard screens provided with the TSENTRY system (NtRtMgr, NtRtProcEd, ProbeX, etc.).  At the bottom of the page is a link to the TSENTRY documentation, which starts and instance of Internet Explorer to display TsentryHelp website.

Following is a screen shot of the NtRtMenu screen.

The NtRtMgr screen can be used to view the status of the TSENTRY system.  It provides a web-based interface mimicking that of the NtRtMgr console application.

Following is a screenshot of the NtRtMgr screen:

The top half of the screen displays information about each of the processes in the system.  As in the console NtRtMgr application, right clicking on any of the process names brings up a menu that allows the user to edit process options (via a link to the NtRtProcEd screen), control the individual process (Activate, Suspend, Deactivate, etc.), or control the process group (Activate Group, Deactivate Group, etc.).

The bottom half of the screen is a log of messages sent to the LogMsg message queue by any of the processes.  Messages logged here are also written to a disk file as configured in the system initialization files.

The two buttons in the lower-right-hand corner of the display allow the user to enter his own LogMsg messages.

The NtRtProcEd screen is the HMI version of the process editor form created when right-clicking a process in the NtRtMgr application and choosing the Edit Options option.

Following is a screenshot of the NtRtProcEd screen:

All of the fields on this screen reflect current run-time values.  These values are initialized from the process initialization file when the TSENTRY system is started.

The fields with a yellow background may be edited; those with white backgrounds may not be edited.  Only users with the “Process Edit” privilege may edit the fields on this screen.

Field Descriptions:

• AppName
  A list box containing all of the processes running under the TSENTRY system.  All of the remaining fields on the screen pertain to the selected application name.

• GroupName
  The name of the process group that the selected application is a member of.  This field is read-only.

• UsesNtRt
  Checkbox indicating whether the process utilizes the tpriNtRt library for process management.  This field is read-only.

• BinName
  The name of the binary executable file for the selected application.  This field is also read-only.

• CmdLine
  All command line parameters for the application.  Spaces are allowed.  Quotation marks encasing the entire string of command line parameters are not necessary.

• Run Mode
  “Standard” indicates that this process is a normal Windows executable file (.exe).  “Rt” indicates that this process is an RTX “hard” real-time executable file (.rtss).  This field is read-only.

• Memory Lock
  Checkbox indicating if the process is locked in memory.  This field is read-only.

• Priority
  The priority level of the process.  Please refer to the documentation on the NtRtMgr startup (section 4.1.1) for an explanation of the priority levels.

• Debug Level
  The debugging level of the process.  The debugging levels at the beginning of the list offer less debugging messages and logging, whereas the levels towards the end of the list offer more debug.

• Start Order
  The order number for the process’s start position.  This value is read-only.

• Startup Options
  There are two sections to the startup options:

• Startup Mode
  Processes can either be started automatically when TSENTRY starts or started manually by the user. If automatic startup is selected (the “Auto” radio button is selected), a startup delay must be defined. The delay indicates the number of milliseconds to wait after the last process was started before starting this process.  Valid values are integers between 0 and 10000.  If manual startup is selected, the startup delay box will be disabled and set to –1.

• Automatic Restart
  Checkbox indicating whether the TSENTRY Manager will automatically restart a process if the process exits or dies unpredictably.

• Wait for Initialization
  The amount of time (in milliseconds) that the TSENTRY Manager will wait for a process to initialize itself.

• Termination Options
  Indicates whether the TSENTRY Manager will forcibly kill a process that takes more than the allotted time to exit gracefully after being requested to do so.  If set to “Auto”, the time to wait for a process to exit gracefully may be entered in the “Max Wait” text box.  If set to “Never Kill”, the TSENTRY Manager will never attempt to forcibly kill the process.

• Pulse Timeout
  The amount of time (in milliseconds) to wait for the process to signal a pulse, indicating that it is functioning properly.  If the TSENTRY Manager does not receive a pulse from the process within this amount of time, the Manager will terminate the process.

• Exception Handling
  A series of flags for determining what information to provide in the log about a process that throws an exception or run-time error.

• Write Changes to File
  Checkbox which indicates whether the settings made on this screen should be written to the process initialization file when the Submit button is clicked.

The ProbeX screen is a diagnostic tool that allows the user to “peek and poke” at variables in shared memory.  Effectively, the user can enter the fully qualified name of a variable in global common, and the ProbeX screen will retrieve and periodically update its current value on the display.  In addition, if the user has the rights to do so he can modify the current value and submit it back to the TSENTRY system. 

Following is a screenshot of the ProbeX screen:

Details on the TrendX screen are provided in the section on the Trend System.

Details on the TriggerMgr screen are provided in the section on the Trend System.

Details on the TrendFileMgr screen are provided in the section on the Trend System.