This page contains a list of features, changes, known issues and known limitations of the Nerve releases.
This version was released on August 1, 2022. Unless otherwise stated, all known issues and limitations of the previous version are still valid.
|Management System||Added brute force login protection.
Added a table view for deployed workloads on the node.
Migrated logging and monitoring features to OpenSearch.
Added retention policies for logging and monitoring.
|Local UI||Added brute force login protection.|
|Nerve Data Services||Added rebrowsing of the address space when using the OPC UA Client input.
Added filtering of node IDs with regex expressions for OPC UA Client inputs.
Added OPC UA Client as a new output.
Refer to What's new in 2.5.0? for more information on new features.
- Improved robustness of the system.
- Introduced tabs for workload configuration settings.
- Added a remote connections tab to the initial workload version configuration.
- When a workload is cloned, remote connections are now cloned as well.
- Improved the UI and functionality of the remote connection list.
- Improved remote connections to allow for longer connection time and transfer of large amounts of data.
- Removed support of TLS versions older than 1.2 for the Management System.
- Nerve internal licensing mechanism has been extended to enable installation and use of CODESYS add-ons.
- Improved usability and handling of labels.
- Improved the communication of the system in error messages.
- Multiple UI/UX fixes and quality of life changes.
- Improved the naming of user permissions.
- Nerve Data Services: Improved usability of the database preview.
- Nerve Data Services: Updated dependencies of the Data Services SDK.
- Fixed an issue where nodes would be incorrectly displayed as offline by implementing a heartbeat mechanism.
- Fixed an inconsistency in workload creation that resulted in newly created workloads not being deployable to version 2.4.1 nodes.
- Fixed an issue where kiosk mode for Grafana would not work properly on Mozilla Firefox.
- Fixed an issue where the created date of a node would show an invalid date.
- Fixed an issue where the Management System would cause an unusual amount of traffic.
- Fixed an issue where the MQTT connection of the Management System might fail to reconnect after refreshing.
- Fixed an issue where nodes would not appear in the node update list when a new version is released.
- Fixed an issue where remote connections could not be added or deleted when a label already existed on the node or workload.
- Fixed an issue where Grafana UI theme color is reset to default when a home dashboard is set.
- Fixed an issue in the Data Services where reaching the MQTT message limit would cause data accumulated in the buffer to not be sent to the Management System.
- Fixed an issue where different fields would be set when deploying a Docker workload from registry or with manual image upload.
- Fixed an issue in the Data Services where tables in Timescale databases could not be deleted.
- Fixed an issue where nodes would appear as offline after replacing a workload version following a node update.
- Fixed an issue where Gateway configurations might become erroneous if security settings were added in an unexpected order.
- Fixed an issue where workloads that cannot be deployed (e.g. workloads that are in downloading phase) would appear as an available update for deployed workloads.
- Fixed an issue where new workload versions could not be created when the first version was marked as released.
- Fixed an issue where the API would not respect the released flag of a workload.
- Fixed an issue where the Management System would crash when a large number of node are connected.
Known issues and limitations
- Excessive logging by the node or workloads may overload the logging system, leading to unusable logs. Monitor the logging of workloads to avoid overlogging.
- The Gateway cannot be specified for extern interfaces by users. Contact TTTech Industrial support if this is desired.
- If a workload deployment is ongoing during the update of the Management System, the deployment might remain incomplete and cannot be removed from the UI. TTTech Industrial support will propose a maintenance window for the Management System update, during which no deployment should be running.
- When a workload with a defined remote connection is undeployed and a new workload is deployed that exposes the same port but has no remote connection defined, the remote connection of the undeployed workload may be established to the new workload.
- The Nerve Connection Manager requires additional packages to work on Debian Bullseye and Ubuntu 22.04. The packages are:
- A workload version that is being provisioned and in the downloading phase can be deleted through the API. Check the workload status before deleting a workload through the API.
- Disabled workloads can be deployed through the API.
- Remote connections might get stuck in connecting state when being established in a slow network. Avoid slow connections like 3G when establishing remote connections.
- If a remote connection to the Local UI is established and then lost, the Local UI will wrongly report Unexpected error instead of stating that the connection was lost.
- Powering off the node or disconnecting it from the network during a workload deployment may lead to inconsistent states in the deployment log. The workload is still properly deployed. Check the deployment details in the log to confirm the deployment state.
- After updating a node to version 2.5.0, the Data Services might be missing from the capabilities list. Rebooting the node again will solve the issue.
- When two VM workloads that together exceed the available CPU limit are deployed to a node, the VMs cannot run at the same time. However, after rebooting the node, both VMs are started automatically.
- Nerve Data Services: The local NerveDB might consume excessive resources when filled with very large amounts of data. Monitor resource usage and set a data retention policy to avoid an overconsumption of resources.
- Nerve Data Services: Using multiple central NerveDB outputs for multiple data flows might result in malfunction and a loss of data. Use a single central NerveDB output with multiple connectors instead.
Scaling and performance limitations
This release has been tested to perform within the following scaling boundaries:
|Maximum number of concurrent devices||200|
|Maximum number of concurrently logged in users||5|
|Maximum workload size||50 GB|
|Maximum number of concurrent remote access sessions||3|
|Maximum number of workloads in workload repository||200|
|Maximum data upload per node||5 datagrams per second with at least 10 sensor values for 200 nodes in parallel.|