Specifications
119
successful operation. These will be specific to each software routine, based on
its intended purpose and defined range of inputs, with the expected range of
outputs. It will be important to stress the software components by attempting their
operation on inputs known to be invalid or corrupt, in order to thoroughly evaluate
the quality of their design.
5.3.1 Hand Held Software
The hand held unit software has several notable responsibilities, including
capturing the analog sensor output into a discrete digital representation,
processing those outputs through the algorithm and output a valid result. It must
be able to send and receive messages from the control box, as well as control
and drive the outputs to the screen and status LEDs. The hand held software
routines must also be able to accept user input in the form of push button
interrupts to the microcontroller, and make the appropriate state changes.
To adequately meet the requirements of end-user application, the software
needs to be able to handle not only the expected order of user operations, but
also handle use cases of invalid operation order. An example of this would be a
case where the user is about to give a breath sample to the hand held unit, but
then decides to randomly push buttons on the device they would not need to
push at the time of sample. This could be for any number of reasons, whether the
user was mishandling the unit, or perhaps some other environmental stimulus
generates an event that the software could detect as a user or device action.
Events where an unexpected input or action is generated are usually called False
Triggers, and can wreck havoc upon any unprepared software routine.
The software routines must also be able to handle values of input that are
outside the defined range of operation. An example of this would be if suddenly
the ADC output values coming into the software routine were over the expected
upper limits. Such bitwise overflow errors could be introduced by digital crosstalk
or false triggering on the input lines, and must be accounted for by the software
in order to prevent the reporting of erroneous and unanticipated results.
5.3.2 Control Box Software
Much like the hand held unit, the software routines of the automobile control box
must be capable of handling both unexpected use-case scenarios, as well as
erroneous and unexpected input outside of the range of expected values. While
the software on the control box will not have quite as many mathematical or
signal processing responsibilities as the hand held software, the validity of its
state transitions are a key element of a well designed automobile interlock unit.
As such, an important requirement of the control box software is to secure all
state transitions, protecting the unit from entering any particular state without
some kind of procedure to verify that the transition is in fact desired.










