Suggestions for authors
This document lists a set of suggestions for writing papers that are likely to be appreciated by the reviewers of this conference. The motivation for this document is that many times good papers fail to be appreciated (and hence accepted) for "misunderstandings" between reviewers and authors. We hope that this document will help improving the average quality of the submitted papers.
Some rule is mandatory (i.e., the page limit) and if the authors do not comply the paper will not even be considered for review. Other points are just suggestions for organizing and stucturing the paper. If the authors prefer to organize their paper in a different way, as long as the paper is appreciated, it is likely be accepted anyway.
This document is in the form of a FAQ. You can use it as a checklist and go through it while writing your paper and before the submission. Remember that you can re-submit updated versions of the paper until the deadline. So, if you realize there is something wrong just you clicked on the "submit" button, you may still update the submitted paper until the final deadline.
Summary
- Is there a page limit? What is the format for submissions?
- My paper does not fit within the page limit. Can I leave proofs and other details out in a appendix?
- How do I convince the reviewers that my approach is actually a good approach?
- How do I convince the reviewers that my work is actually new?
- How important is to check the paper for english?
- How important are system model and assumptions?
- Is it mandatory to have experimental evaluations in the paper?
- My paper does not contain new theorems, nor new schedulability theory. Is it appropriate to ECRTS?
Page Limits
-
The paper must be in the same format as in the final published proceedings, i.e. 10 pt, two columns, 10 pages maximum. Guidelines for formatting you paper can be found here. For your convenience, you can also download a document containing this instruction in PDF format; and a zip archive containing the style files to be used with Latex. Papers exceeding the page limit will not be considered for review. -
My paper does not fit within the page limit. Can I leave proofs and other details out in a appendix?
The general idea is that the submitted version of your paper must contain the same amount of information that, in case of acceptance, will go in the final proceedings. Therefore, if you have additional material that you want to make available to the reviewers, but that will not go into the final proceedings, then you must:- Write a technical report, that can be of any length and any format, containing the additional material;
- Make the tech report available on your web page or in a web site of your institution;
- When you submit the paper, you must submit also the tech report, so that we can make it available to the reviewers (this is to enforce anonymity of the reviewers).
As a final note, remember that the reviewer must evaluate your paper and not the technical report. If the reviewer thinks the paper contains insufficient material to be published, then the paper might be rejected, regardless of the contents of the technical report. -
The paper must be grounded on solid scientific basis. If your paper contains theoretical work, you should present mathematical proofs of correctness. If the paper contains new algorithms, techniques and methodologies that improve on existing state-of-the art (or even regarding a completely new field), you may consider adding an "Experimental Evaluation" section or a "Simulation" section. -
A good idea is to add a short paragraph titled "Contributions of this paper", in which you briefly summarizes the innovative technical contributions of the paper. Also, make sure you make a good comparative analysis with the state of the art.
Please, remember that double submissions are unacceptable because they could compromise the requirement for originality of the paper, and effectively duplicate the costly process of paper review. Check that your paper has enough new work with respect to other papers you published or submitted to other conference/journals. -
Very important. The main goal of a paper is to make other people understand the technical aspect of the proposed research work. If the paper is not properly written in english, the reviewer may not able to understand the merits of the paper. Therefore, it is more likely your paper will get a low score also on the technical aspects (and not only on the presentation).
Take some time to review the presentation aspects (and possibly ask some expert). The submitted paper must already be correct. The final paper is not the place to make the English corrections. -
Very important. Once again, keep in mind that the reviewer (which could be not very expert in your specific domain) has to understand the technical content of the paper. Therefore, spend a paragraph or a subsection or even a section to present the system model, to describe accurately notation and nomenclature, and to discuss the assumption and limitations on your model. -
No, although in many cases it is strongly suggested. If you are going to add an "Experimental evaluation section", make sure you do it properly. The basic idea is that a reader of your paper should be able to reproduce your experiments and obtain the same results. Hence, it is not sufficient to just put a figure with a one line comment. Instead, make sure to describe the experimental setup, the way random generated data has been generated, etc. In case you are reporting statistical data, make sure you specify the confidence you obtained on the data (confidence intervals, variance, or else).
Finally, there is a clear distinction between Experimental Evaluation and Simulation. The first is done on a real-system under a controller set of scenarios; the second is done on a simulated system. Please, use the proper terms when describing your evaluation. -
We particularly encourage submission of papers on industrial case studies, application of real-time technology on realistic systems, real-time operating systems implementations. This is because we believe that our community needs to validate the proposed assumptions and methodologies on realistic applications.
How will we evaluate these papers? The questions the reviewer will be asked to answer are: "did you learn something from the paper?", "is this paper useful to the real-time system community?" where the term "community" includes people from academic institutions and from industry. Therefore, it is important the paper contributes to the community by presenting interesting, non trivial and novel results (not necessarily theoretical). Typical examples:- a case study of applying real-time techniques in the design and implementation of a realistic application) that reports problems and solutions to practical problems that were not directly addressed by the theory;
- an implementation of one (or more) scheduling algorithms on a operating system, showing the impact of hardware mechanisms on the performance of the algorithms and system overhead;
- a study (simulative or experimental) on the impact of current and future hardware architectures on applications and operating system mechanisms;
- a study of the application of formal methods to realistic applications: limits of the model, performance of the methodology, difficulty of applying methodology for non-experts, etc.