Patent Description:
Satellites can be deployed into orbit to provide various space-based operations, such as military and civilian observation operations, communications operations, navigation operations, weather operations, and research operations. Satellites can include various sensors and communication equipment that are used to perform desired tasks. For example, a weather satellite may include one or more cameras or imaging sensors that can be used to take images of Earth, and communication equipment that can be used to communicate the images to a control system on Earth. Although satellites can be configured to perform these specialized operations, satellites are expensive to create and launch into orbit, especially for organizations that may not require the use of an entire satellite with a large number of sensors, or may not require continuous operations on the satellite. As a result, organizations may avoid the use of satellites, limiting the use of promising satellite technology.

The technology disclosed herein provides enhancements for deploying software applications to satellites in a satellite platform.

This Overview is provided to introduce a selection of concepts in a simplified form that are further described below in the Technical Disclosure. It should be understood that this Overview is not intended to identify key features or essential features of the claimed subject matter, nor should it be used to limit the scope of the claimed subject matter.

While several implementations are described in connection with these drawings, the disclosure is not limited to the implementations disclosed herein.

The various examples disclosed herein provide enhancements for satellite hardware and software technology. In particular, the examples disclosed herein provide systems and methods for deploying software applications to an orbiting satellite platform, wherein each of the software applications executes as a virtual node that can share resources with one or more other applications deployed to the same satellite. These virtual nodes may comprise full operating system virtual machines in some examples, and may further include virtual containers. These containers may include Docker containers, Linux containers, j ails, or another similar type of virtual containment node, which can provide an efficient management of resources from a host system. The resources used by the containers may include kernel resources from the host computing system, and may further include repositories and other approved resources that can be shared with other containers or processes executing on the host. However, although resources may be shared between the containers on a host satellite, the containers are provisioned to have private access to the operating system with their own identifier space, file system structure, and network interfaces.

In the present example, to provide the satellite platform, a plurality of satellites are deployed, wherein organizations may generate applications and deploy the applications to the satellites to perform desired operations. The operations may include military and civilian observation operations, communications operations, navigation operations, weather operations, and research operations. To develop the applications, a development platform may be provided as part of a ground control system that permits the organizations to develop software applications using a development tool. Once developed using the tool, the applications may be executed in a virtual or physical test environment replicating the physical satellite platform. This test environment may permit the user to upload the software application to one or more test satellites and monitor the operation of the application prior to deploying the application to the physical satellite cluster. In some implementations, in developing the application, the provided development tool may include an application programming interface (API) or some other command structure, which permits the applications to request and access the various sensors and interfaces provided by the physical satellite. Accordingly, although each of the software applications may perform different operations, they may interact with sensors, such as cameras, antennas, and the like using similar commands.

Once an application is developed using the development tool and the test environment, the application may then be deployed in one or more satellites of the orbiting satellite platform. In some implementations, the application may be provided to each of the one or more satellites using a ground control system as an uplink to the one or more satellites. In other implementations, a single uplink may be made to a satellite in the platform, wherein the satellite is configured to distribute the application to other desired satellites in the platform. Once deployed in the environment, the application may execute on the assigned satellites.

In some implementations, to manage the execution of the applications on each of the satellites, a schedule may be generated, wherein the schedule may be responsible for scheduling the processing of each of the applications, as well as the access for each of the applications to the user sensors. For example, a first application on a satellite may require access to an imaging sensor during a first-time period, while a second application may require access to the same sensor during a second-time period. The schedule provided to the satellite may be used to determine and allocate addressing links between each of the applications to the sensor based on the defined time periods. In at least one implementation, more than one applications may be allocated to the same sensor at any one time. This may permit applications providing different operations to receive the same data, but provide different functionality in relation to the data. In other implementations, a single application may prefer that no other applications receive are access the sensor at the same time. Thus, the schedule may ensure that only a single application is allocated or capable of communicating with the sensor during the defined time period.

To develop the schedule that is provided to the satellites of the satellite platform, an availability service or platform may be used. In particular, during the development of an application, a developer provides deployment requirements to the availability platform, which include geographic areas of interest for the application, and may further include operation times of interest, sensor requirements, or some other similar deployment requirements, including combinations thereof. These requirements are then compared to the available resources of the satellites, wherein the resources may comprise available processing, communication, and sensor resources of each of the satellites, to determine whether the application can be accommodated by the currently orbiting satellites. If the application can be accommodated via the currently orbiting satellites, then the developer may select to deploy the application using the current satellites. In other examples, if only a portion of the deployment requirements could be accommodated, then the developer may be provided with one or more additional selection options for deploying the application.

For example, if the current satellite platform could support eighty percent of geographic area of interest, an option may permit the user to approve or decline the deployment of the application based on whether the eighty percent was adequate for the developer. Accordingly, if the eighty percent were adequate, the application may be deployed to one or more satellites capable of providing the desired operations for the application. In contrast, if the eighty percent were not adequate for the application, then the developer may choose not to deploy the application using the platform, or may choose to add one or more additional satellites to the platform to provide the desired operation. This adding of the satellites may permit the developer to select the various sensors and processing capabilities of the satellite, and deploy the satellite into the required orbit for their operation. Further, once deployed, additional applications may be provided to the new satellite, wherein the new applications may share the physical resources of the satellite with the original application that triggered the deployment of the satellite.

In some implementations, the satellites of the satellite platform may each exchange state information with one or more other satellites and the ground control system for the platform. This state information may include current operational state information for each of the applications, such as the tasks or processes that are operating, and may further exchange data generated at least partially from the sensors of the satellite. This data may be used in a peer group, wherein a first satellite may identify a first set of data, and provide the data to a second satellite. The second satellite may then identify second data and, process the first and second data as defined by the application. This operation may be used, as an example, in imaging operations, wherein a first satellite may take images of an object over a first period of time, and provide data for the images to the second satellite. The second satellite may take subsequent images and use the data for the first images and the subsequent images to make a determination about an object. Although this is one example, it should be understood that other operations may use peer sharing of state data to identify characteristics about measured data from the satellite sensors.

