A CubeSat is a type of very small satellite which is based on a standardized unit of mass and volume. The initial basic CubeSat unit measured 10x10x10 centimetre, conforming to specific interfaces for allowing a standardized containerized launch and had a maximum mass of 1 kilogram (the mass was later on increased to 1,33 kilogram).
It was quickly realized that such basic CubeSat units could be combined to form slightly larger spacecraft while mostly adhering to the same requirements and constraints. Multiples of the basic CubeSat unit were combined together to establish larger CubeSats. For example, a 1-Unit CubeSat measures one single basic CubeSat unit as described above, while a 3-Unit CubeSat consists of 3 standard CubeSat units stacked together.
The CubeSat concept has become very popular, both in university groups, as well as for researchers, space agencies, governments, and companies. CubeSats offer a fast and affordable way for a wide array of stakeholders to be active in space and allow for a fast innovation cycle.
Beginning in 1999, California Polytechnic State University at San Luis Obispo (Cal Poly) and Stanford University developed a very small spacecraft concept to help universities worldwide to enable students and researchers perform space science and exploration.
The aim was to come up with a concept that would not only allow university groups to rapidly implement a small space mission but also to ensure that the chances of being embarked on a space launch as a secondary passenger were maximized. This was enabled by standardizing interfaces and prohibiting or limiting design aspects that could be potentially hazardous and would reduce the chances of being allowed to be launched next to larger, more expensive spacecraft.
The CubeSat reference design was proposed in 1999 by professors Jordi Puig-Suari of California Polytechnic State University and Bob Twiggs of Stanford University. The CubeSat as initially proposed did not set out to become a standard; rather, it became standard overtime by a process of emergence and culminated in a very popular and standardized satellite concept. The first CubeSats were launched in June 2003 on a Rockot launch vehicle.
Given the standardized size of CubeSats it has become possible to develop many standardized functional modules such as power systems, communication systems, etc. The use of such commercial off-the-shelf (COTS) parts is a major reason why CubeSat can be implemented quickly and cost-effectively.
CubeSats are typically launched into space as a containerized payload, inside a deployer, as a means to reduce launch campaign complexity and associated costs.
Non-space parts are often used, and accepted, in CubeSat missions. This enables a low-cost, short implementation cycle approach and allows developers to make use of the latest commercial and industrial grade components. The fact that most CubeSat missions are in low earth orbit and have a short mission lifetime makes it possible to use such components.
Due to the lower complexity and small scope and scale of CubeSat projects it is often possible to use less formal design methods and methodologies. It is often possible to work in compact design teams, further eliminating the need for extensive documentation packages and other overheads. Of course a certain minimum level of formality and documentation is always required.
The CubeSat approach is typically one with a higher accepted technical risk in exchange for either lower cost, faster implementation, more innovation or a combination of those elements. These elements also allow for different risk mitigation approaches (re-flights, in-orbit spares, etc) than traditional risk mitigation approaches.
The strength of CubeSats lies not so much in having the best performance in terms of bandwidth or ground sampling resolution, as this is not very compatible with the extreme restrictions that the satellite size imposes on CubeSat. When used in networks or constellation, however, CubeSats are able to provide much improved temporal resolution at affordable prices.
A formal standard for CubeSats is under development at the International Organization for Standardization (ISO). In effect, the latest revision of the CubeSat Design Specification (CDS), as maintained by CalPoly since its creation in 1999 contains the design specifications and requirements that is the de-facto CubeSat standard, complemented with a set of additional requirements applicable mainly to CalPoly’s P-POD CubeSat deployer system and to CubeSat missions in development in the US.
The CDS accurately describes the form and fit of 1-Unit and 3-Unit CubeSats and by means of interpolation intermediate sizes such as 1.5-Unit and 2-Unit CubeSats. For larger CubeSats such as 6-Unit and 12-Unit CubeSats, the CDS does not really provide an unambiguous handle. This has led to a number of variants of for instance the 6-Unit CubeSat form factor being in use in parallel. With 6-Unit CubeSats being launched into space for the first time in June 2014, it is expected that a standardization of the 6-Unit size will be established soon based on available 6-Unit Deployment canisters and the subsequent emergence of a de-facto standard form factor.
The standardized mass of a CubeSat also turns out to be less of a standard element across all CubeSats but is rather driven by the limitations of the specific CubeSat deployer used.
The applicable requirements and constraints to a particular CubeSat mission is a multi-layered composition of requirements. Depending on the chosen development method and standards, possible additional requirements and constraints may apply. A number of these requirements cannot be known from the start of the mission development. For instance the launch vehicle and launch campaign-specific constraints are only known late in the development, once a launch has been selected and the launch campaign specifics have been agreed with all involved parties.
Therefore, it is common practice to use sets of ‘envelope specifications’ that allow more flexibility during the initial design stages. Once the specific deployer and launch vehicle have been selected, it may be possible for a team to reduce the requirements further to encompass just the remaining candidates.
CubeSat Standard Generic Requirements – lay down the basic constraints for being a CubeSat, mainly form and fit
Deployer Specific Requirements and Constraints – may impose additional constraints such as maximum mass, total envelope, location of possible access hatches, etc
Launch Vehicle Specific Requirements – mainly determine the testing requirements and determine whether specific tests are required or not
Launch Campaign Specific Requirements and Constraints – typically have a programmatic impact, such as latest access to the spacecraft, and impact the options to be allowed to use higher risks system elements (pyrotechnics, propulsion, etc.)
Programmatic and Regulatory Requirements and Constraints – sometimes independent of a specific technical implementation, depending on the sponsor, applicable government agencies, etc.. This includes adherence to national space laws
ISISPACE CubeSat supported sizes
The supported ISISPACE ‘standard’ CubeSat sizes and envelopes for both the CubeSat Structures product line and the CubeSat deployer product line are outlined in the table below. In addition, we are able to customize the CubeSat deployers to accommodate specific designs that are not compatible with these specifications.
|1-Unit CubeSat||1.5-Unit CubeSat||2-Unit CubeSat||3-Unit CubeSat||6-Unit CubeSat||6-Unit-XL CubeSat||8-Unit CubeSat||12-Unit CubeSat||12-Unit-XL CubeSat||16-Unit CubeSat|
|View pdf||View pdf||View pdf||View pdf||View pdf||View pdf||View pdf||View pdf||View pdf||View pdf|