[text]
This Guidance supports agriculture vehicle fleet management applications in the cloud. These applications track vehicle diagnostics and health, predict required maintenance, and provide recommendations to the farm fleet owners. With this architecture, you can automate your fleet, control your fleet from anywhere, and harness actionable data from your fleets. The architecture uses data from Internet of Things (IoT) sensors in addition to cameras at strategic locations and in assets such as tractors and combine harvesters. These assets are equipped with multiple sensors for monitoring environmental conditions and hazards while also detecting changes in farm operations.
Please note: [Disclaimer]
Architecture Diagram
[text]
Step 1
Third-party sensors send data such as environmental conditions and operations data through AWS IoT Greengrass and AWS Lambda with protocol compatibility.
Step 2
AWS IoT Greengrass streams enable ingestion from edge devices to AWS IoT Analytics for data processing and analysis.
Step 3
AWS IoT Analytics stores and enriches data for use in machine learning (ML) model building. Use custom Lambda functions to derive new attributes to classify the data.
Step 4
Analyze and visualize time-series data using Amazon QuickSight.
Step 5
Apply ML to data with hosted Jupyter Notebooks. Build and deploy predictive maintenance models for edge inference with Amazon SageMaker.
Step 6
AWS IoT Events monitors change events from IoT sensors and sends an image capture request back to edge devices through an AWS IoT Core Message Queuing Telemetry Transport (MQTT) topic.
Step 7
Upload images to Amazon Simple Storage Service (Amazon S3) through AWS IoT Greengrass streams. Lambda uses SageMaker to run images against models and optimize operations by detecting crop conditions, the state of physical assets, and obstacles.
Step 8
Geofence an area of interest in Amazon Location Service. Fleets send location coordinates captured through AWS IoT Core.
Step 9
Amazon EventBridge routes geofence events to predefined targets in near real time.
Step 10
Notify users through Amazon Simple Notification Service (Amazon SNS).
Step 1
Third-party sensors send data such as environmental conditions and operations data through AWS IoT Greengrass and AWS Lambda with protocol compatibility.
Step 2
AWS IoT Greengrass streams enable ingestion from edge devices to AWS IoT Analytics for data processing and analysis.
Step 3
AWS IoT Analytics stores and enriches data for use in machine learning (ML) model building. Use custom Lambda functions to derive new attributes to classify the data.
Step 4
Analyze and visualize time-series data using Amazon QuickSight.
Step 5
Apply ML to data with hosted Jupyter Notebooks. Build and deploy predictive maintenance models for edge inference with Amazon SageMaker.
Step 6
AWS IoT Events monitors change events from IoT sensors and sends an image capture request back to edge devices through an AWS IoT Core Message Queuing Telemetry Transport (MQTT) topic.
Step 7
Upload images to Amazon Simple Storage Service (Amazon S3) through AWS IoT Greengrass streams. Lambda uses SageMaker to run images against models and optimize operations by detecting crop conditions, the state of physical assets, and obstacles.
Step 8
Geofence an area of interest in Amazon Location Service. Fleets send location coordinates captured through AWS IoT Core.
Step 9
Amazon EventBridge routes geofence events to predefined targets in near real time.
Step 10
Notify users through Amazon Simple Notification Service (Amazon SNS).
Well-Architected Pillars
The AWS Well-Architected Framework helps you understand the pros and cons of the decisions you make when building systems in the cloud. The six pillars of the Framework allow you to learn architectural best practices for designing and operating reliable, secure, efficient, cost-effective, and sustainable systems. Using the AWS Well-Architected Tool, available at no charge in the AWS Management Console, you can review your workloads against these best practices by answering a set of questions for each pillar.
The architecture diagram above is an example of a Solution created with Well-Architected best practices in mind. To be fully Well-Architected, you should follow as many Well-Architected best practices as possible.
-
Operational ExcellenceRead the Operational Excellence whitepaper
To improve operational efficiency, we recommend enabling logging to Amazon CloudWatch for each AWS service. We also recommend configuring alarms and event notifications and establishing different subscriptions to events through Amazon SNS. Additionally, you can establish Rules for AWS IoT to report on devices experiencing issues logging to CloudWatch. CloudWatch logs enable the user to understand system performance and if business outcomes are being achieved through successful end-user content consumption.
-
SecurityRead the Security whitepaper
AWS IoT Core, AWS IoT Device Management, and AWS IoT Device Defender provide features to manage device security, manage certificates, and publish alerts if a device exhibits behavior that indicates an issue. In this Guidance, customers should follow best practices when setting access requirements using AWS Identity and Access Management (IAM), including least-privilege access, password and key rotation, service control policies, and automated alerting.
Authorization for AWS IoT Core devices is managed through permissions using IAM policies. AWS IoT connected devices support the HTTPS and WebSockets protocol. For requests sent to AWS IoT Core, you can choose to have requests authenticated using IAM or Amazon Cognito, both of which support the AWS SigV4 authentication. For customers implementing HTTPS requests, devices can also be authenticated using X.509 certificates. MQTT messages to AWS IoT Core are authenticated using X.509 certificates. Devices must authenticate using X.509 certificates or the AWS Cognito service.
-
ReliabilityRead the Reliability whitepaper
AWS IoT Device software development kits (SDKs) have built-in functionality to support non-client-side disconnect and queuing of plain MQTT operations in case of network failure. The AWS IoT Device Shadow service provides a reliable data store for devices, apps, and the AWS Cloud services to share data. The shadow manager component enables AWS IoT Greengrass to sync local device shadow states with AWS IoT Core so that app running on an IoT device can still communicate with AWS IoT and the device's shadows when a device goes offline.
Stream Manager can batch data feeds when there is a network failure and can automatically forward information when connectivity is restored. This means you can continue to accept data even when remote locations lose internet connectivity.
-
Performance EfficiencyRead the Performance Efficiency whitepaper
The Guidance will scale serverless and managed services components as needed. It will scale services up to handle the concurrent processing of potentially thousands of requests or scale down during times when there are no pending calls to process.
-
Cost OptimizationRead the Cost Optimization whitepaper
This architecture uses AWS IoT Greengrass ML Inference to perform ML inference locally on AWS IoT Greengrass devices using models that are built and trained in the cloud. AWS IoT Greengrass includes support for Lambda for local processing. Together, these features minimize the cost of transmitting data to the cloud.
-
SustainabilityRead the Sustainability whitepaper
This Guidance incorporates serverless technologies for receiving, processing, and storing data. Serverless services support dynamic scaling, which minimizes the environmental impact of the backend services.
Implementation Resources
A detailed guide is provided to experiment and use within your AWS account. Each stage of building the Guidance, including deployment, usage, and cleanup, is examined to prepare it for deployment.
The sample code is a starting point. It is industry validated, prescriptive but not definitive, and a peek under the hood to help you begin.
Related Content
Fleet Management Solutions for Connected Farms
Disclaimer
The sample code; software libraries; command line tools; proofs of concept; templates; or other related technology (including any of the foregoing that are provided by our personnel) is provided to you as AWS Content under the AWS Customer Agreement, or the relevant written agreement between you and AWS (whichever applies). You should not use this AWS Content in your production accounts, or on production or other critical data. You are responsible for testing, securing, and optimizing the AWS Content, such as sample code, as appropriate for production grade use based on your specific quality control practices and standards. Deploying AWS Content may incur AWS charges for creating or using AWS chargeable resources, such as running Amazon EC2 instances or using Amazon S3 storage.
References to third-party services or organizations in this Guidance do not imply an endorsement, sponsorship, or affiliation between Amazon or AWS and the third party. Guidance from AWS is a technical starting point, and you can customize your integration with third-party services when you deploy the architecture.