An April 30, 2009 ruling by Minnesota’s Supreme Court may put an at least temporary halt to the prosecution of drunk driving in that state. This is because according to Twincities.com “[T]he state’s highest court ruled that defendants in drunken-driving cases have the right to make prosecutors turn over the computer “source code” that runs the Intoxilyzer breath-testing device to determine whether the device’s results are reliable.
Source code basically refers to the computer program that runs breath testing equipment. A more technical definition, though, of source code would be “[c]ode written by a programmer in a high-level language and readable by people but not computers. Source code must be converted to object code or machine language before a computer can read or execute the program.” Montage Group, Ltd. v. Athle-Tech Computer Systems, Inc., 889 So.2d 180, 185, n.5 (Fla. App. 2004) (Citation omitted).
Breath test devices are largely unique among measuring devices because after the amount of alcohol in the breath sample is measured, a variety of mathematical calculations must be performed to make the numbers relevant to the human system. In other words, to make the raw number relevant to whether the motorist has an unlawful level of bodily alcohol.
There are essentially four questions posed by source code litigation. First, are the mathematical equations employed by a particular breath testing device properly formulated, calculated and applied? Second, is the code acceptable to the relevant scientific community? Next, has the code been subjected to an appropriate level of scientific scrutiny both inside and outside of the breath testing device itself? Finally, have any changes to the code been made after the device was approved for use by law enforcement? The answers to these questions will govern whether or not a defense lawyer can persuasively argue that test results should be excluded on the basis that the prosecution cannot guarantee that they are reliable enough to sustain a criminal conviction.
In Minnesota defense wanted to inspect the source code and the prosecutors had essentially been playing shell game, arguing that even though they owned the breath testing machines, and were in possession of the software that ran it, they were not “in possession” of the source code. This is the same game that has been played, mostly unsuccessfully, by prosecutors around the country.
In ruling that the source code was both “discoverable” (meaning the prosecutor had to provide it) and “in the possession of the state” came after lengthy litigation. In the Supreme Court’s 21 page opinion, the court indicated, relative to source code, as follows:
We next determine whether the district courts‟ findings that the State had possession or control of the source code were clearly erroneous. The court of appeals did not reach this issue because it reversed both district courts‟ discovery orders based on the grounds of relevance. Minnesota Rule of Criminal Procedure 9.01, subd. 2(1), requires prosecuting attorneys to assist the defendant in seeking access to matters that are within the “possession or control” of the State.
Both district courts found that the State is the owner of the source code for the Minnesota model of the Intoxilyzer 5000EN, relying on the request for proposal (RFP) issued by the State when replacing the previous version of its breath-test instrument.6 The State argues that the district courts erred; it asserts that our holding in Underdahl I is distinguishable because the Underdahl I court was reviewing this question under the higher threshold of a writ of prohibition, and further contends that the RFP actually gives appellants, not the State, the right to access the source code.
In Underdahl I, the State had been ordered to produce the source code in appellant Underdahl‟s implied consent hearing. 735 N.W.2d at 709. The Commissioner of Public Safety petitioned the court of appeals for a writ of prohibition to prevent the district court from enforcing the order, a writ that can be issued if the mandated discovery “is clearly not discoverable and for which there is no adequate remedy at law.” Id. at 711. We concluded that the Commissioner had failed to meet his burden of demonstrating that the source code was “clearly not discoverable” because the source code was in “possession, custody or control” of the State; the Commissioner had conceded that the State owned some of the source code, a concession supported by the express copyright language in the RFP. Id. at 712.
We similarly conclude that the district courts did not abuse their discretion in finding the State had possession or control of the source code under Minn. R. Crim. P. 9.01, subd. 2(1). The RFP language cited by the district courts supports their conclusions that the State had possession of the source code. The State‟s arguments that appellants have access to the source code are also unpersuasive, because Rule 9.01, subd. 2(1), only speaks to the State‟s obligation to assist a defendant in seeking access to material the State possesses, aside from the defendant‟s possible access. We therefore hold that it was not an abuse of discretion for the district courts to find that the source code was in the possession or control of the State.
Now that the court has ordered that the source code be produced, it will be interesting to see if CMI, the maker of Minnesota’s breath testing equipment, will comply. If they do and it is actually analyzed, it will be interesting to see what defects might thereby be revealed.
In similar litigation in New Jersey, the defense experts found that the source code for another breath testing machine, the Draeger, was filled with problems. The source code in that case was inspected by a company called “Base One.”
Base One stated in their report that, as submitted, the Alcotest software would not pass development standards and testing for the U.S. government or military: “It would fail software standards for the Federal Aviation Administration (FAA) and Federal Drug Administration (FDA), as well as commercial standards used in devices for public safety,” meaning that “the Alcotest would not be considered for military applications such as analyzing breath alcohol for fighter pilots.” Base One explained that if the FAA, for example, were to impose mandatory alcohol testing for all commercial pilots, then the Alcotest would be rejected based on FAA safety and software standards.
In their report Base One noted the following source code problems:
Results Limited to Small, Discrete Values: The A/D converters measuring the IR readings and the fuel cell readings “can produce values between 0 and 4095. However, the software divides the final average(s) by 256, meaning the final result can only have 16 values to represent the five-volt range (or less), or, represent the range of alcohol readings possible. This is a loss of precision in the data; of a possible twelve bits of information, only four bits are used. Further, because of an attribute in the IR calculations, the result value is further divided in half. This means that only 8 values are possible for the IR detection, and this is compared against the 16 values of the fuel cell.
Flow Measurements Adjusted/Substituted: The software takes an airflow measurement at power-up, and presumes this value is the “zero line” or baseline measurement for subsequent calculations. No quality check or reasonableness test is done on this measurement. Subsequent calculations are compared against this baseline measurement, and the difference is the change in airflow. If the airflow is slower than the baseline, this would result in a negative flow measurement, so the software simply adjusts the negative reading to a positive value. If the measurement of a later baseline is taken, and the measurement is declared in error by the software, the software simply uses the last “good” baseline, and continues to read flow values from a declared erroneous measurement device.
Error Detection Logic: The software design detects measurement errors, but ignores these errors unless they occur a consecutive total number of times. For example, in the airflow measuring logic, if a flow measurement is above the prescribed maximum value, it is called an error, but this error must occur 32 consecutive times for the error to be handled and displayed. This means that the error could occur 31 times, then appear within range once, then appear 31 times, etc., and never be reported. The software uses different criteria values (e.g. 10 instead of 32) for the measurements of the various Alcotest components, but the error detection logic is the same as described.
Defects In Three Out Of Five Lines Of Code: A universal tool in the open-source community, called Lint, was used to analyze the source code written in C. This program uncovers a range of problems from minor to serious problems that can halt or cripple the program operation. This Lint program has been used for many years. It uncovered that there are 3 error lines for every 5 lines of source code in C.
Some of Base One’s other relevant observations about the program include: “Readings not Averaged Correctly;” “Catastrophic Error Detection Is Disabled;” “Implemented Design Lacks Positive Feedback;” “Diagnostics Adjust/Substitute Data Readings;” “Range Limits Are Substituted for Incorrect Average Measurements;” “Code Does Not Detect Data Variations;” and “Timing Problems.”
It remains to be seen what will happen in Minnesota, but the possibitity remains that citizens are being wrongfully convicted based on faulty breath test results in Minnesota and around the Country.