Virtual Flatsat and Distributed Digital Nodes

Abstract

Methods and systems are provided to enable virtual FlatSat and distributed node architectures. The virtual platform may be or include a SaaS platform that allows multiple users to access a compute node. The compute node allows a user to test a hardware subsystem by connecting to the SaaS through a remote computer, or to test virtual hardware on the SaaS platform without the use of a remote computer. Testing physical or virtual hardware subsystems on a remote computer involves running application APIs that mimic local software, reducing the likelihood of a hardware subsystem test failure.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of priority under 35 U.S.C. §119(e) of U.S. Provisional Patent Application No. 63 / 38,9320, entitled "VIRTUAL FLATSAT AND DISTRIBUTED DIGITAL NODES.", filed July 14, 2022. The entire disclosures of the above-cited applications are hereby incorporated by reference in their entirety into this specification for all purposes and for all teachings therein. [Technical Field]

[0002] The present disclosure is generally directed to distributed processing systems and distributed processing nodes. Summary of the Invention

[0003] Various embodiments and configurations of the present disclosure address the needs of the prior art.

[0004] The present disclosure provides, among other things, distributed digital node and virtualization techniques.

[0005] The present disclosure may provide many advantages depending on the particular configuration.

[0006] These and other advantages are apparent from the disclosure contained herein.

[0007] A system for a satellite according to at least one embodiment of the present disclosure includes at least one resource for communicating with a payload of the satellite, the at least one resource including a first abstracted physical communication interface, and a controller coupled to the at least one resource and including a second abstracted physical communication interface for communicating with the first abstracted physical communication interface via a communication link.

[0008] In any of the features herein, the communication link includes a USB connection, a UART connection, an Ethernet connection, an SPI connection, a PCI connection, a physical interface, a wireless interface, and / or an I2C connection.

[0009] Any of the features herein, wherein the at least one resource includes a payload server, an edge server, a computational resource, and / or a computational node.

[0010] In any of the features herein, the computing node is a client node or a server node.

[0011] Any of the features herein, wherein the controller includes a third abstracted physical communication interface for communicating with the remote node.

[0012] Any of the features herein, wherein the at least one resource includes an IPCC message encoder / decoder module, an IPCC message payload security module, and a bridge module that forwards messages received over a communication link with the controller.

[0013] In any of the features herein, the remote node is accessible by a primary user and a secondary user.

[0014] In any of the features herein, the bridge module manages accessibility for primary users and secondary users, where a primary user includes one or more users.

[0015] Any of the features herein, wherein the at least one resource includes a second remote node, and the bridge module associates a primary user with the remote node, and the bridge module associates a secondary user with the second remote node.

[0016] Any of the features herein, wherein the remote node and the second remote node are separate from at least one resource and the controller.

[0017] Any of the features herein, wherein a first simulation of the system includes at least one resource and a controller, a second simulation of the system includes at least one second resource and a second controller, and a primary user accesses the first simulation and a secondary user accesses the second simulation.

[0018] Any of the features herein, wherein at least one resource includes a simulation adaptation layer.

[0019] In any of the features herein, the Internet Protocol (IP) connectivity of the simulation adaptation layer is configurable.

[0020] Any of the features herein, wherein the first abstracted physical communication interface and the second abstracted communication interface communicate with each other via Internet Protocol (IP), TCP, UDP, and a direct API.

[0021] Any of the features herein, wherein the at least one resource includes two or more of a payload server, an edge server, a computational resource, and a computational node.

[0022] In any of the features herein, the edge server and the payload server communicate with each other via at least one of Internet Protocol (IP), TCP, UDP, and a direct API.

[0023] In any of the features herein, the controller and / or at least one resource selects an application programming interface (API) to be used to provide data to the user.

[0024] In any of the features herein, the controller and / or at least one resource converts a request for the API into a JSON file and / or converts the JSON file into the API.

[0025] Any of the features herein, wherein the controller and / or at least one resource converts the second request of the second API into a second JSON file and / or converts the second JSON file to the second API.

[0026] Any of the features herein, wherein the request and the second request are transmitted asynchronously.

[0027] Any of the features herein, wherein after confirmation of the translation of the request is received at the controller and / or at least one resource, the second request is transmitted synchronously.

[0028] In any of the features herein, the controller and / or at least one resource adds API execution timing constraints to the JSON file being transformed.

[0029] In any of the features herein, the controller and / or at least one resource converts an API request into a file and / or converts the file into an API, and the controller and / or at least one resource adds API execution timing constraints to the file during conversion.

[0030] In any of the features herein, the API execution timing constraint specifies that the API is executed at a predetermined time after the second API is executed.

[0031] In any of the features herein, the API execution timing constraint specifies that an API is executed at a predetermined time before a second API is executed.

[0032] Any of the features herein, wherein the API execution timing constraint specifies that the API executes at the same time as a second API.

[0033] In any of the features herein, an API execution timing constraint specifies that an API executes for a predetermined amount of time.

[0034] Any of the features herein, wherein the transformation is performed, at least in part, by a simulation adaptation layer.

[0035] In any of the features herein, the file includes a JSON file, a text file, a protocol buffer, or a csv file.

[0036] Any of the features herein, wherein the file specifies an expected response format from the payload.

[0037] In any of the features herein, the expected response format includes an expected time for the response from the payload.

[0038] In any of the features herein, an error message is generated if the response time of the payload is longer than expected.

[0039] Any of the features herein, wherein at least one resource executes the API a predetermined number of times if the response time of the payload is longer than an expected time.

[0040] Any of the features herein, wherein the file includes a plurality of parameters that specify the API execution.

[0041] In any of the features herein, the plurality of parameters include two or more of a data type, a data length, a relative execution time, an API format, an API name, a number of arguments, and an execution mode.

[0042] In any of the features herein, the API execution uses data previously sent to and stored in at least one resource.

[0043] In any of the features herein, the controller and / or at least one resource adds details of one or more dependent APIs to the JSON file being converted.

[0044] Any of the features herein, wherein at least one resource executes one or more applications that interact with the payload.

[0045] In any of the features herein, each of the one or more applications is associated with a different address.

[0046] Any of the features herein, wherein each distinct address comprises an IP address.

[0047] Any of the features herein, wherein the communication between the first abstracted physical communication interface and the one or more applications includes IP communication and / or inter-process communication (IPC) messages.

[0048] Any of the features herein, wherein the communication between the second abstracted physical communication interface and the one or more applications running on the controller includes inter-thread communication.

[0049] Any of the features herein, wherein the at least one resource further includes an encoder / decoder module, a security module, a registration module, a router module, and a listener / transmitter module.

[0050] As per any of the features herein, each application that can run on at least one resource is assigned a unique application ID.

[0051] Any of the features herein, wherein messages exchanged between at least one resource and the controller include a header that includes an application ID.

[0052] In any of the features herein, the header of each message further includes a source hardware device ID, a destination hardware device ID, a field to enable or disable encryption / decryption, a field to enable authentication, and / or a packet sequence number.

[0053] Any of the features herein, for an inbound message from the controller to the at least one resource, the at least one resource processes the header before sending the inbound message to an application of the at least one resource.

[0054] Any of the features herein, wherein for an outgoing message from the at least one resource to the controller, the at least one resource adds a header to the outgoing message before sending it to the controller.

[0055] Any of the features herein, wherein the payload application hardware subsystem is separate from the at least one resource and the controller.

[0056] In any of the features herein, data from the application hardware subsystem is stored locally before being sent to the at least one resource and / or controller.

[0057] Any of the features herein, wherein the application hardware subsystem is tested in a virtual environment that uses at least one resource.

[0058] Any of the features herein, wherein the application hardware subsystem, the at least one resource, and the controller are cloud-based.

[0059] In any of the features herein, at least one of the resource and the controller is cloud-based.

[0060] Any of the features herein further including a satellite, the satellite including at least one resource and a controller.

[0061] Any of the features herein, wherein the at least one resource includes a cloud server simulated computing node, a cloud server simulated computing resource, a desktop computer, and a high performance computing (HPC) device.

[0062] Any of the features herein, wherein the at least one resource corresponds to a compute node, a computational resource running, a sensor hardware subsystem simulated on a cloud server, a sensor hardware subsystem simulated on a desktop computer, a sensor hardware subsystem simulated on a high performance computing (HPC) device, and / or a satellite payload hardware subsystem.

[0063] A method for simulating satellite data collection according to at least one embodiment of the present disclosure includes providing at least one cloud-based computing node that controls a satellite payload, providing at least one remote computing node that includes an application hardware subsystem that simulates the satellite payload, and simulating operation of the satellite payload using the application hardware subsystem based on signals received by the at least one remote computing node from the at least one cloud-based computing node.

[0064] Any of the features herein, wherein the application hardware subsystem includes a sensor simulated by software on at least one remote compute node.

[0065] Any of the features herein, wherein the application hardware subsystem includes a physical sensor that is remote from but in communication with at least one remote computation node.

[0066] A system according to at least one embodiment of the present disclosure includes three or more distributed computations, the three or more distributed computations intercommunicating with each other in a cloud environment, and at least one of the three or more distributed computations communicating with a remote resource via a cloud connection, each of the three or more distributed computations configured to receive information from the remote resource and / or provide commands executable by the remote resource.

[0067] In any of the features herein, the remote resource includes a simulated resource.

[0068] Any of the features herein, wherein the simulated resource includes a simulated sensor.

