Developing firmware for motion control systems can be a tricky business. Strict accuracy and repeatability combine with user safety to present a challenging set of requirements. How do you go about designing motion control firmware to meet these requirements properly? And how can you ensure the resulting implementation is tunable and testable from the start? In using what are some key design methodologies and the beginnings of a framework for safe, testable and tunable motion control firmware, it is important to consider the design goals.

Safety concerns vary by the industry for which you write firmware. In such application areas as medical devices and aerospace systems, safety is the critical priority. How a system handles failures from a safety perspective might vary. For example, in a medical device that uses motion control, if there is a systematic failure, the system must fail in a manner that will keep the patient or user safe. This may simply be to invoke an electromechanical interlock and alert the operator. In other cases, a failure in the system may not be as simple as shutting down, and so the events that take place following a failure must be well defined.

The testability of a motion control system starts with good architecture, and the firmware plays a key role. Test engineers must have the ability to verify all software modules to ensure correct behavior. One of the most common mistakes is testing with only valid (i.e., in range) inputs. The real key to testing is subjecting the system and/or its various modules to invalid inputs and ensuring the system behaves correctly and safely under all possible conditions.

If a bug causes the software to request motion that requires infinite acceleration, does the firmware respond safely or does it instead try to perform the erroneous operation and hope for the best? For a safety-critical system, this can have devastating results, for example if a surgical robot receives an invalid position or velocity command.

Testable motion control systems should also provide means for tuning the motion control parameters. Tuning is necessary to ensure both precision and repeatability in movement outcomes, with such calibration generally motor-specific.

Infrastructure Planning

Reaching all of our design goals properly in the first implementation requires time to think and plan prior to the start of coding. At the same time, we also need to consider the tools we’ll use to get the job done. Before getting into the always-interesting specific motion control algorithms and low-level hardware controls, we should first consider the software framework.

Infrastructure planning starts by thinking and using object-oriented analysis and design techniques. We have a great modeling tool at our disposal in Universal Modeling Language (UML) class diagrams and state charts. But we can begin, with or without UML, by identifying a few objects with limited and discrete sets of responsibilities. Used properly, objects also help avoid coupling between subsystems through encapsulation and good interface design.

To make our discussion concrete, consider the UML class diagram in Figure 1, which shows how to represent sensor and motor objects in an abstract way. We know there are many different types of sensors and motors. However, these objects do have common sets of features. In addition, there is a relationship between motors and their associated sensors. In the model shown, we do not directly incorporate sensor functionality with our motor implementation, but rather associate sensors with a motor instance. This object model immediately shows us extensibility and reuse using abstraction and class inheritance. The sensor and motor object model also sets us up for maintainability because we are avoiding putting all our functionality into a single object.

To reach our testability goals, we need to go a step further than this model by defining the public interface to each object. Once the interface is in place, white box tests can be developed to ensure proper functionality and the ability to handle invalid inputs.

We now have a set of objects in our framework for managing the motion control itself, but I mentioned earlier that infrastructure was one of the keys to success. Let’s assume that our motors and sensors have the data we need, but how can we make it available, especially if we’re running in an embedded system? This is where the classes in Figure 2 become part of our infrastructure.