Open sprocter opened 9 years ago
After giving this some more thought (and re-reading the AADL book's section on modes), it seems to me that there are actually two different sets of choices -- how to model modes (since AADL is quite permissive) and how to translate them.
-- fault and start are incoming event ports
process implementation MyProcess.imp
subcomponents
SpO2Thread : thread SpO2Thread.imp;
connections
incoming_spo2 : port SpO2 -> SpO2Thread.SpO2;
modes
init : initial mode;
running : mode;
error : mode;
init -[ start ]-> running;
init -[ fault ]-> error;
running -[ fault ]-> error;
end MyProcess.imp;
-- fault and start are incoming event ports
process implementation MyProcess.imp
subcomponents
InitializeSpO2Thread : thread InitializeSpO2Thread.imp;
UpdateSpO2Thread : thread UpdateSpO2Thread.imp;
connections
incoming_spo2 : port SpO2 -> InitializeSpO2Thread.SpO2 in modes (init);
incoming_spo2 : port SpO2 -> UpdateSpO2Thread.SpO2 in modes (running);
-- We disregard SpO2 in the error state, we're in failsafe mode
modes
init : initial mode;
running : mode;
error : mode;
init -[ start ]-> running;
init -[ fault ]-> error;
running -[ fault ]-> error;
end MyProcess.imp;
@Override
protected void SpO2ListenerOnMessage(MdcfMessage msg, Integer SpO2Data, ModeType mode) {
// TODO Fill in custom listener code here
}
@Override
protected void initSpO2ListenerOnMessage(MdcfMessage msg, Integer SpO2Data) {
// TODO Fill in custom listener code here
}
@Override
protected void runningSpO2ListenerOnMessage(MdcfMessage msg, Integer SpO2Data) {
// TODO Fill in custom listener code here
}
@Override
protected void errorSpO2ListenerOnMessage(MdcfMessage msg, Integer SpO2Data) {
// TODO Fill in custom listener code here
}
@Override
protected void InitializeSpO2ListenerOnMessage(MdcfMessage msg, Integer SpO2Data) {
// TODO Fill in custom listener code here
}
@Override
protected void UpdateSpO2ListenerOnMessage(MdcfMessage msg, Integer SpO2Data) {
// TODO Fill in custom listener code here
}
Both of your modeling options look good Sam, and I think that they are both worth having in your AADL toolbox with option (i) being the preferred tool. We will have to think through what constitutes 'need'.
Here's the thing: changing connection topology sounds expensive. This is something that modelers tend to forget, or are never aware of -- their models will (hopefully) someday become real systems, with real costs. Every design decision they make has a cost in the real world (e.g., data ports, which have no queuing, are cheaper than event data ports). So the fact of cost can be used as a legitimate criteria by which design decisions are made.
With regard to implementation iii), threads don't really have 'knowledge' of modes, they just carry that information around.
There are a number of situations that seem to need a notion of modality -- app initialization, failover / error states, etc. -- and full AADL supports them. Before modes are implemented, though, we'll need to carefully consider what the resulting translation will look like.