![]() |
iotfleetwise package from aws-iot-fleetwise-edge repoiotfleetwise |
ROS Distro
|
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
Additional Links
Maintainers
- Contact us on GitHub: https://github.com/aws/aws-iot-fleetwise-edge
Authors
Reference Implementation for AWS IoT FleetWise
AWS IoT FleetWise now supports:
- :mechanical_arm: Remote commands for actuators, see the CAN actuators guide and the SOME/IP guide.
- :electric_plug: Network agnostic data collection and actuator commands.
- :red_car: SOME/IP support, see:
- :abc: String datatype support for both sensor data collection and actuator commands.
- :feather: Last Known State (LKS), a lighter method of data collection.
- :cloud: IoT topics as a data destination.
- :jigsaw: Custom functions in expressions.
- :snake: including Python support.
- :fast_forward: Store and forward, for conditional upload of collected data.
- :wrench: UDS DTC data collection.
- :books: Usage as an external library, see the
examples
.
[!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:
-
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.
-
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):
- Vehicle Gateway such as the NXP S32G
File truncated at 100 lines see the full file
Change Log
v1.3.2 (2025-06-24)
Bug fixes:
- Fixed race conditions in
OBDOverCANModule
,DataSenderIonWriter
,CollectionInspectionWorkerThread
andCANDataSource
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 explicitCMAKE_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 toiotGreengrassV2
, 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
. The1.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 optioncollectionSchemeManagerThreadIdleTimeMs
. - 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
to1.15.2
. - Removed unsupported raw CAN frame collection.
- Added optional
awsSdkLogLevel
field to the config file. Valid values areOff
,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 thanOff
, the SDK logs will be redirected to FWE’s logger. Since FWE doesn’t provide all levels,Fatal
is mapped to FWE’sError
andDebug
to FWE’sTrace
. - 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:
- Remote commands for actuators, see the CAN actuators guide and the SOME/IP guide.
- Network agnostic data collection and actuator commands.
- SOME/IP support, see the SOME/IP guide for data collection and commands,
File truncated at 100 lines see the full file
Package Dependencies
Deps | Name |
---|---|
ament_cmake | |
ament_lint_auto | |
ament_lint_common |
System Dependencies
Dependant Packages
Launch files
Messages
- test/system/testframework/ros2_custom_messages/msg/DifferentTypesTest.msg
- test/system/testframework/ros2_custom_messages/msg/Nested2TestMessage.msg
- test/system/testframework/ros2_custom_messages/msg/NestedTestMessage.msg
- test/system/testframework/ros2_custom_messages/msg/PumpUpMessageMain.msg
- test/system/testframework/ros2_custom_messages/msg/PumpUpMessageNested1.msg
- test/system/testframework/ros2_custom_messages/msg/PumpUpMessageNested2.msg
- test/system/testframework/ros2_custom_messages/msg/PumpUpMessageNestedEnd.msg
Services
Plugins
Recent questions tagged iotfleetwise at Robotics Stack Exchange
![]() |
iotfleetwise package from aws-iot-fleetwise-edge repoiotfleetwise |
ROS Distro
|
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
Additional Links
Maintainers
- Contact us on GitHub: https://github.com/aws/aws-iot-fleetwise-edge
Authors
Reference Implementation for AWS IoT FleetWise
AWS IoT FleetWise now supports:
- :mechanical_arm: Remote commands for actuators, see the CAN actuators guide and the SOME/IP guide.
- :electric_plug: Network agnostic data collection and actuator commands.
- :red_car: SOME/IP support, see:
- :abc: String datatype support for both sensor data collection and actuator commands.
- :feather: Last Known State (LKS), a lighter method of data collection.
- :cloud: IoT topics as a data destination.
- :jigsaw: Custom functions in expressions.
- :snake: including Python support.
- :fast_forward: Store and forward, for conditional upload of collected data.
- :wrench: UDS DTC data collection.
- :books: Usage as an external library, see the
examples
.
[!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:
-
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.
-
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):
- Vehicle Gateway such as the NXP S32G
File truncated at 100 lines see the full file
Change Log
v1.3.2 (2025-06-24)
Bug fixes:
- Fixed race conditions in
OBDOverCANModule
,DataSenderIonWriter
,CollectionInspectionWorkerThread
andCANDataSource
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 explicitCMAKE_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 toiotGreengrassV2
, 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
. The1.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 optioncollectionSchemeManagerThreadIdleTimeMs
. - 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
to1.15.2
. - Removed unsupported raw CAN frame collection.
- Added optional
awsSdkLogLevel
field to the config file. Valid values areOff
,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 thanOff
, the SDK logs will be redirected to FWE’s logger. Since FWE doesn’t provide all levels,Fatal
is mapped to FWE’sError
andDebug
to FWE’sTrace
. - 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:
- Remote commands for actuators, see the CAN actuators guide and the SOME/IP guide.
- Network agnostic data collection and actuator commands.
- SOME/IP support, see the SOME/IP guide for data collection and commands,
File truncated at 100 lines see the full file
Package Dependencies
Deps | Name |
---|---|
ament_cmake | |
ament_lint_auto | |
ament_lint_common |
System Dependencies
Dependant Packages
Launch files
Messages
- test/system/testframework/ros2_custom_messages/msg/DifferentTypesTest.msg
- test/system/testframework/ros2_custom_messages/msg/Nested2TestMessage.msg
- test/system/testframework/ros2_custom_messages/msg/NestedTestMessage.msg
- test/system/testframework/ros2_custom_messages/msg/PumpUpMessageMain.msg
- test/system/testframework/ros2_custom_messages/msg/PumpUpMessageNested1.msg
- test/system/testframework/ros2_custom_messages/msg/PumpUpMessageNested2.msg
- test/system/testframework/ros2_custom_messages/msg/PumpUpMessageNestedEnd.msg
Services
Plugins
Recent questions tagged iotfleetwise at Robotics Stack Exchange
![]() |
iotfleetwise package from aws-iot-fleetwise-edge repoiotfleetwise |
ROS Distro
|
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
Additional Links
Maintainers
- Contact us on GitHub: https://github.com/aws/aws-iot-fleetwise-edge
Authors
Reference Implementation for AWS IoT FleetWise
AWS IoT FleetWise now supports:
- :mechanical_arm: Remote commands for actuators, see the CAN actuators guide and the SOME/IP guide.
- :electric_plug: Network agnostic data collection and actuator commands.
- :red_car: SOME/IP support, see:
- :abc: String datatype support for both sensor data collection and actuator commands.
- :feather: Last Known State (LKS), a lighter method of data collection.
- :cloud: IoT topics as a data destination.
- :jigsaw: Custom functions in expressions.
- :snake: including Python support.
- :fast_forward: Store and forward, for conditional upload of collected data.
- :wrench: UDS DTC data collection.
- :books: Usage as an external library, see the
examples
.
[!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:
-
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.
-
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):
- Vehicle Gateway such as the NXP S32G
File truncated at 100 lines see the full file
Change Log
v1.3.2 (2025-06-24)
Bug fixes:
- Fixed race conditions in
OBDOverCANModule
,DataSenderIonWriter
,CollectionInspectionWorkerThread
andCANDataSource
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 explicitCMAKE_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 toiotGreengrassV2
, 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
. The1.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 optioncollectionSchemeManagerThreadIdleTimeMs
. - 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
to1.15.2
. - Removed unsupported raw CAN frame collection.
- Added optional
awsSdkLogLevel
field to the config file. Valid values areOff
,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 thanOff
, the SDK logs will be redirected to FWE’s logger. Since FWE doesn’t provide all levels,Fatal
is mapped to FWE’sError
andDebug
to FWE’sTrace
. - 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:
- Remote commands for actuators, see the CAN actuators guide and the SOME/IP guide.
- Network agnostic data collection and actuator commands.
- SOME/IP support, see the SOME/IP guide for data collection and commands,
File truncated at 100 lines see the full file
Package Dependencies
Deps | Name |
---|---|
ament_cmake | |
ament_lint_auto | |
ament_lint_common |
System Dependencies
Dependant Packages
Launch files
Messages
- test/system/testframework/ros2_custom_messages/msg/DifferentTypesTest.msg
- test/system/testframework/ros2_custom_messages/msg/Nested2TestMessage.msg
- test/system/testframework/ros2_custom_messages/msg/NestedTestMessage.msg
- test/system/testframework/ros2_custom_messages/msg/PumpUpMessageMain.msg
- test/system/testframework/ros2_custom_messages/msg/PumpUpMessageNested1.msg
- test/system/testframework/ros2_custom_messages/msg/PumpUpMessageNested2.msg
- test/system/testframework/ros2_custom_messages/msg/PumpUpMessageNestedEnd.msg
Services
Plugins
Recent questions tagged iotfleetwise at Robotics Stack Exchange
![]() |
iotfleetwise package from aws-iot-fleetwise-edge repoiotfleetwise |
ROS Distro
|
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
Additional Links
Maintainers
- Contact us on GitHub: https://github.com/aws/aws-iot-fleetwise-edge
Authors
Reference Implementation for AWS IoT FleetWise
AWS IoT FleetWise now supports:
- :mechanical_arm: Remote commands for actuators, see the CAN actuators guide and the SOME/IP guide.
- :electric_plug: Network agnostic data collection and actuator commands.
- :red_car: SOME/IP support, see:
- :abc: String datatype support for both sensor data collection and actuator commands.
- :feather: Last Known State (LKS), a lighter method of data collection.
- :cloud: IoT topics as a data destination.
- :jigsaw: Custom functions in expressions.
- :snake: including Python support.
- :fast_forward: Store and forward, for conditional upload of collected data.
- :wrench: UDS DTC data collection.
- :books: Usage as an external library, see the
examples
.
[!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:
-
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.
-
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):
- Vehicle Gateway such as the NXP S32G
File truncated at 100 lines see the full file
Change Log
v1.3.2 (2025-06-24)
Bug fixes:
- Fixed race conditions in
OBDOverCANModule
,DataSenderIonWriter
,CollectionInspectionWorkerThread
andCANDataSource
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 explicitCMAKE_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 toiotGreengrassV2
, 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
. The1.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 optioncollectionSchemeManagerThreadIdleTimeMs
. - 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
to1.15.2
. - Removed unsupported raw CAN frame collection.
- Added optional
awsSdkLogLevel
field to the config file. Valid values areOff
,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 thanOff
, the SDK logs will be redirected to FWE’s logger. Since FWE doesn’t provide all levels,Fatal
is mapped to FWE’sError
andDebug
to FWE’sTrace
. - 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:
- Remote commands for actuators, see the CAN actuators guide and the SOME/IP guide.
- Network agnostic data collection and actuator commands.
- SOME/IP support, see the SOME/IP guide for data collection and commands,
File truncated at 100 lines see the full file
Package Dependencies
Deps | Name |
---|---|
ament_cmake | |
ament_lint_auto | |
ament_lint_common |
System Dependencies
Dependant Packages
Launch files
Messages
- test/system/testframework/ros2_custom_messages/msg/DifferentTypesTest.msg
- test/system/testframework/ros2_custom_messages/msg/Nested2TestMessage.msg
- test/system/testframework/ros2_custom_messages/msg/NestedTestMessage.msg
- test/system/testframework/ros2_custom_messages/msg/PumpUpMessageMain.msg
- test/system/testframework/ros2_custom_messages/msg/PumpUpMessageNested1.msg
- test/system/testframework/ros2_custom_messages/msg/PumpUpMessageNested2.msg
- test/system/testframework/ros2_custom_messages/msg/PumpUpMessageNestedEnd.msg
Services
Plugins
Recent questions tagged iotfleetwise at Robotics Stack Exchange
![]() |
iotfleetwise package from aws-iot-fleetwise-edge repoiotfleetwise |
ROS Distro
|
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
Additional Links
Maintainers
- Contact us on GitHub: https://github.com/aws/aws-iot-fleetwise-edge
Authors
Reference Implementation for AWS IoT FleetWise
AWS IoT FleetWise now supports:
- :mechanical_arm: Remote commands for actuators, see the CAN actuators guide and the SOME/IP guide.
- :electric_plug: Network agnostic data collection and actuator commands.
- :red_car: SOME/IP support, see:
- :abc: String datatype support for both sensor data collection and actuator commands.
- :feather: Last Known State (LKS), a lighter method of data collection.
- :cloud: IoT topics as a data destination.
- :jigsaw: Custom functions in expressions.
- :snake: including Python support.
- :fast_forward: Store and forward, for conditional upload of collected data.
- :wrench: UDS DTC data collection.
- :books: Usage as an external library, see the
examples
.
[!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:
-
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.
-
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):
- Vehicle Gateway such as the NXP S32G
File truncated at 100 lines see the full file
Change Log
v1.3.2 (2025-06-24)
Bug fixes:
- Fixed race conditions in
OBDOverCANModule
,DataSenderIonWriter
,CollectionInspectionWorkerThread
andCANDataSource
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 explicitCMAKE_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 toiotGreengrassV2
, 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
. The1.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 optioncollectionSchemeManagerThreadIdleTimeMs
. - 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
to1.15.2
. - Removed unsupported raw CAN frame collection.
- Added optional
awsSdkLogLevel
field to the config file. Valid values areOff
,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 thanOff
, the SDK logs will be redirected to FWE’s logger. Since FWE doesn’t provide all levels,Fatal
is mapped to FWE’sError
andDebug
to FWE’sTrace
. - 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:
- Remote commands for actuators, see the CAN actuators guide and the SOME/IP guide.
- Network agnostic data collection and actuator commands.
- SOME/IP support, see the SOME/IP guide for data collection and commands,
File truncated at 100 lines see the full file
Package Dependencies
Deps | Name |
---|---|
ament_cmake | |
ament_lint_auto | |
ament_lint_common |
System Dependencies
Dependant Packages
Launch files
Messages
- test/system/testframework/ros2_custom_messages/msg/DifferentTypesTest.msg
- test/system/testframework/ros2_custom_messages/msg/Nested2TestMessage.msg
- test/system/testframework/ros2_custom_messages/msg/NestedTestMessage.msg
- test/system/testframework/ros2_custom_messages/msg/PumpUpMessageMain.msg
- test/system/testframework/ros2_custom_messages/msg/PumpUpMessageNested1.msg
- test/system/testframework/ros2_custom_messages/msg/PumpUpMessageNested2.msg
- test/system/testframework/ros2_custom_messages/msg/PumpUpMessageNestedEnd.msg
Services
Plugins
Recent questions tagged iotfleetwise at Robotics Stack Exchange
![]() |
iotfleetwise package from aws-iot-fleetwise-edge repoiotfleetwise |
ROS Distro
|
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
Additional Links
Maintainers
- Contact us on GitHub: https://github.com/aws/aws-iot-fleetwise-edge
Authors
Reference Implementation for AWS IoT FleetWise
AWS IoT FleetWise now supports:
- :mechanical_arm: Remote commands for actuators, see the CAN actuators guide and the SOME/IP guide.
- :electric_plug: Network agnostic data collection and actuator commands.
- :red_car: SOME/IP support, see:
- :abc: String datatype support for both sensor data collection and actuator commands.
- :feather: Last Known State (LKS), a lighter method of data collection.
- :cloud: IoT topics as a data destination.
- :jigsaw: Custom functions in expressions.
- :snake: including Python support.
- :fast_forward: Store and forward, for conditional upload of collected data.
- :wrench: UDS DTC data collection.
- :books: Usage as an external library, see the
examples
.
[!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:
-
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.
-
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):
- Vehicle Gateway such as the NXP S32G
File truncated at 100 lines see the full file
Change Log
v1.3.2 (2025-06-24)
Bug fixes:
- Fixed race conditions in
OBDOverCANModule
,DataSenderIonWriter
,CollectionInspectionWorkerThread
andCANDataSource
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 explicitCMAKE_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 toiotGreengrassV2
, 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
. The1.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 optioncollectionSchemeManagerThreadIdleTimeMs
. - 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
to1.15.2
. - Removed unsupported raw CAN frame collection.
- Added optional
awsSdkLogLevel
field to the config file. Valid values areOff
,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 thanOff
, the SDK logs will be redirected to FWE’s logger. Since FWE doesn’t provide all levels,Fatal
is mapped to FWE’sError
andDebug
to FWE’sTrace
. - 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:
- Remote commands for actuators, see the CAN actuators guide and the SOME/IP guide.
- Network agnostic data collection and actuator commands.
- SOME/IP support, see the SOME/IP guide for data collection and commands,
File truncated at 100 lines see the full file
Package Dependencies
Deps | Name |
---|---|
ament_cmake | |
ament_lint_auto | |
ament_lint_common |
System Dependencies
Dependant Packages
Launch files
Messages
- test/system/testframework/ros2_custom_messages/msg/DifferentTypesTest.msg
- test/system/testframework/ros2_custom_messages/msg/Nested2TestMessage.msg
- test/system/testframework/ros2_custom_messages/msg/NestedTestMessage.msg
- test/system/testframework/ros2_custom_messages/msg/PumpUpMessageMain.msg
- test/system/testframework/ros2_custom_messages/msg/PumpUpMessageNested1.msg
- test/system/testframework/ros2_custom_messages/msg/PumpUpMessageNested2.msg
- test/system/testframework/ros2_custom_messages/msg/PumpUpMessageNestedEnd.msg
Services
Plugins
Recent questions tagged iotfleetwise at Robotics Stack Exchange
![]() |
iotfleetwise package from aws-iot-fleetwise-edge repoiotfleetwise |
ROS Distro
|
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
Additional Links
Maintainers
- Contact us on GitHub: https://github.com/aws/aws-iot-fleetwise-edge
Authors
Reference Implementation for AWS IoT FleetWise
AWS IoT FleetWise now supports:
- :mechanical_arm: Remote commands for actuators, see the CAN actuators guide and the SOME/IP guide.
- :electric_plug: Network agnostic data collection and actuator commands.
- :red_car: SOME/IP support, see:
- :abc: String datatype support for both sensor data collection and actuator commands.
- :feather: Last Known State (LKS), a lighter method of data collection.
- :cloud: IoT topics as a data destination.
- :jigsaw: Custom functions in expressions.
- :snake: including Python support.
- :fast_forward: Store and forward, for conditional upload of collected data.
- :wrench: UDS DTC data collection.
- :books: Usage as an external library, see the
examples
.
[!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:
-
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.
-
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):
- Vehicle Gateway such as the NXP S32G
File truncated at 100 lines see the full file
Change Log
v1.3.2 (2025-06-24)
Bug fixes:
- Fixed race conditions in
OBDOverCANModule
,DataSenderIonWriter
,CollectionInspectionWorkerThread
andCANDataSource
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 explicitCMAKE_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 toiotGreengrassV2
, 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
. The1.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 optioncollectionSchemeManagerThreadIdleTimeMs
. - 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
to1.15.2
. - Removed unsupported raw CAN frame collection.
- Added optional
awsSdkLogLevel
field to the config file. Valid values areOff
,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 thanOff
, the SDK logs will be redirected to FWE’s logger. Since FWE doesn’t provide all levels,Fatal
is mapped to FWE’sError
andDebug
to FWE’sTrace
. - 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:
- Remote commands for actuators, see the CAN actuators guide and the SOME/IP guide.
- Network agnostic data collection and actuator commands.
- SOME/IP support, see the SOME/IP guide for data collection and commands,
File truncated at 100 lines see the full file
Package Dependencies
Deps | Name |
---|---|
ament_cmake | |
ament_lint_auto | |
ament_lint_common |
System Dependencies
Dependant Packages
Launch files
Messages
- test/system/testframework/ros2_custom_messages/msg/DifferentTypesTest.msg
- test/system/testframework/ros2_custom_messages/msg/Nested2TestMessage.msg
- test/system/testframework/ros2_custom_messages/msg/NestedTestMessage.msg
- test/system/testframework/ros2_custom_messages/msg/PumpUpMessageMain.msg
- test/system/testframework/ros2_custom_messages/msg/PumpUpMessageNested1.msg
- test/system/testframework/ros2_custom_messages/msg/PumpUpMessageNested2.msg
- test/system/testframework/ros2_custom_messages/msg/PumpUpMessageNestedEnd.msg
Services
Plugins
Recent questions tagged iotfleetwise at Robotics Stack Exchange
![]() |
iotfleetwise package from aws-iot-fleetwise-edge repoiotfleetwise |
ROS Distro
|
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
Additional Links
Maintainers
- Contact us on GitHub: https://github.com/aws/aws-iot-fleetwise-edge
Authors
Reference Implementation for AWS IoT FleetWise
AWS IoT FleetWise now supports:
- :mechanical_arm: Remote commands for actuators, see the CAN actuators guide and the SOME/IP guide.
- :electric_plug: Network agnostic data collection and actuator commands.
- :red_car: SOME/IP support, see:
- :abc: String datatype support for both sensor data collection and actuator commands.
- :feather: Last Known State (LKS), a lighter method of data collection.
- :cloud: IoT topics as a data destination.
- :jigsaw: Custom functions in expressions.
- :snake: including Python support.
- :fast_forward: Store and forward, for conditional upload of collected data.
- :wrench: UDS DTC data collection.
- :books: Usage as an external library, see the
examples
.
[!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:
-
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.
-
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):
- Vehicle Gateway such as the NXP S32G
File truncated at 100 lines see the full file
Change Log
v1.3.2 (2025-06-24)
Bug fixes:
- Fixed race conditions in
OBDOverCANModule
,DataSenderIonWriter
,CollectionInspectionWorkerThread
andCANDataSource
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 explicitCMAKE_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 toiotGreengrassV2
, 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
. The1.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 optioncollectionSchemeManagerThreadIdleTimeMs
. - 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
to1.15.2
. - Removed unsupported raw CAN frame collection.
- Added optional
awsSdkLogLevel
field to the config file. Valid values areOff
,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 thanOff
, the SDK logs will be redirected to FWE’s logger. Since FWE doesn’t provide all levels,Fatal
is mapped to FWE’sError
andDebug
to FWE’sTrace
. - 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:
- Remote commands for actuators, see the CAN actuators guide and the SOME/IP guide.
- Network agnostic data collection and actuator commands.
- SOME/IP support, see the SOME/IP guide for data collection and commands,
File truncated at 100 lines see the full file
Package Dependencies
Deps | Name |
---|---|
ament_cmake | |
ament_lint_auto | |
ament_lint_common |
System Dependencies
Dependant Packages
Launch files
Messages
- test/system/testframework/ros2_custom_messages/msg/DifferentTypesTest.msg
- test/system/testframework/ros2_custom_messages/msg/Nested2TestMessage.msg
- test/system/testframework/ros2_custom_messages/msg/NestedTestMessage.msg
- test/system/testframework/ros2_custom_messages/msg/PumpUpMessageMain.msg
- test/system/testframework/ros2_custom_messages/msg/PumpUpMessageNested1.msg
- test/system/testframework/ros2_custom_messages/msg/PumpUpMessageNested2.msg
- test/system/testframework/ros2_custom_messages/msg/PumpUpMessageNestedEnd.msg
Services
Plugins
Recent questions tagged iotfleetwise at Robotics Stack Exchange
![]() |
iotfleetwise package from aws-iot-fleetwise-edge repoiotfleetwise |
ROS Distro
|
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
Additional Links
Maintainers
- Contact us on GitHub: https://github.com/aws/aws-iot-fleetwise-edge
Authors
Reference Implementation for AWS IoT FleetWise
AWS IoT FleetWise now supports:
- :mechanical_arm: Remote commands for actuators, see the CAN actuators guide and the SOME/IP guide.
- :electric_plug: Network agnostic data collection and actuator commands.
- :red_car: SOME/IP support, see:
- :abc: String datatype support for both sensor data collection and actuator commands.
- :feather: Last Known State (LKS), a lighter method of data collection.
- :cloud: IoT topics as a data destination.
- :jigsaw: Custom functions in expressions.
- :snake: including Python support.
- :fast_forward: Store and forward, for conditional upload of collected data.
- :wrench: UDS DTC data collection.
- :books: Usage as an external library, see the
examples
.
[!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:
-
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.
-
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):
- Vehicle Gateway such as the NXP S32G
File truncated at 100 lines see the full file
Change Log
v1.3.2 (2025-06-24)
Bug fixes:
- Fixed race conditions in
OBDOverCANModule
,DataSenderIonWriter
,CollectionInspectionWorkerThread
andCANDataSource
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 explicitCMAKE_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 toiotGreengrassV2
, 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
. The1.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 optioncollectionSchemeManagerThreadIdleTimeMs
. - 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
to1.15.2
. - Removed unsupported raw CAN frame collection.
- Added optional
awsSdkLogLevel
field to the config file. Valid values areOff
,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 thanOff
, the SDK logs will be redirected to FWE’s logger. Since FWE doesn’t provide all levels,Fatal
is mapped to FWE’sError
andDebug
to FWE’sTrace
. - 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:
- Remote commands for actuators, see the CAN actuators guide and the SOME/IP guide.
- Network agnostic data collection and actuator commands.
- SOME/IP support, see the SOME/IP guide for data collection and commands,
File truncated at 100 lines see the full file
Package Dependencies
Deps | Name |
---|---|
ament_cmake | |
ament_lint_auto | |
ament_lint_common |
System Dependencies
Dependant Packages
Launch files
Messages
- test/system/testframework/ros2_custom_messages/msg/DifferentTypesTest.msg
- test/system/testframework/ros2_custom_messages/msg/Nested2TestMessage.msg
- test/system/testframework/ros2_custom_messages/msg/NestedTestMessage.msg
- test/system/testframework/ros2_custom_messages/msg/PumpUpMessageMain.msg
- test/system/testframework/ros2_custom_messages/msg/PumpUpMessageNested1.msg
- test/system/testframework/ros2_custom_messages/msg/PumpUpMessageNested2.msg
- test/system/testframework/ros2_custom_messages/msg/PumpUpMessageNestedEnd.msg