[SEO Subhead]
This Guidance helps agricultural companies obtain advanced analytics from connected assets and streamlines management of connected assets with custom relationships. Agricultural companies include companies that manufacture sensors and control systems on a variety of equipment including tractors, ethanol and bio-fuel production factories, soil probes, and more. AWS Connected Device Framework (CDF) and the CDF Asset Library can help agricultural companies manage connected agricultural equipment for more efficient and secure asset management that enhances device functionality and performance.
Please note: [Disclaimer]
Architecture Diagram
[Architecture diagram description]
Step 1
The first time an agricultural device connects to AWS IoT Core, the AWS Connected Device Framework (CDF) uses the Provisioning hook function built with AWS Lambda for just-in-time provisioning of the device.
Step 2
Upon initial device provisioning, the AWS IoT Core Provisioning hook function sends device properties to the CDF Asset Library Facade, built with Lambda.
Step 3
AWS IoT Device Management stores agricultural device property updates and forwards them to the Lambda CDF Asset Library Facade function.
Step 4
The Lambda CDF Asset Library Facade function transmits the connected device provisioning and property data to Amazon Neptune for storage and enhanced analytics.
Step 5
Amazon Cognito authenticates user access requests for connected device data and analytics.
Step 6
Authenticated user HTTPS requests are sent to Amazon API Gateway, which routes requests through the Lambda CDF Asset Library Facade function and to the Lambda Asset Library function and Neptune.
Step 7
Neptune returns authenticated query response data through CDF and API Gateway, which delivers the data to the user for enhanced graph analytics of connected devices.
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 Excellence
Amazon CloudWatch metrics allow you to monitor the state of API Gateway, Lambda functions, and the Neptune database. Using dashboards with CloudWatch, you can validate that the provisioning workflow, API, and Asset Library are all functioning correctly and within normal limits. You can establish AWS IoT Rules to report on devices experiencing issues to CloudWatch.
Additionally, AWS CloudFormation and AWS CodePipeline enable consistent delivery across different environments. Well-defined continuous integration, continuous delivery (CI/CD) processes also help ensure consistent delivery of changes to the API or Asset Library.
-
Security
AWS IoT Core provides features to manage device security and certificates and to publish alerts in case a device exhibits behavior indicative of an issue through AWS IoT Device Management. Amazon Cognito enables granular access to APIs and asset data by maintaining and validating appropriate claims. Amazon Virtual Private Cloud (Amazon VPC) security groups enable network isolation of asset data stored in Neptune.
-
Reliability
The AWS IoT Device SDK has built-in functionality to support non-client-side disconnect and queuing of plain Message Queuing Telemetry Transport (MQTT) operations in case of network failure. Lambda has built-in failure logic to automatically retry failed operations and a dead-letter queue (DLQ) capability to push failed operations to Amazon Simple Notification Service (Amazon SNS).
Neptune can store an unlimited amount of edges and vertices. By using serverless compute nodes, Neptune can also automatically adjust to query demand. Through Lambda, all compute in this Guidance is stateless and relies on Neptune to persist the system state.
-
Performance Efficiency
By using AWS IoT Core, Lambda and Neptune, the Guidance can scale up to handle the concurrent processing of potentially thousands of requests or scale down when there are no pending calls to process.
Additionally, Neptune is purpose-built for farm ontology (FO), which is graphical in nature, with each asset being related to many other assets. We use AWS IoT Core in this Guidance for device connectivity and data ingestion that can easily scale to a hundred thousand devices and millions of messages a month.
-
Cost Optimization
Neptune allows you to choose storage as standard and I/O-optimized to reduce cost for I/O intensive workloads. Neptune also uses compute nodes on demand and flexibility in storage and compute pricing models, providing an optimized cost and performance ratio for graphical data.
-
Sustainability
Lambda and Neptune with serverless nodes reduce wasted compute cycles by enabling you to use compute only as needed, so you can provision the exact amount of compute needed at any given moment. Since Lambda and Amazon Neptune Serverless are managed services, they leverage shared compute resources and variable demand to reduce overall compute capacity. This helps minimize the environmental impact of the Guidance workload.
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
[Title]
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.