A common input format

[Sophie Quinton]

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

[oliviercros]

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]

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

[erk]

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

[medinajl]

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]

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?

[iceslj]

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.

[martinamaggio]

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.