P19224: Biometric Driver Monitoring

Systems Design

Table of Contents

Team Vision for System-Level Design Phase

The goal of this phase is to determine what individual systems will be necessary in order to fulfill the customer requirements, and determining how these individual systems will interface. At this point in the design, each individual system should have multiple concepts but the interface between them should be determined and frozen. Additionally, the risks document should become very close to the final document, excluding any unexpected risks encountered in the detailed design, build, and test modules.

During this section, our team began to converge on what we think will be the best combination of systems to meet our goal, and have developed a few test plans to further confirm this. Each system still has several backup concepts should unknown problems be encountered.

Functional Decomposition

Figure 1: Function Tree

Figure 1: Function Tree

Figure 1 shows all of the functions that the system must perform, going from the general to specific functions. The most basic, overarching function is to monitor the driver's vitals and biometrics. That function then breaks down into the steps needed to monitor the driver reliably and the finer details of how that should be done.


Figure 2: Benchmarking Matrix

Figure 2: Benchmarking Matrix

The devices we chose for benchmarking against our concept were the Apple Watch, Fitbit, F1 Palm Sensor, and Portable EKG. We felt these devices gave a good range of what combinations are available on the market right now. Right away we find that our concept is the only one to use the complete set of sensors we intend on using. Also, we find that our concept is the only one that transmits to the CAN bus as opposed to real-time monitoring, which is one of the most critical functions in order to meet the customer requirements.

The full document can be viewed here: Benchmarking Matrix

Concept Development

To set up our Morphological Table, we took the functions that the system must perform and came up with some ideas as to how we can perform those functions.

Sensor Power: In order to distribute power to our sensors, power can be sourced directly from a microcontroller/SBC through wires, or have one or more batteries on the driver so that less wires are running between the driver's suit and the board.

Muscle Activity Tracking: Muscle Activity/Force needs to be objectively measured for evaluating fatigue. This can be done with EMG sensors (with or without sensor stickers) or pressure transducers.

EMG Data Collecting: If EMG sensors are used, we need to know how we will use them. EMG sensors can be used on their own however, there are potential benefits in signal quality if the sensors are modified, or if new sensors are designed altogether.

Body Temperature Data Collection Temperature data needs to be gathered using a sensor. This concept is used for figuring out where the sensor should be positioned to get an accurate reading without causing discomfort.

Heart Rate Data Collection: There are many different methods of measuring heart rate, such as pulse oximeters and EKG sensors. We need to choose a way to measure heart rate that's accurate and comfortable for the driver.

Blood O2 Ratio Data Collection: Gathering blood O2 levels is also necessary. If a pulse oximeter is chosen for this function, its data can be used to calculate heart rate on the microcontroller/SBC.

Raw ADC Data Filtering: Filtering the data coming in from the ADC may be necessary if analog filtering built-in or added to the sensors is insufficient to get a clean signal. This concept consists of a variety of digital filters.

Transfer EMG Signal to Processor: This is the connection between the ADC and the microcontroller/SBC. We could send the data to an onboard ADC, or perhaps have the ADC close to the sensor and transmit the digital signal wirelessly.

Quick-Disconnect: These are various kinds of connectors we can use to ensure quick egress. Additionally, there may be no connector at all if the system operates wirelessly.

Board Protection: This consists of various enclosures to protect the microcontroller or SBC from water, heat, or any other hazards that may be encountered.

Data Conversion/Computation: These are the different microcontrollers or SBCs we can use the process the incoming data and ultimately send messages to the CAN bus. Options will vary in terms of computational power, size, and built-in components that we need.

Computer Power: We need to acquire clean power for the SBC/microcontroller. Since the system will be in the vehicle, we could use the vehicle's battery, otherwise we will have to integrate a power source independent of the car.

All concepts and possible components are given a cell in the Morphological Table below. Using the Morphological table, we combined different concepts for performing the functions into concepts for the full system.

Feasibility: Prototyping, Analysis, Simulation

A detailed overview of the tests and analyses that have been performed to verify the feasibility of this project can be found in this document: Feasibility Overview

A summary of the results is shown in Figure 3. Red indicated that a corrective action will need to be taken.

Figure 3: Feasibility Summary

Figure 3: Feasibility Summary

Morphological Table

Figure 4: Morphological Table for Concept 1

Figure 4: Morphological Table for Concept 1

