Short version
I am considering to use BusObjects to implement hard interface control on a (large industrial) application using Simulink and I would like to store the BusObjects (hundrends of them) into a Matlab structure so that the entire application interface specification is well organized. However, it seems that BusObjects cant be contained into structures, nor they can reside on other workspaces other than Matlab Base. Any idea on how to handle this?
Long version
I would like the interfaces specification to be hierarchical and centralized in some way. I mean, I would like to specify the external interface of my application, then the internal interfaces, then the internal interfaces of the internal interfaces and so on. And I would like this information to be stored in one object that resembles the hierarchy. I was thinking in using an structure with BusObjects as elements.
Unfortunately, it seems that, for a bus object to work, it must be declared on the Matlab workspace as an independent variable of class BusObject. It cant be an element of an structure that is a BusObject, or an element of a cell whose elements are BusObjects or an element of a BusObject vector.
Any suggestion on how to handle this? take into account that if you have a model with dozens and dozens of blocks and more than 3 hierarchy levels, then you end up with hundreds of bus objects in the Matlab workspace without any particular structure... I think that is too messy to let it be...
Bus objects are always stored in the global workspace.
Send a request to Mathworks if you want to change this.
Related
I am learning about how to use the expandable connector in dymola.
I am wondering how to ensure the compatibility between two control buses. My guess is that if I define an input variable called X in one control bus, then in the other one, I need to define an output variable also called X. So that when connecting these two control buses, they are coherent.
Based on the above idea, I define the two expandable connectors which represent the control buses, here is the screenshot.
Here is the setting I used when testing my ideas.
But when translating the model, I got an error message like the following. It seems I got the logic wrong. My question is that how should I use the expandable connectors so that they are coherent.
The underlying problem is that there are two public expandable connectors (buses) at the top of the model; and both could in theory be connected from the outside.
The best option would be to not have two public buses at the top of model, e.g.:
Remove one of the two buses
Make one of the two buses protected
(Or more complicated hierarchical variants.)
The VehicleInterfaces library does this in a good way (alternatively you can look some of the commercial libraries).
However, simplest way of making this work is to not declare anything in the buses, i.e. remove the declaration of both 'x' variables.
My questions is about bringing a concept to reality through technical availability of EA.
I am looking for a way to connect instances at an object diagram through which I can transfer tagged values. Let me explain the background of the project.
Purpose is to first have Stereotypes for specific roles in the system, such as "Calculation", "Transmission", "Decision", "Qualification", "Abstraction" etc.
Each of these stereotypes have specific tagged values suitable for their purpose.
Then I am creating instances from these stereotypes, eg. "MotorTorque:Calculation" and "LimitedTorque:Abstraction"
Each of these instances have a common tagged value, "criticality", boolean and I want this tagged value to progress from "MotorTorque:Calculation" to "LimitedTorque:Abstraction" through an output port > some sort of flow > input port kind of way.
Questions are:
1- Is this approach technically achievable in EA? If so what would be the correct way to do it?
2- The purpose is to have this "connection" readable in XMI export of the diagram which I will be using as an input for another purpose.
I have created an MDG Technology for my project with stereotypes and tagged values, however, I am having difficulty achieving this "connection", this "flow" of values.
Thank you for your time.
What you are asking for is not directly achievable. However, many ways lead to Rome.
One way would be to <<trace>> connect those objects to a Status class (or what ever you like to name it) and have this carry the "shared TV".
Another way is (by far more complex) to use an add-in. You would anyway need ways to create groups which share the TV. From your current explanation I can't see what that might be. Maybe the instantiating class of those instances? If so, you make a script that propagates a TV setting from ist current to all other linked instances. I'm not sure if the add-in events fire when a TV is changes (I do have some doubts here). If needed I could look that up.
What you propose is partially feasible.
There is a tagged value inheritance chain in EA, in which tagged values are inherited down the generalization chain, and from a classifier to its instances. In the GUI, inherited tagged values are shown separately from the instance's own ones, and in the API they are accessed using the Element.TaggedValuesEx property. Inherited tagged values can also be overridden.
Since the correct way to create a port (or part/property) is to make it an instance of a component, a port will inherit any tagged values from that component. So if your Calculation stereotype applies to component, ports which are instances of Calculation components will inherit the MotorTorque tagged value.
However, there is no way to "flow" tagged values from one port to another. If you want such a function, you'll have to implement it yourself with an Add-In.
Regarding XMI, first you must understand that an XMI export is based on a package, not a diagram. The XMI format itself is extensible, which means that different tool vendors create their own extensions which are typically not publicly documented. Crucially, diagram layouts are part of these non-standardized extensions. In EA's case, the image data is some sort of UU-encoded bitmap which you won't be able to extract any useful information from.
Elements' tagged values are included in an XMI export, but again, the EA extensions are not publicly documented. In other words, you can import EA:s XMI format in another program, but you will need to reverse-engineer the format. Not impossible, but it's probably better to either write your own specialized export function, or export via CSV. Note, however, that CSV export cannot be automated -- there's no call for it in the API.
Is there any method to use in biojava to predict secondary structure from a given sequence?
Or if not does any anyone how can i implement it? any source code? Any exe to recommend?
I think it is not available in BioJava but what you can do is to do a BLAST search by using BioJava libraries (http://biojava.org/wiki/BioJava:CookBook3:NCBIQBlastService) or RCSB web page and from your BLAST search you can find a protein with 3D structure. Afterwards you can use suggestDomains(Structure s) method of LocalProteinDomainParser class in org.biojava.bio.structure.domain package. Domains might give you some ideas about secondary structures.
I don't think there is secondary structure prediction from sequence in biojava. However there is secondary structure assignment given the structure, based on the DSSP algorithm, see https://github.com/biojava/biojava-tutorial/blob/master/structure/secstruc.md
This is the scenario.
There are three components, A, B and C.
Component A can access methods of component B.
Component B can access methods of component A and component C.
Component C can access methods of component B.
To implement this scenario how many interface description language (IDL) files are needed? How many stubs and skeletons do we require?
I was thinking four IDL files. But can we have multiple stubs and skeletons?
Depending on the size of your services/components (number of methods), I would rather try to split them into logical units rather than based on the number of computers you want to connect.
For example, it can make sense to have two different services implemented by the same server: One for internal purposes and one that is to be published. Or a service is split into two parts, because these two parts do not really belong together logically, although they are for some reason implemented by the same component. All of these services may or may not share the same IDL file.
Last not least, if you still want to minimize the amount of files, keep in mind that declaring, publishing and knowing about a certain service interface does not imply, that a given component must implement the service, must be able to reach the service, wants to use the service, or is allowed to call it.
I am working in matlab simulink.There are two parts of my work.one is about control systems and the other is about image processing.I want to link them such that the control system part only receives a scalar input from image processing part.So i want to use the 'model' block attached to the image processing part such that there is a scalar input to the model block.How can I use this 'model' block such that it has an input port as I donot see any input port to this block.Please guide me.
The Model Block is used whenever you want to make use of a model inside of another model. This is something that is useful, for example, when multiple people are working on a large system that is comprised of multiple self-contained systems each of which could be its own model, but that could also act together in some useful way.
If you are just using Model Blocks for the sake of organizing subsystems together, then you should consider using Subsystems, instead. Subsystems allow you to group blocks together and do not require you to create separate models for each of your components (i.e. your Controller subsystem and your Image Processing subsystem). You can easily make a Subsystem either by dragging in the Subsystem block from the Simulink Library Browser, or by selecting components in your model, right-clicking, and selecting Create Subsystem from Selection.
However, if you actually do want to use Model Blocks, that can be done as follows. So, I'm assuming that you have already created two models -- one for your control system, the other for your image processing algorithm.
First, in each model, make sure you have specified the proper inputs/outputs. You will do this by adding Inport and Outport blocks to the top-level of each model.
Next, create a new model in which you will integrate the Control model and Image Processing model. Add a Model Block for each model (as you had already described doing). For each Model Block, open the Parameters dialog box. You will see a parameter where you can specify the model name. Enter the name of the model that you will be referencing (i.e. either the controller or image processing model). Additionally, you can browse for these models. Once you do that, the inputs and outputs that you had previously specified should now be visible on the Model Blocks.