Open reteprelief opened 5 years ago
There are special rules for data access features in a flow implementation. The same special rule may then be needed for subprogram access features.
Need to check
Prototype patch is in PR https://github.com/osate/osate2/pull/1939
The example model below uses subprogram access features as flow spec end points and in a flow implementation (ft2 in T2.i).
The model doesn't use call sequences. We still need to work out how one would model a flow through a call in a call sequence to a subprogram without parameters.
package Issue39
public
subprogram Logger
properties
Compute_Execution_Time => 95ms .. 105ms;
end Logger;
thread T1
features
log: provides subprogram access Logger;
flows
-- currently not allowed
flog: flow path log -> log;
end T1;
thread implementation T1.i
subcomponents
logger: subprogram Logger;
connections
cl: subprogram access log <-> logger;
flows
flog: flow path log -> cl -> logger -> cl -> log;
end T1.i;
process P1
features
log: provides subprogram access Logger;
flows
flog: flow path log -> log;
end P1;
process implementation P1.i
subcomponents
t1: thread T1.i;
connections
cl: subprogram access log <-> t1.log;
flows
flog: flow path log -> cl -> t1.flog -> cl -> log;
end P1.i;
system S1
features
log: provides subprogram access Logger;
flows
flog: flow path log -> log;
end S1;
system implementation S1.i
subcomponents
p: process P1.i;
connections
cl: subprogram access log <-> p.log;
flows
flog: flow path log -> cl -> p.flog -> cl -> log;
end S1.i;
thread T2
features
sense: in data port;
log: requires subprogram access Logger;
cmd: out event data port;
flows
ft2: flow path sense -> cmd;
end T2;
thread implementation T2.i
flows
ft2: flow path sense -> log -> cmd;
end T2.i;
process P2
features
sense: in data port;
log: requires subprogram access Logger;
cmd: out data port;
flows
fp: flow path sense -> cmd;
end P2;
process implementation P2.i
subcomponents
t2: thread T2.i;
connections
cs: port sense -> t2.sense;
ct: subprogram access t2.log <-> log;
ca: port t2.cmd -> cmd;
flows
fp: flow path sense -> cs -> t2.ft2 -> ca -> cmd;
end P2.i;
device Sensor
features
val: out data port;
flows
fsrc: flow source val;
end Sensor;
device Actuator
features
cmd: in event data port;
flows
fsnk: flow sink cmd;
end Actuator;
system S2
features
log: requires subprogram access Logger;
end S2;
system implementation S2.i
subcomponents
sens: device Sensor;
p: process P2.i;
act: device Actuator;
connections
cs: port sens.val -> p.sense;
cl: subprogram access p.log <-> log;
ca: port p.cmd -> act.cmd;
flows
s2a: end to end flow sens.fsrc -> cs -> p.fp -> ca -> act.fsnk;
end S2.i;
system S
end S;
system implementation S.i
subcomponents
s2: system S2.i;
s1: system S1.i;
connections
cl: subprogram access s2.log <-> s1.log;
end S.i;
end Issue39;
A subprogram group access feature only makes sense in a flow spec if it is the first part of a qualified name. The full reference should be to a subprogram access feature or a parameter or data. For call sequences we would probably need to be able to reference a call sequence in a flow implementation. This needs some more thought...
Fix added by Lutz in 10.1
Currently flow specs can be between parameters of subprogarm access. We should allow them also for subprogram access without parameter. One reason is that we may call a subprogram that does not have in or out parameters