[0069] Any of the features herein, wherein the simulated sensor includes a sensor configured for use on a satellite.

[0070] In any of the features herein, the simulated resources include at least one of simulated software, simulated hardware, and simulated compute nodes.

[0071] Any of the features herein, wherein the cloud environment is executed on a satellite.

[0072] Any of the features herein, wherein the cloud environment is executed on terrestrial servers.

[0073] Any of the features herein, wherein at least one of the three or more distributed computations is virtualized.

[0074] In any of the features herein, all of the three or more distributed computations are virtualized.

[0075] Any of the features herein, wherein the three or more distributed computing devices include at least one of a microcontroller, a microprocessor, a payload server, and an edge server.

[0076] Any of the features herein, wherein communication with the remote resource is achieved through at least one of a physical input / output hardware abstraction layer (IO-HAL) and an application hardware abstraction layer (AH-AL).

[0077] In any of the features herein, the IO-HAL includes an abstracted physical communication interface.

[0078] As per any of the features herein, the AH-AL comprises an abstraction application layer of the physical communication interface.

[0079] In any of the features herein, communication with the remote resource is achieved by transmitting one or more JSON files.

[0080] In any of the features herein, the one or more JSON files define at least one of a current API execution time, a timing-dependent API, a relative execution time, an execution mode, and a number of arguments.

[0081] In any of the features herein, the one or more JSON files are converted into one or more API calls.

[0082] Any aspect may be combined with any one or more of the other aspects.

[0083] Any one or more aspects are disclosed herein.

[0084] Any one or more features substantially as disclosed herein.

[0085] Any one or more features may be substantially as disclosed herein in combination with any one or more other features.

[0086] Any one aspect / feature / implementation may be combined with any one or more other aspects / features / implementations.

[0087] Use of any one or more of the aspects or features disclosed herein.

[0088] It is recognized that any aspect or feature described herein may be combined with any other aspect or feature described herein, regardless of whether the features are from the same implementation as those described.

[0089] The phrases "at least one," "one or more," and "and / or" are open-ended expressions that function both conjunctively and disjunctively. For example, each of the expressions "at least one of A, B, and C," "at least one of A, B, or C," "one or more of A, B, and C," "one or more of A, B, or C," and "A, B, and / or C" means A alone, B alone, C alone, A and B together, A and C together, B and C together, or A, B, and C together. [Brief explanation of the drawings]

[0090] [Figure 1] FIG. 1 illustrates an aspect of a system according to an embodiment of the present disclosure. [Figure 2] FIG. 2 illustrates additional aspects of a system according to an embodiment of the present disclosure. [Figure 3] FIG. 3 illustrates additional aspects of a system according to an embodiment of the present disclosure. [Figure 4] FIG. 4 illustrates an aspect of a system in a cloud environment according to an embodiment of the present disclosure. [Figure 5] FIG. 5 illustrates a call flow diagram according to an embodiment of the present disclosure. [Figure 6] FIG. 6 illustrates a remote node connected to a cloud platform according to an embodiment of the present disclosure. [Figure 7] FIG. 7 illustrates another call flow diagram according to an embodiment of the present disclosure. [Figure 8] FIG. 8 illustrates another remote node connected to a cloud platform according to an embodiment of the present disclosure. [Figure 9] FIG. 9 illustrates another call flow diagram according to an embodiment of the present disclosure. [Figure 10] FIG. 10 illustrates another remote node connected to a cloud platform according to an embodiment of the present disclosure. [Figure 11A] FIG. 11A illustrates a first portion of a call flow diagram according to an embodiment of the present disclosure. [Figure 11B] FIG. 11B illustrates a second portion of a call flow diagram according to an embodiment of the present disclosure. [Figure 12] FIG. 12 illustrates another remote node connected to a cloud platform according to an embodiment of the present disclosure. [Figure 13] FIG. 13 illustrates another call flow diagram according to an embodiment of the present disclosure. [Figure 14] FIG. 14 illustrates another remote node connected to a cloud platform according to an embodiment of the present disclosure. [Figure 15] FIG. 15 illustrates another call flow diagram according to an embodiment of the present disclosure. [Figure 16] FIG. 16 illustrates another remote node connected to a cloud platform according to an embodiment of the present disclosure. [Figure 17] FIG. 17 illustrates another call flow diagram according to an embodiment of the present disclosure. [Figure 18] FIG. 18 illustrates an aspect of a system in a cloud environment according to an embodiment of the present disclosure. [Figure 19] FIG. 19 illustrates aspects of a JSON template according to an embodiment of the present disclosure. [Figure 20] FIG. 20 illustrates another call flow diagram according to an embodiment of the present disclosure. [Figure 21A]FIG. 21A illustrates an aspect of a JSON template according to an embodiment of the present disclosure. [Figure 21B] FIG. 21B illustrates additional aspects of a JSON template according to an embodiment of the present disclosure. [Figure 22] FIG. 22 illustrates another call flow diagram according to an embodiment of the present disclosure. [Figure 23] FIG. 23 illustrates additional aspects of a JSON template according to an embodiment of the present disclosure. [Figure 24] FIG. 24 illustrates another call flow diagram according to an embodiment of the present disclosure. [Figure 25] FIG. 25 illustrates a system having a multi-user mode according to an embodiment of the present disclosure. [Figure 26] FIG. 26 illustrates a system having another multi-user mode according to an embodiment of the present disclosure. [Figure 27] FIG. 27 illustrates a system having another multi-user mode according to an embodiment of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0091] Embodiments of the present disclosure are described in the context of virtual FlatSats and distributed digital nodes.

[0092] FIG. 1 illustrates aspects of a system 100 according to an embodiment of the present disclosure. System 100 includes an onboard controller 104, a payload server 108, an edge server 112, payload server application hardware subsystems (AHSs) 116A-116N, edge server application hardware subsystems (AHSs) 120A-120N, and core application hardware subsystems (AHSs) 124A-124N. Notwithstanding the above, system 100 may include additional or alternative components to those illustrated in FIG. 1, and may additionally or alternatively exclude certain components illustrated in FIG. 1. For example, system 100 may include additional AHSs, additional processing circuitry, additional or alternative servers, and / or the like.

[0093] The on-board controller 104 may include a microcontroller, microprocessor, processor, and / or the like that may be connected to the cores AHS 124A-124N to control or manage the cores AHS 124A-124N. The cores AHS 124A-124N may be or include, for example, attitude determination and control systems (ADCS), inertial measurement units (IMUs), sensors (e.g., temperature sensors, pressure sensors, etc.), and / or the like. The on-board controller 104 may be connected to the cores AHS 124A-124N via a physical interface (PI). The PI may be or include, for example, a universal serial bus (USB), a universal asynchronous receiver / transmitter (UART), Ethernet, a serial peripheral interface (SPI), an inter-integrated circuit (I2C), a peripheral component interconnect (PCI), and / or the like.

[0094] The payload server 108 comprises processing circuitry capable of supporting multiple missions requiring the resources of the payload servers AHS 116A-116N. For example, the payload server 108 may perform tasks such as running payload applications for on-orbit computing, data processing, data communications, security, other onboard non-mission critical computing such as offloading one or more tasks from the edge server 112 and / or onboard controller 104, and / or the like.

[0095] The edge server 112 includes processing circuitry capable of supporting multiple missions requiring the resources of the edge servers AHS 120A-120N. For example, the edge server 112 may enable computation through the use of one or more artificial intelligence (AI) and / or machine learning (ML) data models, algorithms, and / or the like. The AI and / or ML models, etc. may enable and / or assist in station keeping, resource optimization, debris avoidance (e.g., when maneuvering satellites), management decommissioning, combinations thereof, and / or the like.

[0096] Compute nodes, such as the onboard controller 104, payload server 108, and edge server 112, may be connected to core AHSs 124A-124N, payload servers AHSs 116A-116N, and edge servers AHSs 120A-120N, respectively. In some examples, the compute nodes and AHSs are actual hardware platforms interconnected with one another via a physical IO bus, such as USB, UART, Ethernet, I2C, and / or any other similar communication IO bus. The physical IO bus connection between any of the onboard controller 104, payload server 108, and edge server 112 may include low-power IO drivers. The low-power IO drivers, in some examples, are abstracted using an IO hardware abstraction layer (HAL).

[0097] In some cases, in addition to the IO abstraction of the low-power IO drivers, Internet Protocol (IP)-based protocols are used on the IO bus interface drivers. For example, a Remote Network Driver Interface Specification (RNDIS) driver or Abstraction Control Model (ACM) driver and / or similar protocols can be used with USB, a Point-to-Point Protocol (PPP) driver and / or similar protocols can be used with UART, and an Internet Protocol over Ethernet (IPoE) driver and / or similar protocols can be used with Ethernet. As a result, the interconnection between the three compute hardware / computing nodes (e.g., onboard controller 104, payload server 108, and edge server 112) effectively becomes an IP-based interconnection. This may enable International Packet Communication Consortium (IPPC) header and frame formats and application-level security built on top of the IP layer.

[0098] In some cases, the IO bus interface connection between the onboard controller 104 and the cores AHS 124A-124N may implement an IO bus abstraction framework. IO abstraction may be implemented so that software running on the onboard controller 104 (as well as other software and applications) accesses the cores AHS 124A-124N to read and write data. By abstracting the IO bus, changes to the cores AHS 124A-124N do not affect applications running on the onboard controller 104 and accessing the cores AHS 124A-124N.

