Skip to content

Workflow

The process begins by defining the image requirements for inspections based on the client’s specifications. Next, we will provide the client with links to the AI Camera. The captured images will then be uploaded to the CAAS application via an API call.

The plain AI camera links are used only for the pilots which uses auto generated ref_num to capture and upload the images to CAAS API. If the plain is used for production clients, we have an screen to with the input field to get ref_num value. The plain AI camera links for Zurich have an additional input to capture the email id which sent while submitting the images to CAAS API.

The encrypted links are generated by CAAS API and it is separated from AI Camera workflow.

The encrypted URLs will have the required information injected to the HTML template using Jinja template system and the necessary variable will be set on the javascript window object. This includes the ref_num, link created timestamp. The decryption key is configured in creds table. and the decode order is defined in config table.

Generic image capture flow

Below are the API calls in sequence.

  1. /config This API is used to get the image capture configuration based on the endpoint from the URL. The AI Camera application will make this API call with source_name as query parameter read from URL where as the new TriNetra application sends this value as endpoint.

  2. /init_claim This API is used to make an entry in claims table, on subsequent API calls with same ref_num returns with increase in attempt number.

  3. /manual-capture This API is used to store the image in the backend, without AI validation. The meta data like for which side this is captured for will be part of the API request.

  4. /auto-capture This API is used to validate the image (car, VIN, Dashboard) and store it in the VM along with confidence value from AI model, an entry will be made in sides table.

  5. /upload - this will upload the images to CAAS API reading the images information from database based on ref_num and attempt number.

RSGI specific image capture flow

  1. /config - to get the capture configuration
  2. /get_current_state - to get the current status of inspection
  3. /init_claim_rsgi - initialize the inspection, will not consider attempt.
  4. /update_vehicle_subtype - to save vehicle type selection, not applicable for RSGIC
  5. /claim_type This API is to store the capture type "auto" mode or "manual" mode. In RSGIPI flow, the capture mode can be switched from auto to manual mode on the conditions mentioned below.

    • if the capture start time is between 9 AM and 6 PM, the capture mode switched to manual mode automatically
    • if the internet connection is slow, an option is shown to user to switch to manual mode
    • if the capture_mode values is not auto in the decrypted URL
  6. /manual-capture This API is used store the image in the backend, without AI validation.

    An entry made in the sides table and the image is saved in the VM.

  7. /api/v2/auto-capture This API is used to validate the image (car, VIN, Dashboard) and save it in the backend in temporary table auto_capture_images.

    An entry made in the auto_capture_images table and the image is saved in the VM.

  8. /api/v2/confirm-auto-captures This API is used to confirm the auto capture images those are saved to temporary table and moved the db entries to the sides table.

    This is implemented to force the user to capture the vehicle images in the predefined sequence, e.g., Front, FrontRight and not in any random order.

  9. /update_state This API will be called after each stage to update the inspection capture state and below are the states and their meaning. The current state information is saved in current_state table for each inspection.

    Below are the different current state values.

        0 - not initialized
        1 - initialized
        2 - video capture (NA for PI)
        3 - document capture
        4 - OTP screen (NA for Claims)
        5 - inspection completed
        7 - first recapture open
        8 - first recapture is complete
        9 - 2nd recapture is complete
    

    The current state is applicable only for RSGI inspections as these have the state management and others don't have this option.

  10. Video capture screen - applicable only for RSGIC, this is same as RSGIPI video capture in recapture flow. The video is saved to S3 and the url is store in the current_state table.

  11. Document upload screen - this contains the file upload fields which allows the user to upload the documents from the phone's storage. The documents are saved to S3 and the urls are store in the current_state table.

  12. /upload - In RSGI flow, this will validate whether all the required images are saved in the backend. It returns with 412 Precondition Failed as response if all the images are not capture. The status will be set to "Started" on the current_state table. The background service uploads the inspection images to CAAS API.

  13. /otp_details This API will make an API call to CAAS/ADDA API to get phone number and email id of customer and agent. It will make an API call to trigger the client managed API to deliver the OTP via an SMS and an email.

  14. /verify_otp This API is used to verify the OTP using client's API

  15. /update_state An API call is made with current state as 5 to marks the inspection as completed.

RSGIPI specific recapture flow

Video capture on Android devices

  1. /get_current_state We are allowing to take the 1st recapture video on two conditions mentioned below.

    1. current_state = 5 and window.is_recapture = "1"
    2. current_state = 7
  2. /upload_video_recp This API uploads the captured video to S3 and sends the url to CAAS API.

  3. /update_state An API call is made to update the state to 8, to mark the 1st recapture has been completed for the inspection.

Video capture on iOS devices (2nd recapture)

  1. /get_current_state We are allowing to take the 2nd recapture video on the condition mentioned below.

    1. current_state = 8 and window.is_recapture = 2
  2. /remove_directory This API call is redundant and can be removed. It was used to delete previously captured video frames.

  3. /auto_capture_frames This API saves video frames in a unique directory within the VM. A unique ID is generated on each page visit to ensure no repetition.

  4. /iphone/capture_complete This API compiles the video frames into an MP4 video, uploads the video to S3, and sends the URLs to the CAAS API.

  5. /update_state An API call is made to update the state to 9, to mark the 2nd recapture has been completed for the inspection.

Image upload service

This Docker service runs in the background and is specifically built for RSGI as we need to maintain the state for each inspection. This service uploads inspection images, videos, and documents (S3 URLs) to the CAAS API.