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 rules are 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 structuring the paper. If the authors prefer to organize their paper in a different way, as long as the paper is appreciated, it will 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 after you clicked on the "submit" button, you may still update the submitted paper until the final deadline.
The paper must be in the same format as in the final published proceedings, i.e. 10 pt, two columns, 10 pages maximum. Word and Latex templates for formatting you paper can be found here. (Note: the conference will use US Letter (8.5" x 11") trim size.) Note, a full page of text (no headings) should not have more than 59 lines. Papers exceeding the page limit will not be considered for review. Also, please help the reviewers by putting on page numbers for the review version.
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).
Notice that the additional material in the technical report will not be published in the proceedings. Therefore, you are completely free to submit it to some journal or conference.
As a final note, remember that reviewers must evaluate your paper and not the technical report. If reviewers think the paper contains insufficient material to be published, then the paper might be rejected, regardless of the contents of the technical report. Please note that reviewers are not obligated to read material beyond the ten-page limit; additional material in a technical report may or may not be examined.
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 summarize 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 aspects of the proposed research work. If the paper is not properly written in English, reviewers may not able to understand the merits of the paper. Therefore, it is more likely that 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 of your paper (and possibly ask other good writers for their comments/opinions). 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 (who may not be an 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 on presenting the system model, describing accurately notation and nomenclature, and discussing the assumptions and limitations of your model.
Is it mandatory to have experimental evaluations in the paper?
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 randomly generated data has been generated, etc. If you are reporting statistical data, make sure you present measures pertaining to the quality of your obtained 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 controlled 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 in realistic systems, and real-time operating systems implementations. This is because we believe that our community needs to validate the proposed assumptions and methodologies with respect to 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 systems community?" where the term "community" includes people from academic institutions and from industry. Therefore, it is important for the paper to contribute 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 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 (simulation-based 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 the methodology for non-experts, etc.
Of course, there are many examples of this kind, and we cannot be exhaustive in listing all possibilities. So, if your paper does not fit any of the above examples, it may still be appropriate for ECRTS.