No version for distro humble showing github. Known supported distros are highlighted in the buttons above.
Package symbol

iotfleetwise package from aws-iot-fleetwise-edge repo

iotfleetwise

ROS Distro
github

Package Summary

Tags No category tags.
Version 1.0.3
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Description Reference Implementation for AWS IoT FleetWise
Checkout URI https://github.com/aws/aws-iot-fleetwise-edge.git
VCS Type git
VCS Version main
Last Updated 2025-08-12
Dev Status UNKNOWN
Released UNRELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

Reference Implementation for AWS IoT FleetWise

Additional Links

No additional links.

Maintainers

  • Contact us on GitHub: https://github.com/aws/aws-iot-fleetwise-edge

Authors

No additional authors.

Reference Implementation for AWS IoT FleetWise

AWS IoT FleetWise now supports:

[!NOTE] To quickly get started, jump to the Edge Agent Developer Guide, the ROS2 developer guide, the Android Guide, or the Raspberry Pi Tutorial.

AWS IoT FleetWise is a service that makes it easy for Automotive OEMs, Fleet operators, Independent Software vendors (ISVs) to collect, store, organize, and monitor data from vehicles at scale. The Reference Implementation for AWS IoT FleetWise (“FWE”) provides C++ libraries that can be run with simulated vehicle data on certain supported vehicle hardware or that can help you develop an Edge Agent to run an application on your vehicle that integrates with AWS IoT FleetWise. You can then use AWS IoT FleetWise’s to process the collected data, gain insights about the vehicle’s health and use the service’s visual interface to help diagnose and troubleshoot potential issues with your vehicles. Furthermore, AWS IoT FleetWise’s capability to collect ECU data and store them on cloud databases enables you to utilize different AWS services (Analytics Services, ML, etc.) to develop novel use-cases that augment your existing vehicle functionality. In particular, AWS IoT FleetWise can leverage fleet data (Big Data) and enable you to develop use cases that create business value, for example: improve electric vehicle range estimation, optimized battery life charging, optimized vehicle routing, etc. AWS IoT FleetWise can be extended to utilize cloud computing capabilities for use-cases such as helping to improve pet/child detection, Driver Monitoring System applications, Predictive Diagnostics, electric vehicle’s battery cells outlier detection, etc. You can use the included sample C++ application to learn more about the FWE, develop an Edge Agent for your use case and test interactions before integration.

[!IMPORTANT] As provided in the AWS IoT FleetWise Service Terms, you are solely responsible for your Edge Agent, including ensuring that your Edge Agent and any updates and modifications to it are deployed and maintained safely and securely in any vehicles.

AWS IoT FleetWise Architecture

AWS IoT FleetWise is an AWS service that enables automakers and fleet operators to collect, store, organize, and monitor data from vehicles. Automakers need the ability to connect remotely to their fleet of vehicles and collect vehicle ECU/sensor data. AWS IoT FleetWise can be used by OEM engineers and data scientists to build vehicle models that can be used to build custom data collection schemes. These data collection schemes enables the OEM to optimize the data collection process by defining what signals to collect, how often to collect them, and most importantly the trigger conditions (“events”) that enable the collection process.

Customers can define the data collection schemes to trigger based on a schedule or on specific conditions such as, but not limited to: 1. Ambient temperature dropping to below 0 degree or 2. Vehicle crosses state lines or 3. Active diagnostic trouble codes. These conditions are sent to the vehicle through a set of documents called data collection schemes. In summary, your Edge Agent collects the data of interest according to the data collection schemes and decoding rules as specified by the OEM on the AWS IoT FleetWise Console.

The following diagram illustrates a high-level architecture of the system.

FWE receives two documents:

  1. Decoder Manifest - this document describes how signals are collected from the vehicle, and will include details such as, but not limited to: Bus ID, network name, decoding information, etc.

  2. Data Collection Schemes - this document describes what signals to collect. It also describes the condition logic that defines the enablement of the trigger logic that allows these signals to be collected, for example, when Vehicle Speed > 100 km/Hr and Driver Seatbelt is Off and Ambient Temperature < 0 degree C.

FWE Deployment & Supported Platforms

The functional flexibility of FWE and its use of dynamic memory allocation means that it cannot reside in the real-time safety vehicle ECUs. FWE must also be connected to the internet and preferably has access to a “good” portion of vehicle ECU data. OEMs have the flexibility to decide where they can deploy their Edge Agent binary. Possible options include (if present):

  1. Vehicle Gateway such as the NXP S32G

File truncated at 100 lines see the full file

CHANGELOG

Change Log

v1.3.2 (2025-06-24)

Bug fixes:

  • Fixed race conditions in OBDOverCANModule, DataSenderIonWriter, CollectionInspectionWorkerThread and CANDataSource found by coverity 2024.3.1.

Improvements:

  • Refactored telemetry data serialization to ensure Store and Forward uses the same payload size optimizations as regular telemetry data.
  • Updated the default dependency installation prefix to /usr/local, enabling CMake to locate dependencies using its standard search paths without requiring explicit CMAKE_PREFIX_PATH argument.
  • Fixed various Coverity regressions.

v1.3.1 (2025-04-25)

Bug fixes:

  • Fixed memory growth in DTC
  • Fixed for use-after-free bug in CollectionInspectionEngine eval() function

v1.3.0 (2025-04-14)

Bug fixes:

  • Fixed crash when using Greengrass V2 connection type.

Improvements:

  • Improved guide for Greengrass V2
  • Added an option to fwdemo stack to use Greengrass V2 connection type. When MqttConnectionType is set to iotGreengrassV2, the EC2 instance will be configured as a Greengrass core device and FWE will be deployed as a Greengrass component.
  • Make SHA1 code compatible with Boost 1.86.0. The 1.84.0 version is still being used as a dependency, but the code should now compile with more recent versions too. Related to https://github.com/aws/aws-iot-fleetwise-edge/issues/119
  • Added system test framework with 70 reference system tests
  • Update to Ubuntu 22.04 for the development environment
    • Upgraded the ROS2 distribution from Galactic to Humble

v1.2.1 (2025-02-27)

New features:

  • Added Python support in expressions with custom function implementation for both CPython and MicroPython.
  • Added support for IEEE 754 floating-point signals for CAN and OBD.
  • Added support for signed OBD PID signals.
  • Added support for using FWE as an external library, see the examples.

Bug fixes:

  • Fixed deletion of buffer after hand over to sender.
  • Fixed memory leak when generating Ion files for Vision System Data. This was caused by a known issue in the ion-c library. To avoid that all ion-c function calls now happen in the same thread.
  • Fixed possible thread lockups in rare cases when system time jumps to the future, or due to a stdlibc++ issue. Includes the addition of the new option collectionSchemeManagerThreadIdleTimeMs.
  • Fixed sporadic SOME/IP build failures due to concurrent file generation.
  • Fixed possible hang during shutdown when feature FWE_FEATURE_UDS_DTC_EXAMPLE was enabled.

