SOPHIA ATC Systems presents SOPHIA HERMOD, a native ATSMHS server for aeronautical messaging

A scalable AMHS platform combining native X.400/OSI engineering, MTA routing, Message Store, X.500 directory services and unified system administration

- Parnamirim, Rio Grande do Norte, Brazil
IA Illustration

SOPHIA ATC Systems presents SOPHIA HERMOD (High-reliability Exchange, Routing and Messaging Operational Daemon), an ATS Message Server developed for aeronautical messaging environments based on the ATS Message Handling Service (ATSMHS).

HERMOD brings together message transfer, routing, Message Store services, directory functions and technical supervision in a single Linux-based platform, providing an integrated backend for the deployment and operation of AMHS infrastructure.

The platform was designed around three principles: standards-oriented engineering, operational simplicity and technological independence. Its architecture gives SOPHIA ATC direct control over the messaging backend and protocol implementation, without making the AMHS core dependent on proprietary third-party X.400 middleware, recurring protocol-stack subscriptions or externally licensed AMHS components.

SOPHIA HERMOD AMHS Network Overview

SOPHIA HERMOD WebAdmin providing a unified view of AMHS services, infrastructure, peers, Message Store and directory status.

A native X.400 and OSI implementation

A central characteristic of HERMOD is the native development of the protocol components that form its aeronautical messaging core. Rather than placing the product on top of a proprietary third-party AMHS/X.400 middleware layer, the protocol engine and application backend are developed and controlled as part of the SOPHIA HERMOD platform itself.

The engineering covers the X.400 messaging model and the OSI communication layers required for AMHS operation over TCP/IP, including ASN.1/BER processing, RFC 1006 transport, Session, Presentation, ACSE and RTSE mechanisms according to the applicable service interface.

At the messaging level, the architecture addresses the functions associated with MTA-to-MTA transfer, O/R Address processing and routing, Message Store access, message persistence, reports, queues and directory integration.

This gives the development team direct access to the complete backend when a protocol behaviour needs to be analysed, corrected or extended. There is no opaque AMHS middleware layer between the operational system and the protocol implementation.

MTA routing and P1 interconnection

The MTA component manages local and remote message routing using X.400 O/R Addresses. Multiple P1 peers can be configured, with routing decisions directing messages to local subscribers or remote AMHS domains according to the defined addressing and route configuration.

The WebAdmin exposes peer status and topology directly to technical personnel, making the logical AMHS interconnection visible without requiring operators to reconstruct the network from individual configuration files or command-line tools.

SOPHIA HERMOD P1 MTA peer topology

P1 topology view showing configured MTA peers and their operational status.

Message Store and AMHS service integration

HERMOD integrates the ATS Message Server functions around a common message-processing pipeline. The administration environment includes the P1, P3 and P7 service surfaces, subscribers, queues, messages and routing objects required by the AMHS architecture.

The Message Store provides persistent message handling for AMHS clients and applications. The P7 implementation includes the operational mechanisms associated with association establishment, message submission, listing, retrieval, summarization and controlled deletion of stored messages.

Interoperability work is carried out against independent AMHS implementations in controlled test environments. These activities exercise real protocol exchanges and are used as engineering evidence during development, while remaining distinct from any claim of regulatory certification or formal product approval.

X.500-oriented directory services

Aeronautical addressing is managed through an integrated hierarchical directory, allowing O/R Addresses and subscribers to be organized and administered from the same platform used for message routing and system supervision.

HERMOD provides an X.500-oriented directory structure with DAP capabilities and a complementary LDAP interface for integration and administration. This makes the address catalogue part of the AMHS environment rather than an isolated configuration database maintained separately from the messaging system.

SOPHIA HERMOD hierarchical X.500 directory

Hierarchical aeronautical address catalogue presented through the HERMOD administration interface.

Standards-oriented engineering

HERMOD is developed with technical reference to the international specifications that define the ATS Message Handling Service and its underlying messaging environment. The engineering baseline includes ICAO Doc 9880, EUROCONTROL EUR Doc 020 and SPEC-0136, the ITU-T X.400 family, including X.411, X.413 and X.419, as well as RFC 1006 and X.500.

Protocol behaviour is verified at multiple levels, from ASN.1/BER structures and O/R Address constraints to message-transfer procedures, Message Store operations, routing behaviour and the underlying OSI communication stack.