<FIG> illustrates a satellite environment <NUM> according to an implementation. Satellite environment <NUM> includes satellites <NUM>-<NUM>, satellites <NUM>-<NUM>, Earth <NUM>, ground control system <NUM>, and launch system <NUM>. Satellites <NUM> and <NUM> belong to a first peer group <NUM>, and satellites <NUM>, <NUM>, and <NUM> belong to second peer group <NUM>, wherein the peer groups may be used to share state information, such as application state and data for the applications executing thereon. Satellites <NUM>-<NUM> and satellites <NUM>-<NUM> communicate via wireless communication links <NUM>-<NUM>. Ground control system <NUM> communicates with satellites <NUM>-<NUM> and satellites <NUM>-<NUM> using wireless communication link <NUM>.

As described herein, a plurality of satellites <NUM>-<NUM> and <NUM>-<NUM> may be launched and deployed as an orbiting platform for a plurality of different software applications. To generate the applications, design platform <NUM> is provided, which may include various tools and APIs that permit organizations to generate the software applications. In some implementations, design platform <NUM> may provide users with selectable functions and interface elements that are available on each of the satellites. Using the functions and available interface elements, the developer or developers for a particular organization may generate a software application that performs desired operations. For example, a developer may generate an application that uses a camera on a satellite to track movements of relevant objects.

Once the application is developed, the application may be provided to verification platform <NUM>, which can be used to verify and test the application before deploying the application to the satellite platform. Verification platform <NUM> may comprise a physical or virtual testbed, wherein the application can be deployed to one or more test satellites to determine the functionality of the application. In some implementations, in addition to testing the functionality, verification platform may further apply tests to the application to ensure that the application is approved for operating on the physical platform. These tests may include, but are not limited to, ensuring the application is not malicious to other applications that may execute on the same satellite, ensuring the application does not change the flight structure or operations of the satellite, ensuring the data is properly communicated between other satellites and the ground control system, or any other similar tests to verify the operation of the application.

In addition to developing and verifying the application, availability platform <NUM> may be used as part of ground control system <NUM> to schedule the application in the orbiting cluster. This scheduling may be used to determine satellites that apply to the operations of an application, operation times on each of the satellites, processing, communication, and sensor resources of the application, or any other similar scheduling for the satellite platform. In at least one implementation, availability platform <NUM> may receive user input regarding deployment requirements for a software application, wherein the deployment requirements may comprise geographic areas on Earth of interest, operation times of interest, sensor requirements, processing requirements, security requirements, cost constraints, or any other similar deployment requirement, including combinations thereof. Additionally, availability platform <NUM> may identify availability information for resources in the satellite platform, and may determine deployment options for the deployment of a software application based on the deployment requirements and the availability information for the satellite platform. Once the deployment options are identified, they may be provided to the developer of the software application, wherein the developer may use the options to select a deployment of the application in the platform. In some implementations, the application may be implemented using the current satellites in orbit, however, it should be understood that the options provided to the developer may also provide options to add additional satellites to the platform to provide the desired operation.

Once a deployment option is selected via availability platform <NUM>, ground control system <NUM> may initiate an uplink with one or more of the satellites to provide the application to the satellites, as well as update any scheduling information for the satellites. Once uploaded to the desired satellites, the application may begin execution based on the scheduling determined at availability platform <NUM>. In some implementations, the uplink from ground control system <NUM> may be solely responsible for providing the applications to the required satellites. In other implementations, ground control system <NUM> may supply an application to a first set of satellites, which may then distribute the application to one or more other satellites of the satellite platform. For example, ground control system <NUM> may provide a first application to satellite <NUM>, wherein satellite <NUM> may, in tum supply the application to other satellites in a peer group. In particular, satellite <NUM> may provide the application to satellite <NUM> that is in the same peer group, permitting satellite <NUM> to provide operations of the application without directly receiving the communication from ground control system <NUM>. Additionally, similar to providing the initial configuration to the satellites, ground control system <NUM> may further be used to supply updates to each of the applications operating in the satellite platform, and may further update any scheduling information on each of the satellites.

Also illustrated in satellite environment <NUM> is launch system <NUM>, which may be used to transport satellites (sats) <NUM> into orbit with orbiting satellites <NUM>-<NUM> and <NUM>-<NUM>. Satellites <NUM> include a hardware and software configuration that permits applications to execute as virtual nodes on the satellites. In some implementations, satellites <NUM> may be launched using launch system <NUM> without applications, and instead may be provided with a base operating system or hypervisor that can be used to load and execute applications as they are provided in an uplink from ground control system <NUM>. In other implementations, satellites <NUM> may be configured with a first set of applications capable of being executed via an operating system or hypervisor on the satellites. Thus, once into orbit, the applications may initiate execution to provide the operations of the applications. These applications may further be added to, removed, and modified based on information provided in the uplink from ground control system <NUM>.

In some implementations, the launch of satellites <NUM> may be controlled, at least in part, on an application that is desired to be deployed in the satellite cluster. In particular, if currently deployed satellites are incapable of providing the operations of an application, the developer of the application may select to deploy additional satellites with required hardware to support the application. Once deployed, the application may be provided to the newly launched satellites for execution. Additionally, one or more applications may also be provided to the newly launched satellites to share the available resources provided by the new satellite.

