Contents

Chapter 1
Introduction

The most important part of the REXYGEN system is the real-time core contained in a software component called RexCore. The RexCore is an independent process in the case of a Windows or a GNU/Linux operating systems, a group of real-time tasks in the case of a hard real-time operating system or a whole system in the case of a microcontroller but it is always the software component where a control algorithm developed by a user runs and from which a device is being handled and which initiates a communication with all other devices in the field that are involved in the control. It also provides a detailed diagnostics or various communication protocols for human-machine interface.

This document contains all the information for configuration of the RexCore software component on Windows or GNU/Linux operating systems that is necessary to put the RexCore into operation or commisioning. A developer of a control algorithm should read [1]. A user that is not yet familiar with the REXYGEN system should read any of getting-started tutorials, for example [2], [3], [4].

It should be noted that although a big effort has been put into making the RexCore as unified as possible on all supported platforms, it is principally not possible to provide absolutely the same functionality and performance on all devices and environments. A user should consider the targeting platform very carefully and eventually consult his needs with the REX Controls company.

Chapter 2
Configuration

The RexCore itself requires only a very limited interaction with a user. In fact it needs no interaction at all when a standard installation or distributing channel is used and a default configuration is sufficient for a user. It is however often necessary to adjust the default configuration or secure the control system when commissioning or sometimes even during the development.

2.1 Location of Configuration Files

All files that are required for the proper operation of RexCore are located in a configuration directory. The configuration directory is /rex/rexcore in the case of GNU/Linux or in the REX Controls directory in the All users profile in the case of Windows, which should be C:\ProgramData\REX Controls\REX<version>\RexCore in most cases.

Following files may be present in the configuration directory:

• license.txt – A file containing licensing keys for the device. It may be placed manually by a user to the device, but using a REXYGEN Studio or REXYGEN Diagnostics tools for licensing operations is most common.
• exec.rex – A binary file with the control algorithm configuration. A user should not touch the file unless he or she knows exactly what to do.
• hmi.rex – A binary file with the Human-Machine Interface configuration. A user should not touch the file unless he or she knows exactly what to do.
• auth.rex – A binary file with the configuration of users, groups and permissions. A user should not touch the file unless he or she knows exactly what to do.
• rexcore.cfg – A textual file for RexCore with all configuration options that are available and which may be adjusted by a user. A detailed options description is provided in section 2.2.

2.2 Description of Configuration Options

A configuration of RexCore is done by modifying configuration options in the rexcore.cfg file. Each configuration option should be on a single separate line and should have a format option=value with no additional spaces or tabs. A following table contains descriptions of all configuration options.

Chapter 3
System Log

The RexCore has an integrated system log to which all diagnostic messages are stored. Diagnostic messages are errors, warnings or informational messages that may have impact on execution of a control algorithm.

Each message that is written into the system log has an information about a date and time when it was written and flags that indicate a source subsystem and a severity of the message.

3.1 Sources and Severities

Following sources of diagnostic messages exists in the REXYGEN system:

• OS - operating system abstraction layer,
• CORE - real-time core,
• DIAG - diagnostic subsystem,
• BLOCK - function block algorithms,
• IODRV - input/output a communication drivers.

Following severities are distinguished:

• Error,
• Warning,
• Information,
• Verbose information.

See [5] for more information on how to configure the system log.

Chapter 4
Web Interface

Starting with version 2.50 of the REXYGEN system, a highly optimized web server is integrated directly into RexCore. The server listens on port 8008 for HTTP connection and on port 8009 for HTTPS connections by default. A certificate and a private key must be installed to enable HTTPS connections. See chapter 6 for more information.

Although a big effort has been put into stabilization and testing of the integrated web server, an unexpected error may possibly have an impact on the execution of a control algorithm. If that is not acceptable for your critical application, please, consider disabling the integrated web server by setting the options server.http and server.http to "disabled" and wait for the next version of the REXYGEN system where the integrated web server will be put into another completely separated process.

4.1 Available Services

Following services are handled by the integrated web server:

• sending of static file content from the executive configuration files,
• sending of static file content from the directory specified by the web.webroot configuration option,
• providing dynamic content over the REST API,
• providing dynamic content over a WebSocket connection,
• handling diagnostic connections over WebSocket.

See [6] and [7] for more information.

Chapter 5
Authentication

An authentication subsystem has been integrated into the version 2.50 of the REXYGEN system. Users, roles and permissions of the roles are defined by the authentication subsystem. The authentication subsystem may also be attached to standard accounts from passwd/shadow files in the GNU/Linux environment. An engine for PAM and LDAP authentication mechanisms is planned but not yet supported.

User accounts and roles are fixed in the version 2.50. A configuration interface will be added into REXYGEN Studio and REXYGEN Diagnostics in a next service release.

5.1 Users and Roles

Following roles and permissions are defined:

• admin - full permission set, a user with this role may perform any operation and has full control over the target device.
• super - a user with this role can not perform any operation that has an impact on the target device ie. reboot the device, set system clock etc., but still may modify the running executive,
• operator - a user with this role can not change the running executive but may read and change signal values,
• guest - a user with this role can only read signal values and can not make any modifications.

Only the admin role is enabled and the roles super, operator and guest are disabled by default. A user may enable those roles by setting options auth.super.enabled, auth.operator.enabled and auth.guest.enabled. For each role a user account with the respective name is present in the version 2.50.

The authentication subsystem is enabled by default. A user may disable the authentication by the option auth.enabled. The admin has an empty password by default and a user should always set the password after the first login.

A user must provide authentication credentials (name and password) before connecting to the target device from REXYGEN Studio, REXYGEN Diagnostics or REXYGEN HMI Designer or when using the integrated web interface. An error is returned and the connection is closed if invalid credentials are submitted.

5.2 Using Unix Accounts

In the GNU/Linux environment, the authentication subsystem may be attached to standard accounts defined by passwd/shadow files by enabling configuration option auth.allowsystem. To put a user into a specific role, following system group must be present and corresponding user account must a member of that group:

• admin - rex-admin,
• super - rex-super,
• operator - rex-operator,
• guest - rex-guest.

In the GNU/Linux environment, a root system account may also be bound to the admin user of the REXYGEN system by enabling configuration option auth.allowroot.

Example: To bound a "pi" system account with the "admin" role of the REXYGEN system in the Raspberry Pi device, just create a system group "rex-admin" and add the user "pi" as a member with a shell command "usermod -a -G rex-admin pi". It is then possible to login into the REXYGEN system using the user name "pi". The password may be changed with a shell command "passwd".

Chapter 6
Security

A SSL protocol should always be the choice when communicating with the target device over Internet or untrusted network. A self-signed certificate is automatically created during the installation process on both GNU/Linux and Windows machines. If a self-signed certificate is sufficient, there is nothing else that has to be done.

If a custom certificate and a private key is available, a user has to put them into the RexCore configuration directory. A file with the certificate should be named rexcore.cer and a file with the private key should be named rexcore.key. Both files should be in the PEM file format. The RexCore service should be restarted every time a file with certificate or private key is changed.

List of Figures

Bibliography

Documentation reference number: 12481

2020 © REX Controls s.r.o., www.rexygen.com