[0099] In some cases, the physical IO bus interface connections between the payload server 108 and the payload server AHSs 116A-116N, as well as the physical IO bus interface connections between the edge server 112 and the edge server AHSs 120A-120N, may or may not implement the IO bus abstraction framework. For example, the IO bus abstraction framework may not be implemented in instances where the IO bus drivers and applications that access the hardware to read and write data are provided by a hardware vendor. In this instance, the applications may be treated like black boxes, such as the system 100, without direct access to the hardware subsystems to read and write data. As a result, IO bus driver abstraction may not be necessary. In some instances, the AHSs change, and the corresponding drivers and applications running on the payload server 108 also change. In addition, the AHSs may be provided by the application hardware vendor. As a result, in some examples, system 100 may not implement hardware abstraction between payload server 108 and payload servers AHS 116A-116N and / or between edge server 112 and edge servers AHS 120A-120N. Additionally or alternatively, connectivity between payload server 108 and payload servers AHS 116A-116N and connectivity between edge server 112 and edge servers AHS 120A-120N may not require IP-based interconnection (e.g., a PI interface may be sufficient). However, it is understood that various embodiments of the present disclosure may implement IO bus abstraction and / or IP-based interconnection between payload server 108 and payload servers AHS 116A-116N and / or between edge server 112 and edge servers AHS 120A-120N.

[0100] 2 , the onboard controller 104, the payload server 108, and the edge server 112 may have onboard controller applications 212A-212N, payload server applications 204A-204N, and edge server applications 208A-208N, respectively. Each of the applications 212A-212N, 204A-204N, and 208A-208N may correspond to an AHS connected to the onboard controller 104, the payload server 108, or the edge server 112, respectively. In some cases, the applications may run within the payload server 108 as a virtual machine or the like. Each application may have its own IP address for communicating with other components of the system 100. Similarly, the IPCC framework (IPCCFW) running on the payload server 108 may have its own IP address. As a result, communication between the IPCCFW in the payload server 108 and the payload server applications 204A-204N may be IP communications, such as Transmission Control Protocol over Internet Protocol (TCP / IP) or User Datagram Protocol / Internet Protocol (UDP / IP). Within the on-board controller 104, the IPCCFW may communicate with applications on the on-board controller 104 (e.g., on-board controller applications 212A-212N) using Inter-Task Communication (ITC).

[0101] With reference to FIG. 3 , the onboard controller 104 may connect to and communicate with the payload server 108 and / or the edge server 112. In other words, the following description of communication flow occurs between the onboard controller 104 and the payload server 108, and / or between the onboard controller 104 and the edge server 112. As shown in FIG. 3 , the payload server 108 and / or the edge server 112 may execute one or more applications 304A-304B. The applications 304A-304B may be similar to or the same as the payload server applications 204A-204N and / or the edge server applications 208A-208N. While two applications 304A, 304B are illustrated in FIG. 3 , it should be understood that the payload server 108 and / or the edge server 112 may execute fewer or additional applications.

[0102] Each application 304A, 304B may include an application data unit, IPCC header information, and a receiver / transmitter. The receiver / transmitter may enable the application 304A-304B to connect with the IPCC FW, as illustrated in FIG. 3 by the dashed lines. The interface supported between the application 304A-304B and the IPCC FW may be native Linux IPC (Linux Message Queue), WebSockets (e.g., TCP / IP, UDP / IP, etc.), a combination thereof, and / or the like. In instances where both message queue and IP-based communication are used, other inter-process / task / service communication may also be applied. As a result, there may be an initialization process for each application 304A, 304B to register the application 304A, 304B for dynamic interface selection. Additionally or alternatively, the type of interface between each of the applications 304A-304B and the IPCCFW may be selected during construction based on user input if there is a static interface selection (e.g., the user selects either a message queue or an IP-based interface between the application and the IPCCFW).

[0103] The IPCC FW of the payload server 108 and / or the edge server 112 includes multiple layers. The IPCC includes an input / output vendor driver (IO-VD) 308, an input / output vendor driver porting layer (IO-VDP) 312, an input / output hardware abstraction layer (IO-HAL) 316, a network stack 320, and an IPCC library 324. The IO-VD 308 may act as a physical IO bus interface to enable communication between the onboard controller 104 and the payload server 108 and / or the edge server 112. The IO-VDP 312 may include a wrapper layer and an abstraction layer. A network stack 320 may be added on top of the IO-VDP 312. The network stack 320 may be RNDIS for a USB interface, PPP for a UART interface, or Point-to-Point Protocol over Ethernet (PPPoE) for an Ethernet interface. The IPCC library 324 may be located above the network stack 320 in the stack.

[0104] The IPCC library 324 may include various sub-modules, such as an encoder / decoder 328, security 332, bridge / router / application registration service 336, IPCC payload 340, IPCC information 344, and receiver / transmitter 348. The encoder / decoder 328 may encode and / or decode messages or other information communicated between the payload server 108 and / or edge server 112 and the onboard controller 104. The security 332 may perform authentication, and in addition or instead, encryption and decryption, of messages or other information communicated over the IPCC FW. The bridge 336 may perform routing and / or packet forwarding of messages or other information communicated through the IPCC FW. In some cases, the bridge 336 may perform application registration services, for example, when one or more applications 304A-304B are initialized and executed on the payload server 108 and / or edge server 112. The IPCC payload 340 may comprise information communicated over the IPCC FW. IPCC information 344 may comprise information relating to the IPCC, or more generally to the IPCCFW. For example, IPCC information 344 may comprise information about the bandwidth capabilities of the IPCCFW.

[0105] The receiver / transmitter 348 may be websocket-based (e.g., TCP / IP, UDP / IP) or a native Linux IPC message queue. The receiver / transmitter 348 may be similar to or the same as the receiver / transmitter present in one or more of the applications 304A-304B, such that the applications 304A-304B can communicate with the IPCC library 324 (and vice versa). In some cases, the receiver / transmitter 348 and the receiver / transmitter of the applications 304A-304B may be used to establish, maintain, and terminate communications between the IPCC library 324 and the applications 304A-304B.

[0106] In instances where the applications 304A-304B are written as virtual machines or are containerized, communication between the applications 304A-304B and the IPCC library 324 may benefit from IP-based communication. In other cases where the applications 304A-304B are written as native libraries that support standard IPC communication (e.g., message queues), communication between the applications 304A-304B and the IPCC library 324 may benefit from non-IP-based communication. As a result, both Linux IPC messaging and IP-based interfaces may be provided.

[0107] When applications 304A-304B communicate via IPCC, they may undergo service registration, and the IPCC FW assigns each application 304A, 304B an application ID. This can occur at power plug-on initialization (PoI) or any time the application begins initialization. In some cases, registration can occur through pre-configuration provided at application build time. The IPCC FW then provides one or more application programming interfaces (APIs) for registration and deregistration. The APIs may be or include interfaces provided on a display for users to view and / or interact with. Applications may use the APIs for registration and deregistration, and in some cases, the initial registration of an application may require access to a compute node (e.g., payload server 108, edge server 112, etc.). The application ID may be used for purposes of communication between the registered application and other applications, as well as for IPCC session maintenance of the application. In some examples, the application ID may be used by the IPCCFW for further IPCC message mapping / forwarding, as well as to restrict application access for security purposes.

[0108] When any of the applications 304A-304B attempts to send application data units (ADUs) to the onboard controller 104, the application may provide IPCC header information along with the ADU. The IPCC header information may include various parameters. In one example, the IPCC header includes a source hardware device ID (e.g., from the onboard controller 104, the payload server 108, or the edge server 112), a source application or session ID, a destination hardware device ID (e.g., intended for the onboard controller 104, the payload server 108, or the edge server 112), a destination application or session ID, a packet sequence number, IPCCFW level encryption or decryption (which may be or may include a binary indication of whether encryption / decryption is desired at the IPCCFW level), and / or IPCCFW level message authentication (which may be or may include a binary indication of whether message authentication is desired at the IPCCFW level). Such parameters may have different data sizes (e.g., 1 bit, 1 byte, 2 bytes, etc.). It is understood that the above parameter information may be the base fields for the IPCCFW, and that additional or alternative IPCC information may be added to support various scenarios and applications.

[0109] When the IPCC FW receives the IPCC header information and ADUs from the applications, the IPCC header information can be used to perform several functions. For example, the IPCC FW's security 332 may use the header information to enable encryption and / or authentication. As another example, the bridge 336 may perform registration services such as generating application IDs, maintaining sequence numbers, combining them, and / or the like. As yet another example, the IPCC library 324 may encode / decode the IPCC headers (e.g., using the encoder / decoder 328). The encoder / decoder 328 may treat the data units as raw byte sequences, generate IPCC data packets, and transmit the IPCC data packets across destination hardware devices (e.g., if the IPCC assigns the onboard controller 104 as the destination hardware device, the IPCC FW sends the packets to the onboard controller 104). The IPCC FW can also remove the IPCC header information and map / forward the ADUs to the respective applications. The mapping and forwarding may be performed by the bridge 336. For example, when one or more of the applications 304A-304B running on the payload server 108 wants to send messages and / or data to the onboard controller 104, the applications 304A-304B may provide an ADU to communicate with the onboard controller 104 and may send an IPCC header along with the ADU. In some cases, the IPCC header information may be in a different raw byte system, but follow the byte ordering specified by the IPCCFW. The byte system may containerize any one or more of the applications 304A-304B, for example, so that the applications 304A-304B do not need to depend on any particular programming language. Additionally or alternatively, this configuration may allow the applications 304A-304B to be agnostic to IPCC packet formats, IPCC message / header encoding / decoding, their combination, and / or the like.As noted above, while the discussion of applications 304A-304B is made with respect to payload server 108, the same features may also apply to applications 304A-304B running on edge server 112 with respect to any computing node or computer that also uses an IPCC interface to communicate across processing nodes.