<FIG> illustrates an expanded view <NUM> of a satellite <NUM> capable of providing a platform for virtual nodes according to an implementation. Satellite <NUM> includes virtualized execution segment <NUM>, control segment <NUM>, and interface segment <NUM>, which may be coupled using various communication links. Virtualized execution segment <NUM> is representative of a virtualized execution system, which includes a virtualized user space <NUM> for virtual nodes <NUM>-<NUM>, an operating system or hypervisor <NUM>, a storage system <NUM> to store the operating system and virtual user space, and a processing system <NUM>. Control segment <NUM> further includes flight control system <NUM> and propulsion navigation <NUM>. Interface segment <NUM> further includes user sensors <NUM> and communication interface <NUM>, wherein communication interface <NUM> may be used for ground communication and inter-satellite communication. User sensors <NUM> may include imaging sensors, temperature sensors, light sensors, or some other similar sensor capable of interaction with virtual nodes <NUM>-<NUM>.

As described herein, organizations may generate applications that are capable of being deployed as virtual nodes on one or more satellites of a satellite platform. These applications may be provided from a ground control system, or may be provided from another satellite via communication interface <NUM> on satellite <NUM>. Once the applications are provided, operating system/hypervisor <NUM>, which is stored on storage system <NUM> and executed by processing system <NUM> may provide a platform for the execution of the applications. Here, each application provided to satellite <NUM> is executed as a separate virtual node in virtual nodes <NUM>-<NUM>, wherein the virtual nodes may comprise full operating system virtual machines or containers capable of sharing resources from the underlying operating system in storage system <NUM>.

To manage the execution of the virtual nodes, operating system/hypervisor <NUM> may manage a schedule that is used to allocate processing resources of processing system <NUM> to each of the nodes, user sensors <NUM> to each of the nodes, and other similar resources on satellite <NUM>. In particular, the schedule may be used to ensure that each application is scheduled to receive processing resources from processing system <NUM> during defined time periods, and receive access to user sensors <NUM> during defined time periods. In some implementations, one or more of the applications may execute during the same time period on satellite <NUM>. These applications may use different sensors in user sensors <NUM>, may time share the use of sensors in user sensors <NUM>, or may use the same data from user sensors <NUM> in their operation. To allocate the sensors operating system <NUM> may be responsible for providing each operating virtual node with a communication link to the required user sensor, and deallocating or removing the communication link to the required sensor based on the scheduling. For example, an imaging device may be accessed by virtual node <NUM> during a first-time period, wherein virtual node <NUM> may access the sensor based on addressing information provided by operating system <NUM>. Once the time period expires, operating system <NUM> may prevent virtual node <NUM> from accessing the sensor, in some examples, by removing the addressing access of the virtual node, and allocating access of the sensor to a second virtual node.

In addition to the virtual node operations provided in virtualized execution segment <NUM>, satellite <NUM> further includes control segment <NUM>. Control segment <NUM>, which may be communicatively linked to virtualized execution segment <NUM> and interface segment <NUM>, is responsible for logistical control elements of the satellite of satellite <NUM>. The operations may include managing the deployment of solar panels on the satellite, managing the positioning of the satellite with regards to the Earth or the sun, or any other similar operation. In at least one example, flight control system <NUM> may monitor for requests from operating system <NUM>, and determine whether the satellite is capable of accommodating the request from operating system <NUM>. For example, virtual node <NUM> may generate a request to move a user sensor, which also requires movement using propulsion and navigation <NUM>. In response to the request, flight control system <NUM> may determine that the movement cannot be made, and may prevent the movement of the satellite using propulsion and navigation <NUM>. Further, in some implementations, flight control system <NUM>, may provide a notification to operating system <NUM> and virtual node <NUM> indicating that the movement is not permitted.

Although illustrated as a separate system in the example of <FIG>, it should be understood that in some examples, flight control system may be implemented and stored on processing system <NUM> and storage system <NUM>. However, it should also be understood that flight control system may be stored on a separate storage system and use a different processing system than operating system <NUM> and its corresponding virtual nodes.

<FIG> illustrates an operation of a ground control system to provide deployment options for a software application according to an implementation. The operations in <FIG> are referenced parenthetically in the paragraphs that follow with reference to systems and objects of satellite environment <NUM> of <FIG>.

As depicted, availability platform <NUM> of ground control system <NUM> receives (<NUM>) user input indicative of deployment requirements for a satellite software application to be deployed in the satellite platform. These deployment requirements includes geographic areas of interest, and may further include operation times of interest, sensor requirements, processing requirements, security requirements, cost constraints, or any other similar deployment requirement, including combinations thereof. In some implementations, the developer of the application may supply the requirements using natural language to provide information for the application. For example, the developer may provide, "obtain images of all ships in the North Pacific from June through August. " In response to the input, availability platform <NUM>, may use a natural language engine to identify the relevant deployment requirements, such as imaging of ships (type of sensor required), North Atlantic (geographic region), and June through August (time period of interest). In other implementations, rather than providing a natural language input, availability platform may provide drop-down menus, multiple choice selections, or some other similar express selection of the deployment requirements.

In addition to determining the deployment requirements, availability platform <NUM> of ground control system <NUM> identifies (<NUM>) availability of satellite resources of the satellites in the satellite platform, whose orbit covers the geographic areas of interest. This availability information may include the availability of processing resources on the satellites of the satellite platform, the availability of sensors on the satellites of the satellite platform, the availability of communication interfaces, or any other similar information for the satellites currently orbiting for the satellite platform. In some examples, the availability may be based, at least in part, on applications that are already scheduled on the satellites. Thus, if a previously generated application required private use of an imaging sensor over a time period, then the sensor would be unavailable to any other applications during the time period.

