August 2025: Feature releases & highlights

Enhanced NVIDIA Jetson support. Support for moving sites with dynamic location. Improved edge proxy for ISA-95 networks.

NVIDIA Jetson, moving sites, flexible edge proxy

This release brings important enhancements that strengthen support for diverse edge environments — from specialized hardware, to mobile sites, to complex network topologies:

• Enhanced NVIDIA Jetson support: Extended validation of Jetson devices, with dedicated documentation to guide installation and configuration.
• Support for moving sites with dynamic location: Edge sites can now report their current position via an edge API, making it possible to track mobile deployments such as robots, trucks, or drones. The Control Tower map updates dynamically, while historical positions are stored for downstream use.
• Improved edge proxy for ISA-95 networks: Our proxy functionality has been extended from single-layer setups to multi-layer and cross-site proxying, enabling more flexible deployments in segmented or highly restricted network environments.

Enhanced NVIDIA Jetson support

We see a growing number of edge deployments using NVIDIA Jetson devices. The Avassa Edge Enforcer is now validated on Jetson, and we have published dedicated documentation to guide you through installation and configuration.

The recommended setup is to use the Ubuntu distribution for NVIDIA Jetson, which includes the necessary kernel modules. NVIDIA Jetson Linux does not provide these modules by default; if you choose that distribution, you will need to build a custom kernel as described in the NVIDIA Jetson Linux Developer Guide.

Moving sites, dynamic longitude and latitude

More edge use cases now involve mobile sites, such as commercial vehicles, drones, and agricultural robots. Previously, site locations had to be configured statically. With this release, sites can now report dynamic longitude and latitude to the Avassa platform.

This enables:

• Real-time updates of site positions on the Control Tower map
• Storage of historical positions in the Avassa pub/sub bus for visualization tool consumption.

This makes it easier to manage and monitor moving edge sites alongside stationary ones.

The dynamic location mechanism works as follows:

1. The site regularly updates its location to the Control Tower every 5 minutes.
2. The Control Tower persistently stores these locations every hour, balancing data freshness with system efficiency. (After a restart of the Control Tower, this will be the position).
3. Live data can be fetched directly from the site, e.g., when focusing on a site in the UI.

The intervals for 1 and 2 can be configured.

supctl create system settings <<EOF
sites:
location-publish-interval: 5m
location-persist-interval: 1h
EOF

In order for a site to report its actual location, an application deployed at the site needs to report the position using the update-location action.

supctl do --site my-vehicle system update-location  <<EOF
latitude: 57.70232
longitude: 11.98635
EOF

And to see the location history:

supctl do --site my-vehicle volga topics system:location consume --payload-only 
{
  "last-published": 1755782423,
  "latitude": 57.70232,
  "longitude": 11.98635
}
{
  "last-published": 1755782423,
  "latitude": 59.70232,
  "longitude": 12.98635
}
{
  "last-published": 1755782423,
  "latitude": 61.70232,
  "longitude": 14.98635
}

Read more: https://docs.avassa.io/how-to/dynamic-location

Improved edge proxy, ISA-95 networks

In certain network environments, edge hosts may be unable to establish a direct connection to the Control Tower due to firewall rules or other network restrictions. Avassa supports a proxying mechanism in which an Edge Enforcer host with Control Tower connectivity can relay traffic on behalf of other hosts without direct access.

We are introducing a new enhanced proxy model that provides enhanced flexibility, including support for multi-level proxying and cross-site proxying.

In the illustration above, we show a number of capabilities of the enhanced proxy mechanism:

1. Within a site, you can designate a host to act as a proxy for the other hosts within the site.
2. You can also let hosts within a site act as a proxy for other sites/hosts
3. A proxied site can have several parent proxies to enable failover.
4. You can chain proxies in any number of layers

Communication is initiated from lower layers, and allowed networks, as well as proxy ports, can be configured.

Example configuration for a proxy host:

supctl merge system sites my-proxy-site <<EOF
hosts:
  - host-id: 6e4d8db8-0833-4b5f-960d-a358d96aa1f2
    proxy:
      act-proxy: true
      network-access:
        rules:
          10.0.0.0/8: allow
EOF

To install an Edge Enforcer that shall use a proxy, pass the proxy parameter to the install script:

