AI Developer Project Part 5: Combating Distracted-Driver Behavior

Overview of Productization for This AI Project

The fourth Combating Distracted-Driver Behavior article in this five-part series, Designing and Fine-tuning a Distracted-Driver AI Model, discussed the experience of conceptualization and research and development. This final article moves to the next step: productization. This topic provides ideas for product and development features, product choices, and an automatic product-development method.

Now that we have made sure that the technology parts of the distracted-driver solution are sound, we need to shift our focus to the final product that would be delivered to the end customer. Remember the outputs of our design-thinking experiments’ set of features from Overview of a Use Case: Combating Distracted-Driver Behavior:

  • Priced equivalent to about 1/5 of average insurance of the car per year
  • Seamlessly fit onto the vehicle
  • Easy switch on and switch off
  • Subtle alerts based on announcement or beeps that are customizable by the driver. Flashing lights were another option but might disturb passengers in the car, hence should be pointed at the driver.
  • Able to use the systems already built in the car like the speakers, radio, screens, mirrors, air-vents
  • Learn also from car movements like, if the car is at a complete stop then a slight distraction might be ok.

The productization team will use the following ideas to verify using market research if such a product is viable:

  • Mobile aids that could “ping” drivers when distracted
  • Devices in the car that could aid with curbing distraction, such as cameras and flashing lights
  • Steering-wheel accessories that would buzz the user when distracted
  • Reporting aids that would provide a score of distraction at the end of the ride
  • Windshield devices that would project distraction dangers
  • Seat stimulations that would curb distraction
  • Equipment that would play warnings on the car speakers

The final list of features in the final product would be determined based on the end-customer surveys and open questionnaires along with the pricing of the product.

Considerations for production and deployment

The product that finally ends up in the users’ hands needs to have the following:

  1. Usability

    Can be described as how effectively end users can use, learn, or control the system. Here are some questions to ask yourself to determine usability:

    • Am I using a UI metaphor to help users adapt? (For example, the desktop is a metaphor.)
    • Are the most common operations streamlined to be performed quickly?
    • Can new users quickly adapt to the product without help? (Is it intuitive?)
    • Do validation and error messages make sense?
  2. Maintainability (or flexibility, testability)

    The definition of maintainability implies how brittle the product is to change. How easy is it to update the product?

    • Are over-the-air updates possible for fixes and upgrades?
    • Can users do it by themselves?
    • Can we upgrade multiple versions of the product in the same manner?
  3. Scalability

    Scalability is the ability for your program to gracefully meet the demand of stress caused by increased usage—in short, ensuring that your program doesn’t slow or bust when pounded by more users than you originally anticipated. Generally true for a product that has data access to a server.

    • What is your current peak load that you can handle?
    • How many users can access the server until critical operations slow down?
    • Is the primary scaling strategy to “scale up” or to “scale out”— that is, to upgrade the nodes in a fixed topology, or to add nodes?
  4. Availability (or reliability)

    How long the system is up and running and the Mean Time Between Failure (MTBF) is known as the availability of a program.

    • How long does the system need to run without failure?
    • What is the acceptable length of time for the system to be down?
    • Can down times be scheduled?
  5. Extensibility
    • Can we add extensions to the product that will help users use it better?
    • Can third-party app developers and products use your product to help the user?
  6. Security

    The measure of system’s ability to resist unauthorized attempts at usage or behavior modification, while still providing service to legitimate users.

    • Does the system need user- or role-based security?
    • Does code-access security need to occur?
    • What operations need to be secured?
    • How will users be administered?
  7. Portability

    Portability is the ability of your application to run on numerous platforms. This can include mobile platforms (Android*, iPhones, Blackberry), application hosting, viewing, or data portability.

    • Can the data be migrated to other systems?
    • For web applications, which browsers does your web app support?

Product choices for various industries

The distracted-driver technology can be applied in various industries. Key ones include these:

  1. Insurance: The insurance industry would want to provide tools for drivers to drive safely, reducing the accident rates and hence reducing coverages for customers.
  2. Car accessories: Car-accessory manufacturers would want to provide this as a useful accessory for users who want to be reminded of impulsive behavior that might distract people from safe driving.
  3. Automotive manufacturers: May want to add this as a default for high-end vehicles.
  4. Banks: Would want to provide this product as a way of saying thank you to a customer when they get a car loan for an expensive car.
  5. Fleet management: Fleet-management companies for cars and trucks may want to monitor driving safety rules observed by drivers they employ.
  6. Mobile devices: Mobile phone manufacturers could add default apps for preventing distracted driving.

Automatic product-improvement methods

One important way that a product could enhance itself would be during use in the car. Here are some questions to ask:

  1. Can the product learn from the driver who is driving as of now? This would mean some transfer learning AI capabilities that would help the product get better with detection of distractions and the lack thereof with the actual driver, detects what precedes a distracted driver event.
  2. Can the product learn from the environment like: whether the car is stationary or moving, is the car being taken on a ferry, etc.? Technically this would involve the product integrating with other systems in the car or special inferencing for understanding the environments, GPS co-ordinates
  3. Can we learn anything from the sounds in the car, like baby crying behind, loud audio, traffic on the street or phone ringing?
  4. What can we infer from driving habits (speed, acceleration), from surrounding GPS locations, if any distractions due to environment like driver rubber-necking at an accident spot.

Conclusion

In summary, this five-part use case series on Combating Distracted-Driver Behavior walked through the entire process of creating an AI-based product from conceptualization to productization. While we give a sense of the entire process here, we take advantage of Intel® AI Technology to emphasize the AI research and software-development parts of the process.

For reference on AI Developer Project: Combating Distracted-Driver Behavior ›

Join the Intel® AI Academy

Sign up for the Intel® AI Academy and access essential learning materials, community, tools and technology to boost your AI development. Apply to become an Intel® Student Ambassador and share your expertise with other student data scientists and developers.

For more complete information about compiler optimizations, see our Optimization Notice.