Skip to main content
Monica v7 screen image

Monica v7 new release report (by Alan Sambol)

In April 2024, we released a new major version of Monica - v7.0.0. Monica is a next-generation monitoring and control solution (M&C) for the ground segment infrastructure and systems, and one of two flagship products of Amphinicy Technologies. It is tailored for a range of applications, such as RF and optical SatCom, television and radio broadcasting, telecommunications, cable TV, and SCADA system management.

After 1.5 years of development - and frequent correspondence with our customers - we bring to you a new version of Monica M&C. The new version is a major leap forward architecturally, technically and feature-wise.

Let's dive into the major seven new features with our Head of Monica Product Development, Alan Sambol.

1. Remote Agents - endorsed by the European Space Agency

A large part of the Monica v7 development coincided with the project “Remote Agents for Cloud-Based Monitoring and Control” implemented by Amphinicy in the scope of the European Space Agency’s (ESA) Implementation Arrangement with the Government of the Republic of Croatia. In this ESA project, a new architecture for distributed M&C has been implemented and demonstrated.

The primary objective of this update was to adapt Monica for use in distributed and cloud-based systems. We've observed a growing trend in the industry, especially among ground segment operators in the Earth observation and SatCom market, who have antenna sites spread across different geographical locations.

With previous versions of the Monica solution, monitoring a distributed or cloud-based system was done by utilising multiple instances of Monica software in a hierarchy, connected via a REST or WebSocket interface. This is a standard approach adapted in the typical state-of-the-art solutions. However, we have chosen not to pursue this option due to various factors, including its complexity and limited scalability, among others.

Instead, we have implemented a different architectural approach, wherein one central Monica M&C instance interacts with lightweight Remote Agent applications. This approach is significantly simplifying remote site installation, hardware requirements and therefore reducing operational cost and simplifying future maintenance. Customers who benefit from this change are ground station operators, commercial satellite teleports, satellite operators and broadcasters with multiple remote antenna sites.

Let’s see what the target architecture of distributed system looks like (see the image below).

Architecture of distributed system
Architecture of distributed system

 

Essential parts of Monica M&C are instrument adapters and drivers. In Monica v7 they have been extracted into a reusable library and integrated into a lightweight Remote Agent application. As a result, the Remote Agent application supports the complete set of instrument adapters and protocols that core Monica supports.

A Remote Agent application has been implemented using Quarkus - a cloud-native Java framework, and a similar technology stack as the Monica software. In fact, in the same project scope, the whole Monica technology stack has been updated to use the latest versions of frameworks and libraries. In terms of performance, it has been demonstrated that the Remote Agent application is capable of running smoothly on low-end hardware - even on devices as modest as Raspberry Pi 2s. A single CPU core and approximately 300 MB of RAM are sufficient to achieve a polling throughput of 200 parameters per second, demonstrating excellent performance.

The complete Remote Agent configuration is simple and can be performed through the Monica GUI. Once the Remote Agent is installed in the target device network, the complete provisioning is done through the updated Monica v7 GUI. Instruments only need to be configured with a specific Remote Agent ID (see Monica screen below). After that, both the instrument driver and the configuration details - including IP address, port, timeouts, translation of parameters between remote device and Monica - are transferred to the Remote Agent which then proceeds with regular polling of device parameters. The metrics are sent to Monica during device polling. Remote Agents can handle commands transfer from opposite direction as well - from Monica towards a specific device.

Instrument configuration for Remote Agents
Instrument configuration for Remote Agents

 

Message Queuing Telemetry Transport (MQTT)

The communication protocol of choice between Monica and Remote Agents is MQTT (Message Queuing Telemetry Transport) with Protobuf as a serialization library. We consider it highly efficient, by the way. Developed within the IoT domain, it significantly reduces ‘on-the-wire’ overhead compared to conventional REST-based distributed architectures. The protocol is secured using standard TLS connection encryption. In scenarios where only a standard HTTPS port (443) is available on the Remote Agent side, a detailed technical documentation is available on how to efficiently proxy both HTTP and MQTT traffic through the same port.

The configuration of the MQTT broker connection and the Remote Agents is handled by the newly added Remote Agent configuration screen in Monica (see the screen below).

Remote Agent configuration screen
Remote Agent configuration screen

 

Performance improvements

Monica has experienced notable performance improvements with the introduction of the new distributed architecture. Performance tests indicate reduction up to 50% in CPU usage compared to traditional parameter polling conducted in local mode.

 

2. Instrument Manager revamp

Version 7 features a complete revamping of Monica’s core element - the Instrument Manager component. Besides a complete code reorganisation needed for Remote Agents, the module has also been redesigned and re-implemented. This includes:

  • a complete redesign with tabular layout
  • a simplification of main instruments table
  • an auto layout of instrument configuration, with property grouping
  • the embedding of schemas and charts into Instrument Manager tabs
  • complex parameter type support (i.e. TABLE)
  • parameter hierarchy via nested parameter groups
