General

What is AOP?

The Advancis Open Platform (AOP) is a component model and open API that forms the technical foundation of WinGuard. It provides a central IPC bus (via HTTP/WebSockets/JSON) to which independent software components—called Extensions—connect. Each Extension can register its own services (functions and notifications) and thereby extend the API.

Because IPC uses only standard technologies, virtually any programming language can be used to build an AOP component. Official SDKs are available for C++, .NET (C#), and JavaScript. AOP also ships a collection of ready-to-use concepts such as data objects, device integration, user and rights management, and more.

In a WinGuard network, every station forms its own AOP Node. Components can connect locally or remotely and services can be routed between Nodes, making networked integrations possible.

→ See Introduction and Component Model for a full overview.

What does AOP mean for me as an end user?

As an end user of a WinGuard-based system, AOP is largely invisible. It is the underlying platform that WinGuard runs on. What it means in practice is that:

• The system is extensible: Third-party manufacturers can add new device adapters, UI panels, or capabilities without modifying WinGuard itself.
• Integrations follow a uniform model: All connected systems expose their objects and events in the same way, which is why WinGuard can operate and display them consistently.
• Your system can grow: New Modules can be added and removed independently, and the API is designed to support both local and remote access.

What protocols does AOP use for IPC, and what does a connection look like?

AOP uses WebSockets (RFC 6455) as the transport layer with JSON-encoded messages. The message semantics follow JSON-RPC 2.0: each function call carries a method name, parameters, and an ID for correlating responses; notifications are sent asynchronously without an ID.

The connection is established in two steps:

1. An HTTP GET request to the /connect endpoint on the AOP main port (default: 1234). The request headers carry the JWT authentication token, the Base64-encoded LIC file, and optionally a skill override.
2. If the request succeeds, a WebSocket connection is opened to the URI returned in the response. The WebSocket sub-protocol must be aop.ipc.

The SDKs handle this handshake automatically. You only need to deal with the raw protocol if you connect without an SDK.

→ See WebSocket IPC for the full protocol specification.

What is an AOP Node, and how does multi-station networking work?

Every WinGuard station runs its own AOP Node: an independent IPC bus that hosts the local API and all connected components. Nodes are not connected to each other directly via AOP; cross-station communication is handled by the WinGuard network layer.

From a developer’s perspective:

• A Module always connects to exactly one Node (one WinGuard station).
• Services and data are only available at the Node where they exist. A Module connected to station A cannot directly access data that only exists on station B.
• Cross-station service routing is handled transparently by WinGuard. The Module does not need to manage it.

For device adapters, this means the adapter must connect to the station where it is configured. In multi-station setups, an adapter with the multistation trait runs an instance on every relevant station.

→ See Introduction for an overview of the Node model.

Can a Module run on a different machine than WinGuard?

Yes. Modules connect to WinGuard via WebSocket over TCP/IP, so they can run on any machine that has network access to the WinGuard station. The Module executable does not need to be installed on the WinGuard server.

For device adapters, WinGuard can be configured to start the adapter process locally or to connect to a remotely running instance. Remote deployment is useful when the adapter requires direct access to hardware or a local network segment that the WinGuard server cannot reach.

→ See Device Integration Concepts for details on deployment options.