Relationships between identical properties on nested components

[stevevestal]

Data implementations can have a list of data subcomponents, all with Data_Size properties. Thread implementations can contain a sequence of subprogram calls, all with Compute_Execution_Time properties. There are other similar cases. Are there any rules about the relationships between these? Should there be? For example, should the Data_Size of the outermost implementation be a budget for the sum of the sizes of its subcomponents (i.e. a not-to-exceed cap on the sum)? Should the thread Compute_Execution_Time be added to the call sequence sum of Compute_Execution_Times (e.g. it models additional thread overhead), or should the thread value be interpreted as a not-to-exceed budget? Is the interpretation left open to tool developers, so different tools may give different behaviors?

[reteprelief]

Add consistency rule to Section 5.1: "For a data implementation with subcomponents the sum of Data_Size value associated the subcomponents must be the same as the Data_Size value specified for the data component."

[reteprelief]

Note: this check has already been implemented in OSATE.

[stevevestal]

When a thread has both a calls sequence declaration whose subprograms declare Compute_Execution_Times, and the thread itself declares a value for that property, what is the relationship? Is the thread value added to the sum of the sequence times? Or is the thread value an upper bound on the sums of the various calls sequences declared (there could be different sequences in different modes)?

I speculate a scan through the list of standard properties will turn up other properties where similar questions will arise.

[jjhugues]

Add as 5.1 (C1)

[stevevestal]

That may be too strict. Also, the interpretation that overall thread execution time is the sum of the thread execution time and its subcomponent subprogram execution times is useful. Budgeting is already handled by other analysis tools. Do we want to build specific budgeting semantics into the core standard?

[yoogx]

Budgeting semantics is still a never-ending story, and far from being addressed, but you are right I should not have closed it

I simply reacted to this part by Peter, Add consistency rule to Section 5.1: "For a data implementation with subcomponents the sum of Data_Size value associated the subcomponents must be the same as the Data_Size value specified for the data component."

Other properties could be discussed in separate issues, as this is not clear what must be in the standard and what should be tool specific

[jjhugues]

That may be too strict. Also, the interpretation that overall thread execution time is the sum of the thread execution time and its subcomponent subprogram execution times is useful.

This interpretation is not what the standard says: the property definition states the following (see the definition of Compute_Execution_Time in Timing_Properties.aadl in OSATE, or the definition of the property set in the standard document)

_The values specified for this property for a thread are bounds on the Compute_ExecutionTime values specified for ports or subprogram access that dispatch execution.

so this case is handled: a thread specifies bounds on execution time, whatever combination of entrypoint, call sequences etc. that gets executed has to respect this bound.

Unless you have a precise property to report, I consider this issue as settled