In this reference design, the TCU delivers vehicle telematics from the edge to the cloud.  The TCU acquires data from multiple simulated subsystems (for example ADAS and GNSS).  The TCU acquires the data from CAN/CAN-FD and Ethernet sources and propagates data to the cloud using fit-for-purpose mechanisms.  The fleet operator UI can manipulate/throttle TCU to cloud throughput.  The TCU uses fit for purpose mechanisms to deliver telematics data from the edge to the cloud securely, resiliently, and efficiently.  The demonstration uses the GATS, AEM/AEMP, ASAM, and ISO 15638-21:2018 telematics standards where applicable.

Reference Design Storyboard

This story board walks the evaluator through the expected experience when operating the reference design. It also acts as a story for delivering the demonstration to evaluators for live or recorded events.

Device Commissioning and Provisioning

How the device "turns on", starts operating with the local network, how it joins the upstream operator network.

Device throughput for local operation

Although the local device during normal operation would be headless, the demonstration has local output that demonstrates to the user the throughput for incoming data, how the TCU operates on that data, and then the "drop rate" or "sampling rate" or "aggregation rate" of data going to the cloud.

Cloud operator experience

After the local TCU shows to be operating properly, turn to a web console that in near real time displays statistics about the data coming from the TCU.  The UI should be a dashboard-like experience. (detail the experience per data type) 

Configuring tune-able parameters

From the web console, tune the property to change the video snippet size from 8 seconds to 4 seconds.

Change the data acquisition rate from 10 seconds to 5 seconds. 

Operating without connectivity (recorder)

Flip a switch to put the module into hibernation. This should signal the TCU that the upstream link is down, which in turn makes the TCU log additional data.

Operate the TCU for one minute, logging the data.

Flip the switch back on to demonstrate replay to the cloud.

Hardware Components

At this time, the following configuration has not been tested together, it is only "rough estimate"

  • Texas Instruments Jacinto J7
  • Quectel AG550Q

Software Components

  • Flutter (local visualization)
  • IoT Greengrass (local operation)


  • No labels

6 Comments

  1. Bernard Craddock

    Software Components instead of Qt visualization could it be flutter / web?

    1. Richard Elberger

      Yes it could. Will change up.

      1. Bernard Craddock

        Are you (as in amazon) developing all the software components yourselves or do you need or anticipate you'll need help with Flutter (local visualization), as interested in getting involved but can't afford the time and effort if AWS subsequently decide to trash, and rebuild everything themselves again from scratch if you know what i mean  

        1. Richard Elberger

          The goal is to showcase AGL capabilities while demonstrating a V2C workload.

          I would rather have collaboration than building new things for efforts not directly related to V2C (like UI).

          The  limit of AWS device side software choice will either be the AWS Device SDK for C++ or AWS IoT Greengrass.  I anticipate some custom development related to the SAE ATIS messaging.

          If Greengrass (v2 - which is now open source), then it would be very interesting to see Flutter UI affected by Greengrass compute emitted data.


  2. Richard Elberger

    Jan-Simon Moelleris there documentation on how to add a new AGL board target?  Would like to work on this so I can get it started the proper way. 

    We briefly discussed this in the Connectivity EG but it was unclear to me who would do it and/or if any of the core maintainers would have time to do it.

  3. Jan-Simon Moeller

    Hi Richard Elberger

    Scott Murray  is on it right now and we should have a template for next week.


    FYI:

    https://docs.automotivelinux.org/en/master/#6_How_To_Contribute/9_Contribution_Checklist/


    For adding a board, we use a simple template (few text files) in    meta-agl/templates/machine/

    So for a TI board, there is the example of the dra7xx-evm/ (aka Jacinto6).


    TLDR:

    These files are fragments that are concatenated by aglsetup.sh to build the final

      conf/bblayers.conf

      conf/local.conf

    as you know from bitbake projects already.

    We use the aglsetup.sh wrapper to deal with all the config options and specialities of (some) boards.


    HTH.