saeaadl / emv2

AADL Error Model V2 annex language
0 stars 0 forks source link

Bindings keyword is ambiguous #67

Open joeseibel opened 2 years ago

joeseibel commented 2 years ago

Components can have in or out bindings propagations. In E.7, Semantics (7), the standard says, "The keyword bindings is used in execution platform components to identify the binding point of all components bound to them." For example, if a processor has an out bindings propagation, then that processor can propagate errors to all threads bound to it by the property Actual_Processor_Binding.

However, it is possible for certain components to be the targets of multiple kinds of bindings. In the following example, the processor proc is the target for a processor binding, a memory binding, a connection binding, and a function binding:

package StandardIssue
public
  system s
  end s;

  system implementation s.i
    subcomponents
      proc: processor proc;
      ps: process ps.i;
      vb: virtual bus vb;
      subp: subprogram subp;
    properties
      Actual_Processor_Binding => (reference (proc)) applies to ps.t;
      Actual_Memory_Binding => (reference (proc)) applies to ps.t.d;
      Actual_Connection_Binding => (reference (proc)) applies to vb;
      Actual_Function_Binding => (reference (proc)) applies to subp;
  end s.i;

  abstract proc
    annex EMV2 {**
      use types ErrorLibrary;

      error propagations
        bindings: in propagation {ServiceError};
        bindings: out propagation {ServiceError};
      end propagations;
    **};
  end proc;

  process ps
  end ps;

  process implementation ps.i
    subcomponents
      t: thread t.i;
  end ps.i;

  thread t
    annex EMV2 {**
      use types ErrorLibrary;

      error propagations
        processor: in propagation {ServiceError};
        processor: out propagation {ServiceError};
      end propagations;
    **};
  end t;

  thread implementation t.i
    subcomponents
      d: data d;
  end t.i;

  data d
    annex EMV2 {**
      use types ErrorLibrary;

      error propagations
        memory: in propagation {ServiceError};
        memory: out propagation {ServiceError};
      end propagations;
    **};
  end d;

  virtual bus vb
    annex EMV2 {**
      use types ErrorLibrary;

      error propagations
        connection: in propagation {ServiceError};
        connection: out propagation {ServiceError};
      end propagations;
    **};
  end vb;

  subprogram subp
    annex EMV2 {**
      use types ErrorLibrary;

      error propagations
        binding: in propagation {ServiceError};
        binding: out propagation {ServiceError};
      end propagations;
    **};
  end subp;
end StandardIssue;

The way that the standard is currently written, a ServiceError raised in proc would be propagated to ps.t, ps.t.d, vb, and subp. There is no way to restrict a bindings propagation to be only for processor bindings or only for memory bindings. Is this intentional? Is the desirable? Do we want to be able to model that an error propagates out via processor bindings and connection bindings, but not memory bindings nor function bindings?

brlarson commented 1 year ago

This is a multiple path problem like #70. Suggest that multiple paths (and loops) be illegal.