Editorial Policies

Focus and Scope

The Journal of Software Engineering for Robotics (JOSER) is a peer-reviewed journal that publishes two issues a year in March and September. It aims at disseminating high quality scientific and technological research results in the area of robot software development. It publishes both empirical research papers, where the effectiveness in the Robotics domain of existing Software Engineering approaches and methods is evaluated and demonstrated, as well as theoretical contributions that present new Robotic-specific software development results.

The following guidelines serve as a concrete list of evaluation points for reviewers and thus are meant to help authors to prepare submissions with the highest chance of acceptance.

Presentation

Papers must be concise and complete; manuscripts should be carefully proofread and polished. Submissions that do not meet these criteria may be returned unreviewed.

References to standard definitions

Authors should not give their own definitions of well known software engineering concepts, such as modularity, reusability, interoperability, portability, software architecture, class library, middleware, framework, component, object, design pattern, interface, extreme programming, etc. These concepts are already clearly defined in several Software Engineering publications and Computer Science ontology. Authors should refer to these definitions and use them consistently throughout their papers. Authors are welcome to refine these definitions in their specific context (e.g. robotic component), but the new term should be consistent with the meaning of the more abstract term (e.g. component).

In case the authors find those standard definitions not adequate to express their concepts, they should motivate the use of the same term with a different meaning.

Authors should also avoid the use of ambiguous terms, e.g. software tool, software module, and prefer more concrete ones, e.g. Integrated Development Environment, class library, object, component, etc.

Authors should also pay special attention to the meaning of some frequently misused terms, such as method, methodology, technique, approach, development process.

Many terms, such as modularity, reusability, interoperability, ease of use and portability are very generic; authors should always be explicit about what kind of reusability, for example, their work is addressing: source code reusability; for the same kind of robot devices or robotic application; with or without a dependency on particular choices of data structures, programming languages, or middleware; etc.

Graphical notation and code documentation

Authors should use UML as preferred graphical language to represent the properties of the software systems described in their papers. Use of other standard modeling languages (e.g. SysML, Marte, AADL) will also be positively evaluated.

If authors need to use different graphical notations, they should motivate why existing standards are not sufficient for their purpose and specify the semantics of all elements (box, arrow, dashed line, colors, labels, etc.) used in their diagrams.

Authors should avoid inserting code fragments in their manuscripts and are invited to submit their source files as supplementary material.

Source code should be inserted in the manuscript only in the case authors are describing the syntactical features of, for example, a new (robotics-specific) programming language.

Technical quality

All claims should be clearly articulated and supported either by empirical experiments or theoretical analyses.

Motivation, context

Authors should describe the motivations that led them to the research documented in the paper, and justify why they believe the reader should adopt the presented software engineering concepts and solutions.

Authors should also be careful to circumscribe the robotics context in which their results can be applied; for example, industrial service robotics, mobile manipulators with a non-holonomic base, indoor collision-free navigation, etc. Equally important is a discussion of the limits of applicability; for example, the if presented solution is not thread safe, or cannot be used when hard realtime service is required.

Review of the state of the art

State-of-the-art approaches and solutions should be assessed according to objective and, preferably(!), measurable criteria. Authors should avoid statements like “xxx appears to be the best robotic middleware” or “yyy is a great tool for rapid prototyping”.

Background

Authors should focus their papers on the software engineering aspects of their project, but should also provide any useful information about the experimental setup. For example, this may include, if appropriate, an overview of the robotic hardware, of the operational environment, and the performed tasks.

Similarly, the authors are encouraged to clearly describe the relevant technologies that have been used: the operating system release, the compiler version, the middleware infrastructure, etc.

Relevance

Authors should clearly illustrate the robotics software engineering message they want to convey to the readers. Authors are strongly encouraged to explicitly mention if their paper is:

  • a research paper addressing a specific software development problem (e.g. defining criteria to assess software quality attribute of a robotic system, defining an ontology of robotic specific software entities, defining a method to analyse software variability in robotics, etc);

  • an experience report on the use of software engineering concepts and solutions in robotics (e.g. extreme programming, agile development, aspect-oriented design, model-driven engineering, etc.). The experiences should be presented in a way that all other readers can directly profit from the lessons learned by the authors;

  • an evaluation report on using commercial (e.g. Microsoft Robotics Studio) or open-source (e.g. Player/Stage) software tools. Evaluations should try to reach the highest possible level of reproducibility and good experimental practices;

  • a technical report that documents the development of a concrete robotic systems with decision points and trade-offs related to all software artefacts, from requirements and architecture design, through detailed design and implementation, to testing and deployment.

  • a survey paper of the state-of-the-art in a particular aspect of software engineering in robotics (e.g. robotics-specific middleware);

  • a motivated suggestion for a concrete software standardization initiative.

Note that this list is not exhaustive.

Descriptions of pure sensor processing, planning or control functionality should be limited to the extent necessary to introduce the software engineering problem and solution that are described in the paper.

