6.5 Pre- and Postconditions: Check What Comes In and What Goes Out
This concept is so powerful that we can not stress enough how important it is. The idea, as usual, is as old as the ark, but often little utilized.
Continuing the production line analogy, the production line, in Figure 6.52, just builds and ships. From stores to the dump truck in three simple steps!
Figure 6.52. Factory No Checks.
A simple VI example is shown in Figure 6.53.
Figure 6.53. Pre- and postconditions example before.
This all looks pretty straightforward. The readings being passed are compared to the lower limits that are also being passed. Each reading is checked against the corresponding limits as the loop iterates over the incoming readings . The output logical array is all AND-ed and an overall result passed out. So, if all the results are greater than the lower limit the result is True. This could be a check on signal levels, frequency, current, or anything. To add a little importance to the code, the shipment of a product relies on the result being True. The limits are in a database or flat files and are read into memory when the test is kicked off. Simplicity itself!
But, someone makes a mistake. There are 10 readings being passed to this VI, but only seven limits have been set up. What happens? The loop will only iterate seven times, as it is limited to the smallest array (a good thing in itself). This means three results do not get tested . If the first seven all pass, the result passed back is true and the product is shipped. This goes undetected, the last three tests start failing, and we are now in a world of hurt!
6.5.1 Preconditions
In the factory analogy it would be far better to check the materials coming from stores prior to them being built into scrap. Figure 6.54 demonstrates this. This will pick up any inferior subassemblies and material. This example won't pick up any assembly errors though.
Figure 6.54. Factory precondition.
The VI example problems could all be addressed with a simple precondition. In natural language it would be stated thus: The comparison is only valid if both the incoming arrays are the same size .
Sounds straightforward, but the above statement could save a lot of misery when bad production goes out the door.
The code in Figure 6.55 shows one way of implementing the precondition.
Figure 6.55. VI Precondition.
Now, the two incoming arrays are checked to make sure they are the same size. If they are not then a warning is given, and the unit is failed (constant in the false case ensures only a false is passed out). That is it, a simple precondition has ensured that any problems or errors farther upstream in your application will not cause a bad unit to be passed.
One common precondition that is well implemented in LabVIEW is the connection requirements shown in Figure 6.56.
Figure 6.56. Connector Precondition.
Another connector- related precondition we use often is the "No Command ”Error", "UnderRange", or "OverRange" enumerated type setting. When a component sees one of these error commands it will bleat loudly. The reason behind this is that if you neglect to set the connection requirements as above, and drop the component onto your block diagram without connecting and setting it correctly, you will get unpredictable results.
Another simple and useful precondition technique is to remove the default on case structures. This will break the diagram until all the cases are created.
6.5.2 Postconditions
Postconditions are, well, checking that everything is okay at the end. So, why would we apply this? Again, code that checks code.
Back in the factory, Figure 6.57 shows that we're now checking that the unit is assembled correctly prior to shipping to the customer, but we're not doing anything about scrap and waste during manufacturing.
Figure 6.57. Factory postcondition.
An example of a postcondition could be closing switches in a switching system. We will assume that this switching system provides the ability to read back the current state of the switches. So, our component commands some switches to be closed. We could then merrily exit this software assuming that the switching system is indeed in the state we wanted. But, maybe it isn't. Our precondition could be enforced by reading back the current state of the switches and comparing them, ensuring that they are the same. If they are not, then we will carry out another operation or simply throw an error. The same can be applied to setting up instruments and then reading back their settings such as environmental settings (set temperature, pressure, etc.).
Read-backs should commonly be employed when doing communications, file transfers, and database transactions.
6.5.3 Conclusion
The hardest problems to find are when the software appears to behave in the manner in which it was intended, and the outputs seem reasonable (in this scenario all production seems to be A-OK). But, by applying pre- and postconditions the code is doing a sterling job in continuously monitoring the internal hidden behavior of the system. Essentially, the code is checking itself and that has got to be a good thing.
| |
| Top |
EAN: 2147483647
Pages: 66