sprocter commented 9 years ago

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.

sprocter commented 9 years ago

Background

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.

Modeling options
1. Add modes to the process implementation level, and require that the connection topology does not shift between modes.
2. Add modes to the process implementation level and allow for connection topology shifts between modes
Implementation options
1. Threads still map directly to MIDAS tasks and get an additional parameter to specify the current mode (implies modeling option i)
2. A different MIDAS task is generated for each thread × mode permutation (implies modeling option i)
3. Threads still map directly to MIDAS tasks, and have no knowledge of the current system mode (implies modeling option ii)

Examples

Modeling option i

-- 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;

Modeling option ii

-- 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;

Implementation option i

  @Override
  protected void SpO2ListenerOnMessage(MdcfMessage msg, Integer SpO2Data, ModeType mode) {
    // TODO Fill in custom listener code here
  }

Implementation option ii

  @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
  }

Implementation option iii

  @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
  }

Notes

Note that implementation options ii and iii, as well as the (syntactically valid) notion of mode-specific property values would require that certain tasks are only valid in certain modes -- so this would require re-scheduling MIDAS tasks between mode transitions, which may be an expensive operation.
I am rejecting outright the following (syntactically valid) AADL features:
1. Connection topology specifications valid during mode transitions. We can put these in if we want mode transitions to be non-instantaneous, though they're equivalent to manually specifying transition states.
2. Modal call sequences. These may be added if / when call sequences get added to the language.
3. Modes at the thread level -- I'm not sure this buys us anything. This would imply that the connection topology cannot shift between modes, since there is no process-implementation-level (ie, where the process's connections are specified) notion of modality, but then what should MIDAS do with messages that should be routed to a thread that is not valid in the current mode?

scbarrett commented 9 years ago

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.