[0110] 4, computational nodes including the onboard controller 104, payload server 108, and edge server 112 are soft-simulated in a cloud platform according to an embodiment of the present disclosure. In the cloud platform, the payload servers AHS 116A-116N, core AHS 124A-124N, and / or edge servers AHS 120A-120N may operate on remote nodes at the client end, with the remote nodes connecting with the cloud platform, for example, via IP connectivity. As shown in FIG. 4, the main computational nodes (e.g., the onboard controller 104, payload server 108, and edge server 112) may communicate via IPCC packets over IP packets.

[0111] Referring to FIG. 5 , a call flow diagram illustrating intercommunication between the onboard controller 104, the payload server 108, and the edge server 112 in the cloud platform is shown, according to an embodiment of the present disclosure. An application running on the onboard controller 104 (e.g., one of the onboard controller applications 212A-212N) sends a data request via ITS to the IPCCFW of the onboard controller 104. The IPCCFW then sends an API via TCP / IP to a TCP / IP server or client (e.g., the IO-VD 308) to send the data to the TCP / IP server or client in the payload server 108 or the edge server 112. The TCP / IP server then requests data from the IPCCFW in the payload server 108 or the edge server 112. The IPCCFW then sends the data request payload to the TCP / IP, and the API is sent to the local host. The local host may then access a local application to process the data request. After the data request is processed by the application, the application may send the API to the local host, which then sends the data to the IPCCFW. The application then sends a payload containing the response to the TCP / IP server or client, which may then forward the data to the onboard controller 104, which then forwards the data transmission to the application via the IPCCFW.

[0112] In some cases, one or more application hardware subsystems (e.g., payload servers AHS 116A-116N, core AHS 124A-124N, and / or edge servers AHS 120A-120N) may be connected to a main software-simulated compute node. This connection may be simulated on a remote computer (e.g., simulated sensors such as temperature sensors, IMUs, etc.), with the remote computer connected to the main software-simulated compute node (e.g., onboard controller 104, payload server 108, or edge server 112) via a TCP / IP socket connection, as shown in FIG. 8. Alternatively, the application hardware subsystem may be actual physical hardware (e.g., temperature sensor hardware) connected to the remote computer via a physical IO bus interface (e.g., UART, I2C), as shown in FIG. 6. As a result, the cloud platform of system 100 provides a SaaS platform or environment for vendors / clients to integrate and / or test application hardware subsystems developed using simulated software in the SaaS platform, and the application hardware is integrated and certified. In some embodiments, the simulated software may be a satellite platform, while in other embodiments, the simulated software may be a terrestrial platform.

[0113] Referring to FIG. 6 , a remote node connected to a cloud platform is shown according to an embodiment of the present disclosure. The cloud platform includes an onboard controller 104, which includes an application 604 (which may be similar to or the same as any of the onboard controller applications 212A-212N), an application hardware abstraction layer (AHAL) 608, an application hardware simulation adaptation layer (AH-SAL) 612, and a TCP / IP port 616. The remote node includes a remote node 620 that includes a TCP / IP port 624, an AH-SAL 628, an application hardware vendor porting layer (AH-VDP) 632, an AH vendor driver (AH-VD) 636, and an IO vendor driver (IO-VD) 640 that communicates with application hardware 644 via a physical IO interface. In some cases, the application hardware subsystem may be or include actual physical hardware connected to the remote node computer 620. This connection may be a physical interface (e.g., UART, I2C). A driver for an application hardware subsystem (e.g., a temperature sensor driver) may run on a remote computer (e.g., a home computer), which may then be connected to a main soft-simulated compute node (e.g., onboard controller 104, payload server 108, or edge server 112) via TCP / IP socket communication (e.g., communication between TCP / IP 616 and TCP / IP 624).

[0114] Input or output data from application hardware 644 is accessed or obtained by AH-VD 636, which invokes AH-VDP 632. AH-VDP 632 then invokes the AHAL API, which in turn invokes AH-SAL 628. AH-SAL 628, after translation, invokes a socket interface, such as TCP / IP interface 624. As a result, data from application hardware 644 is sent via the socket interface to a soft-simulated onboard controller 104 running in a virtual machine within the cloud platform.

[0115] Referring to FIG. 7, a call flow diagram for remotely connecting to application hardware is shown in accordance with an embodiment of the present disclosure. In some cases, the call flow diagram of FIG. 7 may be the intercommunication call flow shown in FIG. 6. An application 604 running on a virtual machine in the cloud platform (e.g., an application running on a simulated onboard controller 104) may send a data request API to AHAL 608, which forwards the data request API to AH-SAL 612. AH-SAL 612 then converts the API request into a JSON file and sends the file to the remote computer or controller via a TCP / IP interface (e.g., TCP / IP 616 to TCP / IP 624). TCP / IP 624 then pushes the data to AH-SAL 628, which converts the JSON file to an API and sends the API data request to AH-VDP 632. The AH-VDP 632 then forwards the request to the AH-VD 636, which in turn sends the API and command to the IO-VD 640. The command may instruct the application hardware 644 to perform a specific function (e.g., generate temperature data if the application hardware 644 includes a temperature sensor). The IO-VD 640 may also send instructions to the application hardware 644 to send a response at a later time (e.g., send data generated by the application hardware 644 after the application hardware 644 performs the specific function). The application hardware 644 then sends the response to the AH-VD 636 via the IO-VD 640. The AH-VD 636 then processes the response from the application hardware 644 and sends the data response API via the AH-VDP 632 and the AH-SAL 628. The AH-SAL 628 then converts the API to a JSON file and sends the data to the TCP / IP 616 via TCP / IP 624. TCP / IP 616 sends the data to AH-SAL 612, which converts the JSON file to an API.The response API is then sent back to the AHAL 608 and ultimately back to the application 604 running on the onboard controller 104. While the API is described as being converted into a JSON file, it is understood that the API may be converted into other file formats, such as a text file, protocol buffers, a csv file, and / or the like.

[0116] 8, a remote node connected to a cloud platform is shown according to an embodiment of the present disclosure. The cloud platform includes an onboard controller 104, which includes an application 804, an AHAL 808, an AH-SAL 812, and a TCP / IP port 8126. The remote node includes a remote computer 820, which includes a TCP / IP port 824, an AH-SAL 828, an AH-VDP 832, an AH-VD 836, and application hardware 840. In some cases, application 804, AHAL 808, AH-SAL 812, TCP / IP port 816, remote computer 820, TCP / IP port 824, AH-SAL 828, AH-VDP 832, and AH-VD 836 may be similar to or the same as application 604, AHAL 608, AH-SAL 612, TCP / IP port 616, remote computer 620, TCP / IP port 624, AH-SAL 628, AH-VDP 632, and AH-VD 636, respectively.

[0117] In some cases, such as that shown in FIG. 8 , a simulated application hardware subsystem (e.g., a soft-simulated temperature sensor) can run on a remote home computer, which can be connected to the soft-simulated on-board controller 104 via TCP / IP socket communication. In these cases, input / output data from the application hardware 840 is accessed or obtained by the AH-VD 836, which calls the AH-VDP 832. The AH-SAL 828, after translation, calls a socket interface, such as the TCP / IP interface 824. As a result, data from the application hardware 840 is sent via the socket interface to the soft-simulated on-board controller 104, which runs on a virtual machine in the cloud platform. This call flow may enable testing of vendor drivers and vendor driver porting layers (e.g., the AH-VD 836).

[0118] Referring to Figure 9, a call flow diagram of simulated application hardware running on a remote computer is shown in accordance with an embodiment of the present disclosure. An application 804 running on a virtual machine in a cloud platform (e.g., an application running on a simulated onboard controller 104) may send a data request API to AHAL 808, which forwards the data request API to AH-SAL 812. AH-SAL 812 then converts the API request to a JSON file and sends the file to the remote computer or controller via a TCP / IP interface (e.g., TCP / IP 816 to TCP / IP 824). TCP / IP 824 then pushes the data to AH-SAL 828, which performs the JSON file-to-API conversion and sends the API data request to AH-VDP 832. AH-VDP 832 then forwards the request to AH-VD 836, which in turn sends the command to application hardware 840. The command may instruct the application hardware 840 to perform a particular function (e.g., generate temperature data if the application hardware 840 includes a temperature sensor). The application hardware 840 then processes the command and generates a response that is obtained by the AH-VD 836. The AH-VD 836 then processes the response from the application hardware 840 and sends the data response API via the AH-VDP 832 and the AH-SAL 828. The AH-SAL 828 then converts the API into a JSON file and sends the data over TCP / IP 824 to the TCP / IP 816. The TCP / IP 816 sends the data to the AH-SAL 812, which converts the JSON file into an API. The response API is then sent back to the AHAL 808 and finally to the application 804 running on the onboard controller 104. While the API is described as being converted to a JSON file, it is understood that the API may be converted to other file formats, such as a text file, a protocol buffer, a csv file, and / or the like.

