Initial installation

Copy the installation script smartWARE_452.5.0.0.14.auto.run to the user's Linux Home directory, for example "user". So the directory is "/home/user".
Then make the file executable,

and start.

The installation script now starts and the following output is displayed in the terminal.

Since root (sudo) privileges are required for the installation, you will be asked for the password. Enter the password to start the installation. The required files are unpacked to the /tmp directory and then copied to the target directory ~/smartWARE_452.5.0.0.14. (Note: "~/" is the short form of the user's home directory "/home/user")
To access the application with the Internet browser via HTTPS, the installation script generates a self-signed certificate. This certificate can be replaced later by an official certificate (if available) (see basic configuration).

The script now creates the following new directories:

The directory ~/smartWAREData/ contains all persistent data of the application. This is where all the data that needs to be retained is stored, even after a software update, such as the measured values transferred from the Jupiter devices, user settings such as dashboards or device location information. Rights to sudo as a user are required for access The directory ~/smartWARE_452.5.0.0.14/ contains all scripts that are needed to run the application. e.g.: start and stop script to start and stop the Docker services. In this directory, individual settings can also be configured and saved in a .env file. More about this in the chapter "Basic configuration".

Basic Configuration

After executing the installation script, the services can be started automatically with the default
settings.
The services are then started with the following default settings.

These settings are saved in the installation directory of the software (~/smartWARE_452.5.0.0.14) in a file named .env.
To create or modify this file, the ~/smartWARE_452.5.0.0.14/config_smartware.
shscript can be used. The text-based menu navigation allows the parameters to be easily changed.

To save the new settings, select Save/Exit.

The generated .env file is saved at ~/smartWARE_452.5.0.0.14/.env.
The changes to the settings will take effect when you next start the system.
~/smartWARE_452.5.0.0.14/stop_smartware.sh
~/smartWARE_452.5.0.0.14/start_smartware.sh

However, if the ports were altered, the port must then be specified in the browser when accessing the GUI. In this case it would be:
http://ip:8080
https://ip:8443

This changed port must then also be set correctly in the Datastore Gateway of the Jupiter devices! In this case, the port for the HTTP protocol would need to be specified. (Note: The HTTPS
protocol in the Jupiter device is only supported as of firmware version 8.x! Installation of the
smartWARE Evaluation software on a cloud computer over the Internet should therefore only be considered with the
HTTPS support provided by firmware 8.x.)
ip:8080/store

Set time zone

The default time zone setting is DC_TIMEZONE=Europe/Berlin

If the software is operated in another time zone, this setting must be overwritten.

You can find a list of possible time zones here https://en.wikipedia.org/wiki/List_of_tz_database_time_zones

Set up ports

The default setting of the proxy ports is:

This means that the software GUI can be reached via browser using the following URLs:
http://ip
https://ip
It is not necessary to specify the port in this case, because the browsers automatically add port 80 or port 443 for HTTPS, without this being displayed. If the standard ports on the computer to be installed are already in use, the smartWARE Evaluation can be run on any other free ports. To do this, the ports in the .env file must be overwritten. Here is an example:

However, this means that the port must also be specified in the browser when accessing the GUI. In this case it would be:
http://ip:8080
https://ip:8443

This changed port must then also be set correctly in the Datastore Gateway of the Jupiter devices! In this case, the port for the HTTP protocol would need to be specified. (Note: The HTTPS protocol in the Jupiter device is only supported as of firmware version 7.x! Installation of the smartWARE Evaluation software on a cloud computer over the Internet should therefore only be considered with the HTTPS support provided by firmware 7.x.)
ip:8080/store

Replace self-signed certificate

During installation, a self-signed certificate is generated and copied to the directory ~/smartWAREData/reverse_proxy/certs. If you open the software GUI in the browser using the HTTPS protocol, you will get a warning from the browser because the certificate is self-signed. Here is an example for the Chrome browser:

However, you can ignore this warning because the self-signed certificate is not known to the browser. To do this, click the link "continue to... (not secure)".

However, you can also prevent the browsers from warning you by using an officially signed certificate or by providing this to the software.
~/smartWAREData/reverse_proxy/certs directory contains 2 files:

smartware.crt
smartware.key

These files can only be exchanged as root user (sudo).
This certificate and key files can be replaced by the company's own officially signed files. To do this, stop the smartWARE services (see 5.2).
Rename the two existing files (e.g. to smartware.ctr_original , smartware.key_original). Then copy the officially signed files and rename them if necessary.
Important: The files must have the names smartware.crt and smartware.key and must be in PEM/X509 format.
After replacing the files and starting the smartWARE services (see 5.1), please check the log file to ensure that the replaced files do not cause any problems:

Update installation

The update installation is no different from the initial installation. Chapters 3 and 4 therefore also apply to an update. Existing configuration files (e.g. File .env) will be included in the new installation. The installation script will perform the stop of the old installation and restart the new installation.

Operation

The smartWARE Evaluation software consists of several individual programs (also referred to as
microservices). These programs are started as Docker containers. For easy starting and stopping of the services, in the directory:
~/smartWARE_452.5.0.0.14
there are two Linux shell files
start_smartware.sh
stop_smartware.sh

Starting the services

In the Linux console, switch to the directory ~/smartWARE_452.2.0.0.12 and run the script ./start_smartware.sh:

CODE

$ ./start_smartware.sh

It is necessary to enter the character combination ./ (i.e. a dot followed by a slash), otherwise Linux will not find the file. It tells Linux that the file is in the current directory.

When you call this script for the first time after installation, the software packages (images) are loaded from the JUMO server first. The individual services are then started as Docker containers. You can view the current status of the services by starting another shell script:

CODE

$ ./status_smartware.sh

You should now see a list showing you the status of each service:

If all services show the state Up, the services are running. You can now open the start page in the browser by clicking http://IP or https://IP. Where IP stands for the IPv4 address of the W10 PC on which the services were started. However, you can also use the hostname of the computer instead of the IP address or http://localhost, if the browser was started on the same computer.

If ports 80/433 are already being used by another program and you have configured alternate ports through entries in the .env file, please append the respective port to the URL, e.g. http://localhost:8080 or https://localhost:8433..

Stopping the services

To apply changes to the .env files, it is necessary to close each individual service in an orderly fashion before you can restart them. To do this, call the script ./stop_smartware.sh on the Linux console.

CODE

$ ./stop_smartware.sh

It takes a few seconds for all services to close. The following output is displayed on the screen:

Background information

Explanation of terms

Docker: Stores programs and their dependencies in images. These form the basis for virtualized containers that can run on almost any operating system. This makes applications portable and uncomplicated.
Docker Desktop: Docker Desktop is an easy-to-install application for a Windows environment that can be used to build and share containerized applications and microservices. Docker Desktop includes Docker Engine, Docker CLI client, Docker Compose, Docker Content Trust, Kubernetes and Credential Helper.
Docker Compose: Docker Compose is a tool designed to define and enable multicontainer applications. Compose can be used to define services, which can then be started or stopped with a single command.
Docker Image: You may be familiar with the term "image" in the context of virtualization in relation to virtual machines (VMs). Typically, a VM image is a copy of an operating system. If necessary, a VM image contains other installed components such as database and web server. The term comes from a time when software was distributed on optical media such as CD-ROMs and DVDs. If a local copy of the data medium was required, special software was used to create an image. Container virtualization is the logical next step in the development of VM virtualization. Instead of virtualizing a virtual computer (machine) with its own operating system, a Docker image typically includes only one application. This can be a single binary file or a composite of several software components.
Docker Container: Over the last decade, the Docker virtualization solution has fundamentally changed how software is built, distributed and operated. Unlike the previously established virtual machines (VM), Docker virtualizes individual applications. A Docker container, therefore, is an application or software container. The term software container is adapted from physical containers such as those used on ships. In logistics, containers as standardized units made modern retail chains possible in the beginning. Thus, a container can be transported on any ship, truck or train designed for this purpose. This operates almost independently of the contents of the container. On the outside, the container is equipped with standardized interfaces. This is quite similar to the situation with Docker containers.
VHDx file: In a VHDx file, the contents of a complete hard disk can be stored virtually in the form of a single file. The file format is an extension of the VHD format and was first released with Windows 8 and Windows Server 2012. It offers numerous improvements and functional enhancements compared to the VHD format.

Software Struktur

The smartWARE Evaluation software consists essentially of 4 functional units (services):

Datastore
Stores the original data (Cold Data) sent by the Jupiter devices at intervals.
Dataview
Prepares parts of the data (Cold Data) and stores them in the Postgres database (Warm Data). Receives user input from the browser application and provides the data to display the dashboard graphs/tables.
Postgres database
This is where the so-called Warm Data is stored, i.e. the portion of the data that is used for quick display in the dashboards.
Nginx (Reverse Proxy)
The http(s) interface of the services.

These services are developed as Linux Docker containers and are configured and started/stopped using Docker Compose. The data is displayed to the user via a web browser on any computer in the network.

Persistent data

All recorded data is persistently stored by the Datastore service in the Linux user's home directory:

~/smartWAREData/datastore

The data is stored in packed files, and protected from tampering by additional signed files. This entire data set is also referred to as Cold Data.

Deleting this directory or individual files from this directory will result in the loss of the recorded data unless a copy of the data was made!

Backup

Only from version 3.0.0.7 the backup function is supported.

If datastore Backup is enabled, the datastore's data is also stored in the directory when it is received.

~/smartWAREBackup/

To minimize the likelihood of data loss due to a hard drive crash, it is recommended that you move the data from this directory to a NAS on the network on a regular basis. A cron job in conjunction with the rsync program and a shell script can be created for this purpose.

Creating a shell script file e.g. backup_to_nas.sh
Make this file executable with chmod +x backup_to_nas.sh
Verify that the shell script does the job it is supposed to do.
Check if the cron service is active sudo systemctl status cron
If not active, use sudo systemctl start cron to activate the service.

Here is an example of a script that moves the data to a NAS drive, so it copies the data from the ~/smartWAREBackup/ directory to the NAS drive, and then deletes the copied data from the original ~/ smartWAREBackup/ directory. So the original ~/smartWAREBackup/ directory is only used as temporary cache!

CODE

#!/bin/sh
# This script move the files from the smatWAREBackup folder to a NAS folder
# to get an external backup of the recorded files
# this script will be called via cron every 1h
rsync -avL -progress --remove- source -files /home/ <youruser> /
smartWAREBackup /mnt/nas/smartWAREBackup/

This script can now be started, for example, every hour by a cron job. To do this, open the configuration file in an editor

CODE

crontab -e

and contributes to. For example, enter the following line

CODE

# start backup job every hour to move the smartWAREBackup files to the NAS
0 * * * * /home/ <youruser> /backup_to_nas .sh

The file is saved with Ctrl-o and "Enter Key". Exit the Editor with CTRL-X.

Whether the job is started every hour can be checked as follows:

CODE

grep CRON /var/log/syslog
Apr 12 00:00:01 yourlinuxpc CRON[3787445]: (ewks) CMD ( /home/ <youruser> /
backup_to_nas .sh)
Apr 12 01:00:01 yourlinuxpc CRON[3802213]: (ewks) CMD ( /home/ <youruser> /
backup_to_nas .sh)
Apr 12 02:00:01 yourlinuxpc CRON[3817019]: (ewks) CMD ( /home/ <youruser> /
backup_to_nas .sh)