Piraeus is our experimental and research IoT technology that we have used on the Pegasus Mission. It is the critical communications technology that puts the real-time into the Pegasus experience and allows users to view telemetry and location as well as interact with Pegasus as it flies. The following is simplified overview of the technology and its purpose.
Experimental IoT Technology — Research
Piraeus was design by building on several well-known engineering and technical practices and theories used over the last 70 years, including systems engineering, systems theory, control theory, information theory, and open systems theory, to enable a distributed and flexible open systems to be created, managed, and leverage real-time communications. Effectively, Piraeus allows a proxy of a system graph to be represented and simplifies the communications needs of physical or digital actors within the system, while addressing security holistically.
Piraeus is a symmetrical architecture that enables a distributed event-based open system to be organically constructed and communicate with low latency, high throughput, and linear scale. A system graph is constructed within Piraeus, which represent a proxy of the physical and/or digital subsystems outside of Piraeus that constitute the open system. The system graph can be modified at any time to enable “edge actors” (EA), i.e., physical and/or digital subsystem components to communicate. These EAs can emerge and enter the system or remove themselves from the system at any time. This enables the system to organically change and supports graph management, occasionally connected clients, complex systems, and self-organizing systems.
Piraeus is a generalized architecture and creates no constraints and makes no distinction between EAs. These EAs can be devices, services, or processing units, which may be active or passive in nature. Active systems require a channel to be opened by the sender or receiver to Piraeus for communications, while passive systems require Piraeus to make an outbound connection. These simplifications enable a system to be constructed however fluid to address the communication needs of information senders, actuators, intelligence processes, and analytics through same the symmetrical architecture.
Piraeus supports a range of channel and protocols, where EAs choose their respective channel and protocol to communicate. These is no coupling between the channel and protocol to enable communications between EAs. Piraeus makes these transitions between senders and receivers of information, which reduces the constraints for communications. Piraeus supports HTTP, TCP, UDP, and Web Socket channels as well as HTTP-REST, CoAP, MQTT, and WS-N protocols.
No store and forward technology exists intrinsically within the architecture. Communications processing is perform in-memory and separates the nodes in the system graph into independent units of execution. If the need exists for persistent or cached storage of information, then this storage is considered an EA to the system, i.e., another node in the system graph. The elimination or store and forward technologies reduces latency, increases throughput, and enables linear scale to meet system demands.
Security is simplified by authenticating connections the system using a single security token. Piraeus intentionally separates the management and process of security token acquisition by the EAs. This keeps the security within the system simple, while enabling the management of EAs security to be completely outside of the system and/or customized to address specific scenarios. Access control to system resources is executed via distributed access control. Access control policies are constructed outside of Piraeus for system resources, where Piraeus can consume them at runtime. These access control policies are mutable and Piraeus can refresh them to enable external entities to manage access control to the system graphs without side-effect or redeployment.
The system graph is constructed by first assigning a node to the graph called a “Topic”. The Topic is an input into a system proxy within Piraeus. The outputs of the system proxy are called “Subscriptions” and can be either durable or ephemeral. Both Topics and durable Subscriptions are provisioning and manage with the Piraeus API. Ephemeral subscriptions are never provisioned and are self-managed by Piraeus.
A receiver of events, i.e., a subscriber, is associated with a resource in the system graph called a subscription. These subscriptions can be either durable or ephemeral. A durable subscription is a resource that persists itself in the system graph whether the EA is connected or not to the system. These durable subscription can be configured to store events to a specific duration while the EA is not connected, then spool them out once the EA reconnects. An ephemeral subscription does not exist in the system graph until the EA connects to the system. When the EA disconnects, the ephemeral subscription is removed from the system graph and its resources are disposed.
Piraeus enables several transparent benefits.
- Low latency, high throughput, and linear scale.
- Any open system can be constructed that leverage one of the channels and protocols supported by Piraeus.
- System can be composed of any combination or organization of physical or digital edge actors.
- Systems can be simple, complex, complex adaptive, complex adaptive with emergent intelligence, and self-organizing.
- External subsystems can be created and added to the overall system graph.
- Edge Actors are treated as first class citizens and homogenously. There is no need to customized internal system components with address functional roles of Edge Actors.
- No routing technology is required because the system graph defines the route and access control defines access to resources within the graph.
- System resources are self-optimizing.
- Security is simplified and management of edge actors is orthogonal and localized to a party that understand how to implement the scenario however customized.