[0119] AH-SAL (e.g., AH-SAL612, AH-SAL628, AH-SAL812, AH-SAL828, etc.) described herein converts APIs into a JSON file format (or more generally, another file format). This conversion may include converting API names into comma-separated API IDs and converting API arguments into comma-separated arguments with names followed by values. The JSON file may then be transmitted over a TCP / IP socket. Similarly, AH-SAL may parse the received JSON file format bytes and extract the API ID, number of arguments, argument values, and / or the like. AH-SAL may then call the respective AHAL API with the extracted parameters. For arguments in pointer format, AH-SAL may allocate memory accordingly, update the data in the allocated memory, or update the address in the pointer variable.

[0120] 10 , a remote node connected to a cloud platform is shown according to an embodiment of the present disclosure. The cloud platform includes an onboard controller 104, which has an application 804, an AHAL 808, an AH-VDP 1004, an AH-VD 1008, an IO-HAL 1012, an AO-SAL 1016, and a TCP / IP port 816. The remote node includes a remote computer 820, which has a TCP / IP port 824, an IO-SAL 1028, an IO-VDP 1020, and an IO-VD 640 connected to the application hardware 1024 via a physical IO interface.

[0121] 10 may be used when an application hardware vendor has already been tested and integrated to operate with the on-board controller 104 running on the cloud platform. The physical application hardware subsystem may be connected to a remote computer 820 (e.g., a home computer) for testing purposes. Within the remote computer 820, data from the application hardware 1024 may be read by the IO-SAL 1028, which, after conversion, calls TCP / IP 824 to send the data to the on-board controller 104 in the cloud platform.

[0122] 11A-11B, call flow diagrams for simulated application hardware accessible via a remote computer remotely connected to the onboard controller 104 are shown in accordance with an embodiment of the present disclosure. In some cases, the call flow diagrams of FIGS. 11A-11B illustrate the intercommunication call flow shown in FIG. 10. An application 804 running on a virtual machine in the cloud platform (e.g., an application running on the simulated onboard controller 104) may send a data request API to the AHAL 808, which forwards the data request API to the AH-VDP 1004. The AH-VDP 1004 then converts the API request into a vendor driver API that is sent to the AH-VD 1008. The AH-VD 1008 then generates one or more commands for the application hardware 1024 and sends the commands as an API to the IO-HAL 1012. The IO-HAL 1012 then sends the API to the IO-SAL 1016. The IO-SAL 1016 converts the API request into a JSON file and sends the file to the remote computer or controller via a TCP / IP interface (e.g., TCP / IP 816 to TCP / IP 824). TCP / IP 824 then pushes the data to the IO-SAL 1028, which converts the JSON file to API data and sends the API data request to the IO-VD 640. The command may instruct the application hardware 1024 to perform a specific function (e.g., generate temperature data if the application hardware 1024 includes a temperature sensor). The IO-VD 640 may also send instructions to cause the application hardware 1024 to send a response at a later time (e.g., send data generated by the application hardware 1024 after the application hardware 1024 performs the specific function). The application hardware 1024 then processes the command and generates a response that is received by the IO-VD 640 and forwarded to the IO-SAL 1028.The IO-SAL 1028 then converts the API into a JSON file and sends the data to the TCP / IP 816 via TCP / IP 824. The TCP / IP 816 sends the data to the IO-SAL 1016, which converts the JSON file into an API. The response API is then sent back to the AH-VDP 1004 via the IO-HAL 1012 and the AH-VD 1008. The AH-VDP 1004 then processes the response data from the application hardware 1024 and provides a response to the application 804 running on the onboard controller 104 via the AHAL 808. While the API is described as being converted into a JSON file, it is understood that the API may be converted into other file formats, such as a text file, a protocol buffer, a csv file, and / or the like.

[0123] 12 , a remote node connected to a cloud platform is shown according to an embodiment of the present disclosure. The cloud platform includes an onboard controller 104, which has an application 804, an AHAL 808, an AH-VDP 1004, an AH-VD 1008, an IO-HAL 1012, an AO-SAL 1016, and a TCP / IP port 816. The remote node includes a remote computer 820, which has a TCP / IP port 824, an IO-SAL 1028, an IO-VDP 1020, and application hardware 1204.

[0124] 12 may be used when an application hardware vendor has already tested and integrated the application hardware vendor so that it can operate with the on-board controller 104 running on the cloud platform. The physical application hardware subsystem may run on a remote computer, and data from the simulated application hardware is sent to the on-board controller 104 in the cloud platform using TCP / IP 824. In this way, applications developed on the on-board controller 104 can be tested in a simulated environment.

[0125] Referring to Figure 13, a call flow diagram is shown according to an embodiment of the present disclosure. In some cases, the call flow diagram of Figure 13 illustrates the call flow of the intercommunication shown in Figure 12. An application 804 running on a virtual machine in the cloud platform (e.g., an application running on a simulated onboard controller 104) may send a data request API to the AHAL 808, which forwards the data request API to the AH-VDP 1004. The AH-VDP 1004 then converts the API request into a vendor driver API that is sent to the AH-VD 1008. The AH-VD 1008 then generates one or more commands for the application hardware 1204 and sends the commands as an API to the IO-HAL 1012. The IO-HAL 1012 then sends the API to the IO-SAL 1016. The IO-SAL 1016 converts the API request into a JSON file and sends the file to the remote computer or controller via a TCP / IP interface (e.g., from TCP / IP 816 to TCP / IP 824). TCP / IP 824 then pushes the data to the IO-SAL 1028, which converts the JSON file to an API request and sends a command to the application hardware 1204. The command may instruct the application hardware 1204 to perform a specific function (e.g., generating temperature data if the application hardware 1204 includes a temperature sensor). The application hardware 1204 then processes the command and generates a response that is received by the IO-SAL 1028. The IO-SAL 1028 then converts the API request into a JSON file and sends the data via TCP / IP 824 to TCP / IP 816. TCP / IP 816 sends the data to the IO-SAL 1016, which converts the JSON file to an API request. The response API is then sent back to the AH-VDP 1004 via the IO-HAL 1012 and the AH-VD 1008. The AH-VDP 1004 then processes the response data from the application hardware 1024 and provides the response to the application 804 running on the onboard controller 104 via the AHAL 808.While the API is described as being converted to a JSON file, it is understood that the API may be converted to other file formats, such as a text file, a protocol buffer, a csv file, and / or the like.

[0126] 14, a remote node connected to a cloud platform is shown according to an embodiment of the present disclosure. The cloud platform includes a payload server 108 and / or an edge server 112, each of which has an application 804, an AH-VD 1008, an AO-SAL 1016, and a TCP / IP port 816. The remote node includes a remote computer 820 having a TCP / IP port 824, an IO-SAL 1028, an IO-VDP 1020, and an IO driver 1408 connected to application hardware 1404 via a physical IO interface.

[0127] 14 may be used when an application hardware vendor is capable of running a simulated payload server 108 or edge server 112 running on a cloud platform. The physical application hardware subsystem may be connected to a remote computer 820 via a physical IO interface. Data from the application hardware 1404 may be read by the remote computer 820 (via an IO driver 1408) and sent to the simulated payload server 108 / edge server 112 running on the cloud platform using a TCP / IP socket interface.

[0128] Within the remote computer 820, data from the application hardware 1404 may be read by the IO-SAL 1028, which, after transformation, invokes TCP / IP 824 to send the data to the payload server 108 and / or edge server 112 within the cloud platform.

[0129] Referring to FIG. 15, a call flow diagram is shown according to an embodiment of the present disclosure. In some cases, the call flow diagram of FIG. 15 illustrates the call flow of the intercommunication shown in FIG. 14. An application 804 running on a virtual machine in the cloud platform (e.g., an application running on the simulated payload server 108 or the edge server 112) may send a data request API to the AH-VD 1008, which forwards the data request API to the IO-SAL 1016. The IO-SAL 1016 then converts the API request to a JSON file and sends the file to the remote computer or controller via a TCP / IP interface (e.g., TCP / IP 816 to TCP / IP 824). The TCP / IP 824 then pushes the data to the IO-SAL 1028, which performs the JSON file-to-API conversion and sends the API data request to the IO driver 1408. The IO driver 1408 then sends the command to the application hardware 1404. The command may instruct the application hardware 1404 to perform a particular function (e.g., generate temperature data if the application hardware 1404 includes a temperature sensor). The transmission from the IO-SAL 1028 to the IO driver 1408 may also include a command to receive a response from the application hardware 1404. The application hardware 1404 then sends the response to the IO driver 1408. The IO driver 1408 may forward the response to the IO-SAL 1028, which then converts the API to a JSON file and sends the data to the TCP / IP 816 over TCP / IP 824. The TCP / IP 816 sends the data to the IO-SAL 1016, which converts the JSON file to the API. The response API is then sent back to the AH-VD 1008, which processes the response data from the application hardware 1404. The processed data is then returned to the application 604 running on the payload server 108 or edge server 112.While the API is described as being converted to a JSON file, it is understood that the API may be converted to other file formats, such as a text file, a protocol buffer, a csv file, and / or the like.

[0130] 16, a remote node connected to a cloud platform is shown according to an embodiment of the present disclosure. The cloud platform includes a payload server 108 and / or an edge server 112, each of which has an application 804, an AH-VD 1008, an AO-SAL 1016, and a TCP / IP port 816. The remote node includes a remote computer 820 having a TCP / IP port 824, an IO-SAL 1028, and application hardware 1604.

