Update resource budget analyses to use AnalysisResult -> power requirements

[joeseibel]

1. Clear the mode states for a given SystemInstance. That is, the modal adapters for the model all have their modes set to null.

• Just walk the whole tree and clear the modes of all the components. We used to use the SOMs to do this so that we only touched those components that were modal. But we cannot be sure that any single SOM refers to all the modal components because some modal components may not exist in some SOMs.

2. Lookup a non-modal numeric SEI PowerCapacity property value scaled to the given unit (from platform:/plugin/org.osate.contribution.sei/resources/properties/SEI.aadl). Units used: KW, mW and W

3. Collect budget and supply information

• Supply in form of power budget drawn this power supply from other supply. This could be a requires bus access, or an incoming abstract feature. There must be a connection on this feature

If power supply > 0

• List connection info Else // warning unconnected power requirement (in current code, there is no code in else statement, just this comment)

Get destination connection instances for this feature // incoming connections: does the other end provide power? If supply > 0, add text to report (for example) : 40.0 W from EPSU

Same for outgoing connections - if budget > 0, add text to report // outgoing connection. Does the other end have a power budget?

After you checked all features, // power supply and budget based on access connections to this bus // we are checking whether there are connections with the component with power capacity as source or destination // this could be a bus, possibly an abstract component

— same logic for in/out connections again ( // Outgoing / Incoming from Power system as bus) Record budget and supply

4. Building report Check if budget exceeds capacity Check if budget exceeds supply (available)

5. Write out to Excel file

[asazonova]

down to building a model and visitor now

[AaronGreenhouse]

I noticed that the example project resourcebudgets.aadl has nested components with power budgets. The original analysis (as written by Peter) doesn't check this information. I'm assuming the new version doesn't either. I don't know if we want to expand the analysis to deal with this or not.

[AaronGreenhouse]

The question here and I think we need @lwrage to chime in is whether this analysis should stick to what the original implementation does, which is to only check the power across a power transmission system, or whether to extend it to check the requirements hierarchically.

Honestly, if we just want to stick with the original functionality, we don't even need an analysis model.

If we want to check hierarchically a model would definitely be helpful. There are 3 ways to nest (potentially):

1. Power suppliers could nest by connection out features to out features. These features would both be marked with PowerSupply property associations. Idea is this would be additive: all the features connected to the outer feature should sum to the PowerSupply of the outer feature. I don't think I have seen an example of this in the existing models.
2. Power consumers could nest by connection in features to in features. These features would both be marked with PowerBudget property associations. The sum of the budgets of the inner features should equal the budget of the other feature.
3. Power transmission systems can also be power consumers (called Transmission subsystems in the docs). I'm not sure there is anything new to check regarding this relationship; it's more interesting from the point of view of how to structure the results.

Questions

• Can a transmission subsystem get power from more than one "backbone"?
• Can a transmission subsystem get power from a normal power supplier?
• Can a single power supplier contribute to more than one transmission system (from a single feature)?
• Can a power consumer draw from more than one transmission system (on a single feature)?

[lwrage]

I don't think it's necessary to update the analysis itself. There are many things that could potentially be improved, but we would need to consult an electrical engineer to know what makes sense.

[AaronGreenhouse]

So per @lwrage keep the existing functionality and don't try to improve anything. The power analysis model is flawed any how as it doesn't take into account different voltages, etc. This is meant as a proof-of-concept analysis to show that something can be done with power. But no one every followed up on it.

As I mention above, this is actually simple enough that it doesn't require an analysis model, but I think we should use one any way for the learning experience (both for Anna and to just generally expand are experience with trying to use them).

[AaronGreenhouse]

Model for the power analysis should consist of a set of Power Transmission Systems. Each power transmission system is connected to 0 or more Power Suppliers and 0 or more Power Consumers. Transmission systems, suppliers, and consumers are identified by property associations as described in the help text.

A Power Transmission System should have an attribute referring to the ComponentInstance.

A Power Consumer should have an attribute referring to the FeatureInstance.

A Power Supplier should have an attribute referring to the FeatureInstance.

[AaronGreenhouse]

Merged branch 2555_bus_load_analysis_ECORE_adapters into 1383_use_AnalysisResult_in_power_requirements_analysis