Once the availability information and deployment requirements are identified, the operation further determines (<NUM>) options for deployment of the satellite software application based on the deployment requirements and the availability of satellite resources. For example, returning to the imaging example in the North Atlantic, options may be determined based on the availability of satellites over the particular geographic region, with the required sensors, during the required time period. In some examples, an option may permit one hundred percent or the complete operation to be provided for the application with satellites currently in the orbiting platform. In other implementations, only a portion, or a less than complete version, of the operations may be provided via the currently orbiting satellites. For example, if no satellites are in orbit over a geographic region during a particular time period, then images of the geographic region during the time period may not be possible using the currently deployed satellites. As a result, the options identified by ground control system <NUM> to implement the software application in the available satellites, or deploy one or more additional satellites to support a complete implementation of the desired application.

Once the options are determined for the software application, availability platform <NUM> on ground control system <NUM> provides (<NUM>) the options to a developer of the satellite software application. Once provided, via a user interface for the developer, the developer then makes a selection from the options to implement the application within the satellite platform. This may include, providing the software application using an uplink to one or more satellites and initiating execution of the application on the satellites to perform the desired operation.

In some examples, the software application may be developed prior to providing user input to availability platform <NUM>, however, it should be understood that prior to developing an application, a user may check the availability of resources to support the desired operation. Once determining the availability, the user may develop the application to provide the required operations.

In some implementations, when a developer requires a new application be deployed, the developer may specify a budget requirement for the new application. As a result, when the options are determined for the developer, only options that fit within the budget of the developer may be provided. For example, if an application could be deployed with all of the deployment requirements fulfilled, but would cost over the developer's budget, the option may not be made available to the developer. Instead, the developer may be provided with other options, that could provide less than the complete deployment requirements, but fit within the budget of the developer.

In at least one example, in identifying the availability of satellite resources in the satellite platform, the ground control system may determine an orbit availability to support the application. In particular, because the satellite platform may not provide geosynchronous orbits, or may require multiple satellites to cover a particular geographic region or fixed point in space, the ground control system may be required to identify satellites that provide orbits for the desired points of interest. Once the orbit availability is identified, along with the available processing and sensor resources, options may be identified to support the deployment requirements. In some implementations, the satellites identified for a software application may handoff operations as the orbit takes them away from a location of interest. In other implementations, the satellites may exchange state information when two or more satellites are capable of covering a geographic region at any one time (cooperatively providing operations on a point of interest). In still other implementations, the satellites may be used to provide communications from a first geographic location to a second geographic location. Accordingly, the application may operate on satellites that service the first geographic location and the second geographic location, and may further operate on other satellites capable of forwarding communications between the two locations.

Referring now to <FIG> illustrates an operation of a ground control system to provide deployment options for a software application according to an implementation. In particular, <FIG> is representative of operations of a ground control system once deployment options have been provided to a developer of an application. The operations in <FIG> are referenced parenthetically in the paragraphs that follow with reference to systems and objects of satellite environment <NUM> of <FIG>.

As depicted, once the deployment options are provided to the developer of an application, ground control system <NUM> may determine (<NUM>) whether the developer selects a complete accommodation option, wherein the complete accommodation option indicates to the developer that all of the deployment requirements can be met by currently available satellites in the satellite platform. If the user has selected a complete accommodation option, then ground control system <NUM> may deploy (<NUM>) the software application as one or more virtual nodes in the satellite platform. This deployment may include providing via an uplink the software application to at least one satellite and, in some examples, distributing, via the satellites in orbit, the software application to any other required satellites.

In contrast, if the user does not select the complete accommodation option, either because the cost of implementing is too high or because there is currently no availability to support the complete deployment, ground control system <NUM> may determine (<NUM>) whether the developer approves a less than complete accommodation option. In particular, as described herein, availability information may be determined for processing and sensor resources of currently deployed satellites <NUM>-<NUM> and <NUM>-<NUM>, wherein the availability may comprise time availability of the processing and sensor resources, as well as geographic coverage availability of each of the processing and geographic resources. Once determined, the availability information may be compared to the deployment requirements of the software application to determine whether the application can be accommodated by the currently deployed satellites <NUM>-<NUM> and <NUM>-<NUM>. In some examples, either because the satellites are already in use by one or more other software applications during the requested times or the satellites do not cover the required geographic region required by the software application during the required time period, ground control system <NUM> may determine a percentage, ratio, or some other scoring value indicating the amount of the request that can be accommodated using currently deployed satellites. For example, if no current satellites covered the most northern part of the Pacific Ocean, but Satellites could cover the remaining portions of the ocean, then ground control system may indicate a percentage of the ocean that could be covered by the satellites to support an application targeting the entire ocean. In an alternative example, percentages that are less than one hundred percent coverage for a software application may provide a lower cost than other options with a higher percentage of accommodating the request. Accordingly, a developer may select a lower percentage of accommodation to accommodate a budget, although all of the deployment requirements for the application may not be supported by the satellite platform.

If an administrator approves a less than complete accommodation option, then ground control system <NUM> may deploy (<NUM>) the software application as one or more virtual nodes in the satellite platform. In contrast, if the administrator does not approve a less than complete accommodation option, then ground control system <NUM> may determine (<NUM>) whether the developer desires new satellites to support the software application. If the developer does desire new satellites, ground control system <NUM> may deploy (<NUM>) new satellites, such as satellites <NUM>, and deploy the software application as one or more virtual nodes to current satellites in orbit and the additional new satellites requested by the developer. In some examples, the satellites that are deployed may be deployed as a defined form factor with defined sensor and processing configuration. In other examples, the developer of the software application may make modifications and select hardware (processing systems, sensors, and the like) to be deployed as the new satellite. In some implementations, the developer may initially deploy the software application to satellites that are currently in orbit, and further deploy the software application to new satellites as they are launched into orbit. In other implementations, the developer may delay the deployment of the application until the new satellites are placed into orbit, and deploy the application to the satellite platform once the new satellites are deployed.

