buzden
commented
6 years ago Obviously, to solve this, there is a general need to formulate the list of all possible operations we want to have for range expressions (like subtraction of a time constant in your example).
I remind my very-long-time-ago example which we still have in our models to deal with the standard output_rate property: computation((1 / data_port#output_rate.value_range) sec). Here, we have a range of numbers (meaning frequency in Hz, actually) which needs to be transformed into the range of time (to fit the computation operator). Thus, we need to have some operations to do this. This type of division and similar variants are currently supported by the MASIW's AADL simulator, but such operations are not standardized, unfortunately. Without them, it's sometimes hard to write meaningful BA specifications.
First of all, I understand that particularly this example can be implemented without operation of division a constant to a range (which is potentially a dangerous operation in case when range contains zero). Alternative implementation without range-aware division would look like computation( (1 / data_port#output_rate.value_range.upperBound) sec .. (1 / data_port#output_rate.value_range.lowerBound) sec ) but I hope you all agree that this variant does not all any clarity to the specification.
And of course, what I really hope is that in future we will have a nice and unitful property language where dimensioned values like frequency will be controlled by a AADL's core type system and the standard will define nice set of operations on property values.
jjhugues
(this issue was referenced as D.6-10 and D.7-07 in the SaeAadlWiki) Currently, computation action allows fixed behavior_time values only (e.g.
computation(5ms..10ms)). A need has been identified to also accept timed expressions such as:#Compute_Deadline - 5ms