- Newest
- Most votes
- Most comments
Hi Bala, I will explain the main differences and use cases and why the S32G box (Godlbox) has provided Greengrass and FleetWise. Let's begin with Greengrass: Greengrass is an edge runtime supporting cloud service. You can build your device software on top of the Greengrass edge runtime. However, AWS IoT FleetWise is purpose-built to collect and transform. Transfer vehicle data to the cloud in near real-time if you wish to do edge ML - Greengrass can be an excellent addition to run along with FleetWise, make inferences, then sends vehicle data to the cloud - if you only want to send telematics from the car to the cloud FleetWise can handle that for you, it has the libraries for most cars to understand the CAN data (let's say fluid temperatures or battery voltage) and send it to AWS - utilizing IoT core you can directly send that data to databases such as Timestream. Hence, as I mentioned, The AWS IoT FleetWise Edge Agent running in your vehicle's GoldBox uses data collection schemes to control what data to collect and when to transfer it to the cloud. Data collected and ingested through AWS IoT FleetWise Edge Agent software can go directly into your Amazon Timestream table via AWS IoT Core. Now let's understand the role IoT edge plays in this schema; AWS IoT FleetWise integrates with AWS IoT Core to support secure communication between the Edge Agent software and the cloud through MQTT. Each vehicle corresponds to an AWS IoT thing. You can use an existing AWS IoT thing to create a vehicle or set AWS IoT FleetWise to create an AWS IoT thing for your vehicle automatically. AWS IoT Core supports authentication and authorization that help securely control access to AWS IoT FleetWise resources. Vehicles can use X.509 certificates to get authenticated (signed in) to use AWS IoT FleetWise, and AWS IoT Core policies to get authorized (have permissions) to perform specified actions.
thank you for the clarifying question, fleetwise is not only for CAN data, it comes with decoder manifest configuration ready for most cars. I highly recommend looking at the sample architecture https://github.com/aws/aws-iot-fleetwise-edge/blob/main/docs/dev-guide/edge-agent-dev-guide.md here we explain how you can include variety of data (not just CAN) from any sensor with timestamp.
As per the readme document, decoder manifest offers a Raw CAN Data Decoder (Standard CAN), an OBD II (according to J1979 specification) decoder. And those have specific PIDs can be collected over these two interfaces. The software version number, GPS latitude longitude and other parameters are not available in the CAN/OBD II. So I don't find a way to include these parameters, please correct me if I'm wrong here.
Relevant content
- asked a year ago
- asked 2 years ago
AWS OFFICIALUpdated 10 months ago- AWS OFFICIALUpdated 5 months ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated 2 years ago
Thanks Andy for providing the good details.
I have another question related to data collection using Fleetwise and Greengrass. Since the fleetwise can collect and send only the CAN data, I'm going to use the Greengrass to send the rest of non-CAN data to cloud over MQTT for example the location details and other sensor data. Here the same data is sent to cloud in different paths and stored in the common database. This may lead to some missing correlation in the collected data. Is this the right way to collect the data for non-CAN data? If not, please suggest how to handle this scenario.
Thanks, Bala