Improvements:

  • Add checksum for persisted files (e.g Collection scheme, Decoder manifest, Telemetry data). Now when writing a file, the persistency layer calculates the SHA1 for the content and write it to a file alongside the content file with a .sha1 extension. When reading the file, if the .sha1 file doesn’t exist it just logs a warning. This is intended to keep backward compatibility with files that were written by older FWE versions. Otherwise if the .sha1 file exists, a mismatch in the SHA1 when reading the content will cause both the content file and the .sha1 file to be deleted.
  • Store and forward optimized for systems with slow write speed to persistent storage.
  • Update GoogleTest to 1.15.2.
  • Removed unsupported raw CAN frame collection.
  • Added optional awsSdkLogLevel field to the config file. Valid values are Off, Fatal, Error, Warn, Info, Debug, Trace. Previously the AWS SDK logs were always disabled. This allows the logs to be configured in AwsBootstrap.cpp (see the SDK docs for more details). If this is set to some level different than Off, the SDK logs will be redirected to FWE’s logger. Since FWE doesn’t provide all levels, Fatal is mapped to FWE’s Error and Debug to FWE’s Trace.
  • IMDS is now disabled when creating an S3 client. In some situations this could cause delays when creating a new client (for more details see https://github.com/aws/aws-sdk-cpp/issues/1511).

v1.2.0 (2024-11-21)

New features:

File truncated at 100 lines see the full file

Package Dependencies

System Dependencies

No direct system dependencies.

Dependant Packages

No known dependants.

Recent questions tagged iotfleetwise at Robotics Stack Exchange

No version for distro jazzy showing github. Known supported distros are highlighted in the buttons above.
Package symbol

iotfleetwise package from aws-iot-fleetwise-edge repo

iotfleetwise

ROS Distro
github

Package Summary

Tags No category tags.
Version 1.0.3
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Description Reference Implementation for AWS IoT FleetWise
Checkout URI https://github.com/aws/aws-iot-fleetwise-edge.git
VCS Type git
VCS Version main
Last Updated 2025-08-12
Dev Status UNKNOWN
Released UNRELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

Reference Implementation for AWS IoT FleetWise

Additional Links

No additional links.

Maintainers

  • Contact us on GitHub: https://github.com/aws/aws-iot-fleetwise-edge

Authors

No additional authors.

Reference Implementation for AWS IoT FleetWise

AWS IoT FleetWise now supports:

[!NOTE] To quickly get started, jump to the Edge Agent Developer Guide, the ROS2 developer guide, the Android Guide, or the Raspberry Pi Tutorial.

AWS IoT FleetWise is a service that makes it easy for Automotive OEMs, Fleet operators, Independent Software vendors (ISVs) to collect, store, organize, and monitor data from vehicles at scale. The Reference Implementation for AWS IoT FleetWise (“FWE”) provides C++ libraries that can be run with simulated vehicle data on certain supported vehicle hardware or that can help you develop an Edge Agent to run an application on your vehicle that integrates with AWS IoT FleetWise. You can then use AWS IoT FleetWise’s to process the collected data, gain insights about the vehicle’s health and use the service’s visual interface to help diagnose and troubleshoot potential issues with your vehicles. Furthermore, AWS IoT FleetWise’s capability to collect ECU data and store them on cloud databases enables you to utilize different AWS services (Analytics Services, ML, etc.) to develop novel use-cases that augment your existing vehicle functionality. In particular, AWS IoT FleetWise can leverage fleet data (Big Data) and enable you to develop use cases that create business value, for example: improve electric vehicle range estimation, optimized battery life charging, optimized vehicle routing, etc. AWS IoT FleetWise can be extended to utilize cloud computing capabilities for use-cases such as helping to improve pet/child detection, Driver Monitoring System applications, Predictive Diagnostics, electric vehicle’s battery cells outlier detection, etc. You can use the included sample C++ application to learn more about the FWE, develop an Edge Agent for your use case and test interactions before integration.

[!IMPORTANT] As provided in the AWS IoT FleetWise Service Terms, you are solely responsible for your Edge Agent, including ensuring that your Edge Agent and any updates and modifications to it are deployed and maintained safely and securely in any vehicles.

AWS IoT FleetWise Architecture

AWS IoT FleetWise is an AWS service that enables automakers and fleet operators to collect, store, organize, and monitor data from vehicles. Automakers need the ability to connect remotely to their fleet of vehicles and collect vehicle ECU/sensor data. AWS IoT FleetWise can be used by OEM engineers and data scientists to build vehicle models that can be used to build custom data collection schemes. These data collection schemes enables the OEM to optimize the data collection process by defining what signals to collect, how often to collect them, and most importantly the trigger conditions (“events”) that enable the collection process.

Customers can define the data collection schemes to trigger based on a schedule or on specific conditions such as, but not limited to: 1. Ambient temperature dropping to below 0 degree or 2. Vehicle crosses state lines or 3. Active diagnostic trouble codes. These conditions are sent to the vehicle through a set of documents called data collection schemes. In summary, your Edge Agent collects the data of interest according to the data collection schemes and decoding rules as specified by the OEM on the AWS IoT FleetWise Console.

The following diagram illustrates a high-level architecture of the system.

FWE receives two documents:

  1. Decoder Manifest - this document describes how signals are collected from the vehicle, and will include details such as, but not limited to: Bus ID, network name, decoding information, etc.

  2. Data Collection Schemes - this document describes what signals to collect. It also describes the condition logic that defines the enablement of the trigger logic that allows these signals to be collected, for example, when Vehicle Speed > 100 km/Hr and Driver Seatbelt is Off and Ambient Temperature < 0 degree C.

FWE Deployment & Supported Platforms

The functional flexibility of FWE and its use of dynamic memory allocation means that it cannot reside in the real-time safety vehicle ECUs. FWE must also be connected to the internet and preferably has access to a “good” portion of vehicle ECU data. OEMs have the flexibility to decide where they can deploy their Edge Agent binary. Possible options include (if present):

  1. Vehicle Gateway such as the NXP S32G

File truncated at 100 lines see the full file

CHANGELOG

Change Log

v1.3.2 (2025-06-24)

Bug fixes:

  • Fixed race conditions in OBDOverCANModule, DataSenderIonWriter, CollectionInspectionWorkerThread and CANDataSource found by coverity 2024.3.1.

Improvements:

  • Refactored telemetry data serialization to ensure Store and Forward uses the same payload size optimizations as regular telemetry data.
  • Updated the default dependency installation prefix to /usr/local, enabling CMake to locate dependencies using its standard search paths without requiring explicit CMAKE_PREFIX_PATH argument.
  • Fixed various Coverity regressions.

v1.3.1 (2025-04-25)

Bug fixes:

  • Fixed memory growth in DTC
  • Fixed for use-after-free bug in CollectionInspectionEngine eval() function

v1.3.0 (2025-04-14)

Bug fixes:

  • Fixed crash when using Greengrass V2 connection type.

Improvements:

  • Improved guide for Greengrass V2
  • Added an option to fwdemo stack to use Greengrass V2 connection type. When MqttConnectionType is set to iotGreengrassV2, the EC2 instance will be configured as a Greengrass core device and FWE will be deployed as a Greengrass component.
  • Make SHA1 code compatible with Boost 1.86.0. The 1.84.0 version is still being used as a dependency, but the code should now compile with more recent versions too. Related to https://github.com/aws/aws-iot-fleetwise-edge/issues/119
  • Added system test framework with 70 reference system tests
  • Update to Ubuntu 22.04 for the development environment
    • Upgraded the ROS2 distribution from Galactic to Humble

v1.2.1 (2025-02-27)

New features:

  • Added Python support in expressions with custom function implementation for both CPython and MicroPython.
  • Added support for IEEE 754 floating-point signals for CAN and OBD.
  • Added support for signed OBD PID signals.
  • Added support for using FWE as an external library, see the examples.

Bug fixes:

  • Fixed deletion of buffer after hand over to sender.
  • Fixed memory leak when generating Ion files for Vision System Data. This was caused by a known issue in the ion-c library. To avoid that all ion-c function calls now happen in the same thread.
  • Fixed possible thread lockups in rare cases when system time jumps to the future, or due to a stdlibc++ issue. Includes the addition of the new option collectionSchemeManagerThreadIdleTimeMs.
  • Fixed sporadic SOME/IP build failures due to concurrent file generation.
  • Fixed possible hang during shutdown when feature FWE_FEATURE_UDS_DTC_EXAMPLE was enabled.

Improvements:

  • Add checksum for persisted files (e.g Collection scheme, Decoder manifest, Telemetry data). Now when writing a file, the persistency layer calculates the SHA1 for the content and write it to a file alongside the content file with a .sha1 extension. When reading the file, if the .sha1 file doesn’t exist it just logs a warning. This is intended to keep backward compatibility with files that were written by older FWE versions. Otherwise if the .sha1 file exists, a mismatch in the SHA1 when reading the content will cause both the content file and the .sha1 file to be deleted.
  • Store and forward optimized for systems with slow write speed to persistent storage.
  • Update GoogleTest to 1.15.2.
  • Removed unsupported raw CAN frame collection.
  • Added optional awsSdkLogLevel field to the config file. Valid values are Off, Fatal, Error, Warn, Info, Debug, Trace. Previously the AWS SDK logs were always disabled. This allows the logs to be configured in AwsBootstrap.cpp (see the SDK docs for more details). If this is set to some level different than Off, the SDK logs will be redirected to FWE’s logger. Since FWE doesn’t provide all levels, Fatal is mapped to FWE’s Error and Debug to FWE’s Trace.
  • IMDS is now disabled when creating an S3 client. In some situations this could cause delays when creating a new client (for more details see https://github.com/aws/aws-sdk-cpp/issues/1511).

v1.2.0 (2024-11-21)

New features:

File truncated at 100 lines see the full file

Package Dependencies

System Dependencies

No direct system dependencies.

Dependant Packages

No known dependants.

Recent questions tagged iotfleetwise at Robotics Stack Exchange

No version for distro kilted showing github. Known supported distros are highlighted in the buttons above.
Package symbol

iotfleetwise package from aws-iot-fleetwise-edge repo

iotfleetwise

ROS Distro
github

Package Summary

Tags No category tags.
Version 1.0.3
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Description Reference Implementation for AWS IoT FleetWise
Checkout URI https://github.com/aws/aws-iot-fleetwise-edge.git
VCS Type git
VCS Version main
Last Updated 2025-08-12
Dev Status UNKNOWN
Released UNRELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

Reference Implementation for AWS IoT FleetWise

Additional Links

No additional links.

Maintainers

  • Contact us on GitHub: https://github.com/aws/aws-iot-fleetwise-edge

Authors

No additional authors.

Reference Implementation for AWS IoT FleetWise

AWS IoT FleetWise now supports:

[!NOTE] To quickly get started, jump to the Edge Agent Developer Guide, the ROS2 developer guide, the Android Guide, or the Raspberry Pi Tutorial.

AWS IoT FleetWise is a service that makes it easy for Automotive OEMs, Fleet operators, Independent Software vendors (ISVs) to collect, store, organize, and monitor data from vehicles at scale. The Reference Implementation for AWS IoT FleetWise (“FWE”) provides C++ libraries that can be run with simulated vehicle data on certain supported vehicle hardware or that can help you develop an Edge Agent to run an application on your vehicle that integrates with AWS IoT FleetWise. You can then use AWS IoT FleetWise’s to process the collected data, gain insights about the vehicle’s health and use the service’s visual interface to help diagnose and troubleshoot potential issues with your vehicles. Furthermore, AWS IoT FleetWise’s capability to collect ECU data and store them on cloud databases enables you to utilize different AWS services (Analytics Services, ML, etc.) to develop novel use-cases that augment your existing vehicle functionality. In particular, AWS IoT FleetWise can leverage fleet data (Big Data) and enable you to develop use cases that create business value, for example: improve electric vehicle range estimation, optimized battery life charging, optimized vehicle routing, etc. AWS IoT FleetWise can be extended to utilize cloud computing capabilities for use-cases such as helping to improve pet/child detection, Driver Monitoring System applications, Predictive Diagnostics, electric vehicle’s battery cells outlier detection, etc. You can use the included sample C++ application to learn more about the FWE, develop an Edge Agent for your use case and test interactions before integration.

[!IMPORTANT] As provided in the AWS IoT FleetWise Service Terms, you are solely responsible for your Edge Agent, including ensuring that your Edge Agent and any updates and modifications to it are deployed and maintained safely and securely in any vehicles.

AWS IoT FleetWise Architecture

AWS IoT FleetWise is an AWS service that enables automakers and fleet operators to collect, store, organize, and monitor data from vehicles. Automakers need the ability to connect remotely to their fleet of vehicles and collect vehicle ECU/sensor data. AWS IoT FleetWise can be used by OEM engineers and data scientists to build vehicle models that can be used to build custom data collection schemes. These data collection schemes enables the OEM to optimize the data collection process by defining what signals to collect, how often to collect them, and most importantly the trigger conditions (“events”) that enable the collection process.

Customers can define the data collection schemes to trigger based on a schedule or on specific conditions such as, but not limited to: 1. Ambient temperature dropping to below 0 degree or 2. Vehicle crosses state lines or 3. Active diagnostic trouble codes. These conditions are sent to the vehicle through a set of documents called data collection schemes. In summary, your Edge Agent collects the data of interest according to the data collection schemes and decoding rules as specified by the OEM on the AWS IoT FleetWise Console.

The following diagram illustrates a high-level architecture of the system.

FWE receives two documents:

  1. Decoder Manifest - this document describes how signals are collected from the vehicle, and will include details such as, but not limited to: Bus ID, network name, decoding information, etc.

  2. Data Collection Schemes - this document describes what signals to collect. It also describes the condition logic that defines the enablement of the trigger logic that allows these signals to be collected, for example, when Vehicle Speed > 100 km/Hr and Driver Seatbelt is Off and Ambient Temperature < 0 degree C.

FWE Deployment & Supported Platforms

The functional flexibility of FWE and its use of dynamic memory allocation means that it cannot reside in the real-time safety vehicle ECUs. FWE must also be connected to the internet and preferably has access to a “good” portion of vehicle ECU data. OEMs have the flexibility to decide where they can deploy their Edge Agent binary. Possible options include (if present):

  1. Vehicle Gateway such as the NXP S32G

File truncated at 100 lines see the full file

CHANGELOG

Change Log

v1.3.2 (2025-06-24)

Bug fixes:

  • Fixed race conditions in OBDOverCANModule, DataSenderIonWriter, CollectionInspectionWorkerThread and CANDataSource found by coverity 2024.3.1.

Improvements:

  • Refactored telemetry data serialization to ensure Store and Forward uses the same payload size optimizations as regular telemetry data.
  • Updated the default dependency installation prefix to /usr/local, enabling CMake to locate dependencies using its standard search paths without requiring explicit CMAKE_PREFIX_PATH argument.
  • Fixed various Coverity regressions.

v1.3.1 (2025-04-25)

Bug fixes:

  • Fixed memory growth in DTC
  • Fixed for use-after-free bug in CollectionInspectionEngine eval() function

v1.3.0 (2025-04-14)

Bug fixes:

  • Fixed crash when using Greengrass V2 connection type.

Improvements:

  • Improved guide for Greengrass V2
  • Added an option to fwdemo stack to use Greengrass V2 connection type. When MqttConnectionType is set to iotGreengrassV2, the EC2 instance will be configured as a Greengrass core device and FWE will be deployed as a Greengrass component.
  • Make SHA1 code compatible with Boost 1.86.0. The 1.84.0 version is still being used as a dependency, but the code should now compile with more recent versions too. Related to https://github.com/aws/aws-iot-fleetwise-edge/issues/119
  • Added system test framework with 70 reference system tests
  • Update to Ubuntu 22.04 for the development environment
    • Upgraded the ROS2 distribution from Galactic to Humble

v1.2.1 (2025-02-27)

New features:

  • Added Python support in expressions with custom function implementation for both CPython and MicroPython.
  • Added support for IEEE 754 floating-point signals for CAN and OBD.
  • Added support for signed OBD PID signals.
  • Added support for using FWE as an external library, see the examples.

Bug fixes:

  • Fixed deletion of buffer after hand over to sender.
  • Fixed memory leak when generating Ion files for Vision System Data. This was caused by a known issue in the ion-c library. To avoid that all ion-c function calls now happen in the same thread.
  • Fixed possible thread lockups in rare cases when system time jumps to the future, or due to a stdlibc++ issue. Includes the addition of the new option collectionSchemeManagerThreadIdleTimeMs.
  • Fixed sporadic SOME/IP build failures due to concurrent file generation.
  • Fixed possible hang during shutdown when feature FWE_FEATURE_UDS_DTC_EXAMPLE was enabled.

Improvements:

  • Add checksum for persisted files (e.g Collection scheme, Decoder manifest, Telemetry data). Now when writing a file, the persistency layer calculates the SHA1 for the content and write it to a file alongside the content file with a .sha1 extension. When reading the file, if the .sha1 file doesn’t exist it just logs a warning. This is intended to keep backward compatibility with files that were written by older FWE versions. Otherwise if the .sha1 file exists, a mismatch in the SHA1 when reading the content will cause both the content file and the .sha1 file to be deleted.
  • Store and forward optimized for systems with slow write speed to persistent storage.
  • Update GoogleTest to 1.15.2.
  • Removed unsupported raw CAN frame collection.
  • Added optional awsSdkLogLevel field to the config file. Valid values are Off, Fatal, Error, Warn, Info, Debug, Trace. Previously the AWS SDK logs were always disabled. This allows the logs to be configured in AwsBootstrap.cpp (see the SDK docs for more details). If this is set to some level different than Off, the SDK logs will be redirected to FWE’s logger. Since FWE doesn’t provide all levels, Fatal is mapped to FWE’s Error and Debug to FWE’s Trace.
  • IMDS is now disabled when creating an S3 client. In some situations this could cause delays when creating a new client (for more details see https://github.com/aws/aws-sdk-cpp/issues/1511).

v1.2.0 (2024-11-21)

New features:

File truncated at 100 lines see the full file

Package Dependencies

System Dependencies

No direct system dependencies.

Dependant Packages

No known dependants.

Recent questions tagged iotfleetwise at Robotics Stack Exchange

No version for distro rolling showing github. Known supported distros are highlighted in the buttons above.
Package symbol

iotfleetwise package from aws-iot-fleetwise-edge repo

iotfleetwise

ROS Distro
github

Package Summary

Tags No category tags.
Version 1.0.3
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Description Reference Implementation for AWS IoT FleetWise
Checkout URI https://github.com/aws/aws-iot-fleetwise-edge.git
VCS Type git
VCS Version main
Last Updated 2025-08-12
Dev Status UNKNOWN
Released UNRELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

Reference Implementation for AWS IoT FleetWise

Additional Links

No additional links.

Maintainers

  • Contact us on GitHub: https://github.com/aws/aws-iot-fleetwise-edge

Authors

No additional authors.

Reference Implementation for AWS IoT FleetWise

AWS IoT FleetWise now supports:

[!NOTE] To quickly get started, jump to the Edge Agent Developer Guide, the ROS2 developer guide, the Android Guide, or the Raspberry Pi Tutorial.

AWS IoT FleetWise is a service that makes it easy for Automotive OEMs, Fleet operators, Independent Software vendors (ISVs) to collect, store, organize, and monitor data from vehicles at scale. The Reference Implementation for AWS IoT FleetWise (“FWE”) provides C++ libraries that can be run with simulated vehicle data on certain supported vehicle hardware or that can help you develop an Edge Agent to run an application on your vehicle that integrates with AWS IoT FleetWise. You can then use AWS IoT FleetWise’s to process the collected data, gain insights about the vehicle’s health and use the service’s visual interface to help diagnose and troubleshoot potential issues with your vehicles. Furthermore, AWS IoT FleetWise’s capability to collect ECU data and store them on cloud databases enables you to utilize different AWS services (Analytics Services, ML, etc.) to develop novel use-cases that augment your existing vehicle functionality. In particular, AWS IoT FleetWise can leverage fleet data (Big Data) and enable you to develop use cases that create business value, for example: improve electric vehicle range estimation, optimized battery life charging, optimized vehicle routing, etc. AWS IoT FleetWise can be extended to utilize cloud computing capabilities for use-cases such as helping to improve pet/child detection, Driver Monitoring System applications, Predictive Diagnostics, electric vehicle’s battery cells outlier detection, etc. You can use the included sample C++ application to learn more about the FWE, develop an Edge Agent for your use case and test interactions before integration.

[!IMPORTANT] As provided in the AWS IoT FleetWise Service Terms, you are solely responsible for your Edge Agent, including ensuring that your Edge Agent and any updates and modifications to it are deployed and maintained safely and securely in any vehicles.

AWS IoT FleetWise Architecture

AWS IoT FleetWise is an AWS service that enables automakers and fleet operators to collect, store, organize, and monitor data from vehicles. Automakers need the ability to connect remotely to their fleet of vehicles and collect vehicle ECU/sensor data. AWS IoT FleetWise can be used by OEM engineers and data scientists to build vehicle models that can be used to build custom data collection schemes. These data collection schemes enables the OEM to optimize the data collection process by defining what signals to collect, how often to collect them, and most importantly the trigger conditions (“events”) that enable the collection process.

Customers can define the data collection schemes to trigger based on a schedule or on specific conditions such as, but not limited to: 1. Ambient temperature dropping to below 0 degree or 2. Vehicle crosses state lines or 3. Active diagnostic trouble codes. These conditions are sent to the vehicle through a set of documents called data collection schemes. In summary, your Edge Agent collects the data of interest according to the data collection schemes and decoding rules as specified by the OEM on the AWS IoT FleetWise Console.

The following diagram illustrates a high-level architecture of the system.

FWE receives two documents:

  1. Decoder Manifest - this document describes how signals are collected from the vehicle, and will include details such as, but not limited to: Bus ID, network name, decoding information, etc.

  2. Data Collection Schemes - this document describes what signals to collect. It also describes the condition logic that defines the enablement of the trigger logic that allows these signals to be collected, for example, when Vehicle Speed > 100 km/Hr and Driver Seatbelt is Off and Ambient Temperature < 0 degree C.

FWE Deployment & Supported Platforms

The functional flexibility of FWE and its use of dynamic memory allocation means that it cannot reside in the real-time safety vehicle ECUs. FWE must also be connected to the internet and preferably has access to a “good” portion of vehicle ECU data. OEMs have the flexibility to decide where they can deploy their Edge Agent binary. Possible options include (if present):

  1. Vehicle Gateway such as the NXP S32G

File truncated at 100 lines see the full file

CHANGELOG

Change Log

v1.3.2 (2025-06-24)

Bug fixes:

  • Fixed race conditions in OBDOverCANModule, DataSenderIonWriter, CollectionInspectionWorkerThread and CANDataSource found by coverity 2024.3.1.

Improvements:

  • Refactored telemetry data serialization to ensure Store and Forward uses the same payload size optimizations as regular telemetry data.
  • Updated the default dependency installation prefix to /usr/local, enabling CMake to locate dependencies using its standard search paths without requiring explicit CMAKE_PREFIX_PATH argument.
  • Fixed various Coverity regressions.

v1.3.1 (2025-04-25)

Bug fixes:

  • Fixed memory growth in DTC
  • Fixed for use-after-free bug in CollectionInspectionEngine eval() function

v1.3.0 (2025-04-14)

Bug fixes:

  • Fixed crash when using Greengrass V2 connection type.

Improvements:

  • Improved guide for Greengrass V2
  • Added an option to fwdemo stack to use Greengrass V2 connection type. When MqttConnectionType is set to iotGreengrassV2, the EC2 instance will be configured as a Greengrass core device and FWE will be deployed as a Greengrass component.
  • Make SHA1 code compatible with Boost 1.86.0. The 1.84.0 version is still being used as a dependency, but the code should now compile with more recent versions too. Related to https://github.com/aws/aws-iot-fleetwise-edge/issues/119
  • Added system test framework with 70 reference system tests
  • Update to Ubuntu 22.04 for the development environment
    • Upgraded the ROS2 distribution from Galactic to Humble

v1.2.1 (2025-02-27)

New features:

  • Added Python support in expressions with custom function implementation for both CPython and MicroPython.
  • Added support for IEEE 754 floating-point signals for CAN and OBD.
  • Added support for signed OBD PID signals.
  • Added support for using FWE as an external library, see the examples.

Bug fixes:

  • Fixed deletion of buffer after hand over to sender.
  • Fixed memory leak when generating Ion files for Vision System Data. This was caused by a known issue in the ion-c library. To avoid that all ion-c function calls now happen in the same thread.
  • Fixed possible thread lockups in rare cases when system time jumps to the future, or due to a stdlibc++ issue. Includes the addition of the new option collectionSchemeManagerThreadIdleTimeMs.
  • Fixed sporadic SOME/IP build failures due to concurrent file generation.
  • Fixed possible hang during shutdown when feature FWE_FEATURE_UDS_DTC_EXAMPLE was enabled.

Improvements:

  • Add checksum for persisted files (e.g Collection scheme, Decoder manifest, Telemetry data). Now when writing a file, the persistency layer calculates the SHA1 for the content and write it to a file alongside the content file with a .sha1 extension. When reading the file, if the .sha1 file doesn’t exist it just logs a warning. This is intended to keep backward compatibility with files that were written by older FWE versions. Otherwise if the .sha1 file exists, a mismatch in the SHA1 when reading the content will cause both the content file and the .sha1 file to be deleted.
  • Store and forward optimized for systems with slow write speed to persistent storage.
  • Update GoogleTest to 1.15.2.
  • Removed unsupported raw CAN frame collection.
  • Added optional awsSdkLogLevel field to the config file. Valid values are Off, Fatal, Error, Warn, Info, Debug, Trace. Previously the AWS SDK logs were always disabled. This allows the logs to be configured in AwsBootstrap.cpp (see the SDK docs for more details). If this is set to some level different than Off, the SDK logs will be redirected to FWE’s logger. Since FWE doesn’t provide all levels, Fatal is mapped to FWE’s Error and Debug to FWE’s Trace.
  • IMDS is now disabled when creating an S3 client. In some situations this could cause delays when creating a new client (for more details see https://github.com/aws/aws-sdk-cpp/issues/1511).

v1.2.0 (2024-11-21)

New features:

File truncated at 100 lines see the full file

Package Dependencies

System Dependencies

No direct system dependencies.

Dependant Packages

No known dependants.

Recent questions tagged iotfleetwise at Robotics Stack Exchange

Package symbol

iotfleetwise package from aws-iot-fleetwise-edge repo

iotfleetwise

ROS Distro
github

Package Summary

Tags No category tags.
Version 1.0.3
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Description Reference Implementation for AWS IoT FleetWise
Checkout URI https://github.com/aws/aws-iot-fleetwise-edge.git
VCS Type git
VCS Version main
Last Updated 2025-08-12
Dev Status UNKNOWN
Released UNRELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

Reference Implementation for AWS IoT FleetWise

Additional Links

No additional links.

Maintainers

  • Contact us on GitHub: https://github.com/aws/aws-iot-fleetwise-edge

Authors

No additional authors.

Reference Implementation for AWS IoT FleetWise

AWS IoT FleetWise now supports:

[!NOTE] To quickly get started, jump to the Edge Agent Developer Guide, the ROS2 developer guide, the Android Guide, or the Raspberry Pi Tutorial.

AWS IoT FleetWise is a service that makes it easy for Automotive OEMs, Fleet operators, Independent Software vendors (ISVs) to collect, store, organize, and monitor data from vehicles at scale. The Reference Implementation for AWS IoT FleetWise (“FWE”) provides C++ libraries that can be run with simulated vehicle data on certain supported vehicle hardware or that can help you develop an Edge Agent to run an application on your vehicle that integrates with AWS IoT FleetWise. You can then use AWS IoT FleetWise’s to process the collected data, gain insights about the vehicle’s health and use the service’s visual interface to help diagnose and troubleshoot potential issues with your vehicles. Furthermore, AWS IoT FleetWise’s capability to collect ECU data and store them on cloud databases enables you to utilize different AWS services (Analytics Services, ML, etc.) to develop novel use-cases that augment your existing vehicle functionality. In particular, AWS IoT FleetWise can leverage fleet data (Big Data) and enable you to develop use cases that create business value, for example: improve electric vehicle range estimation, optimized battery life charging, optimized vehicle routing, etc. AWS IoT FleetWise can be extended to utilize cloud computing capabilities for use-cases such as helping to improve pet/child detection, Driver Monitoring System applications, Predictive Diagnostics, electric vehicle’s battery cells outlier detection, etc. You can use the included sample C++ application to learn more about the FWE, develop an Edge Agent for your use case and test interactions before integration.

[!IMPORTANT] As provided in the AWS IoT FleetWise Service Terms, you are solely responsible for your Edge Agent, including ensuring that your Edge Agent and any updates and modifications to it are deployed and maintained safely and securely in any vehicles.

AWS IoT FleetWise Architecture

AWS IoT FleetWise is an AWS service that enables automakers and fleet operators to collect, store, organize, and monitor data from vehicles. Automakers need the ability to connect remotely to their fleet of vehicles and collect vehicle ECU/sensor data. AWS IoT FleetWise can be used by OEM engineers and data scientists to build vehicle models that can be used to build custom data collection schemes. These data collection schemes enables the OEM to optimize the data collection process by defining what signals to collect, how often to collect them, and most importantly the trigger conditions (“events”) that enable the collection process.

Customers can define the data collection schemes to trigger based on a schedule or on specific conditions such as, but not limited to: 1. Ambient temperature dropping to below 0 degree or 2. Vehicle crosses state lines or 3. Active diagnostic trouble codes. These conditions are sent to the vehicle through a set of documents called data collection schemes. In summary, your Edge Agent collects the data of interest according to the data collection schemes and decoding rules as specified by the OEM on the AWS IoT FleetWise Console.

The following diagram illustrates a high-level architecture of the system.

FWE receives two documents:

  1. Decoder Manifest - this document describes how signals are collected from the vehicle, and will include details such as, but not limited to: Bus ID, network name, decoding information, etc.

  2. Data Collection Schemes - this document describes what signals to collect. It also describes the condition logic that defines the enablement of the trigger logic that allows these signals to be collected, for example, when Vehicle Speed > 100 km/Hr and Driver Seatbelt is Off and Ambient Temperature < 0 degree C.

FWE Deployment & Supported Platforms

The functional flexibility of FWE and its use of dynamic memory allocation means that it cannot reside in the real-time safety vehicle ECUs. FWE must also be connected to the internet and preferably has access to a “good” portion of vehicle ECU data. OEMs have the flexibility to decide where they can deploy their Edge Agent binary. Possible options include (if present):

  1. Vehicle Gateway such as the NXP S32G

File truncated at 100 lines see the full file

CHANGELOG

Change Log

v1.3.2 (2025-06-24)

Bug fixes:

  • Fixed race conditions in OBDOverCANModule, DataSenderIonWriter, CollectionInspectionWorkerThread and CANDataSource found by coverity 2024.3.1.

Improvements:

  • Refactored telemetry data serialization to ensure Store and Forward uses the same payload size optimizations as regular telemetry data.
  • Updated the default dependency installation prefix to /usr/local, enabling CMake to locate dependencies using its standard search paths without requiring explicit CMAKE_PREFIX_PATH argument.
  • Fixed various Coverity regressions.

v1.3.1 (2025-04-25)

Bug fixes:

  • Fixed memory growth in DTC
  • Fixed for use-after-free bug in CollectionInspectionEngine eval() function

v1.3.0 (2025-04-14)

Bug fixes:

  • Fixed crash when using Greengrass V2 connection type.

Improvements:

  • Improved guide for Greengrass V2
  • Added an option to fwdemo stack to use Greengrass V2 connection type. When MqttConnectionType is set to iotGreengrassV2, the EC2 instance will be configured as a Greengrass core device and FWE will be deployed as a Greengrass component.
  • Make SHA1 code compatible with Boost 1.86.0. The 1.84.0 version is still being used as a dependency, but the code should now compile with more recent versions too. Related to https://github.com/aws/aws-iot-fleetwise-edge/issues/119
  • Added system test framework with 70 reference system tests
  • Update to Ubuntu 22.04 for the development environment
    • Upgraded the ROS2 distribution from Galactic to Humble

v1.2.1 (2025-02-27)

New features:

  • Added Python support in expressions with custom function implementation for both CPython and MicroPython.
  • Added support for IEEE 754 floating-point signals for CAN and OBD.
  • Added support for signed OBD PID signals.
  • Added support for using FWE as an external library, see the examples.

Bug fixes:

  • Fixed deletion of buffer after hand over to sender.
  • Fixed memory leak when generating Ion files for Vision System Data. This was caused by a known issue in the ion-c library. To avoid that all ion-c function calls now happen in the same thread.
  • Fixed possible thread lockups in rare cases when system time jumps to the future, or due to a stdlibc++ issue. Includes the addition of the new option collectionSchemeManagerThreadIdleTimeMs.
  • Fixed sporadic SOME/IP build failures due to concurrent file generation.
  • Fixed possible hang during shutdown when feature FWE_FEATURE_UDS_DTC_EXAMPLE was enabled.

Improvements:

  • Add checksum for persisted files (e.g Collection scheme, Decoder manifest, Telemetry data). Now when writing a file, the persistency layer calculates the SHA1 for the content and write it to a file alongside the content file with a .sha1 extension. When reading the file, if the .sha1 file doesn’t exist it just logs a warning. This is intended to keep backward compatibility with files that were written by older FWE versions. Otherwise if the .sha1 file exists, a mismatch in the SHA1 when reading the content will cause both the content file and the .sha1 file to be deleted.
  • Store and forward optimized for systems with slow write speed to persistent storage.
  • Update GoogleTest to 1.15.2.
  • Removed unsupported raw CAN frame collection.
  • Added optional awsSdkLogLevel field to the config file. Valid values are Off, Fatal, Error, Warn, Info, Debug, Trace. Previously the AWS SDK logs were always disabled. This allows the logs to be configured in AwsBootstrap.cpp (see the SDK docs for more details). If this is set to some level different than Off, the SDK logs will be redirected to FWE’s logger. Since FWE doesn’t provide all levels, Fatal is mapped to FWE’s Error and Debug to FWE’s Trace.
  • IMDS is now disabled when creating an S3 client. In some situations this could cause delays when creating a new client (for more details see https://github.com/aws/aws-sdk-cpp/issues/1511).

v1.2.0 (2024-11-21)

New features:

File truncated at 100 lines see the full file

Package Dependencies

System Dependencies

No direct system dependencies.

Dependant Packages

No known dependants.

Recent questions tagged iotfleetwise at Robotics Stack Exchange

No version for distro galactic showing github. Known supported distros are highlighted in the buttons above.
Package symbol

iotfleetwise package from aws-iot-fleetwise-edge repo

iotfleetwise

ROS Distro
github

Package Summary

Tags No category tags.
Version 1.0.3
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Description Reference Implementation for AWS IoT FleetWise
Checkout URI https://github.com/aws/aws-iot-fleetwise-edge.git
VCS Type git
VCS Version main
Last Updated 2025-08-12
Dev Status UNKNOWN
Released UNRELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

Reference Implementation for AWS IoT FleetWise

Additional Links

No additional links.

Maintainers

  • Contact us on GitHub: https://github.com/aws/aws-iot-fleetwise-edge

Authors

No additional authors.

Reference Implementation for AWS IoT FleetWise

AWS IoT FleetWise now supports:

[!NOTE] To quickly get started, jump to the Edge Agent Developer Guide, the ROS2 developer guide, the Android Guide, or the Raspberry Pi Tutorial.

AWS IoT FleetWise is a service that makes it easy for Automotive OEMs, Fleet operators, Independent Software vendors (ISVs) to collect, store, organize, and monitor data from vehicles at scale. The Reference Implementation for AWS IoT FleetWise (“FWE”) provides C++ libraries that can be run with simulated vehicle data on certain supported vehicle hardware or that can help you develop an Edge Agent to run an application on your vehicle that integrates with AWS IoT FleetWise. You can then use AWS IoT FleetWise’s to process the collected data, gain insights about the vehicle’s health and use the service’s visual interface to help diagnose and troubleshoot potential issues with your vehicles. Furthermore, AWS IoT FleetWise’s capability to collect ECU data and store them on cloud databases enables you to utilize different AWS services (Analytics Services, ML, etc.) to develop novel use-cases that augment your existing vehicle functionality. In particular, AWS IoT FleetWise can leverage fleet data (Big Data) and enable you to develop use cases that create business value, for example: improve electric vehicle range estimation, optimized battery life charging, optimized vehicle routing, etc. AWS IoT FleetWise can be extended to utilize cloud computing capabilities for use-cases such as helping to improve pet/child detection, Driver Monitoring System applications, Predictive Diagnostics, electric vehicle’s battery cells outlier detection, etc. You can use the included sample C++ application to learn more about the FWE, develop an Edge Agent for your use case and test interactions before integration.

[!IMPORTANT] As provided in the AWS IoT FleetWise Service Terms, you are solely responsible for your Edge Agent, including ensuring that your Edge Agent and any updates and modifications to it are deployed and maintained safely and securely in any vehicles.

AWS IoT FleetWise Architecture

AWS IoT FleetWise is an AWS service that enables automakers and fleet operators to collect, store, organize, and monitor data from vehicles. Automakers need the ability to connect remotely to their fleet of vehicles and collect vehicle ECU/sensor data. AWS IoT FleetWise can be used by OEM engineers and data scientists to build vehicle models that can be used to build custom data collection schemes. These data collection schemes enables the OEM to optimize the data collection process by defining what signals to collect, how often to collect them, and most importantly the trigger conditions (“events”) that enable the collection process.

Customers can define the data collection schemes to trigger based on a schedule or on specific conditions such as, but not limited to: 1. Ambient temperature dropping to below 0 degree or 2. Vehicle crosses state lines or 3. Active diagnostic trouble codes. These conditions are sent to the vehicle through a set of documents called data collection schemes. In summary, your Edge Agent collects the data of interest according to the data collection schemes and decoding rules as specified by the OEM on the AWS IoT FleetWise Console.

The following diagram illustrates a high-level architecture of the system.

FWE receives two documents:

  1. Decoder Manifest - this document describes how signals are collected from the vehicle, and will include details such as, but not limited to: Bus ID, network name, decoding information, etc.

  2. Data Collection Schemes - this document describes what signals to collect. It also describes the condition logic that defines the enablement of the trigger logic that allows these signals to be collected, for example, when Vehicle Speed > 100 km/Hr and Driver Seatbelt is Off and Ambient Temperature < 0 degree C.

FWE Deployment & Supported Platforms

The functional flexibility of FWE and its use of dynamic memory allocation means that it cannot reside in the real-time safety vehicle ECUs. FWE must also be connected to the internet and preferably has access to a “good” portion of vehicle ECU data. OEMs have the flexibility to decide where they can deploy their Edge Agent binary. Possible options include (if present):

  1. Vehicle Gateway such as the NXP S32G

File truncated at 100 lines see the full file

CHANGELOG

Change Log

v1.3.2 (2025-06-24)

Bug fixes:

  • Fixed race conditions in OBDOverCANModule, DataSenderIonWriter, CollectionInspectionWorkerThread and CANDataSource found by coverity 2024.3.1.

Improvements:

  • Refactored telemetry data serialization to ensure Store and Forward uses the same payload size optimizations as regular telemetry data.
  • Updated the default dependency installation prefix to /usr/local, enabling CMake to locate dependencies using its standard search paths without requiring explicit CMAKE_PREFIX_PATH argument.
  • Fixed various Coverity regressions.

v1.3.1 (2025-04-25)

Bug fixes:

  • Fixed memory growth in DTC
  • Fixed for use-after-free bug in CollectionInspectionEngine eval() function

v1.3.0 (2025-04-14)

Bug fixes:

  • Fixed crash when using Greengrass V2 connection type.

Improvements:

  • Improved guide for Greengrass V2
  • Added an option to fwdemo stack to use Greengrass V2 connection type. When MqttConnectionType is set to iotGreengrassV2, the EC2 instance will be configured as a Greengrass core device and FWE will be deployed as a Greengrass component.
  • Make SHA1 code compatible with Boost 1.86.0. The 1.84.0 version is still being used as a dependency, but the code should now compile with more recent versions too. Related to https://github.com/aws/aws-iot-fleetwise-edge/issues/119
  • Added system test framework with 70 reference system tests
  • Update to Ubuntu 22.04 for the development environment
    • Upgraded the ROS2 distribution from Galactic to Humble

v1.2.1 (2025-02-27)

New features:

  • Added Python support in expressions with custom function implementation for both CPython and MicroPython.
  • Added support for IEEE 754 floating-point signals for CAN and OBD.
  • Added support for signed OBD PID signals.
  • Added support for using FWE as an external library, see the examples.

Bug fixes:

  • Fixed deletion of buffer after hand over to sender.
  • Fixed memory leak when generating Ion files for Vision System Data. This was caused by a known issue in the ion-c library. To avoid that all ion-c function calls now happen in the same thread.
  • Fixed possible thread lockups in rare cases when system time jumps to the future, or due to a stdlibc++ issue. Includes the addition of the new option collectionSchemeManagerThreadIdleTimeMs.
  • Fixed sporadic SOME/IP build failures due to concurrent file generation.
  • Fixed possible hang during shutdown when feature FWE_FEATURE_UDS_DTC_EXAMPLE was enabled.

Improvements:

  • Add checksum for persisted files (e.g Collection scheme, Decoder manifest, Telemetry data). Now when writing a file, the persistency layer calculates the SHA1 for the content and write it to a file alongside the content file with a .sha1 extension. When reading the file, if the .sha1 file doesn’t exist it just logs a warning. This is intended to keep backward compatibility with files that were written by older FWE versions. Otherwise if the .sha1 file exists, a mismatch in the SHA1 when reading the content will cause both the content file and the .sha1 file to be deleted.
  • Store and forward optimized for systems with slow write speed to persistent storage.
  • Update GoogleTest to 1.15.2.
  • Removed unsupported raw CAN frame collection.
  • Added optional awsSdkLogLevel field to the config file. Valid values are Off, Fatal, Error, Warn, Info, Debug, Trace. Previously the AWS SDK logs were always disabled. This allows the logs to be configured in AwsBootstrap.cpp (see the SDK docs for more details). If this is set to some level different than Off, the SDK logs will be redirected to FWE’s logger. Since FWE doesn’t provide all levels, Fatal is mapped to FWE’s Error and Debug to FWE’s Trace.
  • IMDS is now disabled when creating an S3 client. In some situations this could cause delays when creating a new client (for more details see https://github.com/aws/aws-sdk-cpp/issues/1511).

v1.2.0 (2024-11-21)

New features:

File truncated at 100 lines see the full file

Package Dependencies

System Dependencies

No direct system dependencies.

Dependant Packages

No known dependants.

Recent questions tagged iotfleetwise at Robotics Stack Exchange

No version for distro iron showing github. Known supported distros are highlighted in the buttons above.
Package symbol

iotfleetwise package from aws-iot-fleetwise-edge repo

iotfleetwise

ROS Distro
github

Package Summary

Tags No category tags.
Version 1.0.3
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Description Reference Implementation for AWS IoT FleetWise
Checkout URI https://github.com/aws/aws-iot-fleetwise-edge.git
VCS Type git
VCS Version main
Last Updated 2025-08-12
Dev Status UNKNOWN
Released UNRELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

Reference Implementation for AWS IoT FleetWise

Additional Links

No additional links.

Maintainers

  • Contact us on GitHub: https://github.com/aws/aws-iot-fleetwise-edge

Authors

No additional authors.

Reference Implementation for AWS IoT FleetWise

AWS IoT FleetWise now supports:

[!NOTE] To quickly get started, jump to the Edge Agent Developer Guide, the ROS2 developer guide, the Android Guide, or the Raspberry Pi Tutorial.

AWS IoT FleetWise is a service that makes it easy for Automotive OEMs, Fleet operators, Independent Software vendors (ISVs) to collect, store, organize, and monitor data from vehicles at scale. The Reference Implementation for AWS IoT FleetWise (“FWE”) provides C++ libraries that can be run with simulated vehicle data on certain supported vehicle hardware or that can help you develop an Edge Agent to run an application on your vehicle that integrates with AWS IoT FleetWise. You can then use AWS IoT FleetWise’s to process the collected data, gain insights about the vehicle’s health and use the service’s visual interface to help diagnose and troubleshoot potential issues with your vehicles. Furthermore, AWS IoT FleetWise’s capability to collect ECU data and store them on cloud databases enables you to utilize different AWS services (Analytics Services, ML, etc.) to develop novel use-cases that augment your existing vehicle functionality. In particular, AWS IoT FleetWise can leverage fleet data (Big Data) and enable you to develop use cases that create business value, for example: improve electric vehicle range estimation, optimized battery life charging, optimized vehicle routing, etc. AWS IoT FleetWise can be extended to utilize cloud computing capabilities for use-cases such as helping to improve pet/child detection, Driver Monitoring System applications, Predictive Diagnostics, electric vehicle’s battery cells outlier detection, etc. You can use the included sample C++ application to learn more about the FWE, develop an Edge Agent for your use case and test interactions before integration.

[!IMPORTANT] As provided in the AWS IoT FleetWise Service Terms, you are solely responsible for your Edge Agent, including ensuring that your Edge Agent and any updates and modifications to it are deployed and maintained safely and securely in any vehicles.

AWS IoT FleetWise Architecture

AWS IoT FleetWise is an AWS service that enables automakers and fleet operators to collect, store, organize, and monitor data from vehicles. Automakers need the ability to connect remotely to their fleet of vehicles and collect vehicle ECU/sensor data. AWS IoT FleetWise can be used by OEM engineers and data scientists to build vehicle models that can be used to build custom data collection schemes. These data collection schemes enables the OEM to optimize the data collection process by defining what signals to collect, how often to collect them, and most importantly the trigger conditions (“events”) that enable the collection process.

Customers can define the data collection schemes to trigger based on a schedule or on specific conditions such as, but not limited to: 1. Ambient temperature dropping to below 0 degree or 2. Vehicle crosses state lines or 3. Active diagnostic trouble codes. These conditions are sent to the vehicle through a set of documents called data collection schemes. In summary, your Edge Agent collects the data of interest according to the data collection schemes and decoding rules as specified by the OEM on the AWS IoT FleetWise Console.

The following diagram illustrates a high-level architecture of the system.

FWE receives two documents:

  1. Decoder Manifest - this document describes how signals are collected from the vehicle, and will include details such as, but not limited to: Bus ID, network name, decoding information, etc.

  2. Data Collection Schemes - this document describes what signals to collect. It also describes the condition logic that defines the enablement of the trigger logic that allows these signals to be collected, for example, when Vehicle Speed > 100 km/Hr and Driver Seatbelt is Off and Ambient Temperature < 0 degree C.

FWE Deployment & Supported Platforms

The functional flexibility of FWE and its use of dynamic memory allocation means that it cannot reside in the real-time safety vehicle ECUs. FWE must also be connected to the internet and preferably has access to a “good” portion of vehicle ECU data. OEMs have the flexibility to decide where they can deploy their Edge Agent binary. Possible options include (if present):

  1. Vehicle Gateway such as the NXP S32G

File truncated at 100 lines see the full file

CHANGELOG

Change Log

v1.3.2 (2025-06-24)

Bug fixes:

  • Fixed race conditions in OBDOverCANModule, DataSenderIonWriter, CollectionInspectionWorkerThread and CANDataSource found by coverity 2024.3.1.

Improvements:

  • Refactored telemetry data serialization to ensure Store and Forward uses the same payload size optimizations as regular telemetry data.
  • Updated the default dependency installation prefix to /usr/local, enabling CMake to locate dependencies using its standard search paths without requiring explicit CMAKE_PREFIX_PATH argument.
  • Fixed various Coverity regressions.

v1.3.1 (2025-04-25)

Bug fixes:

  • Fixed memory growth in DTC
  • Fixed for use-after-free bug in CollectionInspectionEngine eval() function

v1.3.0 (2025-04-14)

Bug fixes:

  • Fixed crash when using Greengrass V2 connection type.

Improvements:

  • Improved guide for Greengrass V2
  • Added an option to fwdemo stack to use Greengrass V2 connection type. When MqttConnectionType is set to iotGreengrassV2, the EC2 instance will be configured as a Greengrass core device and FWE will be deployed as a Greengrass component.
  • Make SHA1 code compatible with Boost 1.86.0. The 1.84.0 version is still being used as a dependency, but the code should now compile with more recent versions too. Related to https://github.com/aws/aws-iot-fleetwise-edge/issues/119
  • Added system test framework with 70 reference system tests
  • Update to Ubuntu 22.04 for the development environment
    • Upgraded the ROS2 distribution from Galactic to Humble

v1.2.1 (2025-02-27)

New features:

  • Added Python support in expressions with custom function implementation for both CPython and MicroPython.
  • Added support for IEEE 754 floating-point signals for CAN and OBD.
  • Added support for signed OBD PID signals.
  • Added support for using FWE as an external library, see the examples.

Bug fixes:

  • Fixed deletion of buffer after hand over to sender.
  • Fixed memory leak when generating Ion files for Vision System Data. This was caused by a known issue in the ion-c library. To avoid that all ion-c function calls now happen in the same thread.
  • Fixed possible thread lockups in rare cases when system time jumps to the future, or due to a stdlibc++ issue. Includes the addition of the new option collectionSchemeManagerThreadIdleTimeMs.
  • Fixed sporadic SOME/IP build failures due to concurrent file generation.
  • Fixed possible hang during shutdown when feature FWE_FEATURE_UDS_DTC_EXAMPLE was enabled.

Improvements:

  • Add checksum for persisted files (e.g Collection scheme, Decoder manifest, Telemetry data). Now when writing a file, the persistency layer calculates the SHA1 for the content and write it to a file alongside the content file with a .sha1 extension. When reading the file, if the .sha1 file doesn’t exist it just logs a warning. This is intended to keep backward compatibility with files that were written by older FWE versions. Otherwise if the .sha1 file exists, a mismatch in the SHA1 when reading the content will cause both the content file and the .sha1 file to be deleted.
  • Store and forward optimized for systems with slow write speed to persistent storage.
  • Update GoogleTest to 1.15.2.
  • Removed unsupported raw CAN frame collection.
  • Added optional awsSdkLogLevel field to the config file. Valid values are Off, Fatal, Error, Warn, Info, Debug, Trace. Previously the AWS SDK logs were always disabled. This allows the logs to be configured in AwsBootstrap.cpp (see the SDK docs for more details). If this is set to some level different than Off, the SDK logs will be redirected to FWE’s logger. Since FWE doesn’t provide all levels, Fatal is mapped to FWE’s Error and Debug to FWE’s Trace.
  • IMDS is now disabled when creating an S3 client. In some situations this could cause delays when creating a new client (for more details see https://github.com/aws/aws-sdk-cpp/issues/1511).

v1.2.0 (2024-11-21)

New features:

File truncated at 100 lines see the full file

Package Dependencies

System Dependencies

No direct system dependencies.

Dependant Packages

No known dependants.

Recent questions tagged iotfleetwise at Robotics Stack Exchange

No version for distro melodic showing github. Known supported distros are highlighted in the buttons above.
Package symbol

iotfleetwise package from aws-iot-fleetwise-edge repo

iotfleetwise

ROS Distro
github

Package Summary

Tags No category tags.
Version 1.0.3
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Description Reference Implementation for AWS IoT FleetWise
Checkout URI https://github.com/aws/aws-iot-fleetwise-edge.git
VCS Type git
VCS Version main
Last Updated 2025-08-12
Dev Status UNKNOWN
Released UNRELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

Reference Implementation for AWS IoT FleetWise

Additional Links

No additional links.

Maintainers

  • Contact us on GitHub: https://github.com/aws/aws-iot-fleetwise-edge

Authors

No additional authors.

Reference Implementation for AWS IoT FleetWise

AWS IoT FleetWise now supports:

[!NOTE] To quickly get started, jump to the Edge Agent Developer Guide, the ROS2 developer guide, the Android Guide, or the Raspberry Pi Tutorial.

AWS IoT FleetWise is a service that makes it easy for Automotive OEMs, Fleet operators, Independent Software vendors (ISVs) to collect, store, organize, and monitor data from vehicles at scale. The Reference Implementation for AWS IoT FleetWise (“FWE”) provides C++ libraries that can be run with simulated vehicle data on certain supported vehicle hardware or that can help you develop an Edge Agent to run an application on your vehicle that integrates with AWS IoT FleetWise. You can then use AWS IoT FleetWise’s to process the collected data, gain insights about the vehicle’s health and use the service’s visual interface to help diagnose and troubleshoot potential issues with your vehicles. Furthermore, AWS IoT FleetWise’s capability to collect ECU data and store them on cloud databases enables you to utilize different AWS services (Analytics Services, ML, etc.) to develop novel use-cases that augment your existing vehicle functionality. In particular, AWS IoT FleetWise can leverage fleet data (Big Data) and enable you to develop use cases that create business value, for example: improve electric vehicle range estimation, optimized battery life charging, optimized vehicle routing, etc. AWS IoT FleetWise can be extended to utilize cloud computing capabilities for use-cases such as helping to improve pet/child detection, Driver Monitoring System applications, Predictive Diagnostics, electric vehicle’s battery cells outlier detection, etc. You can use the included sample C++ application to learn more about the FWE, develop an Edge Agent for your use case and test interactions before integration.

[!IMPORTANT] As provided in the AWS IoT FleetWise Service Terms, you are solely responsible for your Edge Agent, including ensuring that your Edge Agent and any updates and modifications to it are deployed and maintained safely and securely in any vehicles.

AWS IoT FleetWise Architecture

AWS IoT FleetWise is an AWS service that enables automakers and fleet operators to collect, store, organize, and monitor data from vehicles. Automakers need the ability to connect remotely to their fleet of vehicles and collect vehicle ECU/sensor data. AWS IoT FleetWise can be used by OEM engineers and data scientists to build vehicle models that can be used to build custom data collection schemes. These data collection schemes enables the OEM to optimize the data collection process by defining what signals to collect, how often to collect them, and most importantly the trigger conditions (“events”) that enable the collection process.

Customers can define the data collection schemes to trigger based on a schedule or on specific conditions such as, but not limited to: 1. Ambient temperature dropping to below 0 degree or 2. Vehicle crosses state lines or 3. Active diagnostic trouble codes. These conditions are sent to the vehicle through a set of documents called data collection schemes. In summary, your Edge Agent collects the data of interest according to the data collection schemes and decoding rules as specified by the OEM on the AWS IoT FleetWise Console.

The following diagram illustrates a high-level architecture of the system.

FWE receives two documents:

  1. Decoder Manifest - this document describes how signals are collected from the vehicle, and will include details such as, but not limited to: Bus ID, network name, decoding information, etc.

  2. Data Collection Schemes - this document describes what signals to collect. It also describes the condition logic that defines the enablement of the trigger logic that allows these signals to be collected, for example, when Vehicle Speed > 100 km/Hr and Driver Seatbelt is Off and Ambient Temperature < 0 degree C.

FWE Deployment & Supported Platforms

The functional flexibility of FWE and its use of dynamic memory allocation means that it cannot reside in the real-time safety vehicle ECUs. FWE must also be connected to the internet and preferably has access to a “good” portion of vehicle ECU data. OEMs have the flexibility to decide where they can deploy their Edge Agent binary. Possible options include (if present):

  1. Vehicle Gateway such as the NXP S32G

File truncated at 100 lines see the full file

CHANGELOG

Change Log

v1.3.2 (2025-06-24)

Bug fixes:

  • Fixed race conditions in OBDOverCANModule, DataSenderIonWriter, CollectionInspectionWorkerThread and CANDataSource found by coverity 2024.3.1.

Improvements:

  • Refactored telemetry data serialization to ensure Store and Forward uses the same payload size optimizations as regular telemetry data.
  • Updated the default dependency installation prefix to /usr/local, enabling CMake to locate dependencies using its standard search paths without requiring explicit CMAKE_PREFIX_PATH argument.
  • Fixed various Coverity regressions.

v1.3.1 (2025-04-25)

Bug fixes:

  • Fixed memory growth in DTC
  • Fixed for use-after-free bug in CollectionInspectionEngine eval() function

v1.3.0 (2025-04-14)

Bug fixes:

  • Fixed crash when using Greengrass V2 connection type.

Improvements:

  • Improved guide for Greengrass V2
  • Added an option to fwdemo stack to use Greengrass V2 connection type. When MqttConnectionType is set to iotGreengrassV2, the EC2 instance will be configured as a Greengrass core device and FWE will be deployed as a Greengrass component.
  • Make SHA1 code compatible with Boost 1.86.0. The 1.84.0 version is still being used as a dependency, but the code should now compile with more recent versions too. Related to https://github.com/aws/aws-iot-fleetwise-edge/issues/119
  • Added system test framework with 70 reference system tests
  • Update to Ubuntu 22.04 for the development environment
    • Upgraded the ROS2 distribution from Galactic to Humble

v1.2.1 (2025-02-27)

New features:

  • Added Python support in expressions with custom function implementation for both CPython and MicroPython.
  • Added support for IEEE 754 floating-point signals for CAN and OBD.
  • Added support for signed OBD PID signals.
  • Added support for using FWE as an external library, see the examples.

Bug fixes:

  • Fixed deletion of buffer after hand over to sender.
  • Fixed memory leak when generating Ion files for Vision System Data. This was caused by a known issue in the ion-c library. To avoid that all ion-c function calls now happen in the same thread.
  • Fixed possible thread lockups in rare cases when system time jumps to the future, or due to a stdlibc++ issue. Includes the addition of the new option collectionSchemeManagerThreadIdleTimeMs.
  • Fixed sporadic SOME/IP build failures due to concurrent file generation.
  • Fixed possible hang during shutdown when feature FWE_FEATURE_UDS_DTC_EXAMPLE was enabled.

Improvements:

  • Add checksum for persisted files (e.g Collection scheme, Decoder manifest, Telemetry data). Now when writing a file, the persistency layer calculates the SHA1 for the content and write it to a file alongside the content file with a .sha1 extension. When reading the file, if the .sha1 file doesn’t exist it just logs a warning. This is intended to keep backward compatibility with files that were written by older FWE versions. Otherwise if the .sha1 file exists, a mismatch in the SHA1 when reading the content will cause both the content file and the .sha1 file to be deleted.
  • Store and forward optimized for systems with slow write speed to persistent storage.
  • Update GoogleTest to 1.15.2.
  • Removed unsupported raw CAN frame collection.
  • Added optional awsSdkLogLevel field to the config file. Valid values are Off, Fatal, Error, Warn, Info, Debug, Trace. Previously the AWS SDK logs were always disabled. This allows the logs to be configured in AwsBootstrap.cpp (see the SDK docs for more details). If this is set to some level different than Off, the SDK logs will be redirected to FWE’s logger. Since FWE doesn’t provide all levels, Fatal is mapped to FWE’s Error and Debug to FWE’s Trace.
  • IMDS is now disabled when creating an S3 client. In some situations this could cause delays when creating a new client (for more details see https://github.com/aws/aws-sdk-cpp/issues/1511).

v1.2.0 (2024-11-21)

New features:

File truncated at 100 lines see the full file

Package Dependencies

System Dependencies

No direct system dependencies.

Dependant Packages

No known dependants.

Recent questions tagged iotfleetwise at Robotics Stack Exchange

No version for distro noetic showing github. Known supported distros are highlighted in the buttons above.
Package symbol

iotfleetwise package from aws-iot-fleetwise-edge repo

iotfleetwise

ROS Distro
github

Package Summary

Tags No category tags.
Version 1.0.3
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Description Reference Implementation for AWS IoT FleetWise
Checkout URI https://github.com/aws/aws-iot-fleetwise-edge.git
VCS Type git
VCS Version main
Last Updated 2025-08-12
Dev Status UNKNOWN
Released UNRELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

Reference Implementation for AWS IoT FleetWise

Additional Links

No additional links.

Maintainers

  • Contact us on GitHub: https://github.com/aws/aws-iot-fleetwise-edge

Authors

No additional authors.

Reference Implementation for AWS IoT FleetWise

AWS IoT FleetWise now supports:

[!NOTE] To quickly get started, jump to the Edge Agent Developer Guide, the ROS2 developer guide, the Android Guide, or the Raspberry Pi Tutorial.

AWS IoT FleetWise is a service that makes it easy for Automotive OEMs, Fleet operators, Independent Software vendors (ISVs) to collect, store, organize, and monitor data from vehicles at scale. The Reference Implementation for AWS IoT FleetWise (“FWE”) provides C++ libraries that can be run with simulated vehicle data on certain supported vehicle hardware or that can help you develop an Edge Agent to run an application on your vehicle that integrates with AWS IoT FleetWise. You can then use AWS IoT FleetWise’s to process the collected data, gain insights about the vehicle’s health and use the service’s visual interface to help diagnose and troubleshoot potential issues with your vehicles. Furthermore, AWS IoT FleetWise’s capability to collect ECU data and store them on cloud databases enables you to utilize different AWS services (Analytics Services, ML, etc.) to develop novel use-cases that augment your existing vehicle functionality. In particular, AWS IoT FleetWise can leverage fleet data (Big Data) and enable you to develop use cases that create business value, for example: improve electric vehicle range estimation, optimized battery life charging, optimized vehicle routing, etc. AWS IoT FleetWise can be extended to utilize cloud computing capabilities for use-cases such as helping to improve pet/child detection, Driver Monitoring System applications, Predictive Diagnostics, electric vehicle’s battery cells outlier detection, etc. You can use the included sample C++ application to learn more about the FWE, develop an Edge Agent for your use case and test interactions before integration.

[!IMPORTANT] As provided in the AWS IoT FleetWise Service Terms, you are solely responsible for your Edge Agent, including ensuring that your Edge Agent and any updates and modifications to it are deployed and maintained safely and securely in any vehicles.

AWS IoT FleetWise Architecture

AWS IoT FleetWise is an AWS service that enables automakers and fleet operators to collect, store, organize, and monitor data from vehicles. Automakers need the ability to connect remotely to their fleet of vehicles and collect vehicle ECU/sensor data. AWS IoT FleetWise can be used by OEM engineers and data scientists to build vehicle models that can be used to build custom data collection schemes. These data collection schemes enables the OEM to optimize the data collection process by defining what signals to collect, how often to collect them, and most importantly the trigger conditions (“events”) that enable the collection process.

Customers can define the data collection schemes to trigger based on a schedule or on specific conditions such as, but not limited to: 1. Ambient temperature dropping to below 0 degree or 2. Vehicle crosses state lines or 3. Active diagnostic trouble codes. These conditions are sent to the vehicle through a set of documents called data collection schemes. In summary, your Edge Agent collects the data of interest according to the data collection schemes and decoding rules as specified by the OEM on the AWS IoT FleetWise Console.

The following diagram illustrates a high-level architecture of the system.

FWE receives two documents:

  1. Decoder Manifest - this document describes how signals are collected from the vehicle, and will include details such as, but not limited to: Bus ID, network name, decoding information, etc.

  2. Data Collection Schemes - this document describes what signals to collect. It also describes the condition logic that defines the enablement of the trigger logic that allows these signals to be collected, for example, when Vehicle Speed > 100 km/Hr and Driver Seatbelt is Off and Ambient Temperature < 0 degree C.

FWE Deployment & Supported Platforms

The functional flexibility of FWE and its use of dynamic memory allocation means that it cannot reside in the real-time safety vehicle ECUs. FWE must also be connected to the internet and preferably has access to a “good” portion of vehicle ECU data. OEMs have the flexibility to decide where they can deploy their Edge Agent binary. Possible options include (if present):

  1. Vehicle Gateway such as the NXP S32G

File truncated at 100 lines see the full file

CHANGELOG

Change Log

v1.3.2 (2025-06-24)

Bug fixes:

  • Fixed race conditions in OBDOverCANModule, DataSenderIonWriter, CollectionInspectionWorkerThread and CANDataSource found by coverity 2024.3.1.

Improvements:

  • Refactored telemetry data serialization to ensure Store and Forward uses the same payload size optimizations as regular telemetry data.
  • Updated the default dependency installation prefix to /usr/local, enabling CMake to locate dependencies using its standard search paths without requiring explicit CMAKE_PREFIX_PATH argument.
  • Fixed various Coverity regressions.

v1.3.1 (2025-04-25)

Bug fixes:

  • Fixed memory growth in DTC
  • Fixed for use-after-free bug in CollectionInspectionEngine eval() function

v1.3.0 (2025-04-14)

Bug fixes:

  • Fixed crash when using Greengrass V2 connection type.

Improvements:

  • Improved guide for Greengrass V2
  • Added an option to fwdemo stack to use Greengrass V2 connection type. When MqttConnectionType is set to iotGreengrassV2, the EC2 instance will be configured as a Greengrass core device and FWE will be deployed as a Greengrass component.
  • Make SHA1 code compatible with Boost 1.86.0. The 1.84.0 version is still being used as a dependency, but the code should now compile with more recent versions too. Related to https://github.com/aws/aws-iot-fleetwise-edge/issues/119
  • Added system test framework with 70 reference system tests
  • Update to Ubuntu 22.04 for the development environment
    • Upgraded the ROS2 distribution from Galactic to Humble

v1.2.1 (2025-02-27)

New features:

  • Added Python support in expressions with custom function implementation for both CPython and MicroPython.
  • Added support for IEEE 754 floating-point signals for CAN and OBD.
  • Added support for signed OBD PID signals.
  • Added support for using FWE as an external library, see the examples.

Bug fixes:

  • Fixed deletion of buffer after hand over to sender.
  • Fixed memory leak when generating Ion files for Vision System Data. This was caused by a known issue in the ion-c library. To avoid that all ion-c function calls now happen in the same thread.
  • Fixed possible thread lockups in rare cases when system time jumps to the future, or due to a stdlibc++ issue. Includes the addition of the new option collectionSchemeManagerThreadIdleTimeMs.
  • Fixed sporadic SOME/IP build failures due to concurrent file generation.
  • Fixed possible hang during shutdown when feature FWE_FEATURE_UDS_DTC_EXAMPLE was enabled.

Improvements:

  • Add checksum for persisted files (e.g Collection scheme, Decoder manifest, Telemetry data). Now when writing a file, the persistency layer calculates the SHA1 for the content and write it to a file alongside the content file with a .sha1 extension. When reading the file, if the .sha1 file doesn’t exist it just logs a warning. This is intended to keep backward compatibility with files that were written by older FWE versions. Otherwise if the .sha1 file exists, a mismatch in the SHA1 when reading the content will cause both the content file and the .sha1 file to be deleted.
  • Store and forward optimized for systems with slow write speed to persistent storage.
  • Update GoogleTest to 1.15.2.
  • Removed unsupported raw CAN frame collection.
  • Added optional awsSdkLogLevel field to the config file. Valid values are Off, Fatal, Error, Warn, Info, Debug, Trace. Previously the AWS SDK logs were always disabled. This allows the logs to be configured in AwsBootstrap.cpp (see the SDK docs for more details). If this is set to some level different than Off, the SDK logs will be redirected to FWE’s logger. Since FWE doesn’t provide all levels, Fatal is mapped to FWE’s Error and Debug to FWE’s Trace.
  • IMDS is now disabled when creating an S3 client. In some situations this could cause delays when creating a new client (for more details see https://github.com/aws/aws-sdk-cpp/issues/1511).

v1.2.0 (2024-11-21)

New features:

File truncated at 100 lines see the full file

Package Dependencies

System Dependencies

No direct system dependencies.

Dependant Packages

No known dependants.

Recent questions tagged iotfleetwise at Robotics Stack Exchange