WATERS 2011 - Post-workshop thoughts
tommaso
following up on the discussions and thoughts exchanged during the
interesting WATERS 2011 workshop day, I would like to share with you
some of my post-workshop thoughts. This year, similarly to last year,
we had an interesting overview of tools for real-time and embedded
systems, and we had the opportunity to check what cool new features
each one is working on.
As you know, one of the challenging goals of WATERS is to enhance
comparability of research results by fostering the use of common tools
and/or data sets for comparing each other's research results.
Of course, the (re-)use of more or less complete tools that may be
available plays an important role in this regard. However, it is quite
evident that we may have also different tools that fulfil different
goals and sometimes help in analysing a system from different but
complementary viewpoints. One clear example is the one of the
heterogeneous tools that encompass the whole life-cycle of a real-time
embedded system, from requirements specification to design, to code
generation, to formal verification etc. The interoperability issues
arising from the attempts of integration of such heterogeneous tools
have been quite stressed by the 2 talks opening WATERS this year.
However, also in tools that can be used in the same life-cycle stage,
sometimes one can find different features or different analysis types
implemented in different tools.
Therefore, one might want to get benefit from a variety of existing
tools in order to gain a more complete picture of its system run-time
behaviour. Ideally, this could be possible if for example the file-
format for exchanging information across these tools were common.
Also, for comparison purposes, it might be extremely useful to import
the configuration or system analysed in a previous related paper with
a different tool (assuming the used data were available for download),
for the purpose of showing the advantages of a novel scheduler or
analysis type over the very same system. However, in the set of tools
presented at the workshop so far, I couldn't spot such chances of
interoperability across different tools.
The issue may become more easily understandable by taking an easy
example: is there a standard (or commonly used) format for exchanging
information about:
-) a task-set composition, in terms of task parameters (WCET, exact or
minimum inter-arrival periods, deadlines, offsets);
-) the composition of a distributed RT application, in terms of
dependencies among tasks deployed on different nodes (i.e., who
communicates with whom?) and the communication model/semantics among
them, etc.
Just to stress the example more, I could spot that some of the tools
that were presented this year were making use of XML-based
representation of such parameters. My question is: what are the
chances to make such representations compatible with each other ?
Apologizing for the length of this message, I hope to get some
interesting and useful comments from all of you.
Thanks and regards,
Tommaso
--
Tommaso Cucinotta, Computer Engineering PhD, Researcher
ReTiS Lab, Scuola Superiore Sant'Anna, Pisa, Italy
Tel +39 050 882 024, Fax +39 050 882 003
http://retis.sssup.it/people/tommaso
Nicola Serreli
mi ero dimenticato di avvertirti:
da un paio di giorni il codice di RT-Druid e' disponibile sull'svn di
erika su tuxfamily
Nicola
Tommaso Cucinotta
Not too much of a big issue here, as we've just got the news
(in Italian, sorry) that the RT-Druid source-code
has just been made available for download from the SVN repository
on the project website (http://erika.tuxfamily.org/).
Regards,
T.
Michael González Harbour
Indeed all the tools that model task sets or dependencies in distributed
applications have their own internal descriptions, but there is no standard.
Creating a standard would be difficult, because everybody would want the
others to use their own description format.
I really have no ideas on how to make such a standard happen.
Best regards,
Michael.
El 25/07/2011 15:38, tommaso escribi�:
> --
> Tommaso Cucinotta, Computer Engineering PhD, Researcher
> ReTiS Lab, Scuola Superiore Sant'Anna, Pisa, Italy
> Tel +39 050 882 024, Fax +39 050 882 003
> http://retis.sssup.it/people/tommaso
--
-----------------------------------------------------------------------
Michael Gonzalez Harbour E-mail: m...@unican.es
Grupo de Computadores y Tiempo Real URL: http://www.ctr.unican.es
Facultad de Ciencias Phone : +34-942-201483
Universidad de Cantabria Fax : +34-942-201402
Avda. de los Castros s/n
E-39005 Santander
SPAIN
-----------------------------------------------------------------------
Paolo Gai
Thanks for the question you made! Here are my 2 cents...interested ip
From the experience I had in the latest years, I see that the usage of
the same file format could be a very nice feature that could help many
tools to interoperate and exchange data.
In my case, we had a recent experience with an IST FP7 project,
INTERESTED, aimed at the interoperability of various tools for
specification, design and code generation.
http://www.interested-ip.eu/
My experience was the following:
- commercial tools do integrate using common file formats when there is
possibility for exploiting business opportunities, or when there is a
strong customer demand. Most of them also have a closed or simply
proprietary file format for reasons of user lock-in.
- free-university tools usually do not have this problem, but typically
they lack man-power. In other words, it is often easier to make a
quick-and-dirty file format (for storing experiment results for the
paper I should have submitted yesterday but for which I got a 1 week
extension), than writing a common exchange format useful for someone
else :-)
Anyway, I can describe some of the fileformats which I think they could
be promising, or at least that we used. They may be useful for many
people...
- one is AUTOSAR XML. Good for designing and storing many information,
supported by many tools, but really difficult and painful to analyze and
import/export (that is, I would not suggest it for a university small tool)
- one is XTC (http://www.interested-ip.eu/interfaces.html). it is an
exchange format for interfacing schedulability analysers to WCET tools.
It is currently supported by RT-Druid (http://erika.tuxfamily.org),
Symta/S (http://www.symtavision.com), AiT (http://www.absint.com), and
(probably) RapiTime (http://www.rapitasystems.com).
I guess the basic things that such a common format should have should be:
1- XML based
2- with open libraries at least in C/Java for reading and writing it
3- human readable (easy if you need to write a file by hand for some
experiments)
4- well documented
This thing does not exist yet I guess.
--BIASED ON---------------------
(Note: of course I'm biased on the following part since I was involved
in the file format definition)
The only pointer I can give in this case is to the file format we used
in RT-Druid, the RTD format.
Good things:
------------
- It addresses point 1 and 3 very well.
- About point 4, we will release soon an updated documentation on
http://erika.tuxfamily.org . Time is never enough for doing everything
we would like to...
- it is open source, EPL license
- the file format contains ways of storing many things, including
architectural and functional part, mapping, WCET, period, and so on.
- there are already backends to OSEK/VDX systems, an OIL compiler, and a
Papyrus UML importer (a video on this will be released soon)
- there is already an AUTOSAR XML importer
- there is already some editor for editing most of the parameters (it is
part of RT-Druid)
- we are actively working on this, and open to integrate with other
open-source tools :-)
Bad things:
-----------
- not yet well documented (but we could fix this in a few months)
- true it is open source, but it is probably too complex for a general
usage. still we are missing a general purpose library to ease the
navigation of the data structure which could be easy to integrate.
- some things are still left undefined or not very well specified in
particular the distributed part is completely missing.
--BIASED OFF--------------------
Ok, that's all for now.-..
PJ
--
Evidence S.R.L. - Paolo Gai, CEO http://www.evidence.eu.com
Tel: +39 050 991 1122 / +39 050 991 1224
Michael González Harbour
The XTC format seems an interesting solution, but the file specification
that you referenced requires a login. Is it public?
If we chose XTC, a metamodel would be needed to make it possible to do
automated format translation, from/to proprietary descriptions.
Best regards,
Michael.
El 26/07/2011 9:48, Paolo Gai escribi�:
--
Paolo Gai
Yes, XTC it is public.
Here are correct links where it can be downloaded:
In my mail I was also wrong. There are already other tools supporting
XTC, which are listed in the page. :-)
Regards,
Paolo
--
Michael González Harbour
I gave a quick look and it seems that XTC is not rich enough to
represent complex systems. For instance, it does not have provisions to
specify distributed systems (networks, network switches, messages, ...).
I don't see how to specify different schedulers, scheduler hierarchy,
scheduling parameters, mutual exclusion resources, ...
Did I overlook these issues?
Best regards,
Michael.
El 26/07/2011 10:43, Paolo Gai escribi�:
--
Moritz Neukirchner
fancy extensions for a standard modeling language because they need to
express e.g. algorithm-specific properties. The only way I see to solve
this, is to have a language that supports such extensions. However, such
extensions will again reduce inter-operability because no tool can be
required to support all extensions.
Best regards,
Moritz
--
Dipl.-Ing. Moritz Neukirchner
Institut für Datentechnik und Kommunikationsnetze (Institute of Computer and
Network Engineering)
Hans-Sommer-Str. 66
D-38106 Braunschweig
Germany
Tel.: +49 531 391 9659
Fax: +49 531 391 4587
E-mail: neuki...@ida.ing.tu-bs.de
Web: http://www.ida.ing.tu-bs.de/~neukirchner
-----Ursprüngliche Nachricht-----
Von: ecrts-...@googlegroups.com [mailto:ecrts-...@googlegroups.com] Im
Auftrag von Michael González Harbour
Gesendet: Dienstag, 26. Juli 2011 10:52
An: ecrts-...@googlegroups.com
Betreff: Re: WATERS 2011 - Post-workshop thoughts
Paolo:
I gave a quick look and it seems that XTC is not rich enough to represent
complex systems. For instance, it does not have provisions to specify
distributed systems (networks, network switches, messages, ...).
I don't see how to specify different schedulers, scheduler hierarchy,
scheduling parameters, mutual exclusion resources, ...
Did I overlook these issues?
Best regards,
Michael.
El 26/07/2011 10:43, Paolo Gai escribió:
> Sorry, I put the wrong link.
>
> Yes, XTC it is public.
>
> Here are correct links where it can be downloaded:
>
> http://www.absint.com/xtc/
>
> In my mail I was also wrong. There are already other tools supporting
> XTC, which are listed in the page. :-)
>
> Regards,
>
> Paolo
>
>
>
>
> Il 26/07/2011 10.13, Michael González Harbour ha scritto:
>> Dear Paolo,
>>
>> The XTC format seems an interesting solution, but the file
>> specification that you referenced requires a login. Is it public?
>>
>> If we chose XTC, a metamodel would be needed to make it possible to
>> do automated format translation, from/to proprietary descriptions.
>>
>> Best regards,
>>
>> Michael.
>>
Michael González Harbour
In my opinion we need a rich language, but it is not necessary that al
tools support all the elements. In our MAST description language we
support many modelling elements, but we can specify restrictions. For
instance, the model allows fixed priorities and EDF, but a particular
tool may be restricted to fixed priorities only. To solve this we have
operations to check that restriction: Fixed_Priorities_Only. Examples of
other restrictions are Monoprocessor_System, Simple_Transactions_Only,
No_Shared_Resources, ....
So the key is to have a rich modelling capability, and then each
analysis tool specifies its own restrictions with respect to the overall
model.
Best regards,
Michael.
El 26/07/2011 11:01, Moritz Neukirchner escribi�:
> I guess, this will be a general problem. People will always require some
> fancy extensions for a standard modeling language because they need to
> express e.g. algorithm-specific properties. The only way I see to solve
> this, is to have a language that supports such extensions. However, such
> extensions will again reduce inter-operability because no tool can be
> required to support all extensions.
>
> Best regards,
> Moritz
>
> --
> Dipl.-Ing. Moritz Neukirchner
> Institut f�r Datentechnik und Kommunikationsnetze (Institute of Computer and
> Network Engineering)
>
> Hans-Sommer-Str. 66
> D-38106 Braunschweig
> Germany
>
> Tel.: +49 531 391 9659
> Fax: +49 531 391 4587
> E-mail: neuki...@ida.ing.tu-bs.de
> Web: http://www.ida.ing.tu-bs.de/~neukirchner
>
>
> -----Urspr�ngliche Nachricht-----
> Von: ecrts-...@googlegroups.com [mailto:ecrts-...@googlegroups.com] Im
> Auftrag von Michael Gonz�lez Harbour
> Gesendet: Dienstag, 26. Juli 2011 10:52
> An: ecrts-...@googlegroups.com
> Betreff: Re: WATERS 2011 - Post-workshop thoughts
>
> Paolo:
>
> I gave a quick look and it seems that XTC is not rich enough to represent
> complex systems. For instance, it does not have provisions to specify
> distributed systems (networks, network switches, messages, ...).
> I don't see how to specify different schedulers, scheduler hierarchy,
> scheduling parameters, mutual exclusion resources, ...
>
> Did I overlook these issues?
>
> Best regards,
>
> Michael.
>
> El 26/07/2011 10:43, Paolo Gai escribi�:
>> Sorry, I put the wrong link.
>>
>> Yes, XTC it is public.
>>
>> Here are correct links where it can be downloaded:
>>
>> http://www.absint.com/xtc/
>>
>> In my mail I was also wrong. There are already other tools supporting
>> XTC, which are listed in the page. :-)
>>
>> Regards,
>>
>> Paolo
>>
>>
>>
>>
>> Il 26/07/2011 10.13, Michael Gonz�lez Harbour ha scritto:
>>> Dear Paolo,
>>>
>>> The XTC format seems an interesting solution, but the file
>>> specification that you referenced requires a login. Is it public?
>>>
>>> If we chose XTC, a metamodel would be needed to make it possible to
>>> do automated format translation, from/to proprietary descriptions.
>>>
>>> Best regards,
>>>
>>> Michael.
>>>
>>> El 26/07/2011 9:48, Paolo Gai escribi�:
Paolo Gai
The XTC Format is used by a tool to ask to a WCET Tool "Please give me
the execution time of this task". Nothing else.
The RTD file specification could be more useful for this. I attach a PDF
document describing it, which is a cut & paste of the manuals we have to
publish soon (RT-Druid was released open source just a week ago... no
time to convert all the previous docs to the public version yet).
Please give it a read if you want, maybe you can find it useful. It
currently only covers only single node, but it has tasks, resources,
functions, and so on, and it is fairly easy to read.
My proposal is that we could start from the RTD file format (or another
existing thing), cut the things we do not need, add the missing
things... What do you think?
Ciao,
PJ
--
Yassine
I have found this discussion by chance, I think you can find some answers of your questions at the following link:
http://www.lias-lab.fr/publications/14102/YassineOUHAMMOU_ThesisReport.pdf
Best regards
Le mardi 26 juillet 2011 11:45:16 UTC+2, Paolo Gai a écrit :
Probably I misunderstood the question... sorry.The XTC Format is used by a tool to ask to a WCET Tool "Please give me
the execution time of this task". Nothing else.The RTD file specification could be more useful for this. I attach a PDF
document describing it, which is a cut & paste of the manuals we have to
publish soon (RT-Druid was released open source just a week ago... no
time to convert all the previous docs to the public version yet).Please give it a read if you want, maybe you can find it useful. It
currently only covers only single node, but it has tasks, resources,
functions, and so on, and it is fairly easy to read.My proposal is that we could start from the RTD file format (or another
existing thing), cut the things we do not need, add the missing
things... What do you think?Ciao,
PJ
Il 26/07/2011 10.51, Michael Gonz�lez Harbour ha scritto:
> Paolo:
>
> I gave a quick look and it seems that XTC is not rich enough to
> represent complex systems. For instance, it does not have provisions to
> specify distributed systems (networks, network switches, messages, ...).
> I don't see how to specify different schedulers, scheduler hierarchy,
> scheduling parameters, mutual exclusion resources, ...
>
> Did I overlook these issues?
>
> Best regards,
>
> Michael.
>
> El 26/07/2011 10:43, Paolo Gai escribi�:
>> Sorry, I put the wrong link.
>>
>> Yes, XTC it is public.
>>
>> Here are correct links where it can be downloaded:
>>
>> http://www.absint.com/xtc/
>>
>> In my mail I was also wrong. There are already other tools supporting
>> XTC, which are listed in the page. :-)
>>
>> Regards,
>>
>> Paolo
>>
>>
>>
>>
>> Il 26/07/2011 10.13, Michael Gonz�lez Harbour ha scritto:
>>> Dear Paolo,
>>>
>>> The XTC format seems an interesting solution, but the file specification
>>> that you referenced requires a login. Is it public?
>>>
>>> If we chose XTC, a metamodel would be needed to make it possible to do
>>> automated format translation, from/to proprietary descriptions.
>>>
>>> Best regards,
>>>
>>> Michael.
>>>
>>> El 26/07/2011 9:48, Paolo Gai escribi�: