Complete and unambiguous Capacity and demand properties

[stevevestal]

BLUF: Recommend adding a Processor_Demand property as the partner to Processor_Capacity; and splitting Data_Rate into Data_Rate_Capacity and Data_Rate_Demand.

Rationale:

Processor_Capacity in units MIPS etc. applies to processor, virtual processor, and system. There are no other properties having Processor_Speed_Units values. What's the purpose of declaring a processor capacity if there is no way to declare a need for this?

Data_Rate applies to many categories. This can be disambiguated by interpreting it as a capacity for pure hardware categories (e.g. processor, bus) and as a demand for pure software categories (e.g. connection). However, this is somewhat ambiguous for abstract, system, virtual processor, and virtual bus categories. There are use cases where a distinction is useful, e.g. a virtual bus that defines an ARINC 664 virtual link where the developer wishes to specify a BPS demand on an underlying bus that is greater than the BPS supply provided to connections in order to specify reserved capacity.

[buzden]

This is one more example of duality of a lot of the AADL properties -- a lot of them can mean both demand and provision.

I see that this ticket is not for the AADLv3, but in AADLv3 exactly this dual pair of processor demands and capacity properties is meant to be solved through named and parameterful first-class bindings. There also a slightly orthogonal but relevant question about units for demand and capacity.

[stevevestal]

Here is the spreadsheet I sent BL and PF in advance of the June 2019 committee meeting.

Comparison Of Loading Properties.xlsx

[jjhugues]

@stevevestal does this issue goes with the more general question of refactoring all scheduling properties?

[jjhugues]

• [ ] @stevevestal to clarify needs for additional applies to
• [ ] SEI to review some properties and standardize them

[stevevestal]

I will try to clarify a bit.

I recommend making an editorial pass through the standard to clearly distinguish 1) the difference between a component placing a demand for a certain kind of resource from a component that can supply that kind of resource; and 2) clearly distinguish resource budgets (upper and lower bounds) from resource actuals (specify with some degree of uncertainty the nominal demand or supply expected for the implemented component).

Here are recommendations for specific changes to the standard itself.

Add a new Processor_Demand property as the partner to Processor_Capacity

Split Data_Rate into new Data_Rate_Capacity and Data_Rate_Demand properties. Mark Data_Rate as deprecated.

Allow Data_Size to be applied to feature group type (all feature groups of that type will have that size) and feature group (specific feature will have that size).

Allow Memory_Size to be applied to a device.

In the definitions for Code_Size, Data_Size, Heap_Size, and Stack_Size, clarify that these are nominal actual demands for bytes that can be satisfied by memory components whose Memory_Size specifies nominal actual capacity for bytes of storage. (There are no standard properties for budgets.)

In the sections on virtual resources, note that these can have both demands and supplies, where what they can supply cannot exceed the sum of what their subcomponents supply plus their declared demand (a legality rule). If a virtual resource demands more than the demands of its subcomponents plus the demands placed on it, that creates a budget/reserve.

[jjhugues]

After reviewing this issues, I came to the conclusion that solving this issue is not possible with the approach suggested here. We cannot reach a "complete" set of properties, and renaming them is not a valid solution either.

Let me elaborate on your example:

1/ One cannot reach a complete set of properties why?: my claim is that for all properties defined in AADL, one may want to have a _demand, _actual, or _whatever variant.

• Priority? could be set by the designer, or computed
• Actual_Processor_Biding? same: one can propose some options, and let a tool optimize the allocation
• the same applies to any quantity actually ..

So how do we stop? we basically cannot.

2/ Secondly, your example could be discussed as well:

• Replacing Memory_Size with Memory_Capacity/Demand? If I want to model an existing board, Memory_Size makes sense as a name. Then, having a software process with a Code_Size is again a fact reflecting the size of the software.

It becomes a demand only when you want to evaluate the feasibility of deploying this process on a board. Hence, interpretation of a set of properties depends on the analysis or modeling viewpoint you make. In other words, your modeling process.

I prefer we keep AADL agnostic on this base. Memory_Size defines .. the size of the memory. How this value is used is left at the discretion of the user.

I would thus recommend we do not add Processor_Demand/Processor_Capacity and similar variants.

Suggested work-arounds

• define two property sets: Resource_Demand, Resource_Capacity. Then, the name of the enclosing package can be used as a tag to specify which interpretation to give. This could be part of an annex document that would detail how to use demand/capacity pair to evaluate resource budgets
• implement the data set mini-annex (has been there since v2.0)
• defer to v3 and its configuration mechanism (that inherits from this data set idea)