[0131] In some cases, the configuration shown in Figure 16 may be used when an application hardware vendor is capable of running a simulated payload server 108 or edge server 112 running on a cloud platform. The physical application hardware subsystem may be run on a remote computer 820. Data from the application hardware 1604 may be sent to the simulated payload server 108 / edge server 112 running on the cloud platform using a TCP / IP socket interface. In this way, applications developed on the payload server 108 and / or edge server 112 may be tested in a simulated environment.

[0132] Referring to Figure 17, a call flow diagram is shown according to an embodiment of the present disclosure. In some cases, the call flow diagram of Figure 17 illustrates the call flow of the intercommunication shown in Figure 16. An application 804 running on a virtual machine in the cloud platform (e.g., an application running on the simulated payload server 108 or the edge server 112) may send a data request API to the AH-VD 1008, which forwards the data request API to the IO-SAL 1016. The IO-SAL 1016 then converts the API request into a JSON file and sends the file to the remote computer or controller via a TCP / IP interface (e.g., from TCP / IP 816 to TCP / IP 824). The TCP / IP 824 then pushes the data to the IO-SAL 1028, which converts the JSON file to an API and sends one or more commands to the application hardware 1604. The command may instruct the application hardware 1604 to perform a particular function (e.g., generate temperature data if the application hardware 1604 includes a temperature sensor). The application hardware 1604 then processes the command and generates a response that is received by the IO-SAL 1028. The IO-SAL 1028 then converts the API to a JSON file and sends the data over TCP / IP 824 to TCP / IP 816. TCP / IP 816 sends the data to the IO-SAL 1016, which converts the JSON file to the API. The response API is then sent back to the AH-VD 1008, which processes the response data from the application hardware 1604. The processed data is then passed to the application 804 running on the payload server 108 or edge server 112. While the API is described as being converted to a JSON file, it is understood that the API may be converted to other file formats, such as a text file, protocol buffers, a csv file, and / or the like.

[0133] In some cases, the entire simulation runs as a single instance in the simulation environment. For example, one application hardware subsystem (e.g., a temperature sensor) may be tested in the simulation environment. As a result, a different instance of the entire simulation may be run to test another application hardware subsystem (e.g., an IMU) in the simulation environment. In other cases, there may be a single instance in which some or all components are simulated. In these cases, two, three, or even more application hardware subsystems (e.g., a temperature sensor and an IMU) may be connected in parallel to the same instance of the simulation for testing. In some cases, there may be a single general-purpose instance of the flight software simulation, and any application hardware subsystem may be tested in that simulation environment. In these instances, the number of application hardware subsystems may be limited (e.g., up to six temperature sensors, up to two IMUs, up to two reaction wheels, etc.).

[0134] IO-SAL (e.g., IO-SAL1016, IO-SAL1028) may convert API calls into a JSON file-formatted byte sequence, such that API names are comma-separated and converted into API IDs, and API arguments are converted into a comma-separated argument count followed by the arguments. The JSON file is then sent over a TCP / IP socket. On the receiving side, IO-SAL parses the JSON file-formatted byte sequence, extracts the API IDs and arguments, and then calls the respective IO-HAL APIs with the appropriate parameters. For arguments in pointer format, IO-SAL may allocate memory accordingly, update the data in the allocated memory, or update the addresses in the pointer variables.

[0135] 18, a cloud platform is illustrated according to an embodiment of the present disclosure. The cloud platform includes a virtual machine soft-simulated binary onboard control (which may be similar to or the same as onboard controller 104), a virtual machine soft-simulated binary payload server (which may be similar to or the same as payload server 108), and a virtual machine soft-simulated binary edge server (which may be similar to or the same as edge server 112). The cloud platform may also include virtual machine soft-simulated binary application hardware subsystems (e.g., payload servers AHS 116A-116N, edge servers AHS 120A-120N, and / or core AHS 124A-124N). In other words, all main compute nodes and all application hardware subsystems (e.g., sensors, application hardware, etc.) connected to the main compute nodes are soft-simulated in the SaaS platform. In this environment, there are no remote simulations connected to the cloud platform.

[0136] For connections between each of the soft-simulated main computing hardware (onboard controller 104, payload server 108, edge server 112), IPCCFW may be used over IP connections, with all connections being IP-based. In full simulation mode, the onboard controller 104 may omit the use of physical IO drivers, and the IO-HAL may bridge communication with the IPCCFW. The onboard controller 104 may communicate with the payload server 108 and / or edge server 112 via IP communication without any physical IO drivers. The soft-simulated onboard controller may include the IO-HAL and IO-VDP API to provide a TCP / IP socket interface that can be used to communicate with AHS, for example, as shown in the call flow diagram of FIG. 13. The payload server 108 or edge server 112 may be either a hardware platform or a simulated software platform that connects to other computing nodes running the SaaS platform.

[0137] Software may be subject to specific timing constraints or requirements to ensure that the hardware operates correctly. Timing issues can arise when driver software attempts to interface with hardware devices remotely. To address these issues, IO-SAL, AH-SAL APIs, and JSON schemas can be defined to account for timing differences. For example, each IO-SAL API transformation may specify timing requirements for the execution time of the current API (e.g., API1) and the next API (e.g., API2). There may be a variety of hardware interface timing requirements that can be addressed using a common schema implemented in a JSON file (or more generally, any other readable file).

[0138] 19, aspects of a JSON template 1900 are illustrated in accordance with an embodiment of the present disclosure. The JSON template illustrated in FIG. 19 may provide a template for time-referenced API execution. For example, API1 may be invoked on a remote node at a first time referenced to Coordinated Universal Time (UTC) or any other known time scheme. If a simulation running on a SaaS platform wants the remote node to execute API1 at the first time, IO-SAL and / or AH-SAL may specify the first time as UTC time in the JSON file. The remote node can time-reference the execution of API1 accordingly. In some cases, for example, if the remote node is connected to the Internet, the timing requirements of API1 may be synchronized with a local time or GMT / UTC server so that the timing requirements are met when API1 is executed.

[0139] As shown in FIG. 19 , JSON template 1900 includes API identifier 1904, execution time 1908, number of arguments 1912, argument information 1916, and argument value 1920. API identifier 1904 may indicate which API is to be executed. Execution time 1908 indicates the time (e.g., in UTC) at which the API is to be executed on the remote node. Number of arguments 1912 may specify the number of arguments passed to the API, and argument information 1916 specifies additional information about each argument passed to the API. Argument value 1920 may indicate a particular value to be populated into the API. For example, API1 in FIG. 19 has a single argument (number of arguments 1912 equals 1), and argument information 1916 specifies information about the single argument. Argument value 1920 indicates the data type, data length, and the data itself to be used when executing the API.

[0140] Referring to FIG. 20, a call flow diagram for time-referenced API execution is shown according to at least one example embodiment of the present disclosure. In some examples, the call flow diagram of FIG. 20 may illustrate the execution of the JSON template of FIG. 19 or the JSON templates of FIGS. 21A-21B. The IO-HAL may send API requests to the IO-SAL, which specifies commands for the application hardware to execute. The IO-SAL may then convert the API requests into a JSON file and send the data to the remote node via a TCP / IP interface. A TCP / IP socket on the remote computer may forward the transmission to the IO-SAL on the remote computer, which may convert the JSON file into an API. Based on the information in the JSON file, which may include timing constraints for API execution, the IO-SAL may specify that API1 is to execute at a first time and that API2 is to execute at a second time after the first time (e.g., 500 microseconds after the first time). The IO-VD may then pass these commands to the application hardware so that the application hardware may execute the APIs at the requested times. In some cases, the IO-VD may send a command for the application hardware to return output data at some specific time after the second time (e.g., a third time 300 microseconds after the second time). As a result, the application hardware may execute the API at the specific time and wait until the third time to send the returned data to the IO-VD. The IO-VD may pass the returned data to the IO-SAL, which converts the API request into a JSON file. The IO-SAL may then pass the JSON file to the IO-SAL on the onboard controller via a TCP / IP socket. The IO-SAL may then convert the JSON file into an API request, which is then sent to the IO-HAL.

[0141] 21A-21B illustrate aspects of a JSON template for time-referenced APIs to execute according to at least one example of the present disclosure. The JSON template includes execution information for API1, API2, API3, and API4. The template may also include relative execution timing for each API. For example, the JSON template may specify that API1 depends on the execution of API2, which in turn depends on the execution of API3, which in turn depends on the execution of API4. Alternatively, API2 may have a timing dependency on API1; for example, if API1 is called at a first time, then API2 is called at a second time, and the difference in time (e.g., the second time minus the first time) is the time interval that needs to be observed for the application hardware.

[0142] As another example, API2 may have a timing dependency on API1, e.g., if API1 is called at a first time and API2 is called after a second time, the time interval therebetween (e.g., the second time minus the first time) is a minimum time interval that must be observed before calling API2 in order for the application hardware to operate. Such an implementation may be illustrated by the call flow diagram of FIG. 20.

[0143] As yet another example, API2 may have a timing dependency on API1, e.g., if API1 is called at a first time, and then API2 is called after a second time and before a third time, then the time interval between the first time and the second time must be minimally respected before calling API2, and API2 is called before the third time minus the first time, for the application hardware to operate.

