Specifications

12
and interfaces, as well as the complete physical appearance of the device,
provides a design team the most dynamic range of variation in delivering a
potential end-user solution. The hardware can be designed to conform to strict
physical size limitations, while providing a determinate level of functionality both
to maximize the quality of use-case scenarios for the operator and to maintain an
upper bound on the per-unit cost of the device. Selection of individual hardware
can also be a function of the software development group’s comfort level with
particular development tools and programming languages, thus reducing the
magnitude of any potential learning curves encountered during the product
design phase.
2.1.4 Platform Conclusions
After evaluating potential candidates for the hardware and software design
platform, it has been determined that a custom solution would be the most
optimum path towards product realization. In evaluating the iPhone platform,
hurdles were discovered in the process of trying to acquire hardware schematics
and resources for developing third party hardware, namely the requirement to
sign a Non-Disclosure Agreement as an incorporated company. Additionally, the
development tools to publish software for the iPhone require an expensive
subscription to Apple’s developer network, which can only be circumvented by
breaking the software restrictions on a particular hardware unit, which would void
the warranty. While the Android platform produces no such limitations for the
software development, the hardware development must overcome the obstacle
of non-standard physical interface across compatible devices that operate on
Android. The implementation of the device on pre-designed hardware also limits
its usability to individuals who already own one of those particular devices,
thereby limiting the market potential for the device. Factor in the costs of
acquiring the smartphone hardware on which to develop our end solution, and
the initial prototyping costs are approximately equivalent across all three potential
platform candidates, lending the advantage to the one that offers the greatest
flexibility.
2.2 System Logic
The system level design for both the handheld breathalyzer unit, as well as the
automobile control unit, calls for the use of programmable logic. This is
necessary for the successful interpretation of output signals from the sensors,
translating user input into device functionality, displaying information related to
the current state of the device, as well as communication with other devices in
the system. The choice for system logic should allow for the development of
complex algorithms to convert sensor data into useful output that can be
interpreted by the operator, as well as the ability to interface with devices
deemed necessary for the computational tasks required. Such devices would
include an Analog-to-Digital converter for decoding a continuous electrical signal