In the alternative, if the developer does not select new satellites to provide the desired operation of the software application, ground control system <NUM> may permit the developer to modify (<NUM>) the application deployment requirements or cancel the application deployment to the satellite platform.

<FIG> illustrates a user interface <NUM> to provide deployment requirements for a software application according to an implementation. User interface <NUM> includes drop-down menus for geographic area of interest <NUM>, time of interest <NUM>, imaging sensor requirements <NUM>, and other sensor requirements <NUM>. Imaging sensor requirements <NUM> includes sensors <NUM>-<NUM>, however, it should be understood that any number of sensors may be made available in the drop-down menu. Although illustrated in the present example with four drop-down menus, it should be understood that any number of drop-down menus might provide similar operations.

As described herein, to deploy an application to an orbiting satellite platform, a developer is required to provide deployment requirements for the application. Here, the user is provided with various drop-down menus to select the various requirements for the application. Once the user selects the requirements, the user may determine the availability of satellite resources for a software application using submit function <NUM>. After submitting the requirements, the ground control system determines the availability of satellite resources in the satellite platform, and determine options to be provided to the user based on the deployment requirements and the satellite availability.

While demonstrated in the example of user interface as providing drop-down menus to select the requirements for a software application, it should be understood that other user interface elements may be provided to a developer to determine the availability of resources in a satellite environment. These user interface elements may include multiple choice selections, natural language input forms, or some other similar user input element. For example, the user may be provided with a text box permitting the user to input natural language requirements for the software application. Once provided, the ground control system may process the natural language input and abstract the deployment requirements for the application.

Although illustrated in the example of <FIG> as providing sensor requirements, it should be understood that the user may also provide processing system and/or communication interface requirements for a satellite. For example, an application may be used to provide communications from a first geographical location to a second geographical location using one or more satellites to forward the communication between the two locations.

<FIG> illustrates a deployment <NUM> of a software application according to an implementation. Deployment <NUM> includes ground control system <NUM>, developer <NUM>, deployed satellites <NUM> with selected satellites <NUM>, and new satellites <NUM>. Deployed satellites <NUM> includes satellites <NUM>-<NUM> and are representative of satellites available in orbit at the time of the request by the developer. New satellites <NUM> include satellites <NUM>-<NUM> and are representative of satellites that can be put into orbit at a future time after the request from a developer. Although illustrated with three satellites in selected satellites <NUM>, it should be understood that any number of current satellites may be selected to provide the operations of the software application.

In the example of deployment <NUM>, ground control system <NUM> provides, via a user interface at step <NUM>, one or more options for a developer <NUM> to deploy a software application in a satellite platform. These options may include an option that can completely service the deployment requirements of the developer using currently deployed satellites, at least one option that can provide a portion of the deployment requirements using the currently deployed satellites, an option that can completely service the deployment requirements of the developer using currently deployed satellites and newly deployed satellites, or some other similar option. Once supplied, developer <NUM> may select, at step <NUM>, an option that requests a combination of currently deploy satellites <NUM> and new satellites <NUM>. After receiving the selection from developer <NUM>, ground control system <NUM> may, at step <NUM>, identify satellites for deployment of the software application, wherein the satellites include currently deployed satellites that can, at least partially, service the operations of the application, as well as new satellites to provide the remaining portion of the operations. Once identified, the application may be deployed as virtual nodes, at step <NUM>, from ground control system <NUM> to selected satellites <NUM>, while new satellites <NUM> are created and deployed into orbit and to provide a platform for the required application.

In some implementations, in identifying new satellites <NUM>, the satellites may comprise a defined form factor with a processing system and sensors for the application. In other implementations, developer <NUM> may define the processing system and/or sensors that are required for the new satellites. In particular, the developer may define any imaging sensors, temperature sensors, processing system, or any other similar processing system or sensor attribute. Once defined, the satellite may be generated, and launched into orbit to provide the desired operations. In some examples, in deploying the application, the application may hold deployment until all of the new satellites are launched into orbit, however, it should be understood that the application may provide initial operations using satellites <NUM>-<NUM> prior to the launch of satellites <NUM>-<NUM> in some examples.

<FIG> illustrates an option user interface <NUM> according to an implementation. Option user interface includes selectable options for complete deployment requirements <NUM>, partial deployment requirements <NUM>-<NUM>, and complete deployment via new satellites <NUM>. Although four options are provided in the present example, it should be understood that more or fewer options may be provided. For example, if complete deployment were impossible using satellites that would be deployed at the time of the application deployment, then the complete deployment requirements <NUM> option may not be provided to the developer.

Here, once a developer of an application provides deployment requirements for the software application, the ground control system may provide the developer with options for deploying the application in the satellite platform. In particular, the ground control system may identify availability attributes for resources on satellites during the time periods required for the application. Once identified, the ground control system may determine options for the user based on the availability information and the deployment requirements of the application, and provide the options to the developer via a user interface.

Here, four options are identified for the developer. A first option, complete deployment requirements <NUM>, permits the software application to be deployed in the platform while providing all of the deployment requirements and is associated with a first cost <NUM>. The second two options, partial deployment requirements <NUM>-<NUM> permit the software application to be deployed in the platform while providing a portion of the deployment requirements and are associated with costs <NUM>-<NUM> and limitations <NUM>-<NUM>. In some examples, costs <NUM>-<NUM> may comprise lower costs than cost <NUM>, and may provide adequate operations for the developer while maintaining a budget for the developer. In the present instance, in addition to costs <NUM>-<NUM>, options <NUM> and <NUM> further include limitations <NUM>-<NUM>, which represent the limitations or the portions of the deployment requirements specified by the developer that cannot be achieved using the deployment option. For example, if a developer would like to track trucks over the European continent during the summer months, a limitation might include a time limitation where the application could not provide the full operation during a particular time period, a location limitation where one or more geographic locations could not be monitored, or some other similar limitation, including combinations thereof.

The last option in the example of user interface <NUM> is deployment with new satellites <NUM>, which includes costs <NUM> and, if any, limitations <NUM>. Here, rather than relying on the satellites that are currently available for the software application, a developer may select to introduce a new satellite to the platform to provide adequate operations of the software application. Thus, in addition to, or in some examples in place of the current satellite deployment, the developer may select to launch a new satellite for the software application. This satellite may comprise a predefined structure in some examples, such as processors, sensors, and the like, or may comprise components selected by the developer and target toward the application. However, cost <NUM> associated with option <NUM> may be more than options <NUM>-<NUM>, and thus may be undesirable for developers with a particular budget. In some examples, the deployment with new satellites may comprise temporarily providing the application to currently deployed satellites, then, when the new satellites are in orbit, adding the operations of the application to the newly deployed satellites.

Although illustrated with a cost and limitations in the present example, it should be understood that other information may be provided in addition to, or in place of, the cost and limitation information. For example, the ground control system may generate an accommodation score for each of the options and provide the accommodation score with the option to assist the user in making a selection for the application.

<FIG> illustrates an operation of a ground control system to design a new satellite according to an implementation. The operations of <FIG> may be provided via ground control system <NUM> or some other similar ground control system.

As described herein, when a user is provided with options for implementing a software application in a satellite platform, the currently available satellites of the platform may be incapable of providing the desired operation. Consequently, the user may select an option to generate at least one new satellite to provide the desired operations. For example, if the current satellites did not cover a desired geographical area, then a new satellite may be deployed to provide coverage of the geographical area.

Here, when the user requests at least one new satellite, the ground control system provides (<NUM>) hardware options for the developer to be implemented in the at least one new satellite. In some examples, the hardware options are determined based on the deployment requirements that are provided for the user. For example, if the developer required specific imaging sensors, then the hardware that is provided to the developer may include the required sensors. In other implementations, such as when the user provides the type of items to be monitored using the satellite (trucks, ships, weather, etc.), the ground control system may determine the types of sensors that can be used for the monitoring, and suggests the sensors to the developer. Accordingly, based on the size, coverage area, and other similar requirements for the application, the ground control system may be used to match the desired objective of the application to the appropriate new sensor.

Once the options are made available to the developer, the operation further receives (<NUM>) user input selecting hardware for the at least one new satellite. In some examples, to receive the input, the user may be provided with drop-down menus, multiple choice selections, or some other similar selection mechanism, wherein the user can select various sensors, processing system options, or any other similar option. After selecting the hardware, the ground control system may then generate (<NUM>) a satellite configuration based on the user input. In some examples, the satellite generated with the new hardware must meet size and shape constraints. Consequently, the ground control system may be required to determine positioning and layout information for the hardware to ensure that the hardware selected by the developer is capable being implemented within the required constraints.

In at least one implementation, as the developer makes selections for the hardware required for the satellite a cost estimate may be provided to the developer. For example, if the developer selected one imaging sensor over another, the cost may be modified to reflect the selected sensor. Additionally, in some implementations, during the selection of the hardware for the satellite, an indication may be made indicating if a larger satellite platform or rocket is required to deploy the provided hardware. Again, if the developer selected a first imaging sensor over a second imaging sensor, the ground control system may indicate that a larger satellite is required to support the first imaging sensor over the second imaging sensor.

<FIG> illustrates an overview <NUM> of managing deployments of software applications according to an implementation. Overview <NUM> includes operation requirements <NUM>, orbit and launch options <NUM>, and cost and scheduling for deployment <NUM>.

As depicted, to deploy an application in a satellite platform, the developer of an application may be required to provide operation requirement <NUM>, wherein the requirements may include mission design (the operations desired to be performed by the application), payload selection (selecting a particular application to deployed for developer), vehicle specification (selecting the hardware of the satellite), or cluster configuration options (identifying state exchange traits and/or geographic requirements for the application), or some combination thereof. Once the traits are determined, orbit and launch options <NUM> may be provided to the developer, wherein the launch options may include options for currently orbiting satellites, and may further include options that provide for the addition of one or more new satellites to the platform. After providing the options, cost and schedule for deployment operation <NUM>, may receive a selection of an option, allocate cost to the option, and schedule the deployment of the application.

Although illustrated as separate in the present implementation, it should be understood that cost may be calculated at the time of the orbit and launch options. Accordingly, the developer may be able to select a particular option based on the cost associated with the particular option.

<FIG> illustrates a deployment <NUM> of an application according to an implementation. Deployment <NUM> includes satellites <NUM>-<NUM>, ground control system <NUM>, and Earth <NUM> with geographic region <NUM>. Although three satellites are included in the present example, it should be understood that any number of satellites may be deployed as the satellite platform.

As described herein, when scheduling an application to be deployed to a satellite platform, the developer of the application is required to provide deployment requirements for the application. These deployment requirements may include mission design, payload selection or application selection, cluster configuration (state communication required between satellites), vehicle specification, or some other similar deployment requirement information for the application. In at least one example, the developer may desire an application that covers geographic area of interest and identifies specific objects within the geographic area of interest. In the present implementation, deployment <NUM> deploys an application to the satellite platform to identify trucks within geographic region <NUM>. To select the satellites for the deployment, the developer may supply requirements indicating geographic region and objects that are to be monitored within the region. In response to the input, ground control system <NUM> may identify availability of satellites of the platform to support requirements, wherein the availability may include sensor and processing system availability, and may also include geographic region and orbit availability. In particular, because satellites of the satellite platform may not operate in a geosynchronous orbit, the satellites may be required to exchange state information, as one satellite is incapable of providing continuous operations on a geographic region. Accordingly, based on the user input, ground control system <NUM> may identify processing and sensor availability for satellites whose orbit covers the geographic region, and determine a scheduling options based on the availability information. Once an option is selected, the application is supplied to the satellites associated with the selection, wherein the application may operate as a virtual node alongside other applications on the same satellite.