We put all of our ideas for how to fulfill different functions into a morphological table and combined them into 3 different concepts. Figure 4 shows the table for one of these concepts.

The full document can be viewed here: Morphological Table

Concept Selection

Concept Screening

Figure 5: Concept Screening

Figure 5: Concept Screening

Above is a screenshot of one of the Pugh chart iterations performed in order to screen our concept options. A second iteration was performed moving the datum to the second concept, and the ranking did not change. Following this, the first concept was chosen to start moving forward with.

The second iteration can be viewed in the full document.

Based on the Pugh chart, we selected concept 1 since it best met our selection criteria. The systems architecture that follows is based on this concept, after going through a concept improvement stage.

Concept Improvement

Pending testing, the first concept seems to be the best in most aspects. One thing that will change from this concept, based on our feasibility analysis, is that we will be modifying the Myoware EMG sensors for a better signal, since they tend to pick up a significant amount of noise from the power supply. We believe that the benefit of a cleaner signal outweighs the cost in increased complexity and time to implement for this part of the system. Some other aspects of the system are still subject to change. For instance, we may choose to design our own quick-disconnect connector. The choice of the SBC/MCU is also subject to change if we find that the Raspberry Pi is not a suitable board. Some possible alternatives include, but are not limited to, a more powerful SBC such as the ASUS Tinker Board, or a board more specialized for DSP and data acquisition such as an NXP Digital Signal Controller.

Systems Architecture

Figure 6: High Level System Architecture

Figure 6: High Level System Architecture

This is a high level view of the system we intend on making. Components such as the SBC/MCU are left abstract in this view. The temperature sensor and pulse oximeter will likely go through an I2C interface, while the EMG sensors will each get a channel on the ADC. Filtering and amplification will be done as needed for the EMG signals. The ADC and CAN interface will, with whatever SBC/MCU we choose, connect/mount directly on the SBC/MCU. All the electronics will be contained in a waterproof case mounted on the car, which will also likely include some form of passive heatsink as some SBCs like the Raspberry Pi 3 B+ (which is included in one of our concepts) tend to get hot, especially in a waterproof case that would have no airflow. Our power source will likely be a separate battery and not the car battery, since that would provide cleaner power and less hindrance to the car's operation despite the added weight.

Figure 7: High Level Software Architecture

Figure 7: High Level Software Architecture

On the software side, all sensor data will come in as a digital signal that has to first be filtered. In the case of the EMGs, the signal will go through a low-pass filter (if the analog filter is insufficient), and then an FFT to see if there are any spikes within the pass band that could be counted out as noise. This will be done for every X number of samples as a moving window. The goal is not necessarily to reconstruct the signal afterward, but rather read the FFT output to determine what the muscle activity is at the moment. We're targeting 100 of these readings per second. Blood oxygen levels and temperature will be sampled at a lower rate, yet will go through a similar filtering process. The blood oxygen levels will be used to compute the driver's heart rate, and all the necessary information will be used to compute a fatigue level for the driver. All metrics are then sent to the CAN bus to be logged. It's important to note that there is a high level of parallelism in the initial conversion and filtering tasks, so the software will likely benefit from the availability of multiple processors.

Other Designs and Flowcharts

Figure 8: Transformation Diagram

Figure 8: Transformation Diagram

Figure 8 shows all inputs to the system and how the system will process or handle those inputs. This mostly consists of what data the system will gather, but also considers how the system must be kept protected in a racing environment. It also shows what outputs we then expect the system to produce, whether they're tied to a requirement or are a byproduct of running the system.

Risk Assessment

Figure 9: Risk Assessment

Figure 9: Risk Assessment

These are the risks we've identified so far for the project. This table has been revised based on the problem definition review. Signal noise still remains the highest risk.

Test Plan

A high-level overview of the tests we plan to do as the system is being developed can be found in this document: High Level Test Plan

Design Review Materials

There are no pre-reading materials for this review. Notes and action items will be updated after the review is done.

Plans for next phase

For the detailed design phase, we'd like to work with our selected concept and work through the specifics of its subsystems. Here is a list of some of the work we would like to complete:





Our project schedule shows when we plan to do these tasks.

Home | Planning & Execution | Imagine RIT

Problem Definition | Systems Design | Preliminary Detailed Design | Detailed Design

Build & Test Prep | Subsystem Build & Test | Integrated System Build & Test | Customer Handoff & Final Project Documentation