[0144] Referring to FIG. 22, a call flow diagram of a time-referenced API is shown in accordance with at least one example embodiment of the present disclosure. The IO-HAL may send an API to the IO-SAL specifying commands for the application hardware to receive. The IO-SAL may then convert the API request into a JSON file and send the data to the remote computer via a TCP / IP interface. A TCP / IP socket on the remote computer may forward the transmission to the IO-SAL on the remote computer, which may convert the JSON file into an API. Based on information in the JSON file, which may include timing constraints for API execution, the IO-SAL may specify that API1 be executed at a first time and that API2 be executed at a second time after the first time (e.g., 200 microseconds after the first time) and after the second time but before a third time (e.g., 400 microseconds after the first time). The IO-VD may then pass these commands to the application hardware, allowing the application hardware to execute the API at the requested time. In some cases, the IO-VD may send a command to the application hardware to return output data at some specific time after the third time. As a result, the application hardware may execute the API at that specific time and wait until that specific time to send the return data to the IO-VD. The IO-VD may pass the returned data to the IO-SAL, which converts the API request into a JSON file. The IO-SAL then passes the JSON file to the IO-SAL on the onboard controller via a TCP / IP socket. The IO-SAL may then convert the JSON file into an API request, which is then sent to the IO-HAL.

[0145] In some instances of timing requests for API execution, the hardware may require immediate or time-constrained authentication or response from the software. In these instances, the IO-SAL / AH-SAL running on the SaaS platform can proactively send authentication / response APIs to the IO-SAL / AH-SAL running on the remote computer. The transmitted information may include the expected hardware event requiring authentication / response and the API ID with the authentication / response encoded in a timing-constrained JSON file. For example, as shown in FIG. 23, the information for API1 may specify that API2 be executed as authentication in response to the execution of API1, allowing the local software to operate on the application hardware if authentication is granted (even if the authentication is sent from the SaaS platform simultaneously with the command to execute the API).

[0146] Referring to FIG. 24, a call flow diagram of time-referenced API execution is shown in accordance with at least one example embodiment of the present disclosure. In some cases, the call flow diagram of FIG. 24 may be executed when application hardware requests authentication or a response from the hardware, for example, when the JSON file shown in FIG. 23 is executed. The IO-HAL may send an API to the IO-SAL specifying the command the application hardware receives. The IO-SAL may then convert the API request into a JSON file and send the data to a remote computer via a TCP / IP interface. A TCP / IP socket on the remote computer may forward the transmission to the IO-SAL on the remote computer, which may convert the JSON file into an API. Based on information in the JSON file, which may include timing constraints for API execution, the IO-SAL may specify that API1 be executed at a first time and that API2 be executed as an authentication or response to the execution of API1. The IO-VD may then pass the command to the application hardware, which executes the API. After API1 is executed, the application hardware may generate data and instructions for the expected authentication or response from the software. For example, the application hardware may generate data indicating that the software authenticates that the hardware executed API1. Upon receiving the hardware event / API, the IO-SAL / AH-SAL running on the remote computer may immediately perform authentication / response based on the determined authentication / response information received in the JSON file. In some cases, the IO-SAL / AH-SAL may not process the data received from the application hardware, but may simply look at the event ID and API ID and take appropriate action. The data received from the hardware is then sent to the IO-SAL / AH-SAL running on the SaaS platform (via a TCP / IP socket after the API request is converted into a JSON file).The IO-SAL / AH-SAL running on the SaaS platform then processes the data and passes it on to the IO-HAL for further action (e.g., the IO-HAL passes the data to the appropriate application running on the SaaS platform).

[0147] In some embodiments, API1 and API2 may both be send APIs (e.g., APIs that send information to application hardware), API1 and API2 may both be receive APIs (e.g., APIs that receive information from application hardware), or one may be a send API and the other a receive API. In some cases, one or more APIs may be time-dependent on other APIs, and the APIs may be strung together in their respective orders in the same JSON file in the sender's IO-SAL / AH-SAL. The receiver's IO-SAL / AH-SAL then processes the required timing references to execute the APIs in a given order and at a given time reference. In some cases, the IO-SAL and / or AH-SAL on the remote node / computer may be configured with a timer-based sequencer and scheduler that handles the execution of back-to-back and timing-dependent APIs.

[0148] In some cases, for example, in remotely connected or simulated environments, network transport delays may be estimated and pre-configured in IO-SAL and AH-SAL, or may be dynamically monitored and measured by the SaaS platform and dynamically configured / changed. If the network delay is configured to be longer than or equal to the timing requirements (e.g., the delay is longer than or equal to the difference between the second time API2 is executed and the first time API1 is executed), IO-SAL and / or AH-SAL running on the SaaS platform may list the timing-dependent APIs in a single JSON file with the requested timing details and forecast IO-SAL and / or AH-SAL running on the remote node / computer to handle the timing constraints required to operate APIs that interface locally with application hardware. If the network delay is set shorter than the timing requirements (e.g., the delay is shorter than the difference between the second time API2 is executed and the first time API1 is executed), the network delay may be treated as being within the safe delay range, and if the timing requirements are met by queuing the API remotely from the SaaS platform, the IO-SAL and / or AH-SAL running on the SaaS platform may maintain and monitor the timing reference of the API. The IO-SAL and / or AH-SAL running on the SaaS platform may also queue the API from the SaaS platform itself. In other words, the lack of network delay can allow the API to be managed without having to send a single JSON file and predict the local SAL managing the timing requirements. In some cases, the transmission of the JSON file may be asynchronous (e.g., a first request in a first JSON file is transmitted at a first time, and a second request in a second JSON file is transmitted later). In other cases, the JSON file may be synchronous.

[0149] The SaaS and / or cloud platforms described herein may be configured to allow multiple users (e.g., primary users, secondary users, etc.) to access the SaaS and / or cloud platform. For multiple users connecting with the SaaS platform, the nodes may be peer-to-peer and in real-time (or near real-time) connections. Real-time intercommunication and peer-to-peer connectivity requirements between nodes may use peer-to-peer TCP / IP or UDP / IP socket connections. The SaaS platform may allow users to log in (e.g., to a remote node and / or directly to the SaaS platform), and for each user session, an IP session may be maintained for the connection.

[0150] FIG. 25 illustrates a system for multi-user access to a cloud / SaaS platform according to an embodiment of the present disclosure. In some examples, the multi-user access platform may include components of the system 100 (e.g., the onboard controller 104, the payload server 108, the edge server 112, the payload servers AHS 116A-116N, etc.). In the multi-user access platform, one or more users may connect remotely, and each user may connect a remote node / computer to the SaaS platform for driver integration or simulation for a flatsat simulation provided in the SaaS platform. The remote node / computer may include an AHS. The SaaS platform may include a single simulation (a single virtual copy of the onboard controller 104, a single virtual copy of the payload server 108, and a single virtual copy of the edge server 112) and allow each user to connect to various compute nodes on the SaaS platform.

[0151] FIG. 26 illustrates another system for multi-user access to a cloud / SaaS platform according to an embodiment of the present disclosure. In some examples, the multi-user access platform may include components of system 100 (e.g., onboard controller 104, payload server 108, edge server 112, payload servers AHS 116A-116N, etc.). Unlike the model of FIG. 25, the multi-user access configuration of FIG. 26 allows multiple users to access separate FlatSat constructions / simulations within the SaaS platform. In other words, the SaaS platform may build a first simulation for a first user (e.g., a primary user) and a second simulation for a second user (e.g., a secondary user). In some cases, the first and second simulations may be the same, while in other examples, the SaaS platform may provide different compute nodes to different users.

[0152] FIG. 27 illustrates yet another system for multi-user access to a cloud / SaaS platform according to an embodiment of the present disclosure. In some examples, the multi-user access platform may include components of system 100 (e.g., onboard controller 104, payload server 108, edge server 112, payload servers AHS 116A-116N, etc.). The SaaS platform may include simulated application hardware within a cloud architecture such that users do not need to connect remote nodes / computers to the SaaS platform. In such an environment, users may log in and access different FlatSat configurations and / or simulations without needing to connect local computers and / or AHSs to the SaaS platform.

[0153] Any steps, functions, and operations described herein may be performed continuously and automatically.

[0154] Exemplary systems and methods of the present disclosure are described in the context of a virtual Flatsat. However, the above description omits a number of well-known structures and devices to avoid unnecessarily obscuring the present disclosure. This omission is not to be construed as limiting the scope of the claimed disclosure. Specific details are set forth to provide an understanding of the present disclosure. However, it should be appreciated that the present disclosure may be practiced in a variety of ways beyond the specific details set forth herein.

[0155] Furthermore, while the exemplary embodiments described herein show the placement of various components of the system, particular components of the system may be located remotely, in a separate portion of a distributed network (e.g., a LAN and / or the Internet), or within a dedicated system. Consequently, it should be appreciated that components of the system may be coupled to one or more devices, e.g., a server, a communications device, etc., or may be located at a particular node of a distributed network, e.g., an analog and / or digital telecommunications network, a packet-switched network, or a circuit-switched network, etc. From the foregoing discussion, and for reasons of computational efficiency, it will be appreciated that components of the system may be located anywhere within the distributed network of components without affecting the operation of the system.

[0156] Furthermore, it should be appreciated that the various links connecting the elements may be wired or wireless links, or a combination thereof, or any other known or later developed element capable of providing or communicating data to and from the connected elements. These wired or wireless links may also be secure links and may allow for the communication of encrypted information. For example, the transmission media used as links may be any suitable carrier of electrical signals, including coaxial cable, copper wire, and optical fiber, and may take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications.