Instrument Manager redesign
Instrument Manager redesign

 

3. Driver editor revamp

In version 6.2, we had introduced a visual driver builder as a new way to create drivers, in addition to writing XML files. After a period of extensive use and gathering feedback from customers and integrators, version 7 introduces a greatly improved, redesigned, and simplified driver editor.

3.1 Merged basic information and Properties sections

Basic information was used for attributes that are part of the XML schema, while user-defined properties allowed to add key-value pairs as additional properties. In relation to the properties system refactoring, we decided to merge those two, since they both are simply properties, with different ways of serializing them into XML being just an implementation detail.

Driver editor - Properties
Driver editor - Properties

 

3.2 Simplified tabs

Parameter configuration tabs have been reorganised and their number has been reduced from seven to just four (see the screen below).

Parameter configuration tabs
Parameter configuration tabs

 

3.3 Constraints

The constraints tab has also been redesigned with improved user experience (on the screen below).

Driver editor - Constraints
Driver editor - Constraints

 

3.4 Translations

The Translations tab has been reorganised with better UX and clear indication of the order of different translations. Also, since the Unpacking policy is performed between two translation steps, it has also been moved to Translations tab.

Driver editor - Translations
Driver editor - Translations

 

3.5 Dependencies

The Dependencies tab is a new tab, containing all information needed to link parameters. A new concept is introduced - Parameter Bindings, to define relationships between parameters and with its main use being SNMP tables.

Driver editor - Dependencies
Driver editor - Dependencies

 

4. Binary protocol support

Prior to Monica v7, creating drivers for binary protocols would require the following steps:

  1. set charset to ISO-8859-1 and use \u notation for HEX payload, i.e. \u00AF
  2. data extraction and checksum calculation using Groovy scriptlets

There were several problems with that approach, including:

  • binary values were not readable on GUI
  • heavy scripting usage impacted performance and time needed to write a new driver
  • a lack of overview of binary packet definition

Monica v7 introduces a new concept - Binary Packet Definition, a part of an Unpacking Policy within a new driver editor (see the screen below).

Packet Definition
Packet Definition

 

With this feature, it is possible to have a data-driven configuration of binary data unpacking without needing any scripting. The packet is split into segments, which - depending on their type - perform all the logic required for data extraction. It also includes a visualisation of the whole packet, with color-coded segment types, even showing gaps between defined segments.

With this feature, it is possible to have an easy way to configure and visualise binary packets for devices returning 100+ parameters in a single response.

 

5. Instrument driver slots

For some time now, there were two similar but opposite requirements from our customers and integrators:

  1. Connection sharing between Instrument Adapters (e.g. TCP devices supporting only a single connection for multiple units)
  2. Multiple connections in a single Instrument Adapter (e.g. TCP devices with multiple ports - one port for read request, another for write requests)

Both points have been addressed using a new concept: driver slots. Driver slots are named child driver definitions. For each slot, connection sharing can be configured at slot definition time (see the screen below).

Driver slots - Shared connection
Driver slots - Shared connection

 

For the second case, a slot definition would look like the following screen.

Driver slots - Multiple connections
Driver slots - Multiple connections

 

The only missing part is to configure parent driver parameters to proxy their translations to child driver parameters. This way, it’s possible to have a ReadWrite parameter on parent driver, where separate child drivers would usually have implementations for Read and Write translations:

Driver slots - Translations
Driver slots - Translations

 

6. Other notable changes

  • New default UI theme
  • Support for polling intervals in milliseconds
  • New proxies in scripting: scheduler, script (supporting nested script calls)
  • Unpacking parameters via script
  • Property system rework
  • Drop support for legacy schemas & InfluxDB

 

7. Modular architecture and licensing flexibility

Starting with version 7, Monica features fully modular architecture, enabling optional modules to be omitted during installation on both the backend and frontend. These modules can be added without requiring a custom Monica build. In this setup, optional modules are dynamically loaded on both the backend and frontend based on their availability and subject to additional license verification.

The first optional modules are SNMP Agent and Registry, with Charting also being optional on the frontend. This allows for straightforward Monica installations without Highcharts license requirement.

Additionally, the optional module can also be Backend-only. For instance, custom features such as specific Instrument Adapters can now function as plugins independent of the Monica core.

To discuss all licensing options, schedule a call with our Sales team.

Conclusion

This version of Monica is our most conclusive and ambitious release up to this date.
The roadmap for version 7 lifecycle looks very exciting and we are already working on some new features.

And what is next?

Already having an idea for collaboration? Get in touch with us today to discuss how we can support your business or project.