[aadl-modeling]: Port connections and latency analysis

[David K]

Hi,

thank you for your answer. After consulting with my supervisor I notices
that I got a wrong approach for my task since there are too much messages
to model (my abstraction level was too deep). Anyways your message helped
me a lot to understand the difference between flows and connections
respectively the usage of the latency.

To answer your question whether I read the online documentation of OSATE:
No, I haven't read it. I didn't knew this exists, but as I searched it I
couldn't find it. My main information sources are the books "Model Based
Engineering with AADL" and "AADL in practice".


Kind regards
David



2018-05-03 16:29 GMT+02:00 Peter Feiler <phf at sei.cmu.edu>:

> Hi,
>
>
>
> Have you checked out the documentation in the online help of OSATE under
> OSATE Core Documentation Analyses?
>
>
>
> When you say cyclical messages do you mean sampled processing?
>
> You can attach the period property to your leaf component – it does not
> have to be a thread
>
> From the documentation:
>
> *Sampling Delay in Periodic Sampled Processing*
>
> In embedded systems it is common to perform periodic sampled processing.
> Examples are displays refreshing at a specified rate, sensors sampling the
> physical environment at a given rate, application systems processing their
> input periodically (periodic threads). This can result in a sampling delay
> as latency contribution, i.e., the amount of time incoming data is in the
> incoming port until the component is dispatched.
>
> The *Period* property allows users to specify the time interval at which
> a component executes. We can annotate a system, abstract, process, thread
> group, thread, device component with a period.
>
> You mention defining flows and binding flows to buses. Flows in AADL are
> specification of flows from input to output within a component. This allows
> us to calculate latency without having to have an implementation for the
> component. You have connections from the output of one component to the
> input of another component. You can associate a latency value with the
> connection. You can also bind the connection to a bus used as transport
> mechanism – you can also use virtual buses to represent protocols with
> their latency contributors.
>
> The latency analysis uses information from the bound bus – if not present
> it uses the latency associated with the connection itself.
>
>
>
> In AADL you specify your functional or task and communication architecture
> separate from the platform, e.g., connections between threads (via their
> enclosing components such as process or system). Binding of threads to
> processor determines who executes where and connections to buses and other
> HW component to indicate the hardware involved in the communication.
>
>
>
> Peter
>
>
>
>
>
> *From:* aadl-modeling-bounces+phf=sei.cmu.edu at lists.sei.cmu.edu [mailto:
> aadl-modeling-bounces+phf=sei.cmu.edu at lists.sei.cmu.edu] *On Behalf Of *David
> K
> *Sent:* Wednesday, May 2, 2018 11:45 AM
> *To:* AADL Modeling <aadl-modeling at lists.sei.cmu.edu>
> *Subject:* [aadl-modeling]: Port connections and latency analysis
>
>
>
> Good afternoon,
>
>
>
> I modelled a AADL-system containing several subsystems connected via
> busses. Now I want to do a basic latency analysis of the systems
> communicating via cyclical messages but I don't know how to do it.
>
>
>
>
>
> My approach is:
>
> 1. defining the ports of the subsystems
>
> 2. define the flows with their latency times
>
> 3. define the bus properties
>
> 4. binding the flows to a bus
>
>
>
>
>
> The cyclical part is still missing in my approach. Do I need to implement
> the threads of the subsystems as well for this?
> And if I need to implement the threads: Are the data flows directly
> connected from the thread-ports to the system-ports or are they going
> through the processor?
>
>
>
>
>
> Kind regards
>
> David
>
-------------- next part --------------
HTML attachment scrubbed and removed