Here, satellites <NUM>-<NUM> are in orbit around earth <NUM>, wherein satellite <NUM> identifies first sensor data, at step <NUM>, related to geographic region <NUM>. Once the data is identified, and the orbit takes satellite <NUM> out of sensor range for geographic region <NUM>, satellite <NUM> will transfer, at step <NUM>, sensor data to satellite <NUM>. For example, if object <NUM> were identified using sensor data for satellite <NUM>, satellite <NUM> may provide global positioning information for object <NUM>, such that satellite <NUM> could maintain the monitoring the object. Once received, satellite <NUM> identifies, at step <NUM>, second sensor data related to geographic region <NUM>, and transfers, at step <NUM>, sensor data to satellite <NUM> when the orbit for satellite <NUM> takes satellite <NUM> away from geographic region <NUM>. Again, this sensor data may include location information for object <NUM>, velocity or speed information for object <NUM>, or any other similar information related to object <NUM>. Further, satellite <NUM> may identify any additional objects within geographic region <NUM>.

Once received at satellite <NUM>, satellite <NUM> may, at step <NUM>, identify any additional sensor data related to the geographic region and, in the present example, provide state data (which includes processed and/or unprocessed sensor data) to ground control system <NUM>. Although illustrated in the present example as satellite <NUM> providing sensor data to ground control system <NUM>, it should be understood that any combination of satellites <NUM>-<NUM> can provide sensor data to the ground control system. Additionally, despite being illustrated in the present example as each satellite identifying sensor data, it should be understood that at least one satellite may be incapable of providing operations for an application due to processing or sensor availability for the application. As a result, in some examples, a satellite may be used exclusively for an application to exchange state information between two other satellites.

While illustrated in the present example as handing off sensor operations between satellites to provide a desired operation of an application across multiple satellites, it should be understood that the scheduling of an application across multiple satellites may be used to provide additional operations. For example, an application may be deployed to multiple satellites to provide communications from one geographical location on earth to a second geographical location on earth. This may permit a party in the first geographical location to quickly communicate with the party in the second geographical location. In another example, rather than using a single satellite for a geographic region, multiple satellites may cooperate to provide operations with respect to a region. Referring to the example of <FIG>, if satellites <NUM>-<NUM> were over geographic region <NUM> at the same time, the satellites may exchange data about the geographic region. For instance, if satellite <NUM> identified an object, satellite <NUM> may provide geographic positioning information to satellite <NUM>, such that satellite <NUM> may provide operations with the same object. In still other implementations, although illustrated in the example of <FIG> as using a geographical region on Earth, it should be understood that satellites may be used to provide radio astronomy. In particular, satellites may be configured use its radio receiver assets or sensors to collect at appropriate times specific radio signals from fixed targets in space. Thus, instead of using a single satellite, satellites may handoff operations during their orbit to detect information from an inertial target in space.

In some implementations, the applications on the satellites may use various exchange triggers to transfer state information to other satellites. These triggers, for an individual satellite, may be based on global positioning coordinates identified by applications on the satellite, the orbit of the satellite, the current time identified by the satellite, a command in the application, signal detection or beacon detection in the satellite, network traffic deltas (latency, dropped packets, and the like), processing system utilization on the satellite, node failure, the addition of a new node, telemetry values, or some other similar trigger value. Referring to the example of deployment <NUM>, the state information communicated between satellites <NUM>-<NUM> may occur based on the orbit of the satellites, based on a measured time of the satellite, based on the identification and monitoring of object <NUM> in geographic region <NUM>, or some other similar trigger based on the monitoring of geographic region <NUM>.

<FIG> illustrates a deployment <NUM> of an application according to an implementation. Deployment <NUM> includes satellites <NUM>-<NUM>, communication system <NUM>, and Earth <NUM>. Although three satellites are included in the present example, it should be understood that any number of satellites may be deployed as the satellite platform. Deployment <NUM> is an example of a communication application which may be used to provide communications between geographical locations on Earth <NUM>.

As depicted, satellite <NUM> is configured to identify communications to communication system <NUM>, wherein, in response to a communication, satellite <NUM> may forward the communication to one or more other satellites and/or a second destination communication system for the communication. For example, a communication may be initiated in Africa and transmitted to satellite <NUM> to be transferred to a destination communication system in Europe. As satellite <NUM> continues to orbit, satellite <NUM> may handoff, at step <NUM>, the operations of the application to satellite <NUM>, wherein the handoff may be based on a lack of signal from communication system <NUM>, based on the orbit location of satellite <NUM>, based on latency of the data packets from communication system <NUM>, or based on any other similar handoff trigger. Once handed off, satellite <NUM> may execute the application to identify, at step <NUM>, communications from communication system <NUM> and forward the communication to at least one destination communication system. Additionally, similar to satellite <NUM>, once a handoff trigger is detected, satellite <NUM> may handoff, at step <NUM>, the operations of the application to satellite <NUM> to provide communication support for communication system <NUM>.

Although illustrated in the example of deployment <NUM> as receiving communications from communication system <NUM>, it should be understood that the application may also be to forward communications to communication system <NUM>. In particular, the active satellite for the application may receive a communication from a second satellite or a second communication system on Earth <NUM>, and forward the communication to communication system <NUM>.

