A common input format

All tools based on a system model that simulate it and/or generate traces
E.g.: simulation or trace generation of an entire system, of a task set...
Post Reply
Sophie Quinton
Site Admin
Posts: 52
Joined: Tue Apr 28, 2015
Location: Inria Grenoble - Rhône-Alpes, France
Contact:

A common input format

Post by Sophie Quinton » Tue Nov 17, 2015

At WATERS'15 we had a lengthy discussion about a common input format for simulation tools. This topic is meant for discussing this issue. Share your experience/opinion/proposal!

Best,
Sophie
Sophie Quinton
INRIA Grenoble - Rhône-Alpes
655 Avenue de l'Europe - Montbonnot
38334 St Ismier Cedex - FRANCE
tel: +33 4 76 61 55 31
https://team.inria.fr/spades/quinton/

oliviercros
Posts: 2
Joined: Tue Jul 07, 2015

Re: A common input format

Post by oliviercros » Wed Nov 18, 2015

Hello,

As a basical state of the art to improve this topic, I started to build a list of already well-known existing real-time simulation tools, in order to focus particularly on the way they modelize input and output informations. I splitted, for now, tools in two parts : processor-oriented, and network-oriented. Currently, I obtained the following informations for processor-oriented tools (tool/input-output modelization/development language) :

Cheddar - XML/AADL - Ada
Fortas - XML - Java
SimSo - Python - Python
Yartiss - XML - Java
TimeWiz - Unknown - Unknown
RapidRM - Unknown - Unknown
MAST - MARTE/XSD - Unknown
CPAL - Unknown - Unknow

I suggest from all the users and readers to contact me about this subject (cros@ece.fr), if you want to ask me questions or to bring some more informations about tools you use or develop inside a specific RT context. I'll be please to add your tool to this list or to precise already existing informations.

The main purpose is to build, first, a global view of each way of modelizing datas in different RT simulation tools, in order to focus on the specifical needs of each and then to integrate these needs inside a common input format.

Sophie Quinton
Site Admin
Posts: 52
Joined: Tue Apr 28, 2015
Location: Inria Grenoble - Rhône-Alpes, France
Contact:

Re: A common input format

Post by Sophie Quinton » Wed Nov 18, 2015

Hi Olivier,

Thanks for getting the discussion started! Could you edit your post to add links to the websites of the tools you mention? That'd be really helpful. I know some of them but not all.

Thanks,
Sophie
Sophie Quinton
INRIA Grenoble - Rhône-Alpes
655 Avenue de l'Europe - Montbonnot
38334 St Ismier Cedex - FRANCE
tel: +33 4 76 61 55 31
https://team.inria.fr/spades/quinton/

User avatar
erk
Posts: 2
Joined: Wed Jul 08, 2015
Location: Toulouse, France
Contact:

Re: A common input format

Post by erk » Thu Nov 19, 2015

Hi everybody,

Very interesting initiative.
In our SchedMCore tool we use a relatively simple text task file format (TFF).
You'll find our usage description in the file attached to the current post.

--
Eric NOULARD, ONERA/DTIM/LAPS, ONERA - Centre de Toulouse
http://www.onera.fr/dtim
2 avenue E. Belin, B.P. 74025, F-31055 Toulouse Cedex 4, FRANCE
tel: +33 (0)5 62 25 26 38, fax: +33 (0)5 62 25 25 93
Attachments
lsmc-TN002-taskfileformat.pdf
(215.46 KiB) Downloaded 180 times
Eric NOULARD, ONERA/DTIM/LAPS, [url=http://www.onera.fr/dtim]ONERA - Centre de Toulouse[url],
2 avenue E. Belin, B.P. 74025, F-31055 Toulouse Cedex 4, FRANCE

medinajl
Posts: 9
Joined: Fri Jun 26, 2015

The MAST model as an input formalism for simulation and response time analysis tools.

Post by medinajl » Thu Feb 04, 2016

Dear all,

There are many ways to do simulation. For those who may see it as a way to observe emergent behavior of a system whose timing models can be extracted and used to get some data about the response times for its tasks, let me comment that the imput model of MAST (a suite of tools for doing response time analysis through schedulability analysis) can also be used for this kind of simulation.

If you like you are invited to use the MAST topic to discuss, exchange ideas and evaluate the usage of its input meta-model/schema/format as a means to collect and compare design intents expressed in terms of their relevant timing models. The underlying meta-model for these timing models is very close to the one used in the UML profile for MARTE, though it can be expressed in a much simpler way. The concrete formats available include an ad-hoc text file, an equivalent XML textual representation, and the XMI of the corresponding ecore meta-model.

The MAST model scales very well from simple single-processor tasking models to fully distributed chains of tasks with or without precedence relationships. It includes forks, joins, branch and merges, delays, offsets, shared resources, hierarchical scheduling, and most of the analysable scheduling policies, RT network protocols, and protection protocols. As I mentioned it is used to do response time analysis by means of both, schedulability analysis, and simulation tools.

If there is interest on it, in a next post we can make a quick rational for its structure and present some flexibility concerns.

To get a closer look please check the MAST documentation (http://mast.unican.es).
Please refer to the MAST description document (http://mast.unican.es/mast_description.pdf) to get a better view of the elements that form the timing models in MAST.

martinamaggio
Site Admin
Posts: 6
Joined: Tue May 05, 2015
Contact:

Re: A common input format

Post by martinamaggio » Tue Jul 05, 2016

During WATERS'16 there was a mention of updates on this topic. It seems that there is something interesting to discuss, as there was a need (for example) to clarify terminology used differently. Any updates on the initiative?

User avatar
iceslj
Posts: 6
Joined: Wed Jul 01, 2015
Location: Verimag @ Grenoble

Re: A common input format

Post by iceslj » Mon Jul 11, 2016

Yes, we are defining formal semantics for the terminology of real-time systems. We have built a formal library in Timed Automata, which consists of a set of automata templates, including Task Activation, Job, Scheduler, etc. For example, Task Activation represents the attributes on tasks' activation, including Offset, MinInterval, jitter, etc. The formal library is extensible, as new attributes can be added into a corresponding template. Given a concrete system, a network of Timed Automata is instantiated with the parameters of the system. Then the WCRT of each task can be computed through model checking. Other properties can also be computed, such as the number of deadline misses. In summary, the formal library serves three purposes: (1) as the formal semantics of the existing terminology; (2) as a modular and extensible framework for incorporating new terminology; (3) as a framework to facilitate exact schedulability analysis through model checking.
Lijun SHAN
E-mail: lijun.shan@imag.fr.
VERIMAG
2, Avenue de Vignate
Centre Equation
F - 38610 GRENOBLE - Gières, FRANCE
Phone : (33) 04.56.52.03.76

martinamaggio
Site Admin
Posts: 6
Joined: Tue May 05, 2015
Contact:

Re: A common input format

Post by martinamaggio » Fri Jul 15, 2016

I am very interested in (1) and (2). During the WATERS discussion, it was clear that there was a lot of terminology clarification going on while you were developing the library. When you have some writing on the matter, please share it here. And if anybody has additional thoughts, it would be good as a starting point for some "terminology standardization" effort.

Post Reply