The content of a paper is relevant to JOSER if it documents, when appropriate,

  • issues and challenges in the development of software systems (applications, frameworks, middleware), that make the robotic domain similar or different to other application domains (e.g. automotive, factory automation). In case of similarity, the paper must make concrete suggestions about how this similarity leads to direct improvements of the robotics software engineering practice. In case of difference, the paper must make clear where this difference poses new software engineering challenges, and how these challenges have been tackled.

  • software quality requirements that have been taken into account (portability, reusability, maintainability, interoperability, etc.).

  • robotics quality attributes that make the authors’ work immediately useful in the industrial practice (robustness, embeddability, ability to cope with existing legacy).

  • software architectures that help to integrate all aspects of robotic systems.

  • software models that lead to reusable robotic software design and that may enable measures and procedures to evaluate software quality factors.

  • metrics and methods that allow the assessment of software quality factors of robotic systems.

  • computational issues related to the implementation of robotics algorithms.

  • software environments and tools that simplify the design, implementation, and reuse of robot software architectures.

  • case studies of successful software development for real robotic systems. The paper should clearly explain why the development was successful, and what are the lessons learned that other readers should apply in their own systems.

Significance

Papers should report on what was learned in doing the work, rather than merely on what was done.

  • Where does the work fit in the development of robotic software systems and applications?

  • What problem/deficit/need does it address?

  • What other work has been done in this area, and why is this contribution important?

  • What software engineering concepts and solutions does it build on?

  • What are the technical and managerial issues related to building robotics software systems and applications?

  • Is the emphasis on integration of existing work, or on new work? If it is on new work, why has the reuse of existing solutions not been possible?

  • Who are the potential users of the work?

When appropriate, authors are encouraged to demonstrate the utility of their work on significant problems and its scientific and economic impact in the robotic industrial practice; any experiments reported should be reproducible.

Originality

Authors should explicitly indicate the novelty of their work with respect to the state-of-the-art and, if relevant, to their previous publications.

 

Section Policies

Regular Papers

Detailed discussion involving new research, applications or developments. There is no length limit on regular papers. The nominal length is 10 single-spaced, double column pages including figures and bibliography. However, it is recommended that papers not exceed 15 single-spaced, double column pages. Papers that exceed this recommended maximum length will still be considered, but might not be guaranteed editorial review or publication in a timely fashion.

Checked Open Submissions Checked Indexed Checked Peer Reviewed

Short Papers

Brief presentations of new technical concepts and developments. Short papers should not exceed 6 single-spaced double column pages including figures and bibliography.

Checked Open Submissions Checked Indexed Checked Peer Reviewed

Comments

Comments are brief contributions that comment on previously published papers. These may include reports on

  • exploitation and validation of research results
  • interpretation of experimental data
  • opinions about open issues

Comments should equal 4 single-spaced double column pages (including reasonably sized figures and references).

Checked Open Submissions Checked Indexed Checked Peer Reviewed
 

Peer Review Process

Papers are reviewed and evaluated according to the following criteria.

  • Relevance. Descriptions of pure sensor processing, planning or control get a lower score than documentations of (1) software architectures that help to integrate these core aspects of robotics, (2) software requirements that have been taken into account (portability, reusability, maintainability, interoperability, etc.), (3) metrics and methods that allow to assess software quality factors of robotic systems, or (4) computational issues related to the implementation of robotics algorithms. Papers should report on what was learned in doing the work, rather than merely on what was done.
  • Significance. Descriptions of ad-hoc software library/framework/middleware for specific robotic systems get a lower score that documentation of reuse/adaptation/reengineering of existing software artifacts. When appropriate, authors are encouraged to demonstrate the utility of their work on significant problems; any experiments reported should be reproducible.
  • Originality. Contributions to relevant standards, benchmarks, software patterns as well as their adoption in novel application contexts are positively evaluated.
  • Technical quality. Use of standard modeling languages (e.g. UML, SysML, Marte, AADL) is positively evaluated as well as motivation why existing standards are not sufficient for the authors’ purpose. All claims should be clearly articulated and supported either by empirical experiments or theoretical analyses.
  • Presentation. Papers must be concise and complete; manuscripts should be carefully proofread and polished. Submissions that do not meet these criteria may be returned unreviewed.

JOSER has a commitment to rigorous yet rapid reviewing.

  1. When a paper is submitted to JOSER, it is first read by the Editor-in-Chief (EIC). If the EIC finds that the paper is very clearly below the standards of the journal or not in its scope, then the paper is rejected immediately, without written review.
  2. The EIC then assigns the paper to an associated editor (AE) who has expertise in the area of the paper. If the AE finds that the paper is very likely to be rejected on full review, the AE will write a single short review explaining that position, and the paper will be rejected.
  3. The AE then assigns the paper to three reviewers. The reviewers will include at least one specialist in Robotics area and at least one in Software Engineering. The reviewers will write detailed technical reviews of the paper, which are returned to the AE.
  4. Possible decisions are Accept, Conditionally Accept, Revise and Resubmit, or Reject. Conditionally accepted papers may still require minor revisions, which will be checked by the AE. A resubmission reccomendation should not be interpreted as any sort of guarantee of acceptance upon resubmission.
  5. Authors receive first notification of the publication decision within six weeks upon paper submission.

 

Open Access Policy

This journal provides immediate open access to its content on the principle that making research freely available to the public supports a greater global exchange of knowledge.