This is the second part in the series of posts regarding what to take into consideration when developing a measurement method. It’s about which questions to ask to clarify the requirements and better understand the surroundings for the measurement. The first part deals with which competences you need for a successful measurement project.
Asking the right questions
Thorough understanding of the system requirements is a necessity when developing measurement systems. To get there, one must know what questions to ask. Many questions are reoccurring regardless of type of measurement system;
- What is the purpose of the measurement?
- How frequent must the measurement be repeated?
- What is the desired degree of automation?
- What are the requirements for repeatability and accuracy?
- Should the raw data be saved or only the result after analysis?
are example of such questions. It is also important to know about the environment, such as temperature and humidity, at which the measurement system shall be operated. Are there external noise factors that needs to be considered, can these be reduced by means of shielding etc.
The purpose of your system
However, most questions depend on what kind of measurement system that are to be developed, and one should adapt the questions accordingly. Usually, the demand for a measurement system can be traced back to one out of four categories;
- A research project, where the user seeks the answer to more or less well-defined questions.
- Early during product development, to make sure the concept is working.
- In the late product development phase, to verify that the product is working as expected (could also be to verify product specifications from subcontractors).
- In production, to ensure product quality of each individual product.
In this blog post we will discuss what is characteristic to requirements for measurement systems belonging to each of these categories.
Flexible systems in research projects
In research, measurements are commonly performed to learn more about something, sometimes without clear expectations on what to find or on what question to ask. Usually, this leads to an iterative process where the result from the first measurements is used to refine the research questions, which in turn will be answered by subsequent, modified measurements. Thus, flexibility is the key word when developing these kind of measurement systems. Both software and hardware should be modular so that different parts can be easily extendable and exchangeable as the focus of the questions changes and the hardware becomes obsolete. When automating, one should focus on the parts that are reoccurring and is not directly coupled to the research, such as calibration, aligning optics etc.
Hard requirements, such as accuracy and repetition rates are usually difficult to define. In general, the researcher wants the system to be as good as possible in order to be able to tackle as many research questions as possible. The requirements will then be defined from the research budget, since more accurate instruments often costs more, or from the specifications of the hardware already available in the lab.
Example of requirements:
- If should be possible to change instrument type or instrument supplier depending on what measurement that is to be performed
- If should be possible to configure a set of instrument settings without modifying the code. For example, the camera settings: IP-address, gain, exposure time…
- All raw data should be stored for later analysis.
- The file format for data should be specific, for example to easily be read in an already defined script in MATLAB or Python.
Systems for evolving requirements in early product development
In R&D, during early product development, measurements are often done to make sure a new concept is working. These measurement systems are similar to systems used in research in the sense that flexibility is an important factor. However, requirements such as accuracy, precision, measurement ranges etc. can sometimes be derived from the requirement of the product(s) to be tested. This depends on if the product has defined requirements from the market or are developed based on a brand new concept that hasn’t been tested before. If deriving measurement system requirements from product requirements, one should be aware that these may change over time. Sometimes it is possible to guess in which direction these might change in advance and prepare the system for these changes.
Some examples of requirements are:
- It shall be possible to measure clock signal frequencies between 30-34 MHz.
- The rise time of the digital signals shall be measured with an accuracy of 1 us.
- If shall be possible for a tester to configure automated measurement sequences of the defined measurements after each other.
- All raw data should be stored in a database.
- All instrument settings should be stored with the measurement data.
- The fixture for holding the product should be adjustable to support if the product changes size (in the range…)
Verification systems for late product development
Later in the product development phase, measurements are done to verify that the product is working as expected. Since the product now has evolved further it should be clearer what measurements are required to verify the functionality of the product. Some questions that are important to ask are:
- Where are the biggest risk of lacking quality?
- What is the acceptable risk for product properties ending up outside the specified tolerances?
A lot of the requirements on the measurement system can be derived from the requirements on the product itself. For example, a product requirement like: “The surface of the metal plate should not have variations larger than ± 1 mm.” can result in the following requirements on the measurement system:
- The plate variations shall be measured over a 500 x 100 mm area.
- The plate variations shall be measured with an uncertainty of ± 0,1 mm.
Quick and easy to use systems in production
In production measurements are done to ensure product quality. At this stage you probably know what you want to measure, but not always how. Requirements are often similar to those used in product verification during product development. One thing that differs is that the test time is often more limited in production than in R&D. Also, it is more important that the user interface is easy to use, than that it offers lot of flexibility. This can result in requirements like:
- Each measurement should not take longer than 10 s to perform.
- The product holder should make sure the product cannot be placed into the measurement system in the wrong way.
- The operator should initiate the measurement by pressing only one button.
- The following error messages should be displayed on error…
Clear and testable requirements
In addition to the examples given here, there are a lot more requirements that can be defined. Hopefully, this post has given you an idea of how to find out what types of requirements that should be defined. Remember that the requirement should be specific, clear and testable. It is a good idea to spend some time on sorting out this part before getting to involved in finding a solution.
One last advice; define the tests for the requirement in parallel with the requirements themselves. By doing so, one avoids the situation where the test system requirement is very difficult or even impossible to verify when the system is completed. You can read more about how good requirements should be defined here.