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]
AWS IoT Greengrass streams enable ingestion from edge devices to AWS IoT Analytics for data processing and analysis.
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.
Apply ML to data with hosted Jupyter Notebooks. Build and deploy predictive maintenance models for edge inference with Amazon SageMaker.
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.
Geofence an area of interest in Amazon Location Service. Fleets send location coordinates captured through AWS IoT Core.
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.
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.
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.
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.
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.
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.
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.
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.
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.