代码拉取完成，页面将自动刷新
Note: AWS IoT FleetWise is currently available in US East (N. Virginia) and Europe (Frankfurt).
Topics
Copyright (C) Amazon Web Services, Inc. and/or its affiliates. All rights reserved.
Amazon's trademarks and trade dress may not be used in connection with any product or service that is not Amazon's, in any manner that is likely to cause confusion among customers, or in any manner that disparages or discredits Amazon. All other trademarks not owned by Amazon are the property of their respective owners, who may or may not be affiliated with, connected to, or sponsored by Amazon.
AWS IoT FleetWise provides a set of tools that enable automakers to collect, transform, and transfer vehicle data to the cloud at scale. With AWS IoT FleetWise you can build virtual representations of vehicle networks and define data collection rules to transfer only high-value data from your vehicles to AWS Cloud.
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 use AWS IoT FleetWise pre-configured analytic capabilities to process collected data, gain insights about vehicle health, and use the service's visual interface to help diagnose and troubleshoot potential issues with the vehicle.
AWS IoT FleetWise's capability to collect ECU data and store them on cloud databases enables you to utilize different AWS services, such as Analytics Services, and ML, to develop novel use-cases that augment and/or supplement your existing vehicle functionality. In particular, AWS IoT FleetWise can help utilize fleet data (Big Data) to create value. For example, you can develop use cases that optimize vehicle routing, improve electric vehicle range estimation, and optimize battery life charging. You can use the data ingested through AWS IoT FleetWise to develop applications for predictive diagnostics, and for outlier detection with an electric vehicle's battery cells.
You can use the included sample C++ application to learn more about the Reference Implementation, develop an Edge Agent for your use case and test interactions before integration.
This software is licensed under the Apache License, Version 2.0.
The Reference Implementation for AWS IoT FleetWise ("FWE") is intended to help you develop your Edge Agent for AWS IoT FleetWise and includes sample code that you may reference or modify so your Edge Agent meets your requirements. 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 thereto are deployed and maintained safely and securely in any vehicles.
This software code base includes modules that are still in development and are disabled by default. These modules are not intended for use in a production environment. This includes a Remote Profiler module that helps sending traces from the device to AWS Cloud Watch. FWE has been checked for any memory leaks and runtime errors such as type overflows using Valgrind. No issues have been detected during the load tests.
Note that vehicle data collected through your use of AWS IoT FleetWise is intended for informational purposes only (including to help you train cloud-based artificial intelligence and machine learning models), and you may not use AWS IoT FleetWise to control or operate vehicle functions. You are solely responsible for all liability that may arise in connection with any use outside of AWS IoT FleetWise's intended purpose and in any manner contrary to applicable vehicle regulations. Vehicle data collected through your use of AWS IoT FleetWise should be evaluated for accuracy as appropriate for your use case, including for purposes of meeting any compliance obligations you may have under applicable vehicle safety regulations (such as safety monitoring and reporting obligations). Such evaluation should include collecting and reviewing information through other industry standard means and sources (such as reports from drivers of vehicles). You and your End Users are solely responsible for all decisions made, advice given, actions taken, and failures to take action based on your use of AWS IoT FleetWise.
This guide is intended to quickly demonstrate the basic features of AWS IoT FleetWise by firstly deploying FWE to an AWS EC2 instance representing one or more simulated vehicles. A script is then run using the AWS CLI to control AWS IoT FleetWise in order collect data from the simulated vehicle.
This guide showcases AWS IoT FleetWise at a high level. If you are interested in exploring AWS IoT FleetWise at a more detailed technical level, see the Getting started guide.
Topics:
After reviewing the FWE source code, to ensure that it meets your use case and requirements, you can use the following CloudFormation template to deploy FWE to a new AWS EC2 instance.
FleetSize
parameter. You can also specify the region IoT Things are created in by updating the
IoTCoreRegion parameter.FWE has been deployed to an AWS EC2 Graviton (ARM64) Instance along with credentials that allow it to connect to AWS IoT Core. CAN data is also being generated on the EC2 instance to simulate periodic hard-braking events. The AWS IoT FleetWise demo script in the following section will deploy a campaign to the simulated fleet of vehicles to capture the engine torque when a hard braking-event occurs.
The instructions below will register your AWS account for AWS IoT FleetWise, create a demonstration vehicle model, register the virtual vehicle created in the previous section and run a campaign to collect data from it.
Open the AWS CloudShell: Launch CloudShell
Copy and paste the following commands to clone the latest FWE software from GitHub, install the dependencies of the demo script and enable latest IoT FleetWise commands in the AWS CLI.
git clone https://github.com/aws/aws-iot-fleetwise-edge.git ~/aws-iot-fleetwise-edge \
&& cd ~/aws-iot-fleetwise-edge/tools/cloud \
&& pip3 install wrapt==1.10.0 plotly==5.3.1 pandas==1.3.5 cantools==36.4.0 boto3==1.18.60 fastparquet==0.8.1
If you are using the AWS CLI v<2.11.24, update the CLI by running:
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install --update
rm -rf ./aws*
The AWS IoT FleetWise demo script performs the following:
obd-nodes.json to add standard OBD signals, and
secondly based on the DBC file hscan.dbc to add CAN signals in a flat signal listobd-decoders.json for decoding
OBD signals from the network interfaces defined in network-interfaces.jsonhscan.dbc to the decoder manifestACTIVEfwdemo which is the same as the name given to the
CloudFormation Stack name in the previous sectioncampaign-brake-event.json that contains a condition-based collection
scheme to capture the engine torque and the brake pressure when the brake pressure is above
7000, and targets the campaign at the fleet.HEALTHY, which means the campaign has been deployed to the
fleetYou can enable S3 upload destination by passing the option --enable-s3-upload. You can pass
your bucket name as option --bucket-name. The demo script will additionally:
campaign-brake-event.json. One campaign will upload data
to to S3 in JSON format, one to S3 in parquet formatThis script will not delete Timestream and S3 resources.
Run the demo script:
./demo.sh --vehicle-name fwdemo
--enable-s3-upload./demo.sh --vehicle-name fwdemo --enable-s3-upload
FleetSize of greater than one above, append the option
--fleet-size <SIZE>, where <SIZE> is the number selected.IoTCoreRegion above, append the option --region <REGION>, where
<REGION> is the selected region.Stack name when creating the stack above, pass the new stack name
to the --vehicle-name option.For example, if you chose to create two AWS IoT things in Europe (Frankfurt) with a stack named
myfwdemo, you must pass those values when calling demo.sh:
./demo.sh --vehicle-name myfwdemo --fleet-size 2 --region eu-central-1
When the script completes, a path to an HTML file is given in the format
/home/cloudshell-user/aws-iot-fleetwise-edge/fwdemo-*.html. Copy the path, then click on the
Actions drop down menu in the top-right corner of the CloudShell window and choose Download
file. Paste the path to the file, choose Download, and open the downloaded file in your
browser.
If you enabled S3 upload, results are stored in
/home/cloudshell-user/aws-iot-fleetwise-edge/fwdemo-*-s3-json-result.html and
/home/cloudshell-user/aws-iot-fleetwise-edge/fwdemo-*-s3-parquet-result.html
This guide is intended to demonstrate the basic features of AWS IoT FleetWise by firstly allowing you to build your own Edge Agent and running it on a development machine (locally or on AWS EC2) in order to represent a simulated vehicle. A script is then run to interact with AWS IoT FleetWise in order to collect data from the simulated vehicle. Instructions are also provided for running your own Edge Agent on an NXP S32G-VNP-RDB2 development board or Renesas R-Car S4 Spider board and deploying a campaign to collect OBD data.
This guide covers building your Edge Agent at a detailed technical level, using a development machine to build and run the executable. If you would prefer to learn about AWS IoT FleetWise at a higher level that does not require use of a development machine, see the Quick start demo.
This section describes how to get started on a development machine.
An Ubuntu 20.04 development machine with 200GB free disk space will be required. A local Intel x86_64 (amd64) machine can be used, however it is recommended to use the following instructions to launch an AWS EC2 Graviton (arm64) instance. Pricing for EC2 can be found, here.
Launch an EC2 Graviton instance with administrator permissions: Launch CloudFormation Template.
Enter the Name of an existing SSH key pair in your account from here.
.pem..pem file. Be sure to update the file permissions: chmod 400 <PATH_TO_PEM>Select the checkbox next to 'I acknowledge that AWS CloudFormation might create IAM resources with custom names.'
Choose Create stack.
Wait until the status of the Stack is CREATE_COMPLETE; this can take up to five minutes.
Select the Outputs tab, copy the EC2 IP address, and connect via SSH from your local machine to the development machine.
ssh -i <PATH_TO_PEM> ubuntu@<EC2_IP_ADDRESS>
Run the following on the development machine to clone the latest FWE source code from GitHub.
git clone https://github.com/aws/aws-iot-fleetwise-edge.git ~/aws-iot-fleetwise-edge \
&& cd ~/aws-iot-fleetwise-edge
Review, modify and supplement the FWE source code to ensure it meets your use case and requirements.
Install the dependencies for FWE by running the commands below.
The commands below will:
libssl-dev libboost-system-dev libboost-log-dev libboost-thread-dev build-essential cmake unzip git wget curl zlib1g-dev libcurl4-openssl-dev libsnappy-dev default-jre libasio-dev.
Additionally it installs the following: jsoncpp protobuf aws-sdk-cppbuild-essential dkms can-utils git linux-modules-extra-aws. Additionally it installs the
following: can-isotp. It also installs a systemd service called setup-socketcan that
brings up the virtual SocketCAN interface vcan0 at startup.python3 python3-pip. It then installs the following
PIP packages:
wrapt cantools prompt_toolkit python-can can-isotp matplotlib boto3 fastparquet. It also
installs a systemd service called cansim that periodically transmits data on the virtual
SocketCAN bus vcan0 to simulate vehicle data.sudo -H ./tools/install-deps-native.sh \
&& sudo -H ./tools/install-socketcan.sh \
&& sudo -H ./tools/install-cansim.sh
Run the following to compile your own Edge Agent:
./tools/build-fwe-native.sh
Run the following on the development machine to provision an AWS IoT Thing with credentials and install your Edge Agent as a service.
Note To create AWS IoT things in Europe (Frankfurt), configure --region to eu-central-1
in the call to provision.sh
sudo mkdir -p /etc/aws-iot-fleetwise \
&& sudo ./tools/provision.sh \
--vehicle-name fwdemo-ec2 \
--certificate-pem-outfile /etc/aws-iot-fleetwise/certificate.pem \
--private-key-outfile /etc/aws-iot-fleetwise/private-key.key \
--endpoint-url-outfile /etc/aws-iot-fleetwise/endpoint.txt \
--vehicle-name-outfile /etc/aws-iot-fleetwise/vehicle-name.txt \
&& sudo ./tools/configure-fwe.sh \
--input-config-file configuration/static-config.json \
--output-config-file /etc/aws-iot-fleetwise/config-0.json \
--log-color Yes \
--vehicle-name `cat /etc/aws-iot-fleetwise/vehicle-name.txt` \
--endpoint-url `cat /etc/aws-iot-fleetwise/endpoint.txt` \
--can-bus0 vcan0 \
&& sudo ./tools/install-fwe.sh
Run the following to view and follow the log for your Edge Agent. You can open a new SSH session with the development machine and run this command to follow the log in real time as the campaign is deployed in the next section. To exit the logs, use CTRL + C.
sudo journalctl -fu fwe@0 --output=cat
The instructions below will register your AWS account for AWS IoT FleetWise, create a demonstration vehicle model, register the virtual vehicle created in the previous section, and run a campaign to collect data from it.
Run the following on the development machine to install the dependencies of the AWS IoT FleetWise demo script:
python3 python3-pip. It then
installs the following PIP packages: wrapt plotly pandas cantools boto3 fastparquetcd ~/aws-iot-fleetwise-edge/tools/cloud \
&& sudo -H ./install-deps.sh
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install --update
rm -rf ./aws*
Run the following to explore the AWS IoT FleetWise CLI:
aws iotfleetwise help
Run the demo script:
./demo.sh --vehicle-name fwdemo-ec2
--enable-s3-upload. You can pass your
bucket name as option --bucket-name../demo.sh --vehicle-name fwdemo-ec2 --enable-s3-upload
(Optional) If you changed the --region option to provision.sh above, append the option
--region <REGION>, where <REGION> is the selected region. For example, if you chose to
create the AWS IoT thing in Europe (Frankfurt), you must configure --region to
eu-central-1 in the demo.sh file.
./demo.sh --vehicle-name fwdemo-ec2 --region eu-central-1
The demo script:
obd-nodes.json to add standard OBD signals,
and secondly based on the DBC file hscan.dbc to add CAN signals in a flat signal listobd-decoders.json for
decoding OBD signals from the network interfaces defined in network-interfaces.jsonhscan.dbc to the decoder manifestACTIVEfwdemo-ec2 which is the same as the name given to
the CloudFormation Stack name in the previous sectioncampaign-brake-event.json that contain a condition1.based
collection scheme to capture the engine torque and the brake pressure when the brake
pressure is above 7000, and targets the campaign at the fleet.HEALTHY, which means the campaign has been deployed to
the fleetIf you enabled S3 upload destination, the demo script will additionally:
campaign-brake-event.json. One campaign will upload data
to to S3 in JSON format, one to S3 in parquet formatThis script will not delete Timestream and S3 resources
When the script completes, the path to the output HTML file is given. On your local machine,
use scp to download it, then open it in your web browser:
scp -i <PATH_TO_PEM> ubuntu@<EC2_IP_ADDRESS>:<PATH_TO_HTML_FILE> .
To explore the collected data, you can click and drag on the graph to zoom in. The red line shows the simulated brake pressure signal. As you can see that when hard braking events occur (value above 7000), collection is triggered and the engine torque signal data is collected.
Alternatively, if your AWS account is enrolled with QuickSight or Grafana, you may use them to browse the data from Amazon Timestream directly.
Run the following on the development machine to deploy a 'heartbeat' campaign that collects OBD data from the vehicle. Repeat the process above to view the collected data.
./demo.sh --vehicle-name fwdemo-ec2 --campaign-file campaign-obd-heartbeat.json
Similarly, if you chose to deploy the 'heartbeat' campaign that collects OBD data from an AWS IoT
thing created in in Europe (Frankfurt), you must configure --region:
./demo.sh --vehicle-name fwdemo-ec2 --campaign-file campaign-obd-heartbeat.json --region eu-central-1
Run the following on the development machine to import your custom DBC file. You also have to provide your custom campaign file. There is no support of simulation of custom signals so you have to test data collection with the real vehicle or custom simulator.
./demo.sh --vehicle-name fwdemo-ec2 --dbc-file <DBC_FILE> --campaign-file <CAMPAIGN_FILE>
Similarly, if you chose to deploy the 'heartbeat' campaign that collects OBD data from an AWS IoT
thing created in in Europe (Frankfurt), you must configure --region:
./demo.sh --vehicle-name fwdemo-ec2 --dbc-file <DBC_FILE> --campaign-file <CAMPAIGN_FILE> --region eu-central-1
Getting started on an NXP S32G board
Getting started on a Renesas R-Car S4 board
AWS IoT FleetWise is an AWS service that enables automakers 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 and sensor data. The following diagram illustrates a high-level architecture of the system. AWS IoT FleetWise can be used by OEM engineers and data scientists to build vehicle models that can be used to create custom data collection schemes. These data collection schemes enable OEMs to optimize the data collection process by defining what signals to collect, how often to collect them, and most importantly the trigger conditions, or events, that enable the collection process.
This document reviews the architecture, operation, and key features of the Reference Implementation for AWS IoT FleetWise ("FWE").
Topics
Decoder Manifest: A configuration used for decoding raw vehicle data into physical measurements. For example, CAN DBC decodes raw data from CAN Bus frames into physical signals like EngineRPM, EngineSpeed, and RadarAmplitude.
Data Collection Scheme: A document that defines the rules used to collect data from a vehicle. It defines an event trigger, filters, duration and frequency of data collection. This document is used by FWE for collecting and filtering only relevant data. A data collection scheme can use multiple event triggers. It can be attached to a single vehicle or a fleet of vehicles.
Board Support Package (BSP): A set of libraries that support running FWE on a POSIX Operating System.
Controller Area Network (CAN): A serial networking technology that enables vehicle electronic devices to interconnect.
On Board Diagnostics (OBD): A protocol used to retrieve vehicle diagnostics information.
Message Queuing Telemetry Transport (MQTT)
Transport Layer Security (TLS)
Original Equipment Manufacturer (OEM)
This document is intended for System and Software Engineers at OEMs and System Integrators who are developing or integrating in-vehicle software. Knowledge of C/C++, POSIX APIs, in-vehicle Networking protocols (such as CAN) and external connectivity protocols (such as MQTT) are pre-requisites.
The below figure outlines AWS IoT FleetWise system elements:
You can use the AWS IoT FleetWise Console to define a vehicle model, which consists of creating a semantic digital twin of the vehicle. The semantic twin includes the vehicle attributes such as model year, engine type, and the signal catalog of the vehicle. This vehicle description serves as a foundation to define data collection schemes and specify what data to collect and which collection triggers to inspect data.
AWS IoT FleetWise enables you to create campaigns that can be deployed to a fleet of vehicles. Once a campaign is active, it is deployed from the cloud to the target vehicles via a push mechanism. FWE uses the underlying collection schemes to acquire sensor data from the vehicle network. It applies the inspection rules and uploads the data back to AWS IoT FleetWise data plane. The data plane persists collected data in the OEM's AWS Account; the account can then be used to analyse the data.
The functionality of FWE is dependent on a set of software layers that are interdependent. The software layers exchange over abstract APIs that implement a dependency inversion design pattern. The below section describes each of the layers bottom up as outline in the figure above.
Vehicle Data Acquisition
This layer binds FWE with the vehicle network, leveraging the onboard device drivers and middle-wares the OEM uses in the target hardware. It has a dependency on the host environment including the operating system, the peripheral drivers and the vehicle architecture overall. This layer listens and/or requests data from the vehicle network and normalizes it, before applying various signal decoding rules that are vehicle protocol specific e.g. CAN Signal database files. The output of this layer is a set of transformed key/value pairs of signals and their corresponding values. This layer has a dependency on the decoding rules the OEM has defined for the signals they want to inspect, which are specified in the Cloud Control plane. This layer stores the decoded values into a signal history buffer. This signal history buffer has a maximum fixed size to not exhaust the system resources.
Vehicle Data Inspection
This layer of the software operates on the signal history buffer by applying the inspection rules. An inspection rule ties one or more signal value to a set of conditions. If the condition is met, a snapshot of the data at hand is shared with the Cloud data plane. More than one inspection rule can be defined and applied to the signal data. This layer holds a set of data structures that allow fast indexing of the data by identifier and time, so that the data collection can be achieved as a quick as the conditions are met. Once a snapshot of the signal data is available, this layer passes over the data to the offboard connectivity layer for further processing. The mechanism of data transmission between these two layers uses also a message queue with a predefined maximum size.
Scheme Management
The Cloud control plane serves FWE with data collection scheme and decoder manifests. A decoder manifest is an artifact that defines the vehicle signal catalog and the way each signal can get decoded from its raw format. A collection scheme describes the inspection rules to be applied to the signal values. The Scheme Management module has the responsibility of managing the life cycle e.g. activation/deactivation based on time and version of the collection schemes and the decoder manifest delivered to FWE. The outcome of the scheme management are at any given point in time, the inspection matrix needed by the Data Inspection Layer and the decoding dictionary needed by by the Data Normalization layer.
Offboard Connectivity
This layer of the software owns the communication of FWE with the outside world i.e. AWS Cloud. It implements a publish/subscribe pattern, with two communication channels, one used for receiving collection schemes and decoder manifest from the Control Plane, and one for publishing the collected data back to the Data Plane.
This layer ensures that FWE has valid credentials to communicate securely with the Cloud APIs.
Service Control
This layer owns the execution context of FWE within the target hardware in the vehicle. It manages the lifecycle of FWE, including the startup/shutdown sequences, along with acting as a local monitoring module to ensure smooth execution of the service. The configuration of the service is validated and loaded into the system in this layer of the software.
The code base of the Reference Implementation consists of 6 C++ libraries that implement the functionalities of the layers described above. All these libraries are loaded in a POSIX user space application running a single process.
These libraries are:
BSP Library
This library includes a set of APIs and utility functions that the rest of the system use to :
This library is used uniformly by all the other libraries in the service.
Vehicle Network Management Library
This library implements a set of wrappers around the in vehicle network communication protocols, and realizes the function of vehicle data acquisition. In this version of the software, this library includes :
Each of the CAN Interfaces configured in the system will have a dedicated socket open. For the Diagnostic session i.e. to request OBD II PIDs, a separate socket is open for writing and reading CAN Frames. This library abstracts away all the Socket and Linux networking details from the rest of the system, and exposes only a circular buffer for each network interface configured, exposing the raw CAN Frames to be consumed by the Data Inspection Library.
Data Management Library
This library implements all raw data decoders. It offers a Raw CAN Data Decoder (Standard CAN), an OBD II (according to J1979 specification) decoder. Additionally, it implements the decoders for the Collection Schemes and Decoder manifests.
This library is used by the Data Inspection Library to normalize and decode the raw CAN Frames, and by the Execution Management library to initiate the Collection Scheme and decoder Manifest decoding.
The library also implements a serialization module to serialize the data FWE wants to send to the data plane. The serialization schema is described below in the data model.
Data Inspection Library
This library implements a software module for each of the following:
Upon fulfillment of one or more trigger conditions, this library extracts from the signal history buffer a data snapshot that's shared with the offboard connectivity library for further processing. Again here a circular buffer is used as a transport mechanism of the data between the two libraries.
Connectivity Library
This library implements the communication routines between FWE and the Cloud Control and Data Plane.
Since all the communication between the device and the cloud occurs over a secure MQTT connection, this library uses the AWS IoT Device SDK for C++ v2 as an MQTT client. It creates exactly one connection to the MQTT broker.
This library then publishes the data snapshot through that connection (through a dedicated MQTT topic) and subscribes to the Scheme and decoder manifest topic (dedicated MQTT topic) for eventual updates. On the subscribe side, this library notifies the rest of the system on the arrival of an update of either the Scheme or the decoder manifests, which are enacted accordant in near real time.
Execution Management Library
This library implements the bootstrap sequence of FWE. It parses the provided configuration and ensures that are the above libraries are provided with their corresponding settings. During shutdown, it ensures that all the modules and corresponding system resources (threads, loggers, and sockets) are stopped/closed properly.
If there is no connectivity, or during shutdown of the service , this library persists the data snapshots that are queued for sending to the cloud. Upon re-connection, this library will attempt to send the data to the cloud. The persistency module in the BSP library ensures that the disk space is not exhausted, so this library just invokes the persistency module when it wants to read or write data to disk.
The SystemD service communicates directly with this library as it runs the main thread of the application.
FWE implements a concurrent and event-based multithreading system.
FWE defines four schemas that describe the communication with the Cloud Control and Data Plane services.
All the payloads exchanged between FWE and the cloud services are serialized in a Protobuff format.
FWE sends two artifacts with the Cloud services:
Check-in Information
This check-in information consists of data collection schemes and decoder manifest Amazon Resource Name (ARN) that are active in FWE at a given time point. This check-in message is send regularly at a configurable frequency to the cloud services. Refer to checkin.proto.
Data Snapshot Information
This message is send conditionally to the cloud data plane services once one or more inspection rule is met. Depending on the configuration of FWE, (e.g. send decoded and raw data), FWE sends one or more instance of this message in an MQTT packet to the cloud. Refer to vehicle_data.proto.
The Cloud Control plane services publish to FWE dedicated MQTT Topic the following two artifacts:
Decoder Manifest: This artifact describes the Vehicle Network Interfaces that the user defined. The description includes the semantics of each of the Network interface traffic to be inspected including the signal decoding rules. Refer to decoder_manifest.proto.
Collection Scheme: This artifact describes effectively the inspection rules, that FWE will apply on the network traffic it receives. Using the decoder manifest, the Inspection module will apply the rules defined in the collection schemes to generate data snapshots. Refer to collection_schemes.proto.
FWE requires a temporary disk location in order to persist and reload the documents it exchanges with the cloud services. The persistency operates on three types of documents:
The persistency module operates on a fixed/configurable maximum partition size. If there is no space left, the module does not persist the data.
Persisted data is uploaded once on the bootup. Upload will be repeated after interval that is set in the static configuration under ["staticConfig"]["persistency"]["persistencyUploadRetryIntervalMs"]. If this value is not set, upload will be retried only on the next bootup.
FWE defines a Logger interface and implements a standard output logging backend. The interface can be extended to support other logging backends if needed.
The logger interface defines the following severity levels :
/**
* @brief Severity levels
*/
enum class LogLevel
{
Trace,
Info,
Warning,
Error,
Off
};
Customers can set the System level logging severity externally via the software configuration file described below in the configuration section. Each log entry includes the following attributes:
[Thread: ID] [Time] [Level] [Filename:LineNumber] [Function()]: [Message]
| Category | Attributes | Description | DataType |
|---|---|---|---|
| canInterface | interfaceName | Interface name for CAN network | string |
| protocolName | Protocol used- CAN or CAN-FD | string | |
| protocolVersion | Protocol version used- 2.0A, 2.0B. | string | |
| interfaceId | Every CAN signal decoder is associated with a CAN network interface using a unique Id | string | |
| type | Specifies if the interface carries CAN or OBD signals over this channel, this will be CAN for a CAN network interface | string | |
| timestampType | Defines which timestamp type should be used: Software, Hardware or Polling. Default is Software. | string | |
| obdInterface | interfaceName | CAN Interface connected to OBD bus | string |
| obdStandard | OBD Standard (eg. J1979 or Enhanced (for advanced standards)) | string | |
| pidRequestIntervalSeconds | Interval used to schedule PID requests (in seconds) | integer | |
| dtcRequestIntervalSeconds | Interval used to schedule DTC requests (in seconds) | integer | |
| interfaceId | Every OBD signal decoder is associated with a OBD network interface using a unique Id | string | |
| type | Specifies if the interface carries CAN or OBD signals over this channel, this will be OBD for a OBD network interface | string | |
| bufferSizes | dtcBufferSize | Max size of the buffer shared between data collection module (Collection Engine) and Vehicle Data Consumer. This is a single producer single consumer buffer. | integer |
| decodedSignalsBufferSize | Max size of the buffer shared between data collection module (Collection Engine) and Vehicle Data Consumer for OBD and CAN signals. This buffer receives the raw packets from the Vehicle Data e.g. CAN bus and stores the decoded/filtered data according to the signal decoding information provided in decoder manifest. This is a multiple producer single consumer buffer. | integer | |
| rawCANFrameBufferSize | Max size of the buffer shared between Vehicle Data Consumer and data collection module (Collection Engine). This buffer stores raw CAN frames coming in from the CAN Bus. This is a lock-free multi-producer single consumer buffer. | integer | |
| threadIdleTimes | inspectionThreadIdleTimeMs | Sleep time for inspection engine thread if no new data is available (in milliseconds) | integer |
| socketCANThreadIdleTimeMs | Sleep time for CAN interface if no new data is available (in milliseconds) | integer | |
| canDecoderThreadIdleTimeMs | Sleep time for CAN decoder thread if no new data is available (in milliseconds) | integer | |
| persistency | persistencyPath | Local storage path to persist Collection Scheme, decoder manifest and data snapshot | string |
| persistencyPartitionMaxSize | Maximum size allocated for persistency (Bytes) | integer | |
| persistencyUploadRetryIntervalMs | Interval to wait before retrying to upload persisted signal data (in milliseconds). After successfully uploading, the persisted signal data will be cleared. Only signal data that could not be uploaded will be persisted. (in milliseconds) | integer | |
| internalParameters | readyToPublishDataBufferSize | Size of the buffer used for storing ready to publish, filtered data | integer |
| systemWideLogLevel | Sets logging level severity: Trace, Info, Warning, Error |
string | |
| logColor | Whether logs should be colored: Auto, Yes, No. Default to Auto, meaning FWE will try to detect whether colored output is supported (for example when connected to a tty) |
string | |
| maximumAwsSdkHeapMemoryBytes | The maximum size of AWS SDK heap memory | integer | |
| dataReductionProbabilityDisabled | Disables probability-based DDC (only for debug purpose) | boolean | |
| metricsCyclicPrintIntervalMs | Sets the interval in milliseconds how often the application metrics should be printed to stdout. Default 0 means never | string | |
| publishToCloudParameters | maxPublishMessageCount | Maximum messages that can be published to the cloud in one payload | integer |
| collectionSchemeManagementCheckinIntervalMs | Time interval between collection schemes checkins(in milliseconds) | integer | |
| mqttConnection | endpointUrl | AWS account's IoT device endpoint | string |
| connectionType | The connection module type, it can be iotCore or iotGreengrassV2 | string | |
| clientId | The ID that uniquely identifies this device in the AWS Region | string | |
| collectionSchemeListTopic | Topic for subscribing to Collection Scheme | string | |
| decoderManifestTopic | Topic for subscribing to Decoder Manifest | string | |
| canDataTopic | Topic for sending collected data to cloud | string | |
| checkinTopic | Topic for sending checkins to the cloud | string | |
| certificateFilename | The path to the device's certificate file (either certificateFilename or certificate must be provided) |
string | |
| privateKeyFilename | The path to the device's private key file (either privateKeyFilename or privateKey must be provided) |
string | |
| rootCAFilename | The path to the root CA certificate file (optional, either rootCAFilename or rootCA can be provided) |
string | |
| certificate | The path to the device's certificate file (either certificateFilename or certificate must be provided) |
string | |
| privateKey | The path to the device's private key file (either privateKeyFilename or privateKey must be provided) |
string | |
| rootCA | The path to the root CA certificate file (optional, either rootCAFilename or rootCA can be provided) |
string | |
| metricsUploadTopic | Topic used to upload application metrics in plain json. Only used if remoteProfilerDefaultValues section is configured |
string | |
| loggingUploadTopic | Topic used to upload log messages in plain json. Only used if remoteProfilerDefaultValues section is configured |
string | |
| remoteProfilerDefaultValues | loggingUploadLevelThreshold | Only log messages with this or higher severity will be uploaded | integer |
| metricsUploadIntervalMs | The interval in milliseconds to wait for uploading new values of all metrics | integer | |
| loggingUploadMaxWaitBeforeUploadMs | The maximum time in milliseconds to cache log messages before uploading them | string | |
| profilerPrefix | The prefix used to categorize the metrics and logs. Can be set unique per vehicle such as clientId or the same for all vehicles if metrics should be aggregated |
string |
FWE has been designed with security principles in mind. Security has been incorporated into four main domains:
FWE can be extended to invoke cryptography APIs to encrypt and decrypt the data as per the need.
FWE has been designed to be deployed in a non safety relevant in-vehicle domain/partition. Due to its use of dynamic memory allocation, this software is not suited for deployment on real time/lock step/safety cores.
You can use the cmake build option, FWE_SECURITY_COMPILE_FLAGS, to enable security-related compile
options when building the binary. Consult the compiler manual for the effect of each option in
./cmake/compiler_gcc.cmake. This flag is already enabled in the default
native compilation script and
cross compilation script for ARM64
Customers are encouraged to store key materials on hardware modules, such as hardware security module (HSM), Trusted Platform Modules (TPM), or other cryptographic elements. A HSM is a removable or external device that can generate, store, and manage RSA keys used in asymmetric encryption. A TPM is a cryptographic processor present on most commercial PCs and servers.
Please refer to AWS IoT Security Best Practices for recommended security best practices.
Please refer to Device Manufacturing and Provisioning with X.509 Certificates in AWS IoT Core for security recommendations on device manufacturing and provisioning.
Note: This is only a recommendation. You are responsible for protecting your system with proper security measures.
FWE has been developed for 64 bit architecture. It has been tested on both ARM and x86 multicore
based machines, with a Linux Kernel version of 5.4 and above. The kernel module for ISO-TP
(can-isotp) would need to be installed in addition for kernels below 5.10.
Contact AWS Support if you have any technical questions about FWE.
The following documents or websites provide more information about FWE.
此处可能存在不合适展示的内容，页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容，可点击提交进行申诉，我们将尽快为您处理。
马建仓 AI 助手