--proxy 192.0.2.4 --proxy 192.0.2.5

See more details in the documentation: https://docs.avassa.io/tutorials/control-tower-proxy

This enhanced proxy feature ensures a consistent and scalable approach to proxying across environments, particularly in segmented networks such as ISA-95 architectures.

Other enhancements

Variables in certificates

Certificate generation now supports variables in the host and alt-name (DNSName) fields. This allows you to define a single certificate configuration that automatically renders individual certificates per site.

For example, by including the site name as a variable, each site will receive a certificate with its own unique hostname, eliminating the need for separate manual configurations.

supctl show --config strongbox vaults mosquitto secrets cert
name: cert
auto-cert:
  issuing-ca: mosquitto
  ttl: 30d
  align-to-midnight: false
  truncate-ttl: false
  host: mosquitto-${SYS_SITE}
  cert-type: server
allow-image-access:
  - "*"
  

supctl -j show --site robot-cluster strongbox vaults mosquitto secrets cert | jq -r '.cert."cert.pem"' | openssl x509 -noout -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            a7:8f:c9:95:1c:52:07:32:1f:17:a9:c4:f7:73:b2:67:8b:e8
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=SE, ST=Some-State, O=Avassa, CN=Avassa
        Validity
            Not Before: Aug 25 23:11:11 2025 GMT
            Not After : Sep 25 06:23:11 2025 GMT
        Subject: C=SE, ST=Some-State, O=Avassa, CN=mosquitto-robot-cluster

Read more in the reference documentation.

The query topic can be used when running supctl at the site

The query-topics action can now be executed directly on a site, not only via the Control Tower. Previously, when running supctl on a site, only the consume command was available. This enhancement gives operators more flexibility to query topic data locally. Read more on running subctl at the site: https://docs.avassa.io/how-to/offline-site#running-supctl-locally-on-the-site

Fetch partial config

A new query parameter, match-path, has been added to enable fetching partial config or state data. This is supported by both the REST API and supctl.

Together with existing parameters — fields (to return only selected fields) and where (to filter items by criteria) — This provides fine-grained control when querying configuration and operational data.

Example:

supctl show --match-path "/v1/*/system/**"
---
x-path: /v1/state/system/certificate-ttls
api-certificates:
...
---
x-path: /v1/state/system/site-profiles/sweden
name: sweden
maintenance-windows:
  - days-of-week: Monday, Tuesday, Wednesday, Thursday, Friday
 ...
---
x-path: /v1/state/system/site-profiles/nightly-upgrades
name: nightly-upgrades
...

On ISA-95

ISA-95 (also published internationally as IEC 62264) is an international standard for integrating enterprise and industrial automation systems.

It was developed by the International Society of Automation (ISA) to provide a structured model for how information flows between:

• Level 4 (Enterprise systems) – business planning and logistics (ERP, SCM, MES).
• Level 3 (Manufacturing operations systems) – production scheduling, maintenance, quality, and inventory.
• Levels 2–0 (Control systems and equipment) – SCADA, DCS, PLCs, sensors, actuators.

Purpose of ISA-95

• Defines a common vocabulary and data models to reduce misunderstandings between IT (enterprise) and OT (operations/automation).
• Standardizes the interfaces and integration between business systems (like ERP) and control systems (like PLCs and SCADA).
• Supports segmentation of networks and responsibilities, which is why it’s often referenced in security and edge-computing discussions.

Relevance to Edge Computing

In edge contexts (like factories, energy plants, or logistics):

• ISA-95 helps determine which data stays local and which flows up to enterprise/cloud systems.
• It provides a rationale for network segmentation (keeping shop-floor machines isolated but still connected through controlled interfaces).
• It’s often cited in proxying and data-flow designs, since traffic must cross ISA-95 boundaries securely.

Avassa in ISA-95 environments

A typical Avassa deployment in ISA-95 environments could look like

Edge Enforcer runs in the Operations Zone (Levels 2/1), close to SCADA/PLCs and workloads. This can also be a layered proxy between levels 2 and 1.

An on-prem or cloud Avassa Control Tower sits in the Enterprise Zone (Level 4).

Proxy Hosts are placed in the Industrial DMZ (Level 3) to securely bridge network segments.