We had some fun in our last post about the Hyperloop open source transportation system, but we didn't get much into the specifics. This week we begin to move things forward.
Before beginning to analyze the feasibility of individual components, we decided to think about how we would architect a Simulink model to simulate the Hyperloop. In my opinion, such a model should include:
- Componentization: It must be possible for a component to be used in isolation in test models, or as part of full system model
- Variants: For each component, it must be easy to switch between different levels of fidelity or content.
- Intuitive: If many engineers are going to participate in this project, it must be easy for them to understand the model.
With that in mind, Matt and I (Guy) built tentative architectures which we describe today. If you have experience creating models for collaborative development involving multiple engineers, we would really like to hear what you think in the comments.
Matt: Systems Approach
I really liked the way the hyperloop proposal partitioned the different systems. So, I followed their lead in my model architecture. I put six systems at the top level. Where applicable, the controls for that specific system reside with its model. This choice makes componentization more straight forward. I like to put images on a mask for each system to make their content clear.
Each of these systems contains a referenced model. Those models become stand-alone environments for contributors to develop their own solutions for that system. Theoretically, these solutions could even depart from those put forth in the proposal. The developer is also free to utilize the modeling domain of their choice, be it Simulink, Simscape or integration of external tools.
It is possible to integrate different combinations of solutions and see how they work together. Variant selection can be parameterized as shown in the Block Parameter dialog below. Here, the variable varComp determines the active variant for the Compressor system.
The valid combinations could be managed through configuration sets within the Variant Manager. In the example below, there is a configuration for a Simulink version of the hyperloop proposal, a Simscape version of the same and a third configuration that utilizes a more conventional solution with hub motors and an independent suspension.
Since the interfaces between my components use Simulink signals, any toolbox or third party tool can be used to design the components. We can leverage advanced physical modeling tools and all users can reap the benefits.
From my perspective, the system-based hierarchy, combined with the images, makes an intuitive model. Using Model Reference means that there is a mechanism for variant control. Using Model Referencing with the right elements of the hierarchy provides the final ingredient; componentization. It’s all there.
To begin, I decided to go with an architecture I see often in Model-Based Design projects: a plant and a controller.
If you look inside the plant, you can find a layer where I convert signals between the ideal continuous plant and the discrete fixed-step controllers.
In the actual plant subsystem, you can see that I make intensive usage of our physical modeling toolboxes. I centered the design around one SimMechanics Solid block representing the center of mass of the capsule.
I also think we should use the Simscape electrical and pneumatic domains to model interactions between components.
To help identifying the data flow, I like to use a color code: green for Inports, red for Outports, blue for SimMechanics connections, etc...
Each component is a Variant Subsystem containing multiple versions of the component, with different implementations. The variants are stored in separate library files. By using a "one file per variant" approach, individual developers should be able to work in their own library file without modifying the rest of the model. This will also allow them to test their designs in smaller test models if needed.
With the central SimMechanics connection, each component can connect to the capsule to get information about its dynamics and apply forces or constraints to it. For example, the simplest model of air drag could look like the following, where I use a Transform Sensor to measure the capsule forward velocity and an External Force and Torque block to apply the drag.
For convenience, I packaged all my files in a Simulink Project. The startup script automatically sets the path and creates necessary variables as you open the project. I also defined shortcuts for common tasks, like opening the main model and plotting the final trajectory.
Now it’s your turn
As you can see, our architectures are very different. We would really like to hear what you think. Do you prefer one, or the other, or something completely different? Tell us why by leaving a comment here.
5 CommentsOldest to Newest
The yellow lines in Matt’s model are tought to read, but otherwise I much prefer having my whole system out in front of me. I think it makes it easier to share work.
However, does Matt’s system have the controller integrated?
1) Classic style of model is the notion of a black box with input-output, so I’d like to see on the first scheme, only the input-system-output.
2) The second scheme should to be as close as possible (visually) to a functional scheme – it facilitates the understanding of the model.
3) The rest of it is concise and clear.
I often find myself in the situation having quite a number of modules (e.g. 14 or more) which are tightly linked, e.g. having a lot of interaction. When drawing the architecture this would result in a lot of lines.
Isn’t it a better solution to use referenced models along with global datastores? This enables each developer to work separately on his/her module. Graphically this eliminates a cluttered architecture. Drawback is of course checking the interfaces at integration.
How do you think about it?
@Han Geerligs: This is a very good point you are bringing up. We should probably make a follow up post highlighting the possible architecture you describe.
Personally, I am not a big fan of the Data Store approach. The main reason is that the data flow becomes less obvious when looking at the model. Even though this requires more “wiring”, I usually find ways to keep the model clearer with lines. For example I would not put 14 components at the same level… I would use Virtual Subsystems and Buses to arrange things in a logical and clear way.
However I understand that Data Stores offer some advantages (especially from a code generation point of view) and are the most appropriate solution in some cases.
@Ryan: Thanks for your comment. I also like to see the system laid out in a clear manner at the top level.
Regarding your controller question: there are controllers within each of the systems you see. At that level, each system is broken down similar to what Guy has shown at the top level, with plant and controller. However, there are also the additional inputs/outputs to the rest of the world, rather than being a closed loop.
Best regards, Matt