This standards-oriented approach is deliberately treated as an engineering process. References to ICAO, EUROCONTROL, ITU-T and related specifications describe the technical basis used during development and do not constitute a declaration of external certification, approval or regulatory homologation.

Complete control of the backend

For long-life critical communication systems, technological control is also an operational consideration. HERMOD has been designed so that the AMHS protocol engine, message-processing logic, routing behaviour, administration layer and system evolution remain under the same engineering lifecycle.

The AMHS/X.400 core therefore does not require a proprietary third-party messaging stack or a recurring subscription to an external AMHS middleware provider. This reduces dependency on another vendor's product lifecycle, licensing model, release schedule or availability of specialized protocol components.

The system runs on standard Linux infrastructure and uses established database and networking technologies, while the aeronautical messaging logic and the X.400/OSI protocol implementation remain directly controlled by SOPHIA ATC.

For technical teams, this means that diagnosis can reach the actual protocol layer: from a routing decision or Message Store transaction down to ASN.1/BER structures, OSI associations and message-transfer behaviour.

Unified administration instead of fragmented configuration

Complex protocol infrastructure does not necessarily require complex day-to-day administration. HERMOD provides a centralized WebAdmin that consolidates the elements needed to understand and manage the system: services, connections, MTA peers, subscribers, O/R Addresses, directory entries, routing, messages, queues, statistics, events and high-availability status.

A complementary administrative CLI is also available for engineering, maintenance and automation tasks.

SOPHIA HERMOD operational statistics

Operational statistics and protocol activity are consolidated in the same administration environment.

Performance for operational messaging environments

SOPHIA HERMOD was designed to process aeronautical messaging traffic efficiently while maintaining the protocol handling, routing, persistence and traceability required by the platform.

Under low-latency network conditions, with stable connections and without communication failures or intermittent links, the platform is capable of processing approximately 80 messages per second.

Actual throughput depends on the deployment architecture, network latency, message size, number of simultaneous associations, storage performance and the characteristics of the connected AMHS peers. For this reason, performance is treated as an operational characteristic of the complete environment rather than as an isolated software benchmark.

From a compact server to high availability

Another objective of the HERMOD architecture is to make AMHS infrastructure deployable according to the real scale and availability requirements of each organization.

A compact installation can place application services and the database on a single server. A distributed architecture can separate the application and database layers. For environments requiring greater service continuity, HERMOD can be deployed with redundant application and database nodes, service virtual IP addresses, VRRP and PostgreSQL replication.

The application and administration model remains consistent between these deployment profiles, allowing an organization to start with a smaller architecture and evolve without replacing the messaging platform.

SOPHIA HERMOD high availability architecture

High-availability topology with redundant application and database layers, service VIPs and continuous infrastructure supervision.

Making AMHS infrastructure more accessible

AMHS is based on mature and highly specialized messaging standards, but implementing those standards should not necessarily imply dependence on expensive proprietary middleware or a rigid infrastructure model.

By combining a native protocol implementation, standard Linux infrastructure, centralized administration and deployment options ranging from a compact node to a redundant cluster, SOPHIA HERMOD aims to lower the technological and operational barrier associated with deploying and maintaining an ATS Message Server.

This approach is particularly relevant for ANSPs, regional communication centres, laboratories, training environments and organizations seeking to modernize aeronautical messaging infrastructure while retaining control over their own architecture and expansion strategy.

The objective is not to simplify AMHS by removing its standards, but to make standards-based aeronautical messaging easier to deploy, understand, administer and evolve.

An AMHS core designed to evolve

HERMOD combines aeronautical messaging, routing, storage, addressing, directory services and system supervision in a common engineering platform. Its architecture has been designed both for current AMHS operation and for continued evolution of the communications environment as aeronautical information services become increasingly interconnected.

For SOPHIA ATC, technological independence means more than software ownership: it means understanding and controlling the complete path of an aeronautical message, from the protocol association and addressing rules to routing, persistence, delivery and operational supervision.

SOPHIA ATC Systems develops software and integrated solutions for Air Traffic Management, aeronautical messaging, operational visualization and aviation safety.

Systems. Control. Technology. Reliability.

Learn more about SOPHIA HERMOD

Comments

There are no comments yet for this item

Join the discussion

You can only add a comment when you are logged in. Click here to login