How to write a paper…

Andrew Alleyne

A technical paper is a very important piece of work that documents your accomplishments on a particular problem and presents it to a research audience. One of the key things to remember when writing a paper is that someone is eventually going to read it. Therefore, the writer should keep in mind the perspective of the reader as s/he puts the efforts down on paper. Quite often the student writes a paper from their point of view of doing the current research. Therefore, they often have a tendency to overemphasize what they are currently working on or a part of the research problem that they found particularly challenging. 5 years from that, the part of the problem the student may be currently focusing on may not be the most important part of the problem when looked at as a whole. Essentially, the paper should provide the future reader with a solution to a problem as well as a framework for reproducing that solution should the reader so desire. There is a delicate balance between including extraneous information versus providing enough to get the point across. Since the medium of a technical paper is often some type of technical framework, it is often advantageous to represent concepts and facts in a concise manner. This may involve equations, graphs or figures instead of textual description. In this case, unfortunately, the best teacher is often experience.

A good guideline for the general flow of a technical paper is as follows. Note that the section titles need not be the same as the ones you’d actually use in your paper.

ABSTRACT:

The abstract should give a brief overview of the main points or contributions of the paper. This should be around 200 words or so. It should describe what was done; not necessarily why or how. From the point of view of the reader, if the abstract describes that something interesting or worthwhile was done then the reader will continue reading the rest of the paper (or find the paper if it’s an electronic search) to determine the details.

INTRODUCTION:

This section provides a motivation for the particular problem under study and gives a background as to what has been done before on this problem or similar problems. The motivation tells why the problem is an important one to look at and justifies the efforts that will be described. The background provides references and discussions that put the proposed work in perspective and context with other previous investigations on the topic. This is important because research is never done in a vacuum. Even if you think you are working on something that nobody else is working on, there must have been some previous building blocks to get you to the stage of research you’re currently at. A good understanding of previous work that has been done gives your work more credibility because it indicates that you know the state of the art and have been able to make a clear contribution that adds to it.

The introduction should finish up with a brief paragraph alerting the reader to what else will be coming in the rest of the paper.

SYSTEM DESCRIPTION/MODELING:

This section will differ slightly depending on whether the paper is more theoretical or more applications-oriented.

For a more applications-oriented paper, this section should begin with a technical description of the system to be studied. This technical description differs significantly from the functional description that would appear in the Introduction. The technical description involves the equations of motion that describe the system model. It also involves the assumptions that were made in setting up the system model. If it’s a complicated system then the modeling can be broken up into subcomponents and each sub-model presented separately. Towards the end of the section, a series of equations/tables/curve fits should be available to the reader that describes the system equations of motion in a form suitable for controller design. This section should end with a verification of the system model by simulation. The simulation of the system description would be compared to data taken from the actual system and hopefully the two sets of data would match. If not, maybe it’s a bit premature to be writing this paper. If the simulation model is not sufficient, and you still want to write the paper, there should be a clear explanation or conjecture of why the model matching did not occur.

For a theoretical paper, this section will be a bit shorter. It will basically introduce the class of systems to be examined. An example system can also be introduced if necessary. If there’s a particular advantage to the theoretical approach you will be presenting later in the paper versus existing control methods, now would be a good time to perhaps point out the shortcomings of the existing methods. This can be done either analytically or by simulation demonstration using the example system that represents your class. It is possible to also wait to show the shortcomings of existing methods until you do a comparison between them and your method in a later section of the paper.

METHODOLOGY:

In this section, you should be presenting the control solution methodology that you will be applying to either the specific system described above, or to the class of systems that you are considering. There would be no results presented here. If it were an applications-oriented paper, here’s where you would go through the controller design process using whatever tools you choose: Adaptive controls, LQ, LQG/LTR, Robust control, etc. The controller design would use the system model to come up with a proposed control algorithm. For a more theoretical paper, this section would consist mostly of the proof of stability or convergence or disturbance rejection associated with your new method.

Basically, this section should contain your main analytical results independently of whether it is applications or theory.

RESULTS:

For an applications oriented paper, this section would first present simulation results using the controller designed in the methodology section on the model verified in the modeling section. Subsequently, you would present the experimental results on the actual system. The results from the simulation implementation and the experimental implementation should match; at least qualitatively. If they do not match, there should be a clear explanation of why. If it’s due to model uncertainty (usually the case) you should explain where the uncertainty is likely to be occurring and what you plan to do about it. The same goes for sensor/actuator issues. At the end of this section, the reader should now know that (a) you’ve looked at a relevant problem, (b) you’ve come up with an appropriate representation for that problem {transfer functions/state space/whatever}, (c) you’ve figured out a good solution procedure for tackling that particular problem, and (d) your approach has been verified both in simulation and experimentally. This means you were looking at the right problem with the right solution methods and it works. Moreover, there is a very consistent thought process that went into getting the final solution being presented.

If the paper is more theoretical, this section could have simulation results for a particular example. If so, it should include a comparison with another relevant methodology from the existing literature to point out the benefits of your approach. The thought process is similar to the applications oriented paper: (a) you’ve looked at a relevant problem, (b) you’ve figured out a good solution procedure for tackling that particular problem and analytically proved it should work, and (c) the benefits of your approach have been verified against existing approaches. This means that you’ve looked at a problem, or class of problems, and come up with a solution that will advance the field of controls. Even if the advance is only a relatively small one, it’s still important because that’s the way research gets done; something on the order of the Internal Model Principle isn’t discovered every day.

During this results section, it’s important not to overwhelm your reader with too many figures. There should be sufficient to get the point across that your method is appropriate for the problem you selected but no more. Since pages are scarce, particularly for journals, excessive figures can actually detract from the validity of your work at a first glance. If it’s a journal paper and the reviewers come back and ask for more data, then you can add it at that time. As was mentioned before, recognizing when you’ve sufficiently demonstrated the concept is a ‘gut’ feeling that is often developed through experience and writing a lot of papers.

CONCLUSIONS:

This section is a wrap up of the paper. However, it’s more than a compact regurgitation of what’s been presented in the paper. This is the opportunity to tell the reader what key concepts s/he should have learned by reading the paper. It should emphasize the main results and why they were important. Moreover, it should reiterate why the work that was done represents a contribution to the field.

The conclusions are also a good place to mention brief plans for future research work. If there are discrepancies between the simulation and experimental data, this would be an appropriate place to say what will be done in the future to eliminate them.