<FIG> illustrates a development computing system <NUM> according to an implementation. Computing system <NUM> is representative of any computing system or systems with which the various operational architectures, processes, scenarios, and sequences disclosed herein for a ground control system can be implemented. Computing system <NUM> is an example of a ground control system from <FIG> and <FIG>, although other examples may exist. Computing system <NUM> comprises communication interface <NUM>, user interface <NUM>, and processing system <NUM>. Processing system <NUM> is linked to communication interface <NUM> and user interface <NUM>. Processing system <NUM> includes processing circuitry <NUM> and memory device <NUM> that stores operating software <NUM>. Computing system <NUM> may include other well-known components such as a battery, power supply, and enclosure that are not shown for clarity. Computing system <NUM> may represent one or more server computing systems, desktop computing systems, laptop computing systems, tablets, or some other computing system, including combinations thereof.

Communication interface <NUM> comprises components that communicate over communication links, such as network cards, ports, radio frequency (RF), processing circuitry and software, or some other communication devices. Communication interface <NUM> may be configured to communicate over metallic, wireless, or optical links. Communication interface <NUM> may be configured to use Time Division Multiplex (TDM), Internet Protocol (IP), Ethernet, optical networking, wireless protocols, communication signaling, or some other communication format - including combinations thereof. In some implementations, communication interface <NUM> may be configured to communicate with satellites of a satellite platform to provide applications, updates, and other configuration information, and may further be configured to receive, from the satellites, state information related to the state of processes for each of the applications and data for each of the applications.

User interface <NUM> comprises components that interact with a user to receive user inputs and to present media and/or information. User interface <NUM> may include a speaker, microphone, buttons, lights, display screen, touch screen, touch pad, scroll wheel, communication port, or some other user input/output apparatus - including combinations thereof. User interface <NUM> may be omitted in some examples. In some implementations, user interface <NUM> may be used to provide deployment availability information for a new software application, and may further be used to receive developer selections for deploying the new software application in the satellite platform.

Processing circuitry <NUM> comprises microprocessor and other circuitry that retrieves and executes operating software <NUM> from memory device <NUM>. Memory device <NUM> may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. Memory device <NUM> may be implemented as a single storage device, but may also be implemented across multiple storage devices or sub-systems. Memory device <NUM> may comprise additional elements, such as a controller to read operating software <NUM>. Examples of storage media include random access memory, read only memory, magnetic disks, optical disks, and flash memory, as well as any combination or variation thereof, or any other type of storage media. In some implementations, the storage media may be a non-transitory storage media. In some instances, at least a portion of the storage media may be transitory. It should be understood that in no case is the storage media a propagated signal.

Processing circuitry <NUM> is typically mounted on a circuit board that may also hold memory device <NUM> and portions of communication interface <NUM> and user interface <NUM>. Operating software <NUM> comprises computer programs, firmware, or some other form of machine-readable program instructions. Operating software <NUM> includes input module <NUM>, resource module <NUM>, and option module <NUM>, although any number of software modules may provide the same operation. Operating software <NUM> may further include an operating system, utilities, drivers, network interfaces, applications, or some other type of software. When executed by processing circuitry <NUM>, operating software <NUM> directs processing system <NUM> to operate computing system <NUM> as described herein.

In at least one implementation, input module <NUM> directs processing system <NUM> to receive user input indicative of deployment requirements for a software application. This input may be provided via drop-down menus, multiple choice selection, natural language input or some other similar input method via user interface <NUM>. In addition to identifying the deployment requirements, resource module <NUM> directs processing system <NUM> to identify an availability of resources in the plurality of satellites. These resources may include processing resources, communication resources, and sensor resources available on each of the satellites, and may be determined based on the current scheduling assigned to each of the satellites, as well load reports, which may be provided via state information from the satellites. Once the deployment requirements and the availability of resources are determined, option module <NUM> may direct processing system <NUM> to determine deployment options for deployment of the software application based on the deployment requirements and the availability of resources in the plurality of satellites, and provide the deployment options to a developer of the software application.

In some examples, the operations to determine deployment options may include determining whether each deployment requirement of the deployment requirements can be satisfied via the plurality of satellites. If each deployment requirement can be satisfied, then an option will be provided that indicates that the software application can be deployed with each deployment requirement satisfied. Additionally, if at least a portion of the deployment requirements can be satisfied, at least one option can be provided that indicates the software application can be deployed with limitations and may provide information about the particular limitations. For example, if the application can be deployed, but only cover a portion of the desired geographic region, then an option may be provided that indicates the limitation for the geographic region.

In some examples, in addition to providing options based on available satellites of the platform, option module <NUM> may further provide options that permit the developer to add new satellites to the platform. Accordingly, to overcome any current deficiencies in the platform, the developer may select to deploy a new satellite, and in some examples the hardware for the new satellite, and deploy the new satellite for the application. Thus, in some implementations, an application may rely on currently available satellites, as well as new satellites to provide the operations of the application.

Claim 1:
A method of providing software application deployments to an orbital satellite platform, the orbital satellite platform comprising a plurality of orbital satellites, the method comprising:
receiving (<NUM>) at an availability platform (<NUM>) of a ground control system (<NUM>, <NUM>) user input indicative of deployment requirements for a software application to be deployed in the orbital satellite platform, the deployment requirements comprising geographic areas of interest for the application;
identifying (<NUM>) at the availability platform (<NUM>) an availability of resources in the plurality of orbital satellites whose orbit covers the geographic areas of interest;
determining (<NUM>) at the ground control system (<NUM>) deployment options for deployment of the software application based on the deployment requirements and the availability of resources in the plurality of orbital satellites;
providing (<NUM>) at the availability platform (<NUM>) the deployment options via a user interface to a developer of the software application, wherein the developer may use the options to select a deployment of the software application in the orbital satellite platform; and
providing from the ground control system (<NUM>) to one or more of the plurality of orbital satellites of the orbital satellite platform the software application for deployment in accordance with the developer selected deployment option.