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) due to misunderstandings between reviewers and authors. We hope that this document will help improving the average quality of the submitted papers.

Some rules are mandatory (e.g., the page limit) and if the paper does not comply with these, it will be rejected without review. Other points are just suggestions for organizing and structuring the paper. 

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.

• Suggestions for Authors
• Page Limits
• Originality
• Presentation
• Evaluation

Is there a page limit? Is there a specific format for submissions?

Yes; see submission page for details.

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 (beyond the pages of main body text permitted by the page limits) 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 (via an email to the PC Chair), so that we can make it available to the reviewers; this is to enforce anonymity of the reviewers.

Note that the additional material in the technical report will not be published in the proceedings and will only be read at the reviewer's discretion.  Remember that reviewers must evaluate your paper and not the technical report.  If the reviewers think that the paper contains insufficient material to be published, then the paper may be rejected, regardless of the contents of the technical report.  Furthermore, reviewers are not obliged to read material in the technical report; therefore, authors should not assume that this material will be examined during the reviewing process.

How do I convince the reviewers that my approach is actually a good approach?

The paper should clearly state the research problem, together with information about the key contributions. A good example of this is to have a clear explanation of the problem in the introduction, together with a well-balanced positioning of why this problem has not been completely solved before. A poor example is to just describe an implementation without saying anything about why this implementation exists or which problem it actually tries to solve. Without this information, the reviewers are left guessing what the actual problem is, which may lead to significant misunderstandings.

You should aim to clearly explain the relationship between your work to the existing state-of-the-art in terms of related work. Make clear where you have built on existing results and the key differences between the proposed approach and those that have been published previously, including prior work of your own. Also consider adding a short paragraph in the conclusions where you briefly summarize the main innovative technical contributions of the paper.  

Additionally, the technical contributions of a paper must have a solid scientific basis. If your paper contains theoretical work, you should present mathematical proofs of correctness. If the paper contains new algorithms, system design or methodology, or applications that improve on existing state-of-the art (or even regarding a completely new field), you should consider adding an "Experimental Evaluation", "Simulation", and/or "Case Study" section to provide evidence of scientific advancement.  As well as explaining the advantages of your new approach with respect to the state-of-the-art, also give a balanced view of its disadvantages. This is generally well appreciated by reviewers, and preferable to leaving it to the reviewers to point out any shortcomings.

How do I convince the reviewers that my work is actually new?

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 review effort. Check that your paper has enough new material with respect to other papers you published or submitted to other conferences/journals. Including material from a 4 or 6 page work-in-progress or workshop paper that has been published is usually fine, provided that it does not have a DOI, or at least 30% new content has been added. Nevertheless you should include a citation to that preliminary publication and explain its relationship to the paper.

How important is writing quality?

The quality of the writing in the paper is very important. The main goal of a paper is to communicate the technical aspects of the work to other people. If the paper is not written in correct English, reviewers may not be able to understand the merits of the paper. Therefore, it is more likely that your paper will get a low score on the technical aspects as well as on the presentation. Take some time to review the presentation of your paper. Automated spelling and grammar checkers can help avoid many minor mistakes. As well as proof reading your paper a number of times yourself, it is recommended that you ask other good writers among your colleagues for their comments and opinions on it. The submitted paper must already be correct. After it has been reviewed is not the time to make corrections to the writing.

Make sure that any notation used is clearly defined and distinct (don’t use symbols that can easily be confused with one another). Over the years, a de-facto standard notation has developed that is used in many real-time systems papers. Where possible try and stay with this common notation as it gives reviewers familiar with it far fewer new things to remember when they read your paper. The best place to define terminology and notation is together in a section called “system model, terminology and notation” or something similar. This gives reviewers a single place to refer back to where they can find any symbols they need to look up again. If you have a large amount of notation in your paper, consider providing a table of notation. Make sure you define all notation and acronyms before they are used.

Make sure that all of your figures, diagrams and graphs are legible when printed out in black and white. (This is the way most reviewers look at the papers and most likely the way they will appear in the printed proceedings). Avoid the temptation to make your figures the size of a postage stamp or thumb nail in order to fit your content into the page limits. Figures should normally fill the column width. Make sure the different lines on the graphs are clearly distinguishable by using markers that are obviously different and where necessary using different line types (e.g. dashed, dotted). Make sure the text on the graphs is legible and not too small.

How important are the system model and assumptions?

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. A proper experimental evaluation may take the form of an implementation of a real system, or via the use of data from case studies, benchmarks or models of real systems. The use of synthetic workloads or models is permitted, but authors are strongly encouraged to properly motivate and justify the choices made in designing their synthetic evaluation. 

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 necessary to describe the experimental setup, including details of case study or benchmark data (or where it can be obtained) and how synthetic data (if used) has been generated. If you are reporting statistical data, then make sure you present measures pertaining to the quality of the results obtained, for example confidence intervals, or variance.

To aid in the reproducibility of results, consider also making your evaluation code available by uploading it onto your web page or institution’s repository and including a reference and URL to it in the submitted paper. Note this is not compulsory but is well appreciated by the community.

Authors are expected to compare their work with the existing state-to-the-art to show the size, scope and significance of the improvements they have made. Experimental evaluations should seek to cover as broad but realistic range of parameters and cases as possible, giving a balanced view of performance, where possible with respect to existing work. Authors should avoid selecting specific cases where there may be a bias in favor of their approach.

My paper does not contain new theorems, nor new schedulability theory. Is it appropriate to ECRTS?

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.