About the division of labor and its consequences
A few years ago we had a chance to take part in the development of a gas meter. At the time of the start of work with the customer, he already had some work. And these developments have seemed to us a very interesting example to demonstrate the consequences of an unsuccessful division of labor according to competencies. Under the cut, we will describe why the separation was unsuccessful, and how we solved the problems that arose as a result.
Three specialists took part in the development of a gas meter (in fact, more, but within the framework of the article we are only interested in three competencies). These were:
The designer provided a device that generates a signal for opening and closing a special valve. He looked like this:
')
It was necessary to measure the time the valve was in the open state (distance from A to B), and the frequency of valve opening.
Of course, it is not possible to process such a signal directly by the microcontroller, so the circuit engineer was tasked with developing an intermediate converter that generates the following signal:
The device will run on battery, so most of the time the microcontroller will be in Sleep Mode. Therefore, the programmer asked to send a signal to the Interrupt pin, set the microcontroller to wake up by the interrupt from the corresponding port, and in the interrupt handler performed the timer start / stop.
Everything looks good so far, each specialist did his job and did it efficiently. Only here the quality of the device as a whole did not suit anyone. At a constant expense, the device gave readings with considerable variation and it was completely unclear what the reason was.
Incorrect operation of the flow meter found at an early stage of development. Such mistakes happen and there is nothing to worry about. Scary is another, no one knew where the error and how to find it.
The reasons for the lack of accuracy of the flow meter could be:
In addition, the developers did not have complete confidence that the problem exists in principle, because the characteristics of the flow meter were determined using a reference bench, which was developed in parallel with the flow meter and was also far from ideal.
As a result, sooner or later we get a situation where each team member, being confident in the impeccability of the results of his work, crumbles a loaf on his neighbor. Whereas the top management perceives the project entirely and displeasedly with the whole team. The team originate conflicts, loud controversy, disunity. The designer declares that there is an error in the program, the programmer says that an error in the design of the valve, etc.
The development of the flow meter is much more complicated and the customer decided to attract new specialists. So we got to work.
We saw two ways to solve the problem:
The first option looks pretty standard and very popular in software development. For example, to check the software, we buy or develop a precision signal generator generated at the output of the converter, feed it to the microcontroller and compare its readings in various conditions with the readings of the generator. The solution is not the cheapest and, sometimes, far from being the fastest, but quite working.
The performance and quality of the input converter can also be assessed using a good and correctly tuned oscilloscope. Or develop a special device for analyzing the conversion.
But to check the operation of the valve is much more difficult, you need to submit a fixed flow, convert the valve signal and measure the signal using a specialized frequency meter. In fact, this is not much different from the flow meter that we already had.
Unfortunately, our customer was not ready to go this way, he needed a more elegant solution, especially since he could not develop a successful algorithm for checking the valve and signal generator.
Therefore, the customer was provided with an employee who has competence in both circuit design and programming with metrology. His task was to analyze the situation as a whole and save the team from the possibility of blaming each other.
Look under the hood. And now our human orchestra began to analyze the project. The analysis began with an input converter:
The original of the scheme has not been preserved, but the essence of it can be caught in the picture. As you can see, the circuit is built on a trigger (4013) and optocouplers. False alarms are eliminated with the help of Zener diode D1 and RC-chains.
The circuit quite well converts the input signal from the valve. But when it was built, the circuit designer did not take into account the ultimate goal and the specifics of the signal.
The essence of the problem was that when setting the task of the circuitry, he was given the oscillogram of the input signal and the expected output type. According to the oscillogram, the circuit technician could not see that the steepness of the key fronts A and B would be insufficient to ensure stable and timely operation of the optocouplers. In fact, the use of comparators was necessary for the transformation scheme to work correctly. Circuit design is not very happy with this solution, since Comparators will complicate the scheme and will certainly give more consumption. In many ways, this concern is connected with the habit of solving the tasks set exclusively in circuit design, not cooperating with the programmer and not using the capabilities of the microcontroller.
With the program, too, everything was not smooth. On the one hand, if the microcontroller is awake all the time, it receives interrupts and instantly starts / stops the timer. However, it was worthwhile to turn on the power saving mode, how the strange began. Looking into the microcontroller datasheet, we found that the microcontroller waking up time depends on many factors, and this significantly affected the accuracy of measurements. The start and stop of the timer lagged far behind the input signal. The programmer knew that the wake-up time is comparable to the time the valve is in the open state, but he expected that it would only lead to a uniform displacement of the timer start / stop relative to the input signal. In fact, we received a significant variation in the readings of the energy-saving and waking microcontrollers. For a metrologist, this problem would be obvious, but he did not participate in software development, because did not have such expertise.
Valve operation analysis failed. It was difficult or impossible to test the valve and evaluate its operation without conversion and measurement of its signal. We decided to deal with problems in the converter and the program, get a measuring and computing unit that will not cause us doubts and test the valve using the obtained unit.
Having understood the project as a whole, we started to solve obvious problems. The easiest way to solve a software problem was to start and stop the timer. On the microcontroller we used, there was a Gate-controlled timer that could be started and stopped in hardware, before the microcontroller wakes up and, if necessary, even without waking it up. If a programmer were interested in metrology, he would have found such a solution himself long ago and tried to implement it. But often programmers are only interested in programming. In addition, there were two more factors that significantly influenced the adoption of unsuccessful decisions by the programmer:
Along the way, we have affected the accuracy of the input signal conversion. For us it was obvious the need to move from optocouplers to comparators. The customer was worried about the problem of increasing consumption, he had already heard about it from his circuit engineering. Circuit engineer was well versed in his subject area, but he didn’t even think about the functionality of the microcontroller used in the project. Not only did the microcontroller already contain two comparators, it also turned out that one of them would be enough for us, we will simply switch the lower and upper levels of the reference voltage programmatically, without using additional external switches. Considering that low power consumption was one of the key advantages of the microcontroller we used, the comparator cost us very cheap (about 8 µA). And the high input resistance of the comparator made it possible to make a set of reference voltages quite inexpensive in consumption (no more than 10 μA). As a result, we have a pretty simple input signal processing scheme:
Since The signal comes from the valve, both positive and negative, we shift it using resistors R1 and R2. Divider R3-R5 we set the reference voltage. As the battery voltage decreases, the reference voltages and the offset to R1 and R2 will decrease synchronously, so this will have little effect on the accuracy of the signal conversion.
To start and stop the timer through the use of gate-control technology, our microcontroller generates signals for opening and closing the gate using a comparator at the hardware level without exiting sleep mode. RC chains are eliminated, since we can programmatically control the gate using the RA5 port of the microcontroller. The comparator output is connected to the trigger CLK input. The comparator voltage reference is switched programmatically (either C12IN0- or C12IN1- is connected, depending on whether we expect the valve to open or close).
Having developed our own signal conversion circuit and our microcontroller firmware, we significantly increased the accuracy of gas flow measurement. We also helped the flow meter designer. Now he could easily notice flaws in the operation of the valve and signal generator, and he did not have to think that the problem was not on his side. Even if he had any questions, he had someone to discuss with them, because we could always describe the signal conversion and measurement algorithm from the metrology point of view and, if necessary, correct something.
The division of tasks according to competences allows the team members to achieve a very high level of development in their fields, but sooner or later we come to the conclusion that specialists no longer understand each other. In this situation, it is very useful to have a person at hand who is knowledgeable in all areas related to the project. It may not be as good as any specialist individually, but able to see the whole picture. Also, the experience of this project has shown that such a specialist has a very positive effect on the interaction of specialists, cultivates the interest of engineers in working with each other. The programmer and the circuit designer began to think more often about measurement errors, the circuit designer discovered new possibilities for using the microcontroller periphery, the designer metrologist began to trust his colleagues and actively use the results of their work for analyzing the hardware.
I would also like to draw attention to the fact that having superficial knowledge in a wide range of areas, the person orchestra at the interview stage does not look attractive from the point of view of both the programmer and the metrologist and circuit design. But in fact, he can play a key role in a difficult situation.
Three specialists took part in the development of a gas meter (in fact, more, but within the framework of the article we are only interested in three competencies). These were:
- Design Engineer, Part-time Metrology Specialist
- Circuit Designer
- Programmer
The designer provided a device that generates a signal for opening and closing a special valve. He looked like this:
')
It was necessary to measure the time the valve was in the open state (distance from A to B), and the frequency of valve opening.
Of course, it is not possible to process such a signal directly by the microcontroller, so the circuit engineer was tasked with developing an intermediate converter that generates the following signal:
The device will run on battery, so most of the time the microcontroller will be in Sleep Mode. Therefore, the programmer asked to send a signal to the Interrupt pin, set the microcontroller to wake up by the interrupt from the corresponding port, and in the interrupt handler performed the timer start / stop.
Everything looks good so far, each specialist did his job and did it efficiently. Only here the quality of the device as a whole did not suit anyone. At a constant expense, the device gave readings with considerable variation and it was completely unclear what the reason was.
Why did this happen?
Incorrect operation of the flow meter found at an early stage of development. Such mistakes happen and there is nothing to worry about. Scary is another, no one knew where the error and how to find it.
The reasons for the lack of accuracy of the flow meter could be:
- Errors in valve design and input generator
- Errors in the input signal conversion circuit
- Software bugs
In addition, the developers did not have complete confidence that the problem exists in principle, because the characteristics of the flow meter were determined using a reference bench, which was developed in parallel with the flow meter and was also far from ideal.
As a result, sooner or later we get a situation where each team member, being confident in the impeccability of the results of his work, crumbles a loaf on his neighbor. Whereas the top management perceives the project entirely and displeasedly with the whole team. The team originate conflicts, loud controversy, disunity. The designer declares that there is an error in the program, the programmer says that an error in the design of the valve, etc.
What to do?
The development of the flow meter is much more complicated and the customer decided to attract new specialists. So we got to work.
We saw two ways to solve the problem:
- Total testing and acceptance of each team member
- Orchestra Man
The first option looks pretty standard and very popular in software development. For example, to check the software, we buy or develop a precision signal generator generated at the output of the converter, feed it to the microcontroller and compare its readings in various conditions with the readings of the generator. The solution is not the cheapest and, sometimes, far from being the fastest, but quite working.
The performance and quality of the input converter can also be assessed using a good and correctly tuned oscilloscope. Or develop a special device for analyzing the conversion.
But to check the operation of the valve is much more difficult, you need to submit a fixed flow, convert the valve signal and measure the signal using a specialized frequency meter. In fact, this is not much different from the flow meter that we already had.
Unfortunately, our customer was not ready to go this way, he needed a more elegant solution, especially since he could not develop a successful algorithm for checking the valve and signal generator.
Therefore, the customer was provided with an employee who has competence in both circuit design and programming with metrology. His task was to analyze the situation as a whole and save the team from the possibility of blaming each other.
Look under the hood. And now our human orchestra began to analyze the project. The analysis began with an input converter:
The original of the scheme has not been preserved, but the essence of it can be caught in the picture. As you can see, the circuit is built on a trigger (4013) and optocouplers. False alarms are eliminated with the help of Zener diode D1 and RC-chains.
The circuit quite well converts the input signal from the valve. But when it was built, the circuit designer did not take into account the ultimate goal and the specifics of the signal.
The essence of the problem was that when setting the task of the circuitry, he was given the oscillogram of the input signal and the expected output type. According to the oscillogram, the circuit technician could not see that the steepness of the key fronts A and B would be insufficient to ensure stable and timely operation of the optocouplers. In fact, the use of comparators was necessary for the transformation scheme to work correctly. Circuit design is not very happy with this solution, since Comparators will complicate the scheme and will certainly give more consumption. In many ways, this concern is connected with the habit of solving the tasks set exclusively in circuit design, not cooperating with the programmer and not using the capabilities of the microcontroller.
With the program, too, everything was not smooth. On the one hand, if the microcontroller is awake all the time, it receives interrupts and instantly starts / stops the timer. However, it was worthwhile to turn on the power saving mode, how the strange began. Looking into the microcontroller datasheet, we found that the microcontroller waking up time depends on many factors, and this significantly affected the accuracy of measurements. The start and stop of the timer lagged far behind the input signal. The programmer knew that the wake-up time is comparable to the time the valve is in the open state, but he expected that it would only lead to a uniform displacement of the timer start / stop relative to the input signal. In fact, we received a significant variation in the readings of the energy-saving and waking microcontrollers. For a metrologist, this problem would be obvious, but he did not participate in software development, because did not have such expertise.
Valve operation analysis failed. It was difficult or impossible to test the valve and evaluate its operation without conversion and measurement of its signal. We decided to deal with problems in the converter and the program, get a measuring and computing unit that will not cause us doubts and test the valve using the obtained unit.
Orchestra Man
Having understood the project as a whole, we started to solve obvious problems. The easiest way to solve a software problem was to start and stop the timer. On the microcontroller we used, there was a Gate-controlled timer that could be started and stopped in hardware, before the microcontroller wakes up and, if necessary, even without waking it up. If a programmer were interested in metrology, he would have found such a solution himself long ago and tried to implement it. But often programmers are only interested in programming. In addition, there were two more factors that significantly influenced the adoption of unsuccessful decisions by the programmer:
- The programmer did not work in active power saving mode. He simply did not encounter the problem of slow waking up the microcontroller and the effects manifested in this connection.
- The programmer was already working with the Gate-controlled timer and was faced with the fact that he simply does not work. So on all subsequent projects, he avoided this function and was afraid of it as a fire. As it turned out, not all programmers read Errata and track revisions of microcontrollers. In the early revisions of the microcontroller, this function really did not work.
Along the way, we have affected the accuracy of the input signal conversion. For us it was obvious the need to move from optocouplers to comparators. The customer was worried about the problem of increasing consumption, he had already heard about it from his circuit engineering. Circuit engineer was well versed in his subject area, but he didn’t even think about the functionality of the microcontroller used in the project. Not only did the microcontroller already contain two comparators, it also turned out that one of them would be enough for us, we will simply switch the lower and upper levels of the reference voltage programmatically, without using additional external switches. Considering that low power consumption was one of the key advantages of the microcontroller we used, the comparator cost us very cheap (about 8 µA). And the high input resistance of the comparator made it possible to make a set of reference voltages quite inexpensive in consumption (no more than 10 μA). As a result, we have a pretty simple input signal processing scheme:
Since The signal comes from the valve, both positive and negative, we shift it using resistors R1 and R2. Divider R3-R5 we set the reference voltage. As the battery voltage decreases, the reference voltages and the offset to R1 and R2 will decrease synchronously, so this will have little effect on the accuracy of the signal conversion.
To start and stop the timer through the use of gate-control technology, our microcontroller generates signals for opening and closing the gate using a comparator at the hardware level without exiting sleep mode. RC chains are eliminated, since we can programmatically control the gate using the RA5 port of the microcontroller. The comparator output is connected to the trigger CLK input. The comparator voltage reference is switched programmatically (either C12IN0- or C12IN1- is connected, depending on whether we expect the valve to open or close).
What is the result?
Having developed our own signal conversion circuit and our microcontroller firmware, we significantly increased the accuracy of gas flow measurement. We also helped the flow meter designer. Now he could easily notice flaws in the operation of the valve and signal generator, and he did not have to think that the problem was not on his side. Even if he had any questions, he had someone to discuss with them, because we could always describe the signal conversion and measurement algorithm from the metrology point of view and, if necessary, correct something.
The division of tasks according to competences allows the team members to achieve a very high level of development in their fields, but sooner or later we come to the conclusion that specialists no longer understand each other. In this situation, it is very useful to have a person at hand who is knowledgeable in all areas related to the project. It may not be as good as any specialist individually, but able to see the whole picture. Also, the experience of this project has shown that such a specialist has a very positive effect on the interaction of specialists, cultivates the interest of engineers in working with each other. The programmer and the circuit designer began to think more often about measurement errors, the circuit designer discovered new possibilities for using the microcontroller periphery, the designer metrologist began to trust his colleagues and actively use the results of their work for analyzing the hardware.
I would also like to draw attention to the fact that having superficial knowledge in a wide range of areas, the person orchestra at the interview stage does not look attractive from the point of view of both the programmer and the metrologist and circuit design. But in fact, he can play a key role in a difficult situation.
Source: https://habr.com/ru/post/308090/
All Articles