System Architecture Selection Process
System Architecture Selection processThis page will describe the steps that were taken in order to define the system architecture.
The system architecture defines all the processors that are needed, what they need to do, and how they will interact with each other. This allows for a strong description of the hardware that is needed and the software each processor needs to run.
Defining The SystemBelow is a block diagram describing the major functionality of the system that needs to be accounted for. If the system doesn't include all the functions shown below, it is incomplete.
Transformation DiagramA transformation describes the flow of energy. It expands on the above high level functional description by showing where the data originates and goes and how power goes through the system.
Morphological ChartTo get a better idea of the different options that are available for the system architecture, a morphological chart is made, shown below. The morphological chart accounts for all the choices that need to be decided between.
Concept DevelopmentFrom the morphological charts, some decisions can be made in isolation, like the data uplinks and downlinks. These will be discussed later. However, a lot of other decisions are much more interdependent. A bottom up approach was used to make the final decision. The purpose of using the bottom up approach is that the system can behave extremely different with different microcontrollers, so decisions should be made with these microcontrollers in mind. However, before the microcontrollers can be picked. The general architecture needs to be decided upon. Various ideas are shown below.
The first five ideas can be eliminated right away. Whether it's because the necessary microcontrollers are overloaded and would need to be too large for this application, or the hardware and software would be much more complex then the final two ideas, all of the the first ideas are eliminated.
The last two ideas cannot be decided upon so easily. They are very similar, but further research needs to be done to provide a well justified decision. This flow can be seen below. The first thing to do is to accurately describe the differences between the architectures, and then describe the software and functionality each microcontroller will be doing. Of the final two architectures, the one on the left is referred to as the 16-1 architecture, and the one on the right is referred to as the clusters architecture.
The 16-1 architecture is a straightforward architecture. It uses the DACQ microcontroller as the master for each cell. It has a second controller on it that can handle the IMU data and reaction wheel control. This microcontroller directly interfaces with the communications systems and downlinks data. It also directly receives and interprets commands. Images and videos from each cell can be multiplexed into the high speed system and downlinked over the 1.2GHz antenna. Some of the major advantages of this architecture are that it is a straight forward architecture and easy to understand. The cells also have a more powerful microcontroller on them and can handle more functionality because of that. Some cons is that the video multiplexer will be a complicated system with many connection. This system can also have a large number of data lines if point to point protocols are used.
The clusters architecture inserts another layer of microcontrollers into the system acting as masters to four cells each. While this may not seem like a good idea, it allows for the cells controllers to be much less complex. Another major advantage is that this system is flexible to be used with the high speed communications. The high speed communications system is a research project from another student, and currently, isn't very flexible to be used in various applications. Because of this, it isn't possible to stream down video from within the cell unless the high speed communications system becomes more robust. It also makes more sense to send down images over the low speed communication networks. However, the clusters architecture can be much easier adapted to send images down over the high speed network in the case that this network becomes more robust. The major downside of this system is the added processor layer.
Software DescriptionsIt is important to note that because of the aforementioned pitfalls of the high speed communications system, it will be treated as it's own system and we will not try to interface our data with it, as it has a high chance for failure if we do so. This would put all images over the data lines, and doesn't allow for video of inside the cells to be taken. Trying to fix the high speed system will be infringing on the research project which is currently ongoing, and adds a large amount of work to this already large project.
16-1 SoftwareBelow are diagrams for each microcontroller. These diagrams describe what functions the controllers will need to do and where the information is coming from and going.
Clusters SoftwareBelow are diagrams for each microcontroller. These diagrams describe what functions the controllers will need to do and where the information is coming from and going.
MicrocontrollersBecause different microcontrollers have wildly different features a table comparing different aspects of four microntrollers was created in order to simplify the process of comparing them.
A link to the full document can be found here: Systems Level Design Documents/System/uC_Benchmarking.xlsx
The microcontrollers looked at included two boards from popular Linux-Capable board-families: the Raspberry Pi Zero and the Beaglebone Green. The other two boards chosen were a ARM Cortex-M7 and a ARM Coretex-M4F that are both supported by FreeRTOS.
Important criteria that we considered were the amount of RAM available to the microcontroller, which is important for being able to handle images, and the power draw, which is important since we have tight power constraints. The RAM information was easily available, but the power information was difficult to determine for most boards and will be obtained empirically in the future.
CamerasBelow is the benchmarking that was done for different cameras that can be used.
The final decision for which camera to use is the ArduCAM Mini. It is a small camera with I2C and SPI interfaces. This makes it easy to work with any processor. It is flexible for our applications with various lenses that can be used. It has built in JPEG compression. It is low cost and low power on top of all that. This makes it a very good camera for our application
In order to better compare the two architecture options, a risk analysis was performed that compared potential risks for both architectures.
A link to the full document can be found here: Systems Level Design Documents/System Design Risk Assessment.xlsx
Overall, the conclusions that were drawn from the risk analysis was that the cluster architecture is more flexible and can better adapting to changing requirements, but the sixteen-to-one architecture provides better redundancy.
A Pugh chart was created in order to assist in making a decision on which architecture was better for our needs.
The chart shows that both concepts are pretty similar in a lot of aspects, but the cluster architecture ends up winning out due to its better flexibility.
The Selected Concept
After created the Pugh Chart, it was decided that the cluster architecture should be used.
With this architecture the microcontrollers for the Cells and the Clusters were tentatively chosen to be the MSP432 and the SAME70 respectively. The MSP432 is very low power, which should be good since there a lot of them and the SAME70 has enough RAM to be able to easily store the images from the cells. Also, both of these boards are supported by FreeRTOS, which will make it easier to implement the real-time requirements of the system.
A more detailed view of the architecture is shown below, which contains the selected microcontrollers as well as rough power budgets for each sub system.
In order to determine what sort of communication buses and nonvolatile storage would be needed by the entire HABIP system, some analysis was performed on how much data the system would generate and where it would be generated.
A link to the full document can be found here: Systems Level Design Documents/System/Data_Bandwidth_Feasibility.xlsx
The spreadsheet shows how much data is expected to be generated by different parts of the subsystems. A lot of these assumptions will likely prove to be inaccurate, but as specific sensors and sample rates are chosen the assumptions can be clarified and the formulas will automatically be applied to the new data.
Based on the current assumptions, it looks like the DACQ IMU will generate a lot of data and so special care might be needed when handling that data.