End-to-end flows between threads in different systems

[Brian Larson]

I'm trying to define an end-to-end flow from a thread in one system to a thread in a different system.

Initially, I tried to define an end-to-end flow in the top-level system implementation using

consecutive periods:  sub1.sub2.sub3.flowSourceID

But subcomponent_flow_implementation only allows a single subcomponent identifier.

Then I tried to create and end to end flow in the process holding the flow source thread:

process Pulse_Oximeter_Process
  features
. . .

    PO_Alarm: out event data port BLESS_Types::Boolean;

      . . .
  flows  
    po_alarm_out : flow source PO_Alarm;
end Pulse_Oximeter_Process;

process implementation Pulse_Oximeter_Process.impl
  subcomponents
     pot: thread Pulse_Oximeter_Thread.impl;
     poc: thread PO_Communication_Thread;

  connections

    . . .
     pol1: port  pot.PO_Alarm -> poc.poa;
     pol2: port  poc.PO_Alarm -> PO_Alarm;
   flows
     pop_po_alarm : end to end flow pot.po_alarm_source -> pol1 ->  poc.po_alarm_flow_pct -> pol2 -> po_alarm_out;
end Pulse_Oximeter_Process.impl;

But this causes error "Cannot refer to a flow specification in the local classifier's namespace."  Using PO_Alarm (the port identifier) doesn't work either.

Therefore, there seems to be no way to define an end-to-end flow that goes up (or down) the containment hierarchy.

I was hoping the graphical editor would render the end-to-end flow, but that seems unlikely if I can't express it in a textual model.

So, how should an end-to-end flow between threads in different systems be modeled?

[jjhugu...@gmail.com]

Brian, please read 10.3 (L3). The termination of an etef is either a subcomponent, a flow sink, or a data component. Neither a port nor a flow source.

 

I guess you want to do this instead, i.e. provide an implementation for your flow source declared in the process.

 

I presume you want to have this flow source turned into an etef to run latency analysis tools. I do not think of a reason why we could not evaluate latency on a flow source/path/or sink, except for the time to implement this of course. This could also be accepted I presume, but we would have to discuss a specific errata first.

 

f2 : end to end flow  foo.f_foo_out -> C1 -> bar.f_bar -> C2 -> P_out;

 

 

package brl_2024_04_15

public

 

      thread foo

            features

                  foo_out: out event port;

            flows

                  f_foo_out : flow source foo_out;

      end foo;

 

      thread bar

            features

                  bar_in: in event port;

                  bar_out: out event port;

            flows

                  f_bar : flow path bar_in -> bar_out;

      end bar;

 

      process P

            features

                  P_out: out event port;

            flows

                  f_P_out: flow source P_out;

      end P;

 

      process implementation P.i

            subcomponents

                  foo: thread foo;

                  bar: thread bar;

            connections

                  C1: port foo.foo_out -> bar.bar_in;

                  C2: port bar.bar_out -> P_out;

      flows 

            f_P_out : flow source foo.f_foo_out -> C1 -> bar.f_bar -> C2 -> P_out;

      end P.i;

     

end brl_2024_04_15;

--
You received this message because you are subscribed to the Google Groups "OSATE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to osate+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/osate/68a06089-59a5-43cb-b6b5-cf2af5a98873n%40googlegroups.com.

[Brian Larson]

Jerome,

This is a very clever solution.  Thank you.

I had not considered f_P_out in the process type as a flow specification, and also f_P_out in the process implementation as a flow implementation.

I will try the same trick the rest of the way up the hierarchy, and flow sink down the other side with end-to-end flow only in the top-level system implementation.   

The model is trying to show high-assurance threads communicating through low-assurance software-hardware-network, yet achieve high-assurance for the system-of-systems as a whole.

The idea is simple and used to get high-assurance composition between an implantable medical device and its programmer.

Both use COTS software radio, TCP/IP stacks, and AES encryption (one in C the other in Java from different vendors).

Only a tiny fraction of the firmware in the device performs safety-critical function, but that depends on parameters chosen for each patient individually.

When the physician has chosen the appropriate prescription for a patient, the programmer writes the parameters to the device, and them reads them back.

By looping back through the less-assured components, the physician can have high-confidence that the prescription chosen is the one that will be executed.

The end-to-end flows model this loop-back.

--Brian