## 2 Materials and Methods
### Typical CubeSat Software Structure  
To better understand and break down a problem, let's look into a typical CubeSat build shown in Figures 9 and 10, and how the declaration of the author's techniques can be used for its system and software design. A CubeSat normally consists of a few main electronics systems:  
* OBC(D): on-board computer (and data);
* ADCS: an altitude determination and control system;
* EPS: electronic power system (could include batteries);
* Comm (or COM): communication system;
* Payload: the \"mission\" of the CubeSat that brings business value to its creators;
* Propulsion: a propulsion system that is typical for a more advanced and bigger (6U+) CubeSats. Additionally, there are a few non-electronic systems (which are out of the scope of this document): solar panels, batteries, antenna(s), and the mechanical structures around which all the modules are assembled. In some pretty complex CubeSat build-ups, OBC(D) and ADCS could be combined and called CDHM, which stands for the command and data handling module. This article will address this module in particular as the most software-heavy and complex of any CubeSat project. If we look into a typical method of implementing the software for such a CubeSat platform, there are two main approaches:  
* Approach A: An OBC/CDHM only coordinates the data exchange between the rest of the system components, where each component has its firmware and program. See Figure 11
* Approach B: An OBC/CDHM does it all. All other components are as \"dummy\" as possible. See Figure 12;  
To be able to perform the mission, both approaches A and B shall basically implement the same software. However, the number of CubeSat components and sub-systems will impose different complexities on the software, its structure, and its data footprints. The typical OBC/CDHM software (both approaches A and B) could be represented as the following main software building blocks, where the OBC/CDHM handles the main control block and other modules represent different system and payload functions. The CDHM normally represents either a server in a client-server architecture of CubeSat software, or a central data and task scheduler in a more classic OS-like CubeSat system architecture. Further breakdown of the data flows and the software components of a typical CubeSat can be represented as follows:  
Figure 10: Top-Level typical CubeSat component structure. Figure 9: Typical CubeSat structure and components. It is reasonable to assume that it is a typical Approach A system architecture that requires several comparable calculation power processors/microcontrollers to be embedded in each system board. Therefore, the energy consumption, complexity, cost, and, last but not least, the probability of a hidden error are at their maximum. This is also a very clear example where each separate component of a CubeSat will be designed in a monolithic manner. Making a separate system component (especially one that runs on separate hardware) in a monolithic manner is rather typical for the industry. The big problem with such distributed yet monolithic systems comes with the integration tests complexity, where the bug-finding efforts and time are very costly and the overall project is very much pressed for time. Instead of such a monolithic system architecture, the software can be designed differently by the use of containerization and microservices. Instead of having many smaller different monolithic components in the system that are compressed into a big one, the business and control logic of those modules is spread towards the containers and corresponding microservices. Each container can represent the particular system component, and in that way, strictly breakdown functions across containers. The suggested approach is represented below in a Figure 12 (Approach B). Figure 11: Approach A: CubeSat on-board software and module structure. Figure 12: Approach B: The proposed container-based software structure of a CubeSat on-board software.