Pegasus-I was a system with the overall goal to broadcast telemetry and control flight operations in real-time. The system was a combination of organized and self-organized sub-systems that interacted with Pegasus-I during the flight. Let’s examine how we structured this and role of self-organizing systems in the mission as well as how we will leverage them for Pegasus-II and Pegasus-III in the near future.

A system is an organized set of things that form a complex whole designed to achieve a goal. The system designed and used for Pegasus-I included seven (7) interconnected actors, Pegasus-I, Ground Station, Chase Vehicle, Web site, and three (3) Azure Blob Storage containers. The nodes could transmit, receive, or transmit and receive information depending on their function. The overall system was composed on nine (9) different sub-systems that managed telemetry and flight operations. These sub-systems communicated with the actors to execute specific tasks within a sub-system.

Three (3) sub-systems were organized, meaning we had predetermined and configured paths for the information to flow. These sub-systems were associated with storing telemetry received from Pegasus-I by the Ground Station and the Chase Vehicle as well as storing the location of the Chase Vehicle itself. These sub-systems were required to be organized because our storage containers in Azure Blob Storage do not connect to Piraeus. Piraeus requires a durable subscription to be configured to any passive receiver. Below in [Figure 1] shows the system actors and organized sub-system graphs for telemetry and location. You will notice that the only organized sub-systems simply ingest telemetry and location from either the Ground Station or Chase Vehicle to Azure Blob Storage. The Web site does not send or receive any information through these sub-systems.

Figure 1

Four (4) of sub-systems were self-organizing, which means they organize themselves on-the-fly to create sub-systems that did not exist before. If these new sub-systems create ephemeral subscriptions to receive information, then those subscriptions will only last for the duration of the connection by the caller. They are disposed upon disconnect. The reason we made this choice for Pegasus-I was that certain sub-systems were only concerned with “now”, not any past history of events to or from the inflight craft. This also reduced the complexity of the system design because we could depend on Piraeus to create the sub-system graphs in Orleans on demand and connect them to the appropriate parties immediately.

When the Web Site connected to the Piraeus gateway, it was entitled to subscribe to the same topics grains in Orleans as the Azure Blob Storage containers. This allowed the Web site to create new sub-systems on-the-fly to receive telemetry and location, shown in [Figure 2]. If the Web site disconnected, both the new subscriptions and their respective observers would be disposed and upon reconnection the sub-systems would be recreated by Piraeus within Orleans.

Figure 2

This takes care storing and displaying telemetry without requiring complex configuration or maintenance, but what about those critical flight operations for delivery system release and parachute deployment? We used the same ability for self-organization for those also. We only need to configure topics [Figure 3] for the Web site to send specific commands to the responsible parties, Ground Station and Chase Vehicle.

Figure 3

Once the Ground Station and Chase Vehicle connection to the Piraeus gateway, the sub-systems were created [Figure 4] and communications enabled from the Web site to these parties.

Figure 4

When you look at the entire system and its sub-systems [Figure 5], it is a complex system. However, using self-organizing systems within Piraeus, we were able to take advantage of creating the sub-systems without the need to configure all of them in advance. We only configured seven (7) topic grains and three (3) subscription grains in Orleans to design the entire system and enable communications and storage so users could view the flight in real-time and allow Mark and I to control flight operations.

Figure 5

Instead of describing the various uses of self-organizing systems, which are numerous, I want to communicate how the planning for Pegasus-II and Pegasus-III will use them. We want to be able to bring the excitement of high altitude science to people in a very personal way and allow people actively participate in the experiment in real-time. In our own way, it is like being onboard the Calypso with Jacques Cousteau. Doing this requires that we leverage not only a Web site, but also phone apps to broadcast to users real-time telemetry, maps, and streaming video through Pegasus’s eye-in-the-sky. These phone apps will receive telemetry, location and update rapidly from 100K feet in the upper atmosphere to user’s eye. Additionally, we working on concepts to get some user-defined personalized information onboard the craft during flight such that users can directly communicate with Pegasus and see personal message during flight. However, we cannot control the number of people using the phone apps or when the users choose to turn the apps on or off, or simply a phone dropping a connection due to poor reception. Therefore, we need a self-organizing system for these users, and Piraeus supports just that for this type of experience.

-Matt Long