Model instantiation fails when flow latencies are assigned in properties

[nvcyc]

OCARINA VERSION:

root@549e23822d46:~/opt/ocarina-build# ocarina --version
Ocarina v2017.1-510-gf2c500f (Working Copy from rf2c500fe)
Copyright (c) 2003-2009 Telecom ParisTech, 2010-2019 ESA & ISAE , 2019-2021 OpenAADL
Build date: Feb 22 2021 22:32:18

HOST MACHINE and OPERATING SYSTEM:

root@549e23822d46:~/opt/ocarina-build# uname -a
Linux 549e23822d46 5.4.0-60-generic #67~18.04.1-Ubuntu SMP Tue Jan 5 22:01:05 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

COMPILER VERSION

root@549e23822d46:~/opt/ocarina-build# gnatls -v

GNATLS 7.5.0
Copyright (C) 1997-2017, Free Software Foundation, Inc.

Source Search Path:
   <Current_Directory>
   /usr/lib/gcc/x86_64-linux-gnu/7/adainclude


Object Search Path:
   <Current_Directory>
   /usr/lib/gcc/x86_64-linux-gnu/7/adalib


Project Search Path:
   <Current_Directory>
   /usr/x86_64-linux-gnu/lib/gnat
   /usr/x86_64-linux-gnu/share/gpr
   /usr/share/gpr
   /usr/lib/gnat

root@549e23822d46:~/opt/ocarina-build# gcc --version
gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

DESCRIPTION:

When latency is assigned to a flow in properties, the model instantiation would fail with the following error:

TestLatency.aadl:48:13: latency cannot be properly instantiated

REPEAT BY:

With using the following test AADL model (named test_latency.aadl):

package TestLatency
public

    data d1
    end d1;


    -- deployment
    system deployment

    end deployment;

    system implementation deployment.impl
        subcomponents
            p1: process p1.impl;

    end deployment.impl;


    -- p1
    process p1

    end p1;

    process implementation p1.impl
        subcomponents
            t1: thread t1.impl;
            t2: thread t2.impl;
        connections
            conn: port t1.out_port -> t2.in_port;
        flows
            flow_t1_t2: end to end flow t1.flow_out_port -> conn -> t2.flow_in_port;
        properties
            latency => 2ms .. 4ms applies to flow_t1_t2;
    end p1.impl;


    -- t1
    thread t1
        features
            out_port: out data port d1;
        flows
            flow_out_port: flow source out_port;
    end t1;

    thread implementation t1.impl
        properties
            latency => 1ms .. 2ms applies to flow_out_port;
    end t1.impl;


    -- t2
    thread t2
        features
            in_port: in data port d1;
        flows
            flow_in_port: flow sink in_port;
    end t2;

    thread implementation t2.impl
        properties
            latency => 1ms .. 2ms applies to flow_in_port;
    end t2.impl;

end TestLatency;

and running Ocarina with the following command

ocarina -aadlv2 -r TestLatency::deployment.impl test_latency.aadl -i

will lead to the following error messages:

TestLatency.aadl:48:13: latency cannot be properly instantiated
Cannot instantiate full model, exit now

SAMPLE FIX/WORKAROUND:

Note that there will not be errors if the latency assignments are embedded in the flow declarations.
That is, using assignment style like flow_out_port: flow source out_port {latency => 1ms .. 2ms;}; will not yield an error.

[yoogx]

Actually, flows are not instantiated. Your work-around simply masks this. I need to cover this case

[nvcyc]

Thanks for your clarification.
Does masking flows block the possibility to conduct an end-to-end latency analysis with Ocarina (e.g., via a backend)?
Is there a plan to instantiate latencies or at least store them in the instantiated model in a way that latency assignments can be accessed by a backend to conduct analysis if needed?

[yoogx]

I analyzed this issue a little bit.

You won't be able to perform flow analysis through a backend since they are not instantiated.
Actually, you do not need flows to do end-to-end latency analysis with Ocarina.

Ocarina has a DSL called REAL that allows one to define analysis, see https://github.com/OpenAADL/AADLib/blob/master/src/real/flow_latency.real for an example on flows

REAL does not consider user defined flows. Instead, the tool instantiate all possible flows in the system, by enumerating all pais of source/sinks and then one can process them. See

ocarina/src/core/instance/ocarina-real_expander-flow_analysis.adb

Line 97 in 60cc1ef

procedure Explore_Flows is

If you can tell me more about what you want to achieve; we may decide on a design. Either we implement the instantiation; or instead you rely on this approach for your own needs.

[yoogx]

Any thoughts on this?

[nvcyc]

Thanks for your information. I have not tried REAL and I should definitely explore it.
I'm generally interested in the analysis that's not beyond any typical use cases (analyzing end-to-end flow latency that's defined in the model).
For this purpose, how do you compare Osate2's latency analysis and Ocarina's real_theorem analysis? Would one be preferred over the other?

[yoogx]

OSATE2 latency analysis applies its own set of rules to evaluate the latency. These work on specific cases. You may want to review the existing documentation and TR.

REAL allows you to get flows and then build your own strategy, allowing for more flexibility. But beware, this was just a research prototype. You may want to review examples in ocarina/examples/real/lib.

Resolute is a different language made by Collins that uses the same principles as REAL. You may want also to investigate this tool.

So, it really depends on your use case. OSATE2 might be enough for your needs.