[0157] While the flowcharts have been described and illustrated with respect to a particular sequence of events, it should be appreciated that modifications, additions, and omissions to this sequence may occur without materially affecting the operation of the disclosed embodiments, configurations, and aspects.

[0158] Many variations and modifications of the present disclosure may be used, and it is possible to provide some features of the present disclosure without providing other features.

[0159] In yet another embodiment, the systems and methods of the present disclosure may be implemented in conjunction with special purpose computers, programmed microprocessors or microcontrollers and peripheral integrated circuit elements, ASICs or other integrated circuits, digital signal processors, hardwired electronic or logic circuitry such as discrete element circuits, programmable logic devices or gate arrays such as PLDs, PLAs, FPGAs, PALs, special purpose computers, equivalent means, or the like. In general, any device or means capable of implementing the methodologies described herein may be used to implement various aspects of the present disclosure. Exemplary hardware that may be used in the present disclosure includes computers, handheld devices, telephones (e.g., cellular, Internet-enabled, digital, analog, hybrid, and others), and other hardware known in the art. Some of these devices include processors (e.g., single or multiple microprocessors), memory, non-volatile storage, input devices, and output devices. Additionally, alternative software implementations, including, but not limited to, distributed processing or component / object distributed processing, parallel processing, or virtual machine processing, may also be configured to implement the methods described herein.

[0160] In yet another embodiment, the disclosed methods may be readily implemented in conjunction with object-based software or object-oriented software development environments to provide portable source code that can be used on a variety of computer or workstation platforms. Alternatively, the disclosed systems may be implemented partially or entirely in hardware using standard logic circuits or VLSI designs. Whether software or hardware is used to implement a system according to the present disclosure depends on the speed and / or efficiency requirements, the particular functionality, and the particular software or hardware system or microprocessor or microcomputer system being used.

[0161] In yet another embodiment, the disclosed methods may be implemented in part in software that may be stored on a storage medium and executed by a programmed general-purpose computer, special-purpose computer, microprocessor, or the like in cooperation with a controller and memory. In these examples, the disclosed systems and methods may be implemented as, for example, a program embedded in an individual's computer, such as an applet, JAVA, or CGI script, as a resource resident on a server or computer workstation, as a dedicated measurement system, as a routine embedded in a system element, or the like. The system may also be implemented by physically incorporating the system and / or method into a software and / or hardware system.

[0162] Although this disclosure describes components and functions implemented in embodiments that refer to particular standards and protocols, this disclosure is not limited to those standards and protocols. Other similar standards and protocols not mentioned herein exist and are considered to be included in this disclosure. Furthermore, the standards and protocols mentioned herein and other similar standards and protocols not mentioned herein are periodically replaced by faster or more efficient equivalents having essentially the same functionality. These replacement standards and protocols having the same functionality are considered equivalents to those included in this disclosure.

[0163] In various embodiments, configurations, and aspects, the present disclosure includes components, methods, processes, systems, and / or apparatus substantially as shown and described herein, including various embodiments, subcombinations, and subsets thereof. Those skilled in the art will understand how to make and use the disclosed systems and methods upon understanding the present disclosure. In various embodiments, configurations, and aspects, the present disclosure includes providing devices and processes in the absence of items not shown and / or described herein, including in the absence of items that may be used in previous devices or processes in various embodiments, configurations, or aspects herein to improve performance, increase ease, and / or reduce cost of implementation.

[0164] The foregoing discussion of this disclosure has been presented for purposes of illustration and description. The foregoing is not intended to limit the disclosure to the form(s) disclosed herein. In the foregoing Detailed Description of the Invention for purposes of illustration, various features of the disclosure are grouped together in one or more embodiments, configurations, or aspects for purposes of streamlining the disclosure. Features of any embodiment, configuration, or aspect of the disclosure may be combined into alternative embodiments, configurations, or aspects other than those described above. This method of disclosure is not to be interpreted as reflecting an intention that the claimed disclosure requires more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive aspects may lie in less than all features of a single foregoing disclosed embodiment, configuration, or aspect. Consequently, the following claims are hereby incorporated into this Detailed Description of the Invention, with each claim standing on its own as a separate preferred embodiment from the present disclosure.

[0165] Furthermore, the description of the present disclosure includes a description of one or more embodiments, configurations, or aspects, and certain variations and modifications, other variations, combinations, and modifications are within the scope of the present disclosure, such as may be within the skill and knowledge of one of ordinary skill in the art upon understanding the present disclosure. It is intended to entitle, and it is not intended to dedicate patentable subject matter to the public, including alternative embodiments, configurations, or aspects to the extent permitted, including alternative, interchangeable, and / or equivalent structures, functions, ranges, or steps to those claimed, regardless of whether such alternative, interchangeable, and / or equivalent structures, functions, ranges, or steps are disclosed herein.

[0166] The terms "at least one," "one or more," "or," and "and / or" are open-ended expressions that operate both conjunctively and disjunctively. For example, the expressions "at least one of A, B, and C," "at least one of A, B, or C," "one or more of A, B, and C," "one or more of A, B, or C," "A, B, and / or C," and "A, B, or C" each mean A alone, B alone, C alone, A and B, A and C, B and C, or A, B, and C, respectively.

[0167] The term "a" or "an" entity refers to one or more of that entity. Whereby, the terms "a" (or "an"), "one or more," and "at least one" may be used interchangeably herein. Also, the terms "comprising," "including," and "having" may be used interchangeably.

[0168] As used herein, the term "automatic" and variations thereof refer to any process or operation, which is typically continuous or semi-continuous and occurs without material human input as the process or operation is performed. However, a process or operation may be automatic even if the performance of the process or operation uses material or non-material human input if the input is received prior to the performance of the process or operation. Human input is considered material if it affects how the process or operation is performed. Human input consenting to the performance of a process or operation is not considered "material."

[0169] Aspects of the present disclosure may take the form of an entirely hardware embodiment, an entirely software (firmware, resident software, microcode, etc.) embodiment, or an embodiment combining software and hardware aspects, which may all be generally referred to herein as a "circuit," "module," or "system." Any combination of one or more computer-readable media may be utilized. The computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium.

[0170] A computer-readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of computer-readable storage media include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer-readable storage medium may be any tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device.

[0171] A computer-readable signal medium may include a propagated data signal having computer-readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take various forms, including, but not limited to, electromagnetic, optical, or any suitable combination thereof. A computer-readable signal medium may be a similar computer-readable medium other than a computer-readable storage medium that can communicate, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied in a computer-readable medium may be transmitted using any appropriate medium, including, but not limited to, wireless, wired, fiber optic cable, RF, etc., or any suitable combination of the foregoing.

[0172] As used herein, the terms "determine," "calculate," "compute," and variations thereof are used interchangeably and include any form of methodology, process, mathematical operation, or technique.

Claims

1. 1. A system including three or more distributed computations intercommunicating with each other in a cloud environment, at least one of which communicates with a remote resource via a cloud connection, comprising: each of the three or more distributed computing resources configured to receive information from the remote resource and / or provide commands executable by the remote resource; system.

2. The system of claim 1 , wherein the remote resource comprises a simulated resource.

3. The system of claim 2 , wherein the simulated resource includes a simulated sensor.

4. The system of claim 3 , wherein the simulated sensor comprises a sensor configured for use on a satellite.

5. The system of claim 2 , wherein the simulated resources include at least one of simulated software, simulated hardware, and simulated compute nodes.

6. The system of claim 1 , wherein the cloud environment is implemented on a satellite.

7. The system of claim 1 , wherein the cloud environment runs on terrestrial servers.

8. The system of claim 1 , wherein at least one of the three or more distributed computations is virtualized.

9. The system of claim 1 , wherein all of the three or more distributed computations are virtualized.

10. The system of claim 1 , wherein the three or more distributed computing devices include at least one of a microcontroller, a microprocessor, a payload server, and an edge server.

11. 10. The system of claim 1, wherein communication with the remote resource is achieved through at least one of a physical Input / Output Hardware Abstraction Layer (IO-HAL) and an Application Hardware Abstraction Layer (AHAL).

12. The system of claim 11 , wherein the IO-HAL comprises an abstracted physical communication interface.

13. The system of claim 11 , wherein the AHAL comprises an abstraction application layer of a physical communication interface.

14. The system of claim 1 , wherein communication with the remote resource is achieved by transmitting one or more JSON files.

15. The system of claim 14 , wherein the one or more JSON files define at least one of a current API execution time, a timing-dependent API, a relative execution time, an execution mode, and a number of arguments.

16. The system of claim 15 , wherein the one or more JSON files are converted into one or more API calls.

17. 1. A system for a satellite, comprising: at least one resource in communication with the satellite payload; a controller coupled to the at least one resource; Including, the at least one resource includes a first abstracted physical communication interface; the controller includes a second abstracted physical communication interface in communication with the first abstracted physical communication interface over a communication link; system.

18. 20. The system of claim 17, wherein the communication link comprises a USB connection, a UART connection, an Ethernet connection, an SPI connection, a PCI connection, a physical interface, a wireless interface, and / or an I2C connection.

19. The system of claim 17 , wherein the at least one resource comprises a payload server, an edge server, a computational resource, and / or a computational node.

20. The system of claim 19 , wherein the